6 ms·

> "Because the style may change, but the underlying data won't." What's the difference? It's the same typing, whether you create styles in CSS or just class na

> "Because the style may change, but the underlying data won't." What's the difference? It's the same typing, whether you create styles in CSS or just class names in the HTML. Designing the first time vs changing it later is the action. The rest of your comment seems to be ranting other issues. CSS can't be split, that's the point. It's been tried often but it just doesnt work in reality and is part of HTML which also covers presentation concerns. I don't see what JSON APIs have to do with this. It's not the most common case but it does actually mean you have an API to use without the presentation if you really want it, so isn't that exactly what you're asking for?

rglullis 6y ago
Let's make this discussion a bit more concrete. Take a look at https://news.ycombinator.com/item?id=25155424 https://news.ycombinator.com/item?id=25155424 and tell me where the CSS is inseparable from the HTML? Or where would one have to change the HTML structure if the designer decides to change the styling of the component/page? I am genuinely curious to get some feedback about it. I'm working on this project where I am dealing now with frontend stuff and I do want (need) to make it as easy as possible for others to integrate with their systems. If there is anything wrong with my approach I'd be very pleased to find out earlier than later.
- manigandham 6y ago
  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

rglullis 6y ago

Let's make this discussion a bit more concrete. Take a look at https://news.ycombinator.com/item?id=25155424 https://news.ycombinator.com/item?id=25155424 and tell me where the CSS is inseparable from the HTML? Or where would one have to change the HTML structure if the designer decides to change the styling of the component/page? I am genuinely curious to get some feedback about it. I'm working on this project where I am dealing now with frontend stuff and I do want (need) to make it as easy as possible for others to integrate with their systems. If there is anything wrong with my approach I'd be very pleased to find out earlier than later.

manigandham 6y ago
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