6 ms·

Show HN: CSS Extras

104 points by mofle 1y ago

christophilus 1y ago
Whoo. I’ll be the first hyper negative prototypical HN commenter. I’m glad I don’t work on browser engines for a living. CSS is getting more complex and spaghetti-capable by the day. > Currently only supported in Chrome 141+. The @function rule is going through the W3C standardization process and will be available in other browsers soon. Also, pretty tired of Chrome effectively front-running standards as a not-so-subtle means of cramming them through.
- Hendrikto 1y ago
  Web standards are in the same boat as C++. They can never really deprecate anything, but they want shiny new things, so they just add and add on top of the pile. Every feature sounds great in isolation, but in aggregate they become a moloch. Then people say “modern CSS is great, you just have to pick the ‘good subset’.”, but then nobody can agree what that subset should be, and everybody else uses a different subset. LLMs also contribute to this, as 90% of what’s available on the web is considered outdated now, but that is the majority of training data.
- runroader 1y ago
  One person's front-running is another's reference implementation. Although, yes, CSS is getting more complex because everything on the web is. What's the last standard feature to really be taken away after actually existing in the wild for a while? XHTML and Flash (effectively a standard if not in reality)?
  - deleted 1y ago
    [deleted]
  - mark_and_sweep 1y ago
    XHTML (or the XML syntax for HTML) wasn't removed (see: https://html.spec.whatwg.org/multipage/introduction.html#html-vs-xhtml https://html.spec.whatwg.org/multipage/introduction.html#htm...). You may be thinking of XSLT, which may be removed in future.
    - runroader 1y ago
      So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C. Is there still a real-world use case for XHTML/"XML syntax for HTML", or is this just exhibit A that no standard can actually be removed from browsers? Re: XSLT, back in the everything-is-XML days I desperately wanted to like XSLT, it seemed so useful (I was that annoying co-worker telling everyone it's supposed to be pronounced "exalt"). But it was such a disaster to actually write or read and no real debugging was possible, I had to use a LOT of conditional bgcolor=red to figure anything out. It didn't take very long to come to the conclusion that XPath was the only useful part.
      - JimDabell 1y ago
        > So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C. XSLT is a W3C standard: https://www.w3.org/TR/xslt/ https://www.w3.org/TR/xslt/
      - mark_and_sweep 1y ago
        > Is there still a real-world use case for XHTML If I need the markup of a page to not contain any structural errors, I often use XHTML for testing at least because, though it's a little more verbose, if there's a nesting error, for example, the browser will flat out refuse to render it and show some sort of stacktrace error page instead. So it's quite a good built-in "tool" for checking that your markup is clean. With HTML, everything goes and the browser will happily render broken markup, which is probably the correct default for the web as a whole. After all, you surely don't want a page like Wikipedia to show an error message to its users because a developer forgot to close a tag somewhere.
  - Sesse__ 1y ago
    Shadow DOM v0 was removed from Chromium in 2019 (with a lot of pain involved).
  - alwillis 1y ago
    Using CSS Grid, which we just got in 2017, is so much easier than using floats and tables. These layouts were also very fragile. Part of the problem is once people get used to doing something a particular way, they don’t want to change. I looked at a friend’s website the other day and it’s using a table-based layout and it wasn’t even that old! Nothing can be removed from CSS because sites from the 90’s and the early 2000’s still have to work in today’s browsers. The good news is most greenfield projects can use floats and tables in the way they were intended, which wasn’t ever layout.
- bastawhiz 1y ago
  The standard for this has been developed in the open at the CSSWG with one of the SASS developers: https://github.com/w3c/csswg-drafts/issues/9350 https://github.com/w3c/csswg-drafts/issues/9350
cluckindan 1y ago
Welp, time to make a @function preprocessor. There is no reason for every single client to recalculate things which could have been completely or partially calculated at build time.
- gregoriol 1y ago
  CSS is becoming a programming language and not just a style sheet. Don't worry about performance, soon you'll be able to run assembly in it.
  - haktan 1y ago
    Yet recently I couldn't find a way to count cousin elements using has and nth-of-type. JS still is needed when use case gets a little complex.
    - california-og 1y ago
      Did you try counter()? There's also the upcoming sibling-index()
- kaoD 1y ago
  It's a tradeoff. I expect this to be non-trivial, do nothing in the general case (when referring to runtime CSS vars) and possibly increase your final CSS size for any sufficiently complex codebase when unrolled.
- afavour 1y ago
  But there are also plenty of use cases where recalculation will be valuable in the client. CSS variables cascade so a preprocessor isn't going to be able to know ahead of time what any given variable value is.
  - cluckindan 1y ago
    Sure, the new syntax allows doing some nifty stuff with the cascade. In practice, however, I foresee most usage being simple one-time transformations of design tokens. I suppose it is more of a theme architecturing issue.
ape4 1y ago
Obvious question: are CSS functions Turing complete?
- est 1y ago
  I remember there's expression() on IE6.
  - csswizardry 1y ago
    Way ahead of its time. Unfortunately.
- zamadatix 1y ago
  CSS Custom Functions are defined in a way they don't add anything over traditional CSS in this regard. I.e. they are just allowed to act as custom functions - not recursion mechanism, jump mechanisms, loop mechanisms, etc.
- Sesse__ 1y ago
  They are not allowed to loop or recurse, so no, by themselves, they are not (unless you accept repeating the function a potentially infinite amount of time). CSS in general is Turing complete if you allow running multiple frames, although it requires ugly hacks. See e.g. https://codepen.io/propjockey/pen/dywNyBQ https://codepen.io/propjockey/pen/dywNyBQ, which is quite insane IMO.
- qingcharles 1y ago
  Stupider question: how long until it can run Doom?
- cluckindan 1y ago
  No. The implementation treats the function body as just another CSS rule set, which is applied to some virtual element. The ”result: somevalue;” rule then sets the ”result” style property on that element, and that property value gets plopped onto the call site. Kinda clever, actually.
bilekas 1y ago
Oooh this will not end well.. Also side question, is it really necessary to have this as an npm package ?
- kaoD 1y ago
  > is it really necessary to have this as an npm package ? Is anything really necessary? Not snark: almost nothing is necessary in life but many things are convenient.
  - bilekas 1y ago
    Surely a cdn is more convenient. I don't want to install an entire package manager just to 'install' 2 CSS files.
    - dinkleberg 1y ago
      But if you’re already using npm in your project, as a significant number of front end projects are, it means you can serve them directly rather than requiring an external CDN.
    - kaoD 1y ago
      Storing your food in the fridge requires an entire fridge (and power, and...) Your particular circumstances might not require it (maybe you're just temporarily camping or you only store non-perishable food) but that doesn't mean that fridges, in general, are unnecessary or less convenient than just storing food in a cupboard. Even if you only eat in restaurants and you don't need a fridge, the restaurant does. This being packaged won't prevent it from being delivered from a CDN. It will actually make it easier to automatically deploy all versions to CDNs as they are published, like in https://www.jsdelivr.com/ https://www.jsdelivr.com/, while being CDN-only is less convenient when you actually need the many affordances that a package manager provides. If I already have a package manager and do: yarn add css-extras And then in my code: import 'css-extras'; ...and I get it versioned in my package.json, cached, available offline, not subject to link rot, automatically inserted in my bundle, processed, minified and with its dead code eliminated... that's surely more convenient than vendoring from a CDN and manually doing all that process (or worse, not doing it at all and just dropping a raw <link> to the CDN in my HTML, with all its drawbacks).
gampleman 1y ago
It would be quite nice to see some more "killer" uses of this new feature that aren't just "we removed some duplication and... saved less than 1% of our loc". And maybe there are some really compelling ones... I think the only really useful one I see here is `--abs`, which really should just be built-in.
- semolino 1y ago
  abs() exists with cross-browser support: https://developer.mozilla.org/en-US/docs/Web/CSS/abs https://developer.mozilla.org/en-US/docs/Web/CSS/abs There are also other non-custom math functions like round() which can be very useful.
  - deleted 1y ago
    [deleted]
- hombre_fatal 1y ago
  It's not for DRYing/golfing code. The main use case of functions is that you can parameterize code. This lets you parameterize stylesheets, like set a base font size and primary color, and then derive your whole theme from it, from spacing to secondary border colors to how buttons look when they're hovered.
  - gampleman 1y ago
    You can do that with custom properties already. AFAICT functions don't introduce any new abilities on that front (apart from the aforementioned DRY-ing).
chris_wot 1y ago
I’m so confused why people are ragging on this. Why is this considered detrimental? Looks pretty good to me…
- llbbdd 1y ago
  It's a post about web development on HN. Half the comments will rag incessantly, half will talk about how the web should go back to being a delivery mechanism for documents only like it's 1995 forever, someone will rant about Google for some reason. It's a neverending nightmare.
  - typpilol 1y ago
    Don't forget the people that have to tell us how much they hate JavaScript on every single web dev post too
- robertoandred 1y ago
  People who don’t understand the problems CSS has to solve are opposed to CSS solving those problems. Sure it can all be stuffed into Tailwind classes!!
  - ezeekqil 1y ago
    ¯\\_(ツ)_/¯
  - lerp-io 1y ago
    the problem is that if there was a tailwind-like replacement for css, nobody would ever use css again lmao.
    - djxfade 1y ago
      It is, it's called inline styles
- JadeNB 1y ago
  I'm no expert in this domain, but I suspect it's less "this is a bad problem to solve" and more "every solution to a problem moves farther away from the ideal simplicity of a markup langage." (I'm not weighing in on the validity of this position, just reporting what I perceive the position itself to be.)
solaraQuill55 1y ago
CSS is becoming the new JavaScript.
- mock-possum 1y ago
  As someone who works with both those languages professionally, I’m not sure what you mean by that. CSS applies to a new narrow band of the spectrum of how the web functions.
spankalee 1y ago
One problem I think people are going to run into here is loading CSS libraries from the components that use them. Luckily, CSS Modules are starting to land in multiple browsers. Firefox added support behind a flag, and it might ship in 145. So you'll be able to import the CSS from your JS modules, and apply it to the document: import extras from 'css-extras' with {type: 'css'}; if (!document.adoptedStyleSheets.includes(extras)) { document.adoptedStyleSheets.push(extras); } Or, if you use shadow DOM: this.shadowRoot.adoptedStyleSheets.push(extras);
ulrischa 1y ago
CSS is changing so fast. I guess we will see Doom in CSS shortly
- CharlesW 1y ago
  This may feel true if you've re-engaged with CSS's progression in the last ~5–7 years. In reality, the last big qualitative leap was Grid in 2017. This project is based on just one new proposed rule which won't be available in all mainstream browsers until 2027-28, and won't be safe for production use until close to the end of the decade.
  - lelandfe 1y ago
    In reality, CSS's big changes are a drumbeat pounding monthly: https://developer.chrome.com/blog/css-wrapped-2023 https://developer.chrome.com/blog/css-wrapped-2023 https://chrome.dev/css-wrapped-2024/ https://chrome.dev/css-wrapped-2024/ Of note from 2023: subgrids, :has, container queries, nesting... And in 2022, cascade layers (plus <style scoped>, I mean @scope, I mean :scope).
  - ulrischa 1y ago
    The last big thing was grid? Sorry but there are big things coming to css nearly every month. Container queries, @scope ... and so on
dmix 1y ago
Not supported by Firefox or Safari https://caniuse.com/?search=%40function https://caniuse.com/?search=%40function
- CharlesW 1y ago
  Yes, @function is still at the "public working draft" stage. https://www.w3.org/TR/css-mixins-1/ https://www.w3.org/TR/css-mixins-1/
rrgok 1y ago
It is time to reject this ugly double dash prefix kebab-cased variables names. PHP looks better in comparison. What goes in some people's mind when they come up with these ugly conventions and rules?
- svieira 1y ago
  A single global namespace makes you start doing interesting and horrible things when you need to divide it.
- dmix 1y ago
  CSS isn't exactly a clean language. In my experience most projects are write-only... CSS just accumulates. It is rarely refactored or carefully designed. It is only occasionally mass deleted in redesigns and redone. Having a standard namespace pattern eliminates a lot of hierarchical issues, which is a very common issue with CSS. Utility based libraries tend to avoid this these days and use simpler names, but those are also supposed to be your root libraries, not your custom CSS.
- spartanatreyu 1y ago
  > What goes in some people's mind when they come up with these ugly conventions and rules? The earlier versions of the CSS spec had no double dash prefix sigil for custom properties. You could just make up a value like: "bigger", "accent", etc... The problem is that CSS needs to be able to add new properties overtime, and we don't want any name collisions with variable names that web developers have already taken. So we need a sigil that only custom properties and that regular properties can't use. - We can't use `$` because that would conflict with SCSS, and we wouldn't be able to use custom properties in the same file as scss variables - We can't use any of the following symbols because they're already used in CSS itself: !@#.,%^&>~:?\|{}`()+*/"'; - We can't use `<` because it could harm parsing performance. - We can't prefix with `-`, `_`, or `__` because developers have already used them in their files. - That seems to leave just: `--` or something even weirder. So `--` is longer but in the context of not breaking anything, it's the best option on the table. ------------- Now we're in this unusual spot where custom properties are genuinely more useful then what came before (they're like scss vars but they can update live and cascade too!), but they're a little wordy. Probably not for long though, the upgraded attr() function will remove a lot of the massive walls of definitions that too many design systems and methodologies are relying on, and the upcoming functions used with the conditionals (if, media, where, not etc...) will take that further.

104 points by mofle 1y ago

Whoo. I’ll be the first hyper negative prototypical HN commenter. I’m glad I don’t work on browser engines for a living. CSS is getting more complex and spaghetti-capable by the day. > Currently only supported in Chrome 141+. The @function rule is going through the W3C standardization process and will be available in other browsers soon. Also, pretty tired of Chrome effectively front-running standards as a not-so-subtle means of cramming them through.

Hendrikto 1y ago
Web standards are in the same boat as C++. They can never really deprecate anything, but they want shiny new things, so they just add and add on top of the pile. Every feature sounds great in isolation, but in aggregate they become a moloch. Then people say “modern CSS is great, you just have to pick the ‘good subset’.”, but then nobody can agree what that subset should be, and everybody else uses a different subset. LLMs also contribute to this, as 90% of what’s available on the web is considered outdated now, but that is the majority of training data.
runroader 1y ago
One person's front-running is another's reference implementation. Although, yes, CSS is getting more complex because everything on the web is. What's the last standard feature to really be taken away after actually existing in the wild for a while? XHTML and Flash (effectively a standard if not in reality)?
- deleted 1y ago
  [deleted]
- mark_and_sweep 1y ago
  XHTML (or the XML syntax for HTML) wasn't removed (see: https://html.spec.whatwg.org/multipage/introduction.html#html-vs-xhtml https://html.spec.whatwg.org/multipage/introduction.html#htm...). You may be thinking of XSLT, which may be removed in future.
  - runroader 1y ago
    So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C. Is there still a real-world use case for XHTML/"XML syntax for HTML", or is this just exhibit A that no standard can actually be removed from browsers? Re: XSLT, back in the everything-is-XML days I desperately wanted to like XSLT, it seemed so useful (I was that annoying co-worker telling everyone it's supposed to be pronounced "exalt"). But it was such a disaster to actually write or read and no real debugging was possible, I had to use a LOT of conditional bgcolor=red to figure anything out. It didn't take very long to come to the conclusion that XPath was the only useful part.
    - JimDabell 1y ago
      > So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C. XSLT is a W3C standard: https://www.w3.org/TR/xslt/ https://www.w3.org/TR/xslt/
    - mark_and_sweep 1y ago
      > Is there still a real-world use case for XHTML If I need the markup of a page to not contain any structural errors, I often use XHTML for testing at least because, though it's a little more verbose, if there's a nesting error, for example, the browser will flat out refuse to render it and show some sort of stacktrace error page instead. So it's quite a good built-in "tool" for checking that your markup is clean. With HTML, everything goes and the browser will happily render broken markup, which is probably the correct default for the web as a whole. After all, you surely don't want a page like Wikipedia to show an error message to its users because a developer forgot to close a tag somewhere.
- Sesse__ 1y ago
  Shadow DOM v0 was removed from Chromium in 2019 (with a lot of pain involved).
- alwillis 1y ago
  Using CSS Grid, which we just got in 2017, is so much easier than using floats and tables. These layouts were also very fragile. Part of the problem is once people get used to doing something a particular way, they don’t want to change. I looked at a friend’s website the other day and it’s using a table-based layout and it wasn’t even that old! Nothing can be removed from CSS because sites from the 90’s and the early 2000’s still have to work in today’s browsers. The good news is most greenfield projects can use floats and tables in the way they were intended, which wasn’t ever layout.
bastawhiz 1y ago
The standard for this has been developed in the open at the CSSWG with one of the SASS developers: https://github.com/w3c/csswg-drafts/issues/9350 https://github.com/w3c/csswg-drafts/issues/9350

cluckindan 1y ago

Welp, time to make a @function preprocessor. There is no reason for every single client to recalculate things which could have been completely or partially calculated at build time.

gregoriol 1y ago
CSS is becoming a programming language and not just a style sheet. Don't worry about performance, soon you'll be able to run assembly in it.
- haktan 1y ago
  Yet recently I couldn't find a way to count cousin elements using has and nth-of-type. JS still is needed when use case gets a little complex.
  - california-og 1y ago
    Did you try counter()? There's also the upcoming sibling-index()
kaoD 1y ago
It's a tradeoff. I expect this to be non-trivial, do nothing in the general case (when referring to runtime CSS vars) and possibly increase your final CSS size for any sufficiently complex codebase when unrolled.
afavour 1y ago
But there are also plenty of use cases where recalculation will be valuable in the client. CSS variables cascade so a preprocessor isn't going to be able to know ahead of time what any given variable value is.
- cluckindan 1y ago
  Sure, the new syntax allows doing some nifty stuff with the cascade. In practice, however, I foresee most usage being simple one-time transformations of design tokens. I suppose it is more of a theme architecturing issue.

ape4 1y ago

Obvious question: are CSS functions Turing complete?

est 1y ago
I remember there's expression() on IE6.
- csswizardry 1y ago
  Way ahead of its time. Unfortunately.
zamadatix 1y ago
CSS Custom Functions are defined in a way they don't add anything over traditional CSS in this regard. I.e. they are just allowed to act as custom functions - not recursion mechanism, jump mechanisms, loop mechanisms, etc.
Sesse__ 1y ago
They are not allowed to loop or recurse, so no, by themselves, they are not (unless you accept repeating the function a potentially infinite amount of time). CSS in general is Turing complete if you allow running multiple frames, although it requires ugly hacks. See e.g. https://codepen.io/propjockey/pen/dywNyBQ https://codepen.io/propjockey/pen/dywNyBQ, which is quite insane IMO.
qingcharles 1y ago
Stupider question: how long until it can run Doom?
cluckindan 1y ago
No. The implementation treats the function body as just another CSS rule set, which is applied to some virtual element. The ”result: somevalue;” rule then sets the ”result” style property on that element, and that property value gets plopped onto the call site. Kinda clever, actually.

bilekas 1y ago

Oooh this will not end well.. Also side question, is it really necessary to have this as an npm package ?

kaoD 1y ago
> is it really necessary to have this as an npm package ? Is anything really necessary? Not snark: almost nothing is necessary in life but many things are convenient.
- bilekas 1y ago
  Surely a cdn is more convenient. I don't want to install an entire package manager just to 'install' 2 CSS files.
  - dinkleberg 1y ago
    But if you’re already using npm in your project, as a significant number of front end projects are, it means you can serve them directly rather than requiring an external CDN.
  - kaoD 1y ago
    Storing your food in the fridge requires an entire fridge (and power, and...) Your particular circumstances might not require it (maybe you're just temporarily camping or you only store non-perishable food) but that doesn't mean that fridges, in general, are unnecessary or less convenient than just storing food in a cupboard. Even if you only eat in restaurants and you don't need a fridge, the restaurant does. This being packaged won't prevent it from being delivered from a CDN. It will actually make it easier to automatically deploy all versions to CDNs as they are published, like in https://www.jsdelivr.com/ https://www.jsdelivr.com/, while being CDN-only is less convenient when you actually need the many affordances that a package manager provides. If I already have a package manager and do: yarn add css-extras And then in my code: import 'css-extras'; ...and I get it versioned in my package.json, cached, available offline, not subject to link rot, automatically inserted in my bundle, processed, minified and with its dead code eliminated... that's surely more convenient than vendoring from a CDN and manually doing all that process (or worse, not doing it at all and just dropping a raw <link> to the CDN in my HTML, with all its drawbacks).

gampleman 1y ago

It would be quite nice to see some more "killer" uses of this new feature that aren't just "we removed some duplication and... saved less than 1% of our loc". And maybe there are some really compelling ones... I think the only really useful one I see here is `--abs`, which really should just be built-in.

semolino 1y ago
abs() exists with cross-browser support: https://developer.mozilla.org/en-US/docs/Web/CSS/abs https://developer.mozilla.org/en-US/docs/Web/CSS/abs There are also other non-custom math functions like round() which can be very useful.
- deleted 1y ago
  [deleted]
hombre_fatal 1y ago
It's not for DRYing/golfing code. The main use case of functions is that you can parameterize code. This lets you parameterize stylesheets, like set a base font size and primary color, and then derive your whole theme from it, from spacing to secondary border colors to how buttons look when they're hovered.
- gampleman 1y ago
  You can do that with custom properties already. AFAICT functions don't introduce any new abilities on that front (apart from the aforementioned DRY-ing).

chris_wot 1y ago

I’m so confused why people are ragging on this. Why is this considered detrimental? Looks pretty good to me…

llbbdd 1y ago
It's a post about web development on HN. Half the comments will rag incessantly, half will talk about how the web should go back to being a delivery mechanism for documents only like it's 1995 forever, someone will rant about Google for some reason. It's a neverending nightmare.
- typpilol 1y ago
  Don't forget the people that have to tell us how much they hate JavaScript on every single web dev post too
robertoandred 1y ago
People who don’t understand the problems CSS has to solve are opposed to CSS solving those problems. Sure it can all be stuffed into Tailwind classes!!
- ezeekqil 1y ago
  ¯\\_(ツ)_/¯
- lerp-io 1y ago
  the problem is that if there was a tailwind-like replacement for css, nobody would ever use css again lmao.
  - djxfade 1y ago
    It is, it's called inline styles
JadeNB 1y ago
I'm no expert in this domain, but I suspect it's less "this is a bad problem to solve" and more "every solution to a problem moves farther away from the ideal simplicity of a markup langage." (I'm not weighing in on the validity of this position, just reporting what I perceive the position itself to be.)

solaraQuill55 1y ago

CSS is becoming the new JavaScript.

mock-possum 1y ago
As someone who works with both those languages professionally, I’m not sure what you mean by that. CSS applies to a new narrow band of the spectrum of how the web functions.

spankalee 1y ago

One problem I think people are going to run into here is loading CSS libraries from the components that use them. Luckily, CSS Modules are starting to land in multiple browsers. Firefox added support behind a flag, and it might ship in 145. So you'll be able to import the CSS from your JS modules, and apply it to the document: import extras from 'css-extras' with {type: 'css'}; if (!document.adoptedStyleSheets.includes(extras)) { document.adoptedStyleSheets.push(extras); } Or, if you use shadow DOM: this.shadowRoot.adoptedStyleSheets.push(extras);

ulrischa 1y ago

CSS is changing so fast. I guess we will see Doom in CSS shortly

CharlesW 1y ago
This may feel true if you've re-engaged with CSS's progression in the last ~5–7 years. In reality, the last big qualitative leap was Grid in 2017. This project is based on just one new proposed rule which won't be available in all mainstream browsers until 2027-28, and won't be safe for production use until close to the end of the decade.
- lelandfe 1y ago
  In reality, CSS's big changes are a drumbeat pounding monthly: https://developer.chrome.com/blog/css-wrapped-2023 https://developer.chrome.com/blog/css-wrapped-2023 https://chrome.dev/css-wrapped-2024/ https://chrome.dev/css-wrapped-2024/ Of note from 2023: subgrids, :has, container queries, nesting... And in 2022, cascade layers (plus <style scoped>, I mean @scope, I mean :scope).
- ulrischa 1y ago
  The last big thing was grid? Sorry but there are big things coming to css nearly every month. Container queries, @scope ... and so on

dmix 1y ago

Not supported by Firefox or Safari https://caniuse.com/?search=%40function https://caniuse.com/?search=%40function

CharlesW 1y ago
Yes, @function is still at the "public working draft" stage. https://www.w3.org/TR/css-mixins-1/ https://www.w3.org/TR/css-mixins-1/

rrgok 1y ago

It is time to reject this ugly double dash prefix kebab-cased variables names. PHP looks better in comparison. What goes in some people's mind when they come up with these ugly conventions and rules?

svieira 1y ago
A single global namespace makes you start doing interesting and horrible things when you need to divide it.
dmix 1y ago
CSS isn't exactly a clean language. In my experience most projects are write-only... CSS just accumulates. It is rarely refactored or carefully designed. It is only occasionally mass deleted in redesigns and redone. Having a standard namespace pattern eliminates a lot of hierarchical issues, which is a very common issue with CSS. Utility based libraries tend to avoid this these days and use simpler names, but those are also supposed to be your root libraries, not your custom CSS.
spartanatreyu 1y ago
> What goes in some people's mind when they come up with these ugly conventions and rules? The earlier versions of the CSS spec had no double dash prefix sigil for custom properties. You could just make up a value like: "bigger", "accent", etc... The problem is that CSS needs to be able to add new properties overtime, and we don't want any name collisions with variable names that web developers have already taken. So we need a sigil that only custom properties and that regular properties can't use. - We can't use `$` because that would conflict with SCSS, and we wouldn't be able to use custom properties in the same file as scss variables - We can't use any of the following symbols because they're already used in CSS itself: !@#.,%^&>~:?\|{}`()+*/"'; - We can't use `<` because it could harm parsing performance. - We can't prefix with `-`, `_`, or `__` because developers have already used them in their files. - That seems to leave just: `--` or something even weirder. So `--` is longer but in the context of not breaking anything, it's the best option on the table. ------------- Now we're in this unusual spot where custom properties are genuinely more useful then what came before (they're like scss vars but they can update live and cascade too!), but they're a little wordy. Probably not for long though, the upgraded attr() function will remove a lot of the massive walls of definitions that too many design systems and methodologies are relying on, and the upcoming functions used with the conditionals (if, media, where, not etc...) will take that further.