The trouble with allowing a procedural language for styling is that all you can do with it is run it. PostScript and PDF work that way, which is why doing anything other than printing those formats,is very tough. Copying text from PDF barely works. It's an output-only format.
I wanted a constraint-type system. A is above B, B is to the left of C, D is below A and B. Something like that. All declarative, handled by a constraint solver. Any serious parametric CAD system has that. Usually with more features than you need for web layout, like the ability to handle curves.
Funnily enough Apple's UI toolkits (both macOS's AppKit and iOS's UIKit) use Cassowary constraint solvers under the hood. There was also a startup a while back (The Grid, I think?) that was trying to use it as the basis of a web design platform. No clue if they ever shipped anything but I remember seeing their source release for the constraint solver and thinking, "Man, if calculating layout in JavaScript wasn't a total jankfest for end-users I'd totally use this".
Cassowary was suggested to w3c in 1999 IIRC, but was rejected. Even though the concerns are understandable at the time (processing requirements), it's still a sad development.
I guess you're talking about GSS, which works fine, but I haven't seen any mention of it on the internets until this. What bugs me most is that we're stuck with what browsers provide, and they not gonna do display: cassowary; or display: kiwi; no matter how loud you cry for something a little more sane than a bunch of css crutches glued together.
Oh, that looks so promising that just glancing over that page and seeing a request/allocate cycle felt like a breath of fresh air (well, good old fresh). Thanks for sharing!
That makes sense for GUI systems. If you have lots of elements with alignment constraints, a constraint solver is the right tool for the job. 20 years ago, they were obscure pieces of software, though, and rather alien to people who were thinking "word processor".
280 North did this with Cappuccino and their Atlas tool (which has unfortunately been swallowed up and forgotten after the company was acquired by Motorola).
Alan Kay always said the web should be rendered by itself, but it seems like it would have been a terrible idea. The transition to tablets using alternate widgets (for selection boxes, etc.), gpu acceleration, and many other things would have been way harder to shoehorn in in something that was rasterizing itself.
Not quite. Flash and Shockwave were centrally controlled systems. What Kay probably had in mind, as you can read in Personal Dynamic Media, is all the GUI object frantically sending messages back and forth and aligning themselves.
You still see that now and then, with things like chat bubbles in 3D worlds maneuvering themselves to get clear of other chat bubbles and such as viewpoints change and characters move. But for more static general layout, no.
there are definitely positives about html and being declarative for sure...at least in the beginning... but looking at the complex beasts that web browsers have become now (maintaining/optimizing js, decades of backwards compatibility etc) it seems in the end, only google and apple can fund them (microsoft throwing in the towel, mozillas recent cutbacks)... im not sure this is what we originally wanted from the web...
as you say though, self rendering pages would need an api to provide accessibility, and also html is much easier to grok than bytecodes (developer accessibility)
Funny you mention that. I'm currently in the process of creating a declarative language specifically for UI designers. The goal is to let them describe interfaces in a platform-agnostic pseudo-ish code, and it's all based on parametric constraints exactly as you described.
I wanted a constraint-type system. A is above B, B is to the left of C, D is below A and B. Something like that. All declarative, handled by a constraint solver. Any serious parametric CAD system has that. Usually with more features than you need for web layout, like the ability to handle curves.