I also dont think you can cleanly separate HTML and style. Technically you can separate them but doing so in practice just handicaps your design and ability to express things in HTML and CSS (Zen Garden prohibiting css 3+ in most cases).

People have this idea that they should be decoupled. You can do that if you really contort them. Naturally, they are coupled.

The structure of HTML puts constraints on the style. You have to know about the style when writing HTML, even in this Zen Garden project. You can't escape the style and HTML understanding each other. If you have a compelling reason to make a broad range of styles swappable then OK - but you are constraining the design space considerably and there is usually no reason for this complexity and reduction in expressiveness.

The document and the style depend on eachother. You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).

This is why all UI paradigms tightly couple style and structure. QT, GTK, SwiftUI, Flutter, etc. Its the same with CSS/HTML except for people who delude themselves into thinking these were supposed to be loosely coupled.

▲

the_other 5 hours ago | parent | next [-]

> The document and the style depend on eachother.

I’d previously understood the relationship to be that the document could remain unchanged, whilst the style (including visual structure/layout) changed. The simplest canonical example is that you can change the font, and all the words and meaning remain unchanged.

> You see this with localization. You might need to change spacing or padding or breakpoints to accomodate different languages (text being different length in different languages).

This is a really intereting case. Strictly I’d say it was a different document, if the language has changed. Really good translations change idiom, which can change meaning, and words, at the level of ohraes, although the intent would be preserved.

But I’m nit-picking, being contrarian, or exploring the edges of your comment.

Today, many web documents are app GUIs. Each field is essentially the same “thing” regardless the languge of its label. And in that sense, these are the same document, and your point holds.

I still think that if you can keep the markup as minimal as possible (reduce the div nesting to just what’s require to mark up logical sections of the content), then you could make a good stab at Zen-gardening your design. It’s very hard to do, however.

▲

ForHackernews 6 hours ago | parent | prev | next [-]

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

▲

collingreen 3 hours ago | parent [-]

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 version or a vision impaired version) without having to change/control the content.

Like most things in this space, different tradeoffs make one better than the other in different scenarios. Taking a hard stance of "one true way" is probably missing some imagination or experience.

	▲	MrJohz 2 hours ago \| parent \| next [-]
		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.
	▲	vehemenz an hour ago \| parent \| prev [-]
		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.

▲

fragmede 7 hours ago | parent | prev [-]

Couple them how you want, HTML+CSS+JS is the system we've got, and it has to render well on mobile, tablet, and desktop. "deluded" and "supposed to be" are just word barriers that get in the way of doing shit that works.