3 ms·

> Let’s take a break from all these principles and architectures, and remember that CSS is ultimately about implementing visual designs. I enjoyed the overview

> Let’s take a break from all these principles and architectures, and remember that CSS is ultimately about implementing visual designs. I enjoyed the overview (though the web component/shadow Dom bits others noted here would have been nice) but I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual designs. Much of the struggling we've seen over the decades is because the separations aren't aligned with how we're using them. It makes sense for documents to have separate stylesheets. It doesn't make sense to fragment the implementation of a layout across several files and complexly-interacting languages. This isn't really a fault of the article. I only just realized this in the past year myself and I've been writing html since the all caps era. I took a first swing at writing about this recently in: https://t-ravis.com/post/doc/what_color_is_your_markup/ https://t-ravis.com/post/doc/what_color_is_your_markup/

wwweston 4y ago
> I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual designs. I think that realization had solidly set-in throughout the industry by 2010 or so, and why so much effort over the most recent decade went into things that do lend themselves to an app-like focus such as native flexbox & grid capabilities, shadow dom, and even recent things like :has(). But personally... I think that "apps as documents" paradigm has actually worked out pretty brilliantly, even considering how squirrelly CSS can be. The inspectability of the UI layer is one of the reasons why the browser is so much more than the VM that lived, and HTML/CSS has so much flexibility that many native UI toolkits lack. It's not right for every situation, but for the common case I think there are reasons it's often what people reach for first.
- abathur 4y ago
  It's an incredibly flexible toolkit. Not calling it bad! It just isn't cut along the seams we'd cut it along if we were building it fresh. There's tons of evidence in the record-of-innovation that people are iterating around these problems--so I suspect there are plenty of people who have indeed internalized this to some degree. But I also see a lot of continual coverage that indicates this realization hasn't diffused. (I don't want to pretend to have invented the wheel, but for example I see the fights around semantic VS functional tailwind-style css as hinging on this. Functional css makes sense for layouts as it collapses pointless separation; semantic classes make sense for documents which are more likely to evolve or get restyled without new markup.)
TimTheTinker 4y ago
Jesse James Garrett (the early web luminary who coined the term "ajax") was already talking about the dual purposes of the web in the year 2000. He called them "Web as software interface" and "Web as hypertext system". In The Elements of User Experience (2000) he writes: "The Web was originally conceived as a hypertextual information space; but the development of increasingly sophisticated front- and back-end technologies has fostered its use as a remote software interface." [0] [0] http://www.jjg.net/elements/pdf/elements.pdf http://www.jjg.net/elements/pdf/elements.pdf

wwweston 4y ago

> I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual designs. I think that realization had solidly set-in throughout the industry by 2010 or so, and why so much effort over the most recent decade went into things that do lend themselves to an app-like focus such as native flexbox & grid capabilities, shadow dom, and even recent things like :has(). But personally... I think that "apps as documents" paradigm has actually worked out pretty brilliantly, even considering how squirrelly CSS can be. The inspectability of the UI layer is one of the reasons why the browser is so much more than the VM that lived, and HTML/CSS has so much flexibility that many native UI toolkits lack. It's not right for every situation, but for the common case I think there are reasons it's often what people reach for first.

abathur 4y ago
It's an incredibly flexible toolkit. Not calling it bad! It just isn't cut along the seams we'd cut it along if we were building it fresh. There's tons of evidence in the record-of-innovation that people are iterating around these problems--so I suspect there are plenty of people who have indeed internalized this to some degree. But I also see a lot of continual coverage that indicates this realization hasn't diffused. (I don't want to pretend to have invented the wheel, but for example I see the fights around semantic VS functional tailwind-style css as hinging on this. Functional css makes sense for layouts as it collapses pointless separation; semantic classes make sense for documents which are more likely to evolve or get restyled without new markup.)

TimTheTinker 4y ago

Jesse James Garrett (the early web luminary who coined the term "ajax") was already talking about the dual purposes of the web in the year 2000. He called them "Web as software interface" and "Web as hypertext system". In The Elements of User Experience (2000) he writes: "The Web was originally conceived as a hypertextual information space; but the development of increasingly sophisticated front- and back-end technologies has fostered its use as a remote software interface." [0] [0] http://www.jjg.net/elements/pdf/elements.pdf http://www.jjg.net/elements/pdf/elements.pdf