good good but are there really websites with 2 or more variously different designs for the same content, like Zen Garden did?
Light theme and dark theme?
I'd say mobile and desktop (from same html) would be more like css zen garden, than light/dark.
The CSS Zen Garden dream, finally shipped
61–70 of 117 posts
Re: The CSS Zen Garden dream, finally shipped
#62Earlier quoted context omitted.
The dream was that you could separate content from presentation and content could be adapted and reinterpreted by anyone using whatever tools they choose: User Agents that actually respected the users' vision, not the publishers'.
And accessibility. The posts above claiming design and content are inextricably linked are probably blessed with all the standard senses. As usual it's a bunch of folks talking past each other. Style and content together is a nice simplification when you want to conform to a particular vision. Separation is a nice abstraction if you want to enable multiple views of the same content (like a pdf version or a colorblind…
I think that's an original issue though.
Accessibility certainly requires a content-first approach, I agree with you there. If you view each part of an application solely in terms of what it looks like to a sighted user, it's easy to miss the subtleties of what the underlying structure ought to be.
But when you start layering on the presentation, you're still generally binding that presentation layer tightly to the current content. If you, for example, were to restructure the links in the Zen Garden footer for some reason, most of the styles would break because they're bound to the current structure of the content. The separation you talk about only exists in one direction.
By comparison, when I talk about separation and decoupling in terms of code, I mean that there is a single, explicit, and tight API that acts as a clear boundary between two units. By explicit, I mean that I've designed the units specifically so that they expose this API - this is almost exactly the opposite of what I should be doing with content and presentation, as you point out! By tight, I mean that the API is as minimal as I can make it - two units interacting via an API need to understand nothing of each other except that API, and that API is as small as possible.
None of that is happening when it comes to the interaction between content and presentation. The content is not explicit - I'm actively trying to write the content for the design, which precludes making it an explicit API surface. Nor is the content tight - again, I want to build the content without worrying about how I will layer the design on top, and I don't want to limit myself to just a small surface area here.
So to me, it makes sense to see the content and presentation as being coupled together, even if that coupling ideally goes in one direction only. And if two systems are coupled together, it makes sense to do that explicitly by co-locating those systems. Therefore, I tend to prefer systems like Tailwind that let me apply the presentation layer directly in the content layer. (In practice, I mostly prefer other tools that still let me write real CSS syntax, but Tailwind is pretty damn convenient a lot of the time.)
As an aside, talking about accessibility, I'd forgotten how inaccessible some of the Zen Garden designs are with their addition of extra content in the presentation layer alone.
Re: The CSS Zen Garden dream, finally shipped
#63> There’s one honest footnote. nails on a chalkboard. when will agents stop writing like this
Using slop constructs to convey intricacies about beautiful design is the purest form of anti-design.
Re: The CSS Zen Garden dream, finally shipped
#64The CSS Zen Garden worked because everyone was using a single markup file. In real life, it doesn't really work. Instead of thinking of separation of concerns as a religious principle, think about what benefits it actually yields in the case of HTML. When the markup is completely separated from its styling, this means that the CSS rules need a way to be mapped onto the DOM. This involves specific elements, organized…
> Tailwind looks ugly, but there are no hidden abstractions or structures in the code Verily, Tailwind is the assembly language of CSS. No structure, no semantics, no abstractions, only twiddling specific bits of visual representation. To turn to it is to admit that your product lacks the structure and the design vision that allow to use some abstraction ("semantic classes"), and that all you can usually do is to pat…
This seems like a radical, unsupported conclusion to draw from a single frontend architecture decision.
Maybe there's an overwhelmingly positive case to be made for high-abstraction CSS with hidden structures. Outside those few select cases, we've known the tradeoffs for 25 years, and the added complexity is rarely worth it.
Re: The CSS Zen Garden dream, finally shipped
#65Earlier quoted context omitted.
The dream was that you could separate content from presentation and content could be adapted and reinterpreted by anyone using whatever tools they choose: User Agents that actually respected the users' vision, not the publishers'.
And accessibility. The posts above claiming design and content are inextricably linked are probably blessed with all the standard senses. As usual it's a bunch of folks talking past each other. Style and content together is a nice simplification when you want to conform to a particular vision. Separation is a nice abstraction if you want to enable multiple views of the same content (like a pdf version or a colorblind…
Except HTML is already a presentational markup language. People lose track of this.
Consider: MathML has a presentational schema and a content schema. The whole point of presentational MathML is the intermingling of concerns. If you want interoperable data, you use content MathML.
Interoperability is a noble goal, but if you want HTML to do everything you're already barking up the wrong tree.
Re: The CSS Zen Garden dream, finally shipped
#66> There’s one honest footnote. nails on a chalkboard. when will agents stop writing like this
That's where I stopped reading.
Re: The CSS Zen Garden dream, finally shipped
#67The CSS Zen Garden worked because everyone was using a single markup file. In real life, it doesn't really work. Instead of thinking of separation of concerns as a religious principle, think about what benefits it actually yields in the case of HTML. When the markup is completely separated from its styling, this means that the CSS rules need a way to be mapped onto the DOM. This involves specific elements, organized…
> The CSS Zen Garden worked because everyone was using a single markup file. In real life, it doesn't really work
The dream of the CSS Zen Garden never really extended beyond itself. That wasn't the point. The point was to show people "look at all these pages that look nothing like each other: they're all the same HTML." That was the magic.
Keep in mind the context: you still largely needed structural HTML to effect the layout of your page. Almost everybody was building with HTML where the markup was critical to the appearance. Frontpage, Dreamweaver, and every other tool generated almost no CSS—or at least no good CSS.
This isn't my interpretation. From the site itself:
> There is a continuing need to show the power of CSS. The Zen Garden aims to excite, inspire, and encourage participation. ... CSS allows complete and total control over the style of a hypertext document. The only way this can be illustrated in a way that gets people excited is by demonstrating what it can truly be, once the reins are placed in the hands of those able to create beauty from structure.
Re: The CSS Zen Garden dream, finally shipped
#68The postprocessor remains to fix some performance issue with @import? How does inlining imports fixes it? When I loaded the page, the font flickered. Perhaps the article isn't about font import, those better be in html headers or simply stick to system fonts.
CSS imports create a dependency tree of stylesheets. You can't render anything until all of the styles are loaded and parsed. Imports create a blocking serial dependency.
Re: The CSS Zen Garden dream, finally shipped
#69The current firefox.com is incredibly simple, though. It's also pretty tablet/phone centric (everything is so large on Desktop).
Yeah... I was trying to figure out what he was pointing to, and was like.. oh, the Firefox website... went there and was pretty uninspired by the design, at least in desktop.
Re: The CSS Zen Garden dream, finally shipped
#70Earlier quoted context omitted.
No, it's not disingenious. Tables _were_ accessible and easily navigable, including by screen readers. They are also a very logical way of organizing content. > One of the reasons we moved to XHTML, semantic markup, CSS instead of Tables... was to enable accessibility. Again, nope. Try a design with 3-4 columns with the old CSS and see how it behaves. The order of elements in the HTML often differs from the visual or…
I remember tables within tables within tables. Were those really accessible? The humans writing that html couldn't always keep it straight
Yes? What's problematic with nested tables? You just tab in and out of them.
Now try to navigate something like the WSJ/NYTimes home page.
If you remember the old days of good UI, there was this idea of "tab groups".