6 ms·
Moving CSS to JS because of selectors? Hm, I often do the exact opposite. I effectively move JavaScript logic into CSS queries and data into corresponding tags/
by gambler 8y ago
Moving CSS to JS because of selectors? Hm, I often do the exact opposite. I effectively move JavaScript logic into CSS queries and data into corresponding tags/attributes. When I started doing that, my scripts became far more enjoyable to write, trivial to reuse across projects and orders of magnitude easier to analyze/debug (just run the query and see what it finds, mostly).
All things considered, CSS is a pretty good language. Selectors are a great query language, as long as your tags have well-expressed information.
CSS definitely needs something to address specificity, though. Maybe HTML needs an explicit tag or attribute to denote context, so that styles from higher level contexts would not apply to nested contexts. Purely from syntax perspective this could be addressed in CSS queries themselves, but I doubt such implementations would be efficient.
Another things CSS needs is some way to analyze it from scripts. It's amazing that there is no way to query/modify CSS rules from JS. It would solve so many issues with very little client-side code. You could implement CSS variables, for example.
I'm talking about interacting with actual styles. E.g.
let x = CSS.forSelector('article p').getRule('font-weight');
or maybe:
let x = CSS.activeRules['article p']['font-weight'];
CSS.forSelector('article p').setRule('font-weight', '10'p);
You can fake the last one by dynamically generating CSS on the page, but that approach has many issues that would be avoided if there was a clean programmatic interface.
With an API like this you could trivially post-process styles, extend core CSS functionality and even do some cool runtime analysis, like finding which rules aren't used on a page.
---
General CSS note. One thing I advise everyone to try is getting rid of any BEM classes for your components and replacing them with custom attributes. The idea is that each component (block in BEM) gets its own attribute and all the elements and modifiers go inside that attribute.
So instead of BEM
<div class="block__element block__element--modifier">
you get this:
<div a-block="element modifier">
or this:
<div a-block="element-modifier">
(By convention, custom attributes should always have dashes, so you never run into conflicts with core HTML standards and so that everyone can tell they're custom from the first glance. I never thought I would miss XML namespaces, but they sure would come in handy here.)
Not only it's shorter and nicer to look at, it expresses more useful information and can be queried in ways that's impossible with BEM.
To use this, you need to be aware of the following CSS selectors:
[attr~=val]
[attr|=val]
- frosted-flakes 8y agoAccording to the standard, custom attributes _must_ begin with 'data-'. For example, `data-a-block`. Of course, it still works if you omit 'data-', so I fully expect that this requirement will be changed to "must contain a hyphen".
- apineda 8y agoWhat about performance when relying so heavily on this string matching with attribute selectors.
- gambler 8y agoWhat about it? Personally, I haven't run into any real issues with performance using advanced CSS selectors. But as with any performance statements, this applies to HTML, CSS and JS I worked with, on the browsers I tested with.
- Izkata 8y ago> Another things CSS needs is some way to analyze it from scripts. It's amazing that there is no way to query/modify CSS rules from JS. There is: document.styleSheets It's existed for years, I remember fiddling with it in 2011 to dynamically change width/height of elements by changing the css rule from javascript. http://www.javascriptkit.com/dhtmltutors/externalcss3.shtml http://www.javascriptkit.com/dhtmltutors/externalcss3.shtml