4 ms·

As someone coming to web development from iOS development, CSS is the only thing I've really been struggling with. I just have such a hard time working with a m

by m12k 9y ago

As someone coming to web development from iOS development, CSS is the only thing I've really been struggling with. I just have such a hard time working with a model where changes aggregate around so much, so changes intended for one place end up messing something up elsewhere. Maybe I'm just not using it right? To me it just seems much saner that components (and the styling thereoff) are by default completely isolated from each other and their parents and children, and styling is only shared where you explicitly request it. Maybe this is due to the historical roots, where CSS is intended to style documents rather than apps? Maybe it's in the same category as JavaScript in that it's easy to hack something together that sorta works, but it takes a lot more overview and discipline to create something sane and maintainable? And where there are a ton of online resources that are outdated or will teach you bad habits?

wwweston 9y ago
> changes intended for one place end up messing something up elsewhere. Maybe I'm just not using it right? CSS selectors allow you a really wide latitude in the applied scope of the styles you specify -- you can literally pick everything (with the asterisk selector), or you can pick only one thing (with an id selector). With an almost arbitrarily fine-grained set of possibilities in between. A project could take a component centered approach, with unique id and/or class names for every component and only using selectors that begin rooted with those id/class names (the unique names thing can be harder with a large team than it should be -- I've sometimes thought that rather than a CSS preprocessor, I could use a smart linter that can take some comment hints and manage problems like this better). Or you could moderate that a bit with a reasonable core set of global styles addressing typography and baseline margins/padding and a few layout concepts, and go component from there. And then follow two heuristics: when you find you're playing whack-a-mole, you probably do have too many overlapping broadly scoped styles. If you're repeating yourself over and over again (or even relying heavily on a preprocessor to repeat yourself), you might be better served by a more broadly scoped selector. If this doesn't describe your approach, maybe you are indeed just not using it right. :) (And welcome to the club, happens to all of us at some point). If this does describe your approach and it still hurts more than a bit, well, maybe it is indeed the fault of CSS.
pjmlp 9y ago
It is a pain alright. I still hope one day WebComponents will finally get us the sane native model on the Web. Until then I try to focus on native projects, when given the option.
naasking 9y ago
> I just have such a hard time working with a model where changes aggregate around so much, so changes intended for one place end up messing something up elsewhere. You're better off with functional/atomic css then, because the styles aren't cascading like css is typically used, which, while powerful, doesn't scale. As such, the classes defined in an atomic css framework are consistent and reusable everywhere. See for example, http://tachyons.io/ http://tachyons.io/ It maps much better to the programmer mindset, where we're typically generating dynamic content, and so generating the sets of style classes needed entails just using our usual code reuse techniques.
- m12k 9y ago
  Thank you for the tip - this does indeed seem to map much more to the way I tend to think.

by m12k 9y ago

wwweston 9y ago

> changes intended for one place end up messing something up elsewhere. Maybe I'm just not using it right? CSS selectors allow you a really wide latitude in the applied scope of the styles you specify -- you can literally pick everything (with the asterisk selector), or you can pick only one thing (with an id selector). With an almost arbitrarily fine-grained set of possibilities in between. A project could take a component centered approach, with unique id and/or class names for every component and only using selectors that begin rooted with those id/class names (the unique names thing can be harder with a large team than it should be -- I've sometimes thought that rather than a CSS preprocessor, I could use a smart linter that can take some comment hints and manage problems like this better). Or you could moderate that a bit with a reasonable core set of global styles addressing typography and baseline margins/padding and a few layout concepts, and go component from there. And then follow two heuristics: when you find you're playing whack-a-mole, you probably do have too many overlapping broadly scoped styles. If you're repeating yourself over and over again (or even relying heavily on a preprocessor to repeat yourself), you might be better served by a more broadly scoped selector. If this doesn't describe your approach, maybe you are indeed just not using it right. :) (And welcome to the club, happens to all of us at some point). If this does describe your approach and it still hurts more than a bit, well, maybe it is indeed the fault of CSS.

pjmlp 9y ago

It is a pain alright. I still hope one day WebComponents will finally get us the sane native model on the Web. Until then I try to focus on native projects, when given the option.

naasking 9y ago

> I just have such a hard time working with a model where changes aggregate around so much, so changes intended for one place end up messing something up elsewhere. You're better off with functional/atomic css then, because the styles aren't cascading like css is typically used, which, while powerful, doesn't scale. As such, the classes defined in an atomic css framework are consistent and reusable everywhere. See for example, http://tachyons.io/ http://tachyons.io/ It maps much better to the programmer mindset, where we're typically generating dynamic content, and so generating the sets of style classes needed entails just using our usual code reuse techniques.

m12k 9y ago
Thank you for the tip - this does indeed seem to map much more to the way I tend to think.