Live data from Hacker News

CSS is unnecessary given a layout language

pchiusano.github.io

141–150 of 183 posts

Re: CSS is unnecessary given a layout language

#141

Earlier quoted context omitted.

Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with ta…

The root of the problem has little to do with either technology: it's related to the desire to cart application chrome around with documents, using a technology that was designed to render documents -- and documents only. At a fundamental level, what's missing is the ability to add a link rel=chrome tag in a document's header, such that you'd only sends a header with a title, that link rel=chrome tag, and its content…

The chrome (nav, footer, etc.) that you mentioned is one part of the equation, but the other part is styling/layout of the content itself. That is, within a page that features chrome, there is still the need to layout other elements of the page.

So, CSS fails miserably at the latter. And, ironically, the former (i.e. chrome) can largely be handled very cleanly via other means (e.g. a templating system that modularizes the chrome and content elements).

In any event, what you're saying is true to a large extent. It is not ideal to cart around data with presentation, so it is tempting to impose some degree of additional separation by some technology.

But, the challenge is that it doesn't tend to match the real world. That is, the idea that there are or should be these agnostic HTML documents lying around filled with, effectively, unstructured data is more myth than anything. The unstructured data is in the database or elsewhere. What you're generally doing is taking all of that raw content and presenting it. That's how it ends up in HTML. And, the truth is that HTML is really a presentation language more than a document/data language. If you want the latter, then you'd move up a level to "pure" XML. But, the same problem exists: now you really do have raw content akin to DB data, so how do you now impose a visual layout on that data?

So, here, I would argue that the separation has largely occurred before you get to HTML, thus it is OK to use HTML's more intuitive layout capabilities to layout the document.

Attempting to instead remove it from the HTML is simply adding an abstraction. And, honestly, we haven't decoupled anything. We've just moved it to an interdependent, less intuitive document that must now be carted around too.

So, while CSS is onerous for layout, I think the motivation behind relocating layout responsibility must also be scrutinized. Even if a less onerous CSS replacement existed, the cost of separation must really be weighed against what is actually being gained.

Re: CSS is unnecessary given a layout language

#143

CSS is broken. I've just been watching a colleague learning HTML/CSS for the first time. HTML was easy and she has a very good handle on that, producing some nice HTML5 markup by hand very quickly. CSS has been a nightmare - mostly not because of selectors or values (that comes later), but because of basic layout issues caused by the nasty hacky layout model of CSS - in particular the concepts of floats, block and in…

Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with ta…

"Not only that, the resulting table-based design HTML was an intuitive read."

Wow, Stockholm syndrome can be really messy.

It's likely possible to produce readable table-based design, but the tools at the time most assuredly did NOT produce that. Nothing sucks like spending a couple hours figuring out which of the eleventy-billion inline-styled cells Dreamweaver has bumped to 2px too wide, shattering an entire image-sliced layout.

Re: CSS is unnecessary given a layout language

#144

In Servo we've been able to get a lot of parallelism out of the basic building blocks of CSS. Any replacement would have to have a good story here. "Just write your layout in JS" is not good enough and would be a large performance regression.

Constraints based system is the way to go. And yes, it should be native replacement for CSS- a DOM property called constraints instead of style. Unfortunately, JS has to be used for now. [1] As for parallelism, we still have web workers for the solving of constraints computations. http://gridstylesheets.org [1]

> As for parallelism, we still have web workers for the solving of constraints computations.

I am confident that the lack of shared memory, along with the heavyweight nature of web workers, means that any attempt to use web workers to perform parallel layout will be slower than sequential.

Re: CSS is unnecessary given a layout language

#145

Earlier quoted context omitted.

Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with ta…

The root of the problem has little to do with either technology: it's related to the desire to cart application chrome around with documents, using a technology that was designed to render documents -- and documents only. At a fundamental level, what's missing is the ability to add a link rel=chrome tag in a document's header, such that you'd only sends a header with a title, that link rel=chrome tag, and its content…

Said another way...

>a level of abstraction is still missing in the web developer's toolkit.

As CS people we kind of intuitively feel this, but I'm not sure we really are missing anything, because, basically, HTML is already at the presentation layer. Remember when the proposed solution was to use XSLT to transform XML into HTML? Terrible as that was, the motivation behind it was a nod to the fact that XML is data and HTML is presentation.

So, I also wouldn't agree that mixing chrome and content together in HTML documents was a compensation as much as simply using HTML for its purpose. The content actually starts elsewhere (XML,database, etc.). It ends up in HTML for the very purpose of presentation.

There are ways to separate out chrome and modularize it that can use pure HTML. That makes sense. But, I don't think we really need another tech, language, or abstraction.

Now, we have added CSS to further abstract and LESS on top if that for still more abstraction. It can go on ad infinitum, but at some point, we are losing value with each additional abstraction.

Re: CSS is unnecessary given a layout language

#146

Earlier quoted context omitted.

Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with ta…

"Not only that, the resulting table-based design HTML was an intuitive read." Wow, Stockholm syndrome can be really messy. It's likely possible to produce readable table-based design, but the tools at the time most assuredly did NOT produce that. Nothing sucks like spending a couple hours figuring out which of the eleventy-billion inline-styled cells Dreamweaver has bumped to 2px too wide, shattering an entire image-…

If you're talking Dreamweaver, auto-generated inline styles, and image slicing, I think it's safe to say that you're signing up for pain irrespective of what the output is.

Still, finding a 2px misalignment would likely be a more masochistic exercise if you were wading through nested divs with no clear grid layout vs. nested tables.

But, I think your complaint is with the tool itself. Maybe that's why I sincerely know of no web devs who have implemented a serious project with Dreamweaver. My personal (brief) experience with it was that any support for real separation of concerns was so lacking that whether it generated tables vs. CSS was the least of my worries.

Re: CSS is unnecessary given a layout language

#148
post #93
post #51

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 c…

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 declara…

> 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.

Re: CSS is unnecessary given a layout language

#149
"It’s true that in using a language like Elm for layout, one loses the ability to cut and paste random CSS found on Stack Overflow in cargo-cult fashion without understanding what it does. I consider this limitation a feature."

Wow, elitist much?

Re: CSS is unnecessary given a layout language

#150
post #91

Earlier quoted context omitted.

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, b…

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). [1] http://en.wikipedia.o…

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].

[1] https://www.cs.washington.edu/research/constraints/cassowary...

[2] https://developer.apple.com/library/ios/documentation/userex...

[3] http://gridstylesheets.org/

Post reply on HN