Graphical layout is one of the most underestimated challenges in computer science. Programmers instinctively look at the problem and thing "oh, this is logical, I'll just whip up some basic principles and layout primitives and I'll have this solved in no time!"
No, you won't. Designing a layout framework is really, really hard. Designing one that is simultaneously expressive enough to handle all of the crazy corner cases that pop up on a daily basis AND simple enough to allow "normal people" to actually use and extend it is quite difficult. For example, the Android layout system is suitably expressive but totally mystifying to anyone who hasn't spent a year reading the source for View/ViewGroup/FrameLayout/ViewRootImpl.
The OP's suggestion that there is some singular, beautiful, composable layout system that we could drop in to replace CSS is, frankly, a pipe dream. Or rather, I would be far more convinced if he actually pointed to a spec or pre-existing system that we might base our new system off of [1].
I see only three real possibilities going forward, in order of increasing likelihood:
1. Someone does indeed come up with the One True Layout System (very unlikely).
2. We finally shove bytecode-level runtimes into a browser and let a thousand flowers bloom (even odds).
3. We keep incrementally improving CSS, adding support for various layout relationships that people need (probably).
[1] Elm's system looks neat, but it's not there yet.
I used to work with whacky designers who would always come up with ideas that broke the layout system for whatever toolkit we were using, so I quickly "adapted" by using canvas and doing it all myself. To that end I created Bling:
The idea is that layout in WPF is so ridiculously complicated, yet data binding could be made so ridiculously simple (hey, they are almost constraints!), that it is often easy to just "do the math" for the layout you want rather than configuring a high-level layout component to do it. The same principles probably apply to ReactJS also (which provides a nice databinding system like WPF). Elm doesn't provide for constraints directly, I think (rather without behaviors, you'd have to compose various events to simulate them in an inelegant way, but please correct me if I'm wrong).
Have you used Qt's layouts? The problem with Android's layout system (if I understand it correctly) is that you specify how things are arranged relative to each other, so you never really know where something is. Added to that you have counter-intuitive behavior from things being calculated at time of addition rather than time of display (can't remember exactly, but I ran into something like that).
Qt is more declarative. I forget the function calls but in pseudocode you can do things like
horizLayout.add(Text("abc").setFixedWith(12));
horizLayout.add(Text("XYZ").setExpand().setAlign(kCentered));
horizLayout.add(Text("").setFixedWidth(12));
and you get something like:
[abc | XYZ | ]
(where [] is the width of the layout, and | separates each element.)
I've found it to be pretty intuitive.
> The problem with Android's layout system (if I understand it correctly) is that you specify how things are arranged relative to each other, so you never really know where something is.
RelativeLayout is just one of the several layouts you can use on Android. Typical Android GUI's are usually a mix of this one and a few others. This combination is very powerful and has been instrumental in making Android GUI's scale so well to many different devices with various resolutions and DPI's, a challenge that Apple will soon face.
Have you seen http://gridstylesheets.org/, which works as a polyfill and puts the Cassowary Constraint Solver behind CSS? It doesn't solve all CSS issues, but it's better than what I'm using today [1].
1. Someone _has_ come up with the One True Layout System. It's just that most people like to pretend TeX doesn't exist or, when they grok the box-and-glue layout model, try to reinvent it from scratch.
Someone yell at me if I'm wrong, but isn't TeX designed for paged content?
That means while TeX might work amazingly for paginated content, single page apps, or really any non-paginated content, is very much a screwdriver where a hammer should be used scenario.
Overall it is, but when the above commenter mentions box-and-glue, they're talking about the building blocks of the line breaking algorithm TeX uses (you can read about it in this paper: http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab... ). The box-and-glue system is a way of expressing a layout as an optimization problem (in the paper, they talk mostly about determining line breaks within a paragraph, but the idea of minimizing badness can be extended to determining page breaks as well). A bigger concern for me is the performance of laying out any reasonably complex page — the performance we get from rendering a reasonably complex webpage today is generally much better than rendering a reasonably complex LaTeX document.
I've come across a feature request for Firefox where someone proposed to use the Knuth Plass line breaking algorithm just for text layout, but they didn't get very much traction: https://bugzilla.mozilla.org/show_bug.cgi?id=630181
Are there any CSS replacement proposals that are based on linear programming [1]? There are a lot of things you cannot solve with just LP (e.g. rearranging floats on a page) but it's a pretty good -- and simple -- abstraction for laying out boxes relative to each other.
Solving LP is fast, especially when many of your constraints are equality constraints (as would be when specifying tables).
I think Cassowary [1] is what you're talking about (particularly section 1.2 where they talk about some modifications to make their system very fast for incremental updates). Apple has based their constraint-based layout system, Autolayout [2], on Cassowary. There's also a project that incorporates Cassowary constraints into a CSS-like declarative syntax called GSS [3].
does TeX have responsive layout with a variable document width? For the past year my ability to use CSS alone to convert an existing HTML Website and make it work on mobile has been putting food on my table. Could I be using TeX for the same thing?
In theory, yes. TeX basically outputs DVI. DVI is meant to be a 'DeVice-Independent' format, so someone could come up with a browser layout engine that implements it, thus giving Web pages TeX-like typography and layout quality.
Designing one that is simultaneously expressive enough to handle all of the crazy corner cases that pop up on a daily basis AND simple enough to allow "normal people" to actually use and extend it is quite difficult.
Erm, ... No and yes,
OK, take old problem in designing a system, demand that it solve "all of the crazy corner cases" and viola, you have a challenging, even unsolvable problem in computer science. Indeed, such problems are not even problems of computer science, they are problems of software engineering, of human relations and so-on.
Designing a layout system isn't a hard problem but it does involve tradeoff. Like many other system, if you shop around for something that's all things to all people and assign a vast committee to create it, you'll windup with a thing a best ugly and possibly unusable. But there's nothing too specific to designing layout systems here.
I absolutely agree that the main issue is that the system can't be improved by competing concepts.
The development model is really important - what started as a private hack became a designed-by-committee mess, and now is starting to become more sane in the age of HTML5, as new useful technologies and APIs are being added.
The big issue is CSS (and Javascript is only slowly becoming better), which stems from the designed-by-committee (with bad taste) era - if it was designed today with Google etc. at the table, it probably would be a lot better.
People try to work around that by using pre-compilers like LESS and CoffeeScript, but those cannot fix the underlying issues. If people could design their own CSS engines, the development model would allow for rapid iteration and whatever people like the best would see broad adoption.
Reminds me of the BPF packet filter bytecode - limited, but fast and secure.
A few websites manage to reimplement decent scrolling today, but I have yet to see scrolling that's better than standard behavior. This sounds like a move to have everyone use their own scrolling engine.
Maybe we are at a point where there are too many novice user to care about interoperability, but I'm a big fan of the fact that my browser understands the content it renders and that I can run plugins to manipulate it. I daily highlight text to search for it, drag non-marked-up url's to the URL bar to open said links, change page layout for easier reading, translate words as my curser point to them, etc, etc. all features that flash pages used to break and a "canvas/webGl" world would appear to break as well.
No, you won't. Designing a layout framework is really, really hard. Designing one that is simultaneously expressive enough to handle all of the crazy corner cases that pop up on a daily basis AND simple enough to allow "normal people" to actually use and extend it is quite difficult. For example, the Android layout system is suitably expressive but totally mystifying to anyone who hasn't spent a year reading the source for View/ViewGroup/FrameLayout/ViewRootImpl.
The OP's suggestion that there is some singular, beautiful, composable layout system that we could drop in to replace CSS is, frankly, a pipe dream. Or rather, I would be far more convinced if he actually pointed to a spec or pre-existing system that we might base our new system off of [1].
I see only three real possibilities going forward, in order of increasing likelihood:
1. Someone does indeed come up with the One True Layout System (very unlikely).
2. We finally shove bytecode-level runtimes into a browser and let a thousand flowers bloom (even odds).
3. We keep incrementally improving CSS, adding support for various layout relationships that people need (probably).
[1] Elm's system looks neat, but it's not there yet.