4 ms·

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

by po 3y ago

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

louzell 3y ago
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.
- kaba0 3y ago
  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).
- isleyaardvark 3y ago
  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.
  - Clamchop 3y ago
    Templates, themeable products like WordPress, dark modes and alt accessibility presentations...
  - imbnwa 3y ago
    >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.
    - isleyaardvark 3y ago
      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.
weinzierl 3y ago
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.
- kaba0 3y ago
  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.
  - antod 3y ago
    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.

by po 3y ago

louzell 3y ago

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.

kaba0 3y ago
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).
isleyaardvark 3y ago
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.
- Clamchop 3y ago
  Templates, themeable products like WordPress, dark modes and alt accessibility presentations...
- imbnwa 3y ago
  >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.
  - isleyaardvark 3y ago
    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.

weinzierl 3y ago

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.

kaba0 3y ago
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.
- antod 3y ago
  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.