3 ms·

When pages get complicated, you're going to start having issues in targeting these elements unless you only ever have exactly 1 single design for each element,

When pages get complicated, you're going to start having issues in targeting these elements unless you only ever have exactly 1 single design for each element, no matter where it is. What happens if you want a different styled buttons? What happens if you put <button> inside different tags or different order? What happens if you need to change a single <button> specifically? The complexity of cascading rules and specificity and HTML structure is what makes the reality so different than this ideal. But if you can really keep everything flat with simple modifier classes, then that's exactly what Tailwinds already does for you.

rglullis 6y ago
> you're going to start having issues in targeting these elements unless you only ever have exactly 1 single design for each element, no matter where it is. My example shows precisely how untrue that is. The buttons got different styles without having to change anything in the html structure. > What happens if you put <button> inside different tags? Then you define the corresponding rule. With SASS that is almost too easy. Also, don't forget that the C in CSS means cascading. > different order? display:grid, grid-template and even position:absolute if you need. Do you think it will be too repetitve? Make a SASS mixin that defines these for you. Not only you're still keeping CSS separate from the HTML structure, it will very likely work in the same way that all of those "pull-x" and "push-y" rules are doing anyway. > single <button> specifically? I am not against using classes and ids that define purpose and even state (for the odd case where the attributes are not enough/non-existent). What I am against is the definition classes that are mapped to the presentation. You can have a <button class="critical-action-trigger"> all you want, but please do not make <button class="size-huge red">. Likewise, if the "fire all nukes" button is so special, it deserves to be represented with <button id="fire-all-nukes">. > then that's exactly what Tailwinds already does for you. I said above. If tailwind was only providing a bunch of utlity mixins and variables that I could then @import to my SASS, I would understand. What I don't understand and do not want is to have classes that I am supposed to be writing inside the HTML. The reason that I don't want that is not out of "purity", but rather because this lack of separation of concerns is leading us to a sub-optimal solution and forcing every frontend developer to reinvent component libraries every time they want to do something that is non-standard. If we had a 100% style-free "standard" component library and the CSS designers focused only on implementing their design languages against that standard, the chances of us getting a more paretto-efficient basis for frontend development would grow immensely. Nowadays, every frontend developer either needs to do everything on their own or hope that there is already a combination of JS component library + design language that is acceptable. If we had my way, everyone could then start their application with the standard components, pick any design language that claimed to implement the rules for the standard components and customize only the relevant parts. Everyone's 80% of the job would be mostly done.
- mercer 6y ago
  > Then you define the corresponding rule. With SASS that is almost too easy. Also, don't forget that the C in CSS means cascading. Over the lifetime of projects 'cascading' always led to headaches. There's a reason the whole BEM thing became a thing. > Do you think it will be too repetitve? Make a SASS mixin that defines these for you. Not only you're still keeping CSS separate from the HTML structure, it will very likely work in the same way that all of those "pull-x" and "push-y" rules are doing anyway. I used to do all that. Still do for some projects that rely heavily on SASS. But using mixins and functions and extends and whatnot adds complexity that I honestly feel I can't justify anymore. /Why/ do I want to keep CSS separate from HTML when in practice they tend to end up entangled anyways. It just reeks or cargo-culting 'separation of concerns' where really it's just 'separation of technologies that are separate for historical reasons'. > I am not against using classes and ids that define purpose and even state (for the odd case where the attributes are not enough/non-existent). What I am against is the definition classes that are mapped to the presentation. You can have a <button class="critical-action-trigger"> all you want, but please do not make <button class="size-huge red">. But why? Other than 'this is the way it has always been and I refuse to change my mind'? > I said above. If tailwind was only providing a bunch of utlity mixins and variables that I could then @import to my SASS, I would understand. What I don't understand and do not want is to have classes that I am supposed to be writing inside the HTML. Because it works. And it's measurably easier to do, in the experience I and many others have. And because I still can't find a good argument not to. > If we had a 100% style-free "standard" component library and the CSS designers focused only on implementing their design languages against that standard, the chances of us getting a more paretto-efficient basis for frontend development would grow immensely. I do agree with this, I think. But day to day it's not going to happen. When someone comes up with a popular style-free standard, assuming that's practically possible and good enough to become popular, I'd happily switch to that. > Nowadays, every frontend developer either needs to do everything on their own or hope that there is already a combination of JS component library + design language that is acceptable. If we had my way, everyone could then start their application with the standard components, pick any design language that claimed to implement the rules for the standard components and customize only the relevant parts. Everyone's 80% of the job would be mostly done. Yes, but honestly by that logic we could dismiss any improvement and argue for some kind of ideal where HTML and CSS are not used for app development in the first place. But that's just not the reality we live in.

rglullis 6y ago

> you're going to start having issues in targeting these elements unless you only ever have exactly 1 single design for each element, no matter where it is. My example shows precisely how untrue that is. The buttons got different styles without having to change anything in the html structure. > What happens if you put <button> inside different tags? Then you define the corresponding rule. With SASS that is almost too easy. Also, don't forget that the C in CSS means cascading. > different order? display:grid, grid-template and even position:absolute if you need. Do you think it will be too repetitve? Make a SASS mixin that defines these for you. Not only you're still keeping CSS separate from the HTML structure, it will very likely work in the same way that all of those "pull-x" and "push-y" rules are doing anyway. > single <button> specifically? I am not against using classes and ids that define purpose and even state (for the odd case where the attributes are not enough/non-existent). What I am against is the definition classes that are mapped to the presentation. You can have a <button class="critical-action-trigger"> all you want, but please do not make <button class="size-huge red">. Likewise, if the "fire all nukes" button is so special, it deserves to be represented with <button id="fire-all-nukes">. > then that's exactly what Tailwinds already does for you. I said above. If tailwind was only providing a bunch of utlity mixins and variables that I could then @import to my SASS, I would understand. What I don't understand and do not want is to have classes that I am supposed to be writing inside the HTML. The reason that I don't want that is not out of "purity", but rather because this lack of separation of concerns is leading us to a sub-optimal solution and forcing every frontend developer to reinvent component libraries every time they want to do something that is non-standard. If we had a 100% style-free "standard" component library and the CSS designers focused only on implementing their design languages against that standard, the chances of us getting a more paretto-efficient basis for frontend development would grow immensely. Nowadays, every frontend developer either needs to do everything on their own or hope that there is already a combination of JS component library + design language that is acceptable. If we had my way, everyone could then start their application with the standard components, pick any design language that claimed to implement the rules for the standard components and customize only the relevant parts. Everyone's 80% of the job would be mostly done.

mercer 6y ago
> Then you define the corresponding rule. With SASS that is almost too easy. Also, don't forget that the C in CSS means cascading. Over the lifetime of projects 'cascading' always led to headaches. There's a reason the whole BEM thing became a thing. > Do you think it will be too repetitve? Make a SASS mixin that defines these for you. Not only you're still keeping CSS separate from the HTML structure, it will very likely work in the same way that all of those "pull-x" and "push-y" rules are doing anyway. I used to do all that. Still do for some projects that rely heavily on SASS. But using mixins and functions and extends and whatnot adds complexity that I honestly feel I can't justify anymore. /Why/ do I want to keep CSS separate from HTML when in practice they tend to end up entangled anyways. It just reeks or cargo-culting 'separation of concerns' where really it's just 'separation of technologies that are separate for historical reasons'. > I am not against using classes and ids that define purpose and even state (for the odd case where the attributes are not enough/non-existent). What I am against is the definition classes that are mapped to the presentation. You can have a <button class="critical-action-trigger"> all you want, but please do not make <button class="size-huge red">. But why? Other than 'this is the way it has always been and I refuse to change my mind'? > I said above. If tailwind was only providing a bunch of utlity mixins and variables that I could then @import to my SASS, I would understand. What I don't understand and do not want is to have classes that I am supposed to be writing inside the HTML. Because it works. And it's measurably easier to do, in the experience I and many others have. And because I still can't find a good argument not to. > If we had a 100% style-free "standard" component library and the CSS designers focused only on implementing their design languages against that standard, the chances of us getting a more paretto-efficient basis for frontend development would grow immensely. I do agree with this, I think. But day to day it's not going to happen. When someone comes up with a popular style-free standard, assuming that's practically possible and good enough to become popular, I'd happily switch to that. > Nowadays, every frontend developer either needs to do everything on their own or hope that there is already a combination of JS component library + design language that is acceptable. If we had my way, everyone could then start their application with the standard components, pick any design language that claimed to implement the rules for the standard components and customize only the relevant parts. Everyone's 80% of the job would be mostly done. Yes, but honestly by that logic we could dismiss any improvement and argue for some kind of ideal where HTML and CSS are not used for app development in the first place. But that's just not the reality we live in.