[danShumway]

I would strongly disagree with this, for two reasons.

1. Interfaces aren't special, the majority of application interfaces on my computer are just interactive documents, they're just styled to look like they're not. Outside of some specific examples (games, Blender, Krita, maps), I think very often if you can't sit down and describe an interface as pure text, something has gone wrong with your UX. And in fact, if you're interested in building genuinely accessible apps for low-vision users, it is a prerequisite that you be able to describe your interface using just text.

Most native apps are just interactive documents and forms.

2. The need to change presentation depending on context has gone up over time, not down. There's this theory that documents used to need to be flexible, but now we're all using interfaces where the data we're displaying should be tightly coupled to the interface and it just doesn't make sense given that screen sizes are far more diverse today (HDPI scaling is still a problem on Linux), phone sizes are more diverse, we have people using apps in hands-free settings, they're getting tied into personal assistants, we have more awareness now of accessibility concerns, devices like the Steam Deck exist.

Building polymorphic interfaces is more important today than it was 20 years ago when you could make 3 interfaces and just call it a day and assume you were supporting every device/control scheme. You didn't have people asking whether they could control your reader app with a gamecube controller.

And there are only two ways to build good polymorphic interfaces -- redesign multiple versions of the same interface, which doesn't scale and is guaranteed to leave uncommon and under-represented devices behind, or dive really hard into semantic[0] interfaces where you describe more precisely what data is rather than just what things look like.

The tight coupling of interfaces to presentation is usually bad for the end user and is usually unnecessary (in my opinion, based on the native desktop applications I commonly use). I often think that user interfaces would improve dramatically for everyone and our interfaces would be a lot easier to adapt to new computing interfaces and control schemes if we forced developers to build them with their monitors turned off, and then handed off the finished project to a separate team to make them look pretty.

----

I do agree with you on one point though:

> HTML wasn't designed for my ~modern assumption about what the document is. It was designed to be the document

HTML is at its best when it is not treated as a way to author interfaces, but rather as a render target in and of itself. A lot of design problems on the web stem from the fact that app developers view the pixels on the screen as their primary UX rather than as a secondary side-effect of their UX, which is HTML.

And I guess also to be fair, there is a valid critique here about the HTML "color" representing a mix of concerns. In some ways, HTML is kind of a flawed example of what we're trying to do. HTML was one iteration towards this idea of having user-facing data-driven interfaces. It's not necessarily perfect, it's just that it hasn't been supplanted (yet).

[0]: I understand you don't like the word (https://t-ravis.com/post/doc/semantic_the_8_letter_s-word/), but it's the best one to use here.

[abathur]

I think you would be strongly disagreeing with something I didn't say.

> Interfaces aren't special... if you can't sit down and describe an interface as pure text, something has gone wrong with your UX.

I'm not sure how this disagrees with anything I wrote. I am not even saying that defining an interface with xml is bad. I'm saying the interface of a website and the documents it contains are muddled.

> There's this theory that documents used to need to be flexible, but now we're all using interfaces where the data we're displaying should be tightly coupled to the interface and it just doesn't make sense given that screen sizes are far more diverse today (HDPI scaling is still a problem on Linux), phone sizes are more diverse, we have people using apps in hands-free settings, they're getting tied into personal assistants, we have more awareness now of accessibility concerns, devices like the Steam Deck exist.

I said literally nothing about tossing aside responsive/adaptive interfaces or designs.

I said that interface-html and interface-css are tightly coupled. This is already true. They already almost always evolve together. It is already exceedingly rare to see a web site/app fully redesign without changing html.

I don't think we're in disagreement.

I am talking about the document and interface's style and structure being entwined together because the tools were designed for something different than what they are mostly used for. I am saying component-oriented approaches are ~recognizing and trying to rectify this mismatch (and people using Tailwind are reacting to a real deficiency in the core technologies).

[danShumway]

Apologies for reading more into your article than it was trying to say. You're probably right that we're talking past each other a little bit. That being said:

> I'm saying the interface of a website and the documents it contains are muddled.

There is some truth to this, but it's overstated. I don't believe that the distinction between a website and a document is particularly clear on a conceptual level. Those things are muddled on the web because they are actually muddled in real life, there isn't a clear distinction between a document and an application -- and often it makes sense to treat them as the same thing.

> I said that interface-html and interface-css are tightly coupled. This is already true. They already almost always evolve together. It is already exceedingly rare to see a web site/app fully redesign without changing html.

I don't think this is particularly strong evidence either. Redesigns are large. I'd say an above-average number of site redesigns that I see involve changing the database layer too, that doesn't mean I'd encourage everyone to stop separating their database from their application logic.

A bigger thing here though is that this feels opposite to me to how I think about HTML. HTML in your app should be more likely to change than your CSS, not the other way around. HTML is your user interface. When you do a site redesign, you change what data you present to the user and how you present it. That's HTML. To me, this is like saying that splitting font display from UTF-8 characters is wrong because most of the time you revise a book it involves changing the characters, not just the font.

Incidentally if you redesign a website you will also often change the style, but... the style is secondary. I love the CSS garden stuff, I love how it got people thinking about separation of concerns, but it also encouraged people to think of HTML as if it's this extremely static interface that we apply a manifold of styles to, and that's usually incorrect.

So sure, of course HTML and CSS often change in parallel, but... so?

----

> I am saying component-oriented approaches are ~recognizing and trying to rectify this mismatch (and people using Tailwind are reacting to a real deficiency in the core technologies).

This is another thing where I feel like there must be something I'm missing because if you said this in isolation without mentioning Tailwind, I think I'd agree with it. I do agree that using semantic tags in CSS is bad for maintainability. I do agree that CSS has downsides, and I do think it should almost always be used in a component-oriented fashion.

But I've used Tailwind for a little while now (maybe not heavily enough, I don't know?) -- I don't think Tailwind is very component-oriented. It's component-oriented in the strictest sense that you put styles on a component. But it doesn't encourage building logical units of style, it doesn't encourage reuse, it doesn't encourage structuring of style, it makes it harder to look at the output and understand where a style is coming from or what part of the code set it.

You can have that stuff with Tailwind, but Tailwind doesn't seem to be helping with it, and most of the time that I see Tailwind it makes it harder to reason about the style of the app in a structured way. Most of the time I see Tailwind it's just attached directly to HTML like an inline style. And if I came to you and said I was going to stop using functions and just inline all of my code, you wouldn't characterize that as "component-based programming".

Honestly, if we're talking about component-based interfaces, Tailwind-based interfaces feel a lot more like early JQuery interfaces than they feel like React or Vue. Forget separation of style and layout, I don't think Tailwind encourages the use of components at all.

At least to me -- again, I know a bunch of people love it, I keep thinking there must be something I'm missing. But in practice, every Tailwind app I hack on makes it harder for me to couple CSS to a JS component.

[abathur]

> Apologies for reading more into your article than it was trying to say.

<3 (Nothing wrong with reading in, but thanks nonetheless.)

> You're probably right that we're talking past each other ... I don't believe that the distinction between a website and a document is particularly clear on a conceptual level. Those things are muddled on the web because they are actually muddled in real life, there isn't a clear distinction between a document and an application -- and often it makes sense to treat them as the same thing.

Part of the trouble here is that document is an overloaded term (there's a reason why the linked post has a full section on what is and isn't the document). You may be disagreeing with where I'm choosing to draw the lines here, and that's... okay. I suspect this is mostly coming down to perspective.

Categorizing isn't my natural mode. The world is a mess of gray, and a single language closing over both interfaces and documents is necessarily so.

(At the risk of projecting...) I get the sense you're seeing this from something like the context of what I called the "html-concrete document". From that perspective it's mostly unclear what bits are an interface and what bits are documents (and whether there's one document or N of them, etc.). They're all already muddled in the concrete document. (If you step up to considering several html-concrete documents on the same site, I guess you could use template induction to work towards understanding.)

The perspective I'm coming at this from is concerned with how we can author marked-up documents to maximize reusability. This perspective is concerned with, as the post said, "the one closest to the document in the eyes of the author" which I called "an abstract-document". I think this is conceptually clear (but it may not be clear to anyone but the author).

> So sure, of course HTML and CSS often change in parallel, but... so?

I didn't say it was a problem that they change in parallel--just that this change is a sign that the interface-html and interface-css are already tightly coupled. I'm not arguing for more or less coupling between them, but pointing out that a fraction of the global html/css/js namespaces are comprised of tightly-coupled code structure/style/behavior that comprise "the interface" (as the interface designer sees it) almost certainly co-mingled with structure/style/behavior for stuff that isn't the interface (where they can all unintentionally clash).

> This is another thing where I feel like there must be something I'm missing because if you said this in isolation without mentioning Tailwind, I think I'd agree with it.

These are separate ideas (hence the aside). I'm not arguing that Tailwind is component oriented. The component folks, and the Tailwind folks, and the BEM folks (and many more folks trying different things!) are all reacting to problems caused by the status quo separation of concerns. The component folks are more directly trying to rectify the mismatch, but they're all still patching around deficiencies in the stack.

> I've used Tailwind for a little while now (maybe not heavily enough, I don't know?) -- I don't think Tailwind is very component-oriented. It's component-oriented in the strictest sense that you put styles on a component. But it doesn't encourage building logical units of style, it doesn't encourage reuse, it doesn't encourage structuring of style, it makes it harder to look at the output and understand where a style is coming from or what part of the code set it.

I could probably clarify that I find the Tailwind style a bit revolting, and set about writing the linked piece in part to dunk on it (among others). In the process of pulling things apart to understand them, though, I felt like I could see the problems it's reacting against. It's a ~reasonable way to make lemonade, even if I don't like it.

> Most of the time I see Tailwind it's just attached directly to HTML like an inline style.

This is both a thing I personally find revolting about Tailwind, and a big part of the value/leverage I think Tailwind users are reaching for.

> And if I came to you and said I was going to stop using functions and just inline all of my code, you wouldn't characterize that as "component-based programming".

Maybe reframing this function/inline analogy a bit will help clarify?

If you showed me a 2000-line function, I'd ask the obvious question about why you didn't abstract it out into multiple units with meaningful names.

But if you responded by explaining that this code was destined for a global namespace where there was a real risk of code written by others also defining/overwriting/wrapping the identifiers you chose, we'd end up having a similar conversation about the ways around. You could hand-namespace all of the identifiers and make human reviewers keep up. You could introduce tooling to namespace identifiers to avoid clashes. You could try to engineer in stronger component boundaries. You could indeed choose to inline as much as possible.

I would say I'm not a huge fan of the inlining approach because it's a mess to read, but if you countered that you were extremely confident that the code was stuffed with implementation quirks so tightly coupled to something in the stack that it would almost certainly not be reusable elsewhere and would almost certainly be faster to rewrite from scratch than understand and refactor... I wouldn't call you crazy.

[kaba0]

Thank you for this discussion and article, both were an interesting read!

One tiny criticism regarding the article: I was hoping you would actually color code the HTML code samples visually, I believe it would have aided understanding better. You could have even used a more realistic/concrete sample as well.

[abathur]

Thanks for the kind words :)

In 2021 I prototyped some documentation single-sourcing tools. I made leaps fueled by intuition and years of frustration, so I found it hard to explain to others what I did and why.

In early 2022 I started sketching this post as ~intellectual-groundwork on the ~motivating problems I saw in existing markup languages. What I hoped would be a few weeks stretched into several months of drafts I wasn't happy with.

Trying to write one _coherent_ motivating post made it clear just how many iterative intuitive leaps I'd made along the way, so I started splitting out asides/sections into posts to make incremental progress and show my math. (The linked post is currently the most-recent of 6 on documentation at https://t-ravis.com/room/doc/; the other 5 have seeds in it.)

Color-coding the examples was indeed on the to-do list from early on, but after starting over a few times and still feeling unsure it would communicate, I got frustrated enough (exacerbated by unrelated ~burnout) to just shove it out the door and turn to other fires for a while. (Part of why I haven't made a follow-up post, even though I intend to.) It's been better received than I feared, so it probably makes sense to go back and improve those when I start the next post in the series.

(You can see where it falls in the rough outline of the broader intellectual project at https://t-ravis.com/post/doc/the_trouble_with_anonymous_gizm...)