3 ms·

CSS files are in a league in their own for how badly they represent the state of my app. In no other data structure would we say "oh sure, lets arbitrarily name

CSS files are in a league in their own for how badly they represent the state of my app. In no other data structure would we say "oh sure, lets arbitrarily name groups of key/value pairs in a nested hierarchy that may or may not match where they are applied. Also, its a global namespace so let's preface every name with our application name". At scale, CSS classes are really difficult to find when looking at your component and have ambiguous naming and nesting patterns. They shouldn't exist. Styled-components solves all these problems, randomly generating CSS classes under the hood, while still creating CSS files for you. Check out https://www.styled-components.com/docs/basics#motivation https://www.styled-components.com/docs/basics#motivation. I'm not sure I can be sympathetic to "the final HTML DOM output" matching your expectations here. Think about a Dropdown select. We still need to create a library with a bunch of absolutely positioned <div>s here because you literally can't build a good looking dropdown with normal HTML. It's really hard for me to think fondly of HTML/CSS when all they provide is assembly-code level specification. Flexbox and Grid are great counter-examples here. Still no nice looking dropdown.

danShumway 7y ago
> because you literally can't build a good looking dropdown with normal HTML. I want to push back against this in particular, not only because I think it does HTML/CSS a disservice, but because I've maintained codebases that took this approach and they're really bad to work with. You're trading a little bit of CSS annoyance for constant positioning/z-index errors -- and you'll need to update your positions whenever your page scrolls or a component grows... there are just so many ways for this to go wrong, and there's always an edge case that developers miss. Nothing is absolute, but most of the time the proper way to do something like a custom dropdown selector or tooltip is to semantically group it with the component it's attached to, and then at most absolute-position one element to center it relative to its parent. <div class="Input"> <input class="Input__Field"> <ul class="Input__Options Input__Options--hidden"> <li>Option One</li> <li>Option Two</li> </ul> </div> .Input { position: relative; } .Input__Options { position: absolute; /* etc */ } .Input__Options--hidden { display: none; } I don't like everything about CSS, there are a number of problematic design choices in the language -- particularly specificity. I also wouldn't necessarily be against a new primitive for scoping CSS to specific DOM trees. But annoyances aside, overall CSS is pretty great, and on net the apps I maintain that make heavy use of CSS are easier to maintain and less buggy than the apps I work on that try to use JS code to accomplish the same tasks. Obviously that's anecdotal. Again, this doesn't mean you can't compose your CSS in JS. But separation of concerns is not for you. The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. When you spit out HTML and CSS, you are spitting out an application interface. You're really worried about where you write your CSS, and I couldn't care less. I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.
zzo38computer 7y ago
> because you literally can't build a good looking dropdown with normal HTML. I disagree. Build a drop down field using the normal form field elements; it is up to the browser to render them in a suitable way. (Which way is suitable may depend on details which the author is unaware of.) > The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. ... I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector. That I agree. Let the user to override/ignore the styles, or to use them without changing if that is what the user wish.

danShumway 7y ago

> because you literally can't build a good looking dropdown with normal HTML. I want to push back against this in particular, not only because I think it does HTML/CSS a disservice, but because I've maintained codebases that took this approach and they're really bad to work with. You're trading a little bit of CSS annoyance for constant positioning/z-index errors -- and you'll need to update your positions whenever your page scrolls or a component grows... there are just so many ways for this to go wrong, and there's always an edge case that developers miss. Nothing is absolute, but most of the time the proper way to do something like a custom dropdown selector or tooltip is to semantically group it with the component it's attached to, and then at most absolute-position one element to center it relative to its parent. <div class="Input"> <input class="Input__Field"> <ul class="Input__Options Input__Options--hidden"> <li>Option One</li> <li>Option Two</li> </ul> </div> .Input { position: relative; } .Input__Options { position: absolute; /* etc */ } .Input__Options--hidden { display: none; } I don't like everything about CSS, there are a number of problematic design choices in the language -- particularly specificity. I also wouldn't necessarily be against a new primitive for scoping CSS to specific DOM trees. But annoyances aside, overall CSS is pretty great, and on net the apps I maintain that make heavy use of CSS are easier to maintain and less buggy than the apps I work on that try to use JS code to accomplish the same tasks. Obviously that's anecdotal. Again, this doesn't mean you can't compose your CSS in JS. But separation of concerns is not for you. The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. When you spit out HTML and CSS, you are spitting out an application interface. You're really worried about where you write your CSS, and I couldn't care less. I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.

zzo38computer 7y ago

> because you literally can't build a good looking dropdown with normal HTML. I disagree. Build a drop down field using the normal form field elements; it is up to the browser to render them in a suitable way. (Which way is suitable may depend on details which the author is unaware of.) > The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. ... I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector. That I agree. Let the user to override/ignore the styles, or to use them without changing if that is what the user wish.