I think the specific problem of CSS & JS (rather than the more interesting 'separation of concerns' conversation) is partly due to CSS itself not being fully separatable.
It's used for style & design, but also for functionality. In some ways, ideally, function related CSS would be stored with the module, but site-level design CSS would be separate.
Additionally, CSS by design has greedy selectors. If I put in a:
a { text-decoration: none; border-bottom: 1px solid pink;}
in my site.css, it will muck up any components which use an <a> tag, but don't specifically re-write the border.
Are there good solutions to this?
I kind of feel in some ways, with SPAs and web apps being a thing rather than simple pages, we need a new way of defining styling, which then compiles to CSS, figuring out the correct over-rides along the way.
Some solutions to the greedy css selectors are how web components can limit scope to certain elements. Angular 2 has some level of emulation for this. CSS modules also tries to achieve something similar through scoped classnames.
Element level selectors are so often demonized and having written quite a bit of CSS in my life, I have come to appreciate how easy it is to write and maintain CSS when you actually use those element level selectors mixed with relationship selectors ( >, +, ~,) and attribute selectors.
I don't demonize them, I use them too. But if you rely on them too much then eventually it causes problems. Especially on a large project that grows over time in CSS and HTML.
Attribute selectors are indeed handy and are on par with class names in my suggestion.
> It's used for style & design, but also for functionality
So true.
I once searched days for a broken event handler in JavaScript, just to find out that somewhere deep inside a CSS file, someone disabled events for the element.
Until one uses it, it might be hard to realize how incredibly useful it is. From both CSS and JS perspectives. I rarely use it simply because of older IE lacking support.
The question should be "How do we define module interfaces?"
Take Bootstrap as practical example.
How does it "interface" with your code?
CSS classes of course!
But wait!
If you use its "components" it also interfaces via HTML elements.
If you use even more of it, it also interfaces via JavaScript.
But even if you just use their CSS, how to switch to BlazeCSS, for example?
Well, you kick out Bootstrap, include BlazeCSS and ... you replace the CSS classes in your HTML elements, done...almost, sometimes you even have to fix up the HTML.
Hopefully this gets better with Web Components.
The problem we have right now is that CSS stuff is top down, while it still requires heavy customization from the bottom up (some styling only work for specific element types, etc.)
With Web Components, we can have custom elements "at the bottom" which are transparent in their child element usage, and can let CSS frameworks target them from the top. V1 uses ul/li for tabs, V2 uses divs all the way, but the users just includes the css/js and the used tag <fw-tabs> stays the same.
Gather together the things that change for the same reasons. Separate things that change for different reasons. Sometimes that means that splits cleanly by language boundaries, but what should we do if it doesn't.
18 comments
[ 2.9 ms ] story [ 26.6 ms ] threadIt's used for style & design, but also for functionality. In some ways, ideally, function related CSS would be stored with the module, but site-level design CSS would be separate.
Additionally, CSS by design has greedy selectors. If I put in a:
in my site.css, it will muck up any components which use an <a> tag, but don't specifically re-write the border.Are there good solutions to this?
I kind of feel in some ways, with SPAs and web apps being a thing rather than simple pages, we need a new way of defining styling, which then compiles to CSS, figuring out the correct over-rides along the way.
Attribute selectors are indeed handy and are on par with class names in my suggestion.
So true.
I once searched days for a broken event handler in JavaScript, just to find out that somewhere deep inside a CSS file, someone disabled events for the element.
Didn't even know CSS had that power.
I never heard of that. I just looked up CSS pointer-events [0], is that what you're referring to or are there others?
[0] http://caniuse.com/#feat=pointer-events
You can layer elements how you like and then, in the end, disable all the elements "in the front" of the element that you want to have "clickable".
maybe there should be a file editor that's feature aware but also separates those file for you.
[0] https://twitter.com/BenLesh/status/812092408519413761
The question should be "How do we define module interfaces?"
Take Bootstrap as practical example.
How does it "interface" with your code?
CSS classes of course!
But wait!
If you use its "components" it also interfaces via HTML elements.
If you use even more of it, it also interfaces via JavaScript.
But even if you just use their CSS, how to switch to BlazeCSS, for example?
Well, you kick out Bootstrap, include BlazeCSS and ... you replace the CSS classes in your HTML elements, done...almost, sometimes you even have to fix up the HTML.
Hopefully this gets better with Web Components.
The problem we have right now is that CSS stuff is top down, while it still requires heavy customization from the bottom up (some styling only work for specific element types, etc.)
With Web Components, we can have custom elements "at the bottom" which are transparent in their child element usage, and can let CSS frameworks target them from the top. V1 uses ul/li for tabs, V2 uses divs all the way, but the users just includes the css/js and the used tag <fw-tabs> stays the same.