If clojurians were to redesign html/css/js/ the browser experience... i wonder what that would look like.
a clojure-based browser 😄
wasn't the initial idea for javascript to be scheme?
Yes. JavaScript is scheme with an object system borrowed from Self and a syntax borrowed from Java
Eich’s original scripting language was in fact Scheme but management told him not to be silly and to try again
On fosdem 2020 there was a talk about nyxt-browser (called next back then). a browser built in common lisp. (https://github.com/atlas-engineer/nyxt) The engine is pluggable (Blink / Webkit allowed), looked pretty interesting. Obivously just an UI though (not re-imagining html/js/css 😛)
https://archive.fosdem.org/2020/schedule/event/next_web_browser/ here's the talk
also; yes. I was at the 2020 talk; but since there was another talk too it seems 🙂
On the subject of css, I'd really like something new and better to come along. Then I won't be fighting with issues like this: Why is it moving! W.T.A.F
looks like you got something changing the window height slightly to put the vertical scrollbar on right side.
It was working when I had stuff lower on the page. I had stuff I had to scroll down to see, I removed that. ANd now everything twitches
yeah because the scrollbar was always present
You're right, so I need to now make one of the top three boxes smaller
but i dont understand, how is the vertical scrollbar being triggered?
dunno without seeing the page, perhaps have an element that's resizing itself by 1px
can take a quick look at it if you want if you have a link
ive pushed it to my git live page thing https://stuartstein777.github.io/ It twitches, but if you hit parse then play, it twitches even worse!
I think I'm just going to move the output box to the bottom row
yeah not getting the issue on my mac, and i'm pretty sure if you resize your window just slightly to reduce the height it won't happen to you either. can check on my pc when i get back home
@qmstuart Even if moving the output box fixes it for you, the issue will still remain. Someone with a different screen size may hit it. It is perfectly fine if you are the only one using it though.
Does anyone have any links/resources for what an ideal, clojure based layout library might look like? (no relation to html/css required)
"Grid Systems in graphic design by Joseph Müller-Brockmann" sounds awesome
I bet it's some dynamic css causing it, loading then unloading. I don't think this is actually something that's just CSS's problem, similar issues can arise in any context.
sounds like asking for an ideal framework
I guess ideal isn't the right adjective, but any ideas for a cohesive, thoughtful approach. I think iOS is based on the https://constraints.cs.washington.edu/cassowary/. SwiftUI has some interesting ideas.
CSS is apparently a descendant from "let's make a magazine on the screen" and has things like "float" and "clear" because it assumes a "flow" to the "page"
backwards compatibility with CSS is non-goal
I see, that makes way more sense to me, said it that way, thank you
I recently read Grid Systems in graphic design by Joseph Müller-Brockmann which was really interesting. It's the kind of approach I would be interested in, but it only covers static print. It doesn't really cover dynamic UI (it's from 1981)
not exactly Clojure, but https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/ looked interesting when I checked it long time ago
facebook’s yoga is a layout engine that implements flexbox cross-platform
@sova every time, if possible. Flex is quite amazing to be honest :)
Hmm I'll have to put some time into learning what the heck it is.
it is related but not exactly compatible with web’s flexbox
seems interesting. Is there any sort of background on why things are the way they are? Like a rationale or first principles approach? I've been slowly reading through different design systems which is the closest analog I can find.
As an example, I think "Grid Systems in graphic design" by Joseph Müller-Brockmann is the type of thing I'm looking for, but for computer UIs rather than print
this talk is really interesting so far, https://www.youtube.com/watch?v=Ie-gqwSHQr0. thanks for the pointer!
I don't know anything off hand but flexbox seems to be something that a lot of time and effort went into. I'm sure there's resources out there that goes into the background and rationale of its design
Looking at the https://annairish.github.io/historicizing/history, it seems like it was derived from Mozilla's XUL. I didn't realize flexbox originated in 2008. This is the closest resource I could find to anything that might resemble a problem statement or rationale: http://mb.eschew.org/2 The design examples are pretty great, http://mb.eschew.org/figures/figure2.7.jpg
So interestingly enough, Apple’s UI frameworks have used constraint-based systems for a long time and devs hate it. They’re now moving away from it with SwiftUI. I was all gung-ho on ccss and gss before I played around with the Apple version a little and I kind of get it: when the tool you have is CSS you often run into problems that feel like they’d be easier to solve with a constraint-based system, but when the tool you have is a constraint-based system, you just want the overconstrainted/underconstrained errors to go away
Does that include designer sentiment? I think one issue that could use more work is being more thoughtful about the hand off between designers and programmers. It's hard to tell if the issue with constraints is the tooling, workflow issues between programmers and designers, or some combination of other factors.
Just browsing the layout options in SwiftUI, it seems like it's mostly VStacks and HStacks which is reasonable from a programmer perspective, but it kind of already assumes that the paddings, frames, etc. have already been worked out by a designer. It doesn't seem to try to encode or build on top of any design system. The intended workflow seems different compared to the Interface builder approach where you could theoretically have a designer fully layout the UI and the programmer just hooks up actions.