What I mean by this is STOP every single type of abstraction/library/programming layer for CSS - nothing gets it right, everything causes a problem.
The ONLY way to deal with CSS is program it directly in the way the docs say, never anything else.
There's nothing wrong with using Bootstrap or whatever, and I definitely use JavaScript to program CSS. What I am saying is - no abstractions - no "better way" - no trying to turn CSS into something it isn't via whatever your new abstraction is that can be added to the N other abstractions that other people have made over the years.
Program the damn machine.
And with grid, variables, animation, container queries, modern CSS is amazing. You just need to treat it with a little respect.
One problem (20yrs ago at least) was that for a long time the specs weren't supported very well by common browsers. So everyone just prodded at hacks using trial and error instead of learning it. That approach never really went away even after support improved.
> So everyone just prodded at hacks using trial and error instead of learning it.
And dev tools made this feedback loop much faster.
1: https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...
Namely:
- Selectors are a global namespace. Imagine if every variable and function in your favorite programming languages were global and so had to be unique. No modules or namespaces. Developing a system to fix that would be pretty high on my list of priorities... coming up with a cool solution and then people telling me to "just learn the language" would be pretty fucking infuriating, don't you think?
- Several fighting priority systems (did you know about newer ones like @layer?). And equivalent priority falls back to source order - OK, so how do you square that with dynamic loading? Some navigation paths through an app would inject some CSS first whereas others would inject other CSS first. Good luck!
- Rule priority is decided by selector specificity also.
HTML has also answered your these needs with the locally scoped ShadowDOM.
A selector is not not a variable or a function. CSS has functions (e.g translate) and it has variables, which are both distinct concepts in the language from selectors.
> No modules or namespaces. CSS is not supposed to be a turing complete general purpose programming language. Why would you need namespaces and modules to style up HTML tags?
Congratulations, you have attacked the analogy rather than the argument.
One of my earliest webdev jobs was at a company whose product was a widget you could add to your site by adding our `<script>` tag. Thus, our CSS needed to coexist with the first-party site's, not to mention any other third-party widgets on there. In other words: the same exact reason you need modules in traditional languages.
Of course one drawback with that is you are also depending on developers and content managers at sites following your documentation on how to use your products, which is a different problem.
on edit: obviously if you have been writing css since 1997 and one of your first webdev jobs was this kind of thing, things were much more difficult back then. I did the same sort of thing in 2014-2015, not particularly difficult to make work. I worked web dev since 1999, first job was dynamic generation of web sites and other media from single source data.
That misses the point. They're identifiers scoped to the entire document - the same way global variables and global functions are identifiers scoped to an entire program.
what does this mean? Selectors are how you query a particular element to apply styles to it, I think what you mean is that selectors as a query language does not allow you to query any element from any other element the way you can with XPath but in many use cases you need to start querying globally.
but we can also see that the only way that querying from element to any other element makes sense if you could do something like (pseudo XPath / CSS abomination coming up)
.someclass[[ancestor::.mainEntry .headline:empty]]
or maybe you would prefer
.mainEntry[[.headline:empty]] .someclass
which sure, I have, some very few times thought boy it would be nice if I could do more involved context selection in CSS based on an elements surrounding DOM than sibling axis and the like offer.
however > Imagine if every variable and function in your favorite programming languages were global and so had to be unique.
yes, I know you are not saying that variables in CSS need to be global. However I think you have perhaps not internalized yet how CSS variables and scoping rules work have created a situation that allows for often elegantly solving problems that one might wish one had a more powerful query language to handle.
The following is of course not elegant, but is an example of how we change the design of .someclass based on having an ancestor mainEntry that has an empty .headline using variables.
https://codepen.io/bryanrasmussen/pen/xbEoabM
>OK, so how do you square that with dynamic loading? Some navigation paths through an app would inject some CSS first whereas others would inject other CSS first.
yes I've run into this situation before, however for me it was a framework issue not a css standards issue, and it sounds to me with phrases like "navigation paths" and "app inject some css" that it was a JS framework that made you unhappy and not actually the state of Web standards.
> or maybe you would prefer
> .mainEntry[[.headline:empty]] .someclass
I don't really know xpath but isn't that this?
.mainEntry:has(.headline:empty) .someClass
As you already said, this approach would work fine if you had no external payloads that inject their own HTML and CSS on the page, either at runtime or by being loaded by other modules in a CMS.
It also breaks when your :root selector is being polluted by overly generic variables by your platform, like in the most recent versions of Wordpress.
HTML was designed to be a document language, like a PDF, but worse because it has no absolute positioning so text just changes shape when you change the width.
Almost every website does NOT follow the "document" paradigm but an "app" paradigm with navbars, sidebars, panels, etc. None of these things fit the model HTML was specialized for.
If HTML/CSS were for those things, we would have had scoped rules for classes day 1.
There are still no affordances for many things, so people have to invent their own solutions.
When faced with a widespread standard that is sorely lacking, instead of patching the standard globally, people come up with their own workarounds. This accumulates until the whole thing becomes a conceptually "pure" core under a transfigured mess of patches to make it work the way the modern world needs it to work.
For HTML, I feel that PHP and Web 2.0 did unspoken harm to it. A lot of things that are done by server-side rendering (and afterwards in client-side rendering) should just be features built into HTML from the start. Templates, themes, widgets (panels), components, etc. Now we have "templates" and "components" but neither of these terms mean something in HTML that actually does what you would expect from a templating language which is critical of almost every website.
I mean, am I crazy to think that if you have 2 webpages that share the same navbar, you shouldn't need a build step or special program just to handle this use case in a way that is maintainable? It should just be built into HTML? Javascript isn't a solution to this because that means the website is unusable without Javascript, and that sounds stupid. You need to enable Javascript just to have a navbar? Or you need a whole SSR just to avoid having to copy-paste the navbar? Or a build step? How did we keep using this thing for 30 years?
I feel like because developers could just do this with PHP/JS, these basic features never made into the pure HTML language.
The weird thing is that these languages still get features, just not any features that makes it more powerful at building simple things. HTML has video, web assembly, CSS has animated fonts. But you still need a separate program if you want the same navbar everywhere.
I'd also like if anyone could look at the specifications for CSS, ideally for Grid, especially the `grid-template-*` and `grid-auto-*` subset of rules, mixmaxing and gotchas and tell me what CSS exactly is right now, So I can avoid turning it into something that is not.
CSS is fine. Most people just never learned it.
Some topics I'm curious what people think about:
- What’s the one thing this doesn’t cover that you’d expect it to?
- Does the syntax feel natural to you, or did you find yourself confused by anything?
- I'm looking for edge cases: what kind of complex selector scenario would trip this compiler up or be impossible to express with this model?
AMA—happy to answer any questions about the tool, the implementation, or the design choices.
.btn {
&:enabled:hover {
background: dodgerblue;
}
&:disabled {
background: gray;
}
}Unfortunately I can’t give it more attention now, because I should have gone to sleep a couple of hours ago…
—⁂—
Another approach entirely is to embrace last-declaration-wins, by :where()ing everything:
:where(.t0) { background: var(--primary-color); }
:where(.t0:hover) { background: var(--primary-hover-color); }
:where(.t0:active) { background: var(--primary-pressed-color); }
:where(.t0[disabled]) { background: var(--surface-color); }
Considering the `:where` approach, I would say it might work most of the time, but it doesn't cover cases where you don't need to set a value, or when your condition requires a more complex selector (e.g., a parent/root context). It was very important for me to support all cases, so I don't feel limited by the tool.
I don’t know what you mean.
> when your condition requires a more complex selector (e.g., a parent/root context)
I don’t see the problem. :where() takes a <complex-selector-list>.
You are probably right about `:where`, but using it with complex selectors might noticeably affect the performance, as it does with `:has`. Didn't run any test for `:where` specifically, though. Also, we apply lots of styles to the same elements, most of which are overridden.
Another issue is using a different set of longhand/shorthand properties for different states that won't be correctly overridden in this approach.
So it might work pretty well in most of the cases, especially simple ones. But it's definitely not better than mutually exclusive selectors.
revert-layer <https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...> may be relevant to the situation you describe. Not the simplest thing, but it’s a tool most don’t know about yet which can do that kind of thing.
—⁂—
On :where(). It’s easy to see why :has() can tank performance: it’s doing a whole new complicated thing. :where() is a good deal simpler, and this specific form of it (where it’s the entire selector) has only the effect of zeroing specificity. I’d be mildly surprised if the performance difference from wrapping an entire selector in :where(…) was measurable even in a worst-case synthetic document.
These days if starting a greenfield web app, each page has its own style/css sent in the head tag.
Because it’s usually just base layout + page specific styles/overrides then it barely adds any overhead in the scheme of things(couple of extra KB).
Maybe the base layout could be moved into a static file to be cached but whatever, it’s already ridiculously quick to render plain html/css.
.thing
.thing-container .thing
html body .thing-container .thing.thing.thing.thing
`styled-components` is just an advanced CSS injector. We used it as an injector in the early version of Tasty.