Hacker News Reader

Comment by po | Hacker News Reader

I'm not sure where the myth of the web's separation of concerns first arose - possibly from some architecture astronaut who'd never written an element in their life, perhaps from someone who really knew better but needed to slip something past the mediocrity police

I'm pretty sure it came from CSS Zen Garden (http://www.csszengarden.com). The same HTML with dozens of different presentations all done exclusively with CSS changes. Don't get me wrong, I agree with you that for the most part the separation is a myth, but I personally remember before seeing CSS Zen Garden, the idea wasn't as common.

View on HN

It's hard to argue against the power of separating content from presentation when we can see the results with our own eyes in a couple clicks on Zen Garden. I have a hard time seeing how the disparaging title of "architecture astronaut" is warranted by it.

HTML and CSS has overlapping control over many properties on how a given document is rendered, so Zen Garden is more like “check out this Turing complete program written in CSS” — cute and interesting, but it is not practical as we can see from.. literally no real website doing anything remotely like that. This myth came from a time when we had markdown-level HTML markups, and it made sense back then: sure, why not let me color headers red? But it doesn’t scale as it simply doesn’t compose. That cascading part doesn’t make sense for many properties: should padding be inherited? It basically never makes sense. Components are the sane building blocks (as has been realized by desktop GUIs decades ago), and we are much better off with strong encapsulation here (shadow dom is a welcome change).

That power is only for the contrived example of doing a complete redesign that doesn’t change any of the html content. It’s like one of those demos people make of a CSS-only thingamajig that would be much easier to do any other technology. It makes for an interesting tech demo but isn’t practical for day-to-day development.

Templates, themeable products like WordPress, dark modes and alt accessibility presentations...

>That power is only for the contrived example of doing a complete redesign that doesn’t change any of the html content.

Didn't Github just re-style their whole UI? Presuming that's an extreme possibility seems like premature optimization unless you run Product.

That’s more like YAGNI.

The other comment made a good point about WP templates, I can only speak to my own experience. I have mostly worked on projects where I could edit the HTML, and in those cases using a Tailwind-like methodology was dramatically easier. Even when doing a full-site redesign.

So if you are designing for a project where you are unable to edit HTML, sure, use the right tools for the right. Or if the bulk of your coding time is spent doing full site redesigns instead of updates to an existing design, then it wouldn’t be the right approach. I wouldn’t use it on a project intended to be white-labelled, otherwise that’s the methodology I’d use.

I think the idea comes directly from timbl himself. Maybe he even got it from one of it the webs predecessors, like project Xanadu maybe. Certainly older than CSS Zen Garden (which is a brilliant project) and even older than CSS (which was the one of at least two style sheet languages that won).

The original idea was that the server provides the content and the consumer (browser) is responsible for presentation. In this thinking the separation of content and presentation makes total sense and the delineation is just a matter of practicality.

If the same party provides content and the presentation I find the distinction much harder to justify. Especially since there is no hard boundary (server pure content, consumer pure style) people will draw the line where it is convenient for them. What you inevitably will end up with is crossovers like in Tailwind.

That would make sense only in an alternative universe where HTML itself didn’t end up with styling-related functionality, but remained closer to its XML ancestry.

HTML was spawned from SGML and HTML predates XML. The only XML ancestry was later on when a couple of versions of HTML were rewritten to be based on XML (XHTML which was eventually abandoned), but even then it needed a lot of backwards compatible escape hatches, and was only valid XML with strict modes etc.

Reply on news.ycombinator.com