4 ms·

The article name describes Tailwind exactly for me. I personally am a fan of schematic html/css. I remember the days off CSS Zen Garden, with well marked up ht

The article name describes Tailwind exactly for me. I personally am a fan of schematic html/css. I remember the days off CSS Zen Garden, with well marked up html you can change the visual look completely by swapping out the style sheet. There’s a nice decoupling layer, it’s flexible, it’s conceptually simple, it works. Despite all that I find myself using Tailwind. I’m not a frontend/designer expert, Tailwind goes against what I believe makes good HTML, Tailwind is ugly to me, polluting classes with markup. It’s equivalent to the embedding inline styles anti pattern. However in an imperfect world it works surprisingly well for visual styling on large projects, with many teams and components and just as well in small single page sites. The perfectionist in me says it’s horrible, the I can’t be bothered with frontend design in me says it’s so much less effort and avoids styling conflicts from multiple style sheets/components and I don’t care if it’s ugly or against the ethos of good html.

abathur 3y ago
The discomfort is because html and css were misabstracted. They were designed for the old world of documents, where the idea of restyling a bunch of documents for a new letterhead (etc.) makes a lot of sense. They've been adapted for the world of interface design, but the separation of concerns doesn't make sense in that axis. It makes sense for the content of a document to be separate from it's style. It doesn't make as much sense to separate the structure of an interface from it's style. (In practice they are almost always tightly coupled.) Tailwind is flattening these back down into roughly one layer from the author's perspective, where they make sense for the design work. (I wrote a bit more about this perspective in https://t-ravis.com/post/doc/what_color_is_your_markup/ https://t-ravis.com/post/doc/what_color_is_your_markup/)
- danShumway 3y ago
  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/ https://t-ravis.com/post/doc/semantic_the_8_letter_s-word/), but it's the best one to use here.
  - abathur 3y ago
    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 3y ago
      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.
- imbnwa 3y ago
  So what really what we want is to bring back presentation attributes full-force, a la SVG, for contexts where the page is not expected to be printed? Do I have that right?
  - abathur 3y ago
    I don't mean to prescribe anything that specific (lest anyone reject the diagnosis because they don't like the prescription). I think people are using Tailwind in roughly a presentation-attribute way in order to claw back some of the combinatorial complexity that comes from letting conceptually-distinct components share a namespace. I don't mean that stylesheets are a bad/wrong way to express style for interfaces, nor that we don't want a separate DSL for expressing style. Web components are a meaningful gesture at better ways to manage the problem, but you still need a decent chunk of JS to take advantage. (If you must, imagining how native HTML + CSS could support expressing components with well-controlled encapsulation/boundaries might give you a better sense of where I'd try to start if this was suddenly my problem to solve.)
dimmke 3y ago
I adopted Tailwind but I did it in I think a way that would make the creator of Tailwind crazy. But it’s for a project only I work on, so meh. I’ve found that even with components that can do their own scoping, it becomes easier to use a semantic class name. Because I’ll create a component, and then later want to use it in a different way I didn’t originally consider. If you don’t have a semantic class name applying overrides becomes difficult. What I end up doing is designing things in browser, because it’s so quick. And then I slowly abstract it out into a class with @apply rules, but I have my own way that I like to group them. So like one line will be for typography, one will be for layout. It’s so much less verbose than regular CSS I find it really easy to read and change quickly. But I also know CSS really well, so I can quickly scan the shorthand and understand exactly what it’s doing. Tailwind is the first time I’ve ever willingly used a CSS framework because it just clicks for me, but I don’t use it the way it’s “meant” to be used. Also the defaults for things like text sizing etc… help keep me standardized somewhat. It reduces the number of options and in a good 70% of cases prevents me from spending hours obsessively changing the first or second decimal point of a number and trying to decide if something looks better being 1 pixel to the left (or sometimes a half or quarter pixel ) So if you have OCD, consider Tailwind!
- afiori 3y ago
  IMHO the secret of tailwind is that it is not really a CSS framework, it is a different way to author CSS. The only real difference is that you do not use >, +, or *
  - dimmke 3y ago
    I think it’s an interesting question - what should the goal of a CSS “framework” be? Because in the past, CSS struggled with achieving basic common layouts without using hacks. That’s why Bootstrap and its grid system were so popular. But that’s not an issue anymore. Tailwind doesn’t hide much behind abstractions. So many times as a programmer, I’ve been forced to adopt tooling that promises to make something easier, only to have issues with the tooling, or it having its own learning curve etc… outweigh any benefit. Tailwind is just easy, and it’s the first time I’ve encountered something that actually rewards underlying knowledge instead of trying to prevent the user from needing it.

abathur 3y ago

The discomfort is because html and css were misabstracted. They were designed for the old world of documents, where the idea of restyling a bunch of documents for a new letterhead (etc.) makes a lot of sense. They've been adapted for the world of interface design, but the separation of concerns doesn't make sense in that axis. It makes sense for the content of a document to be separate from it's style. It doesn't make as much sense to separate the structure of an interface from it's style. (In practice they are almost always tightly coupled.) Tailwind is flattening these back down into roughly one layer from the author's perspective, where they make sense for the design work. (I wrote a bit more about this perspective in https://t-ravis.com/post/doc/what_color_is_your_markup/ https://t-ravis.com/post/doc/what_color_is_your_markup/)

danShumway 3y ago
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/ https://t-ravis.com/post/doc/semantic_the_8_letter_s-word/), but it's the best one to use here.
- abathur 3y ago
  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 3y ago
    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.
imbnwa 3y ago
So what really what we want is to bring back presentation attributes full-force, a la SVG, for contexts where the page is not expected to be printed? Do I have that right?
- abathur 3y ago
  I don't mean to prescribe anything that specific (lest anyone reject the diagnosis because they don't like the prescription). I think people are using Tailwind in roughly a presentation-attribute way in order to claw back some of the combinatorial complexity that comes from letting conceptually-distinct components share a namespace. I don't mean that stylesheets are a bad/wrong way to express style for interfaces, nor that we don't want a separate DSL for expressing style. Web components are a meaningful gesture at better ways to manage the problem, but you still need a decent chunk of JS to take advantage. (If you must, imagining how native HTML + CSS could support expressing components with well-controlled encapsulation/boundaries might give you a better sense of where I'd try to start if this was suddenly my problem to solve.)

dimmke 3y ago

I adopted Tailwind but I did it in I think a way that would make the creator of Tailwind crazy. But it’s for a project only I work on, so meh. I’ve found that even with components that can do their own scoping, it becomes easier to use a semantic class name. Because I’ll create a component, and then later want to use it in a different way I didn’t originally consider. If you don’t have a semantic class name applying overrides becomes difficult. What I end up doing is designing things in browser, because it’s so quick. And then I slowly abstract it out into a class with @apply rules, but I have my own way that I like to group them. So like one line will be for typography, one will be for layout. It’s so much less verbose than regular CSS I find it really easy to read and change quickly. But I also know CSS really well, so I can quickly scan the shorthand and understand exactly what it’s doing. Tailwind is the first time I’ve ever willingly used a CSS framework because it just clicks for me, but I don’t use it the way it’s “meant” to be used. Also the defaults for things like text sizing etc… help keep me standardized somewhat. It reduces the number of options and in a good 70% of cases prevents me from spending hours obsessively changing the first or second decimal point of a number and trying to decide if something looks better being 1 pixel to the left (or sometimes a half or quarter pixel ) So if you have OCD, consider Tailwind!

afiori 3y ago
IMHO the secret of tailwind is that it is not really a CSS framework, it is a different way to author CSS. The only real difference is that you do not use >, +, or *
- dimmke 3y ago
  I think it’s an interesting question - what should the goal of a CSS “framework” be? Because in the past, CSS struggled with achieving basic common layouts without using hacks. That’s why Bootstrap and its grid system were so popular. But that’s not an issue anymore. Tailwind doesn’t hide much behind abstractions. So many times as a programmer, I’ve been forced to adopt tooling that promises to make something easier, only to have issues with the tooling, or it having its own learning curve etc… outweigh any benefit. Tailwind is just easy, and it’s the first time I’ve encountered something that actually rewards underlying knowledge instead of trying to prevent the user from needing it.