4 ms·

HTML and CSS are inseparable. Or at least, CSS can't do anything without the proper references in HTML anyway. And you're likely using IDs and classes already

HTML and CSS are inseparable. Or at least, CSS can't do anything without the proper references in HTML anyway. And you're likely using IDs and classes already to target, so instead of typing the name in HTML and the styles in a stylesheet, why not just condense into typing the style as a class name in the HTML? This carries you pretty far while you can still customize as necessary. I do skip tailwinds when I'm not working in a component framework since I can type less verbose CSS, or if there's a complex situation that needs more control.

rglullis 6y ago
> why not just condense into typing the style as a class name in the HTML? Because the style may change, but the underlying data won't. I know that nowadays everyone default architecture is to have data coming from some json API and that will have to be processed and rendered in the client anyway - but it is not just because something is the common case that it is the only case. By looking at the discussions, I am starting to realize that most of the people that are okay with mixing HTML and CSS have only to work with one application to be worried about. If that is the case, then yes, it gets obvious why people want to treat everything as object code. Consider different scenarios, though. Think of how many APIs could've been avoided if we actually looked and said "HTML is data content and structure, and CSS is presentation, so why can't the HTML be the API? The microformats people have been clamoring for this for decades already, yet no one listens. How much fragmentation could be reduced if we had half-dozen frontend developers saying "we are going to build a JS component library that is strictly about behavior so that anyone can style however they want with CSS"? All of those man-hours wasted reinventing wheels just because there is an unnecessary coupling between component structure and styling, penny wise and pound foolish. It's almost as if companies don't want to have their data easily accessible outside of their own sites and if developers actually want to spend their time reconfiguring databases and creating ever-growing Rube Goldberg machines for their own fun and profit...
- manigandham 6y ago
  > "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.

rglullis 6y ago

> why not just condense into typing the style as a class name in the HTML? Because the style may change, but the underlying data won't. I know that nowadays everyone default architecture is to have data coming from some json API and that will have to be processed and rendered in the client anyway - but it is not just because something is the common case that it is the only case. By looking at the discussions, I am starting to realize that most of the people that are okay with mixing HTML and CSS have only to work with one application to be worried about. If that is the case, then yes, it gets obvious why people want to treat everything as object code. Consider different scenarios, though. Think of how many APIs could've been avoided if we actually looked and said "HTML is data content and structure, and CSS is presentation, so why can't the HTML be the API? The microformats people have been clamoring for this for decades already, yet no one listens. How much fragmentation could be reduced if we had half-dozen frontend developers saying "we are going to build a JS component library that is strictly about behavior so that anyone can style however they want with CSS"? All of those man-hours wasted reinventing wheels just because there is an unnecessary coupling between component structure and styling, penny wise and pound foolish. It's almost as if companies don't want to have their data easily accessible outside of their own sites and if developers actually want to spend their time reconfiguring databases and creating ever-growing Rube Goldberg machines for their own fun and profit...

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