[HN Gopher] CSS WG resolved to officially work on native custom ...
___________________________________________________________________
CSS WG resolved to officially work on native custom functions and
mixins
Author : donohoe
Score : 60 points
Date : 2024-02-13 13:33 UTC (9 hours ago)
(HTM) web link (css.oddbird.net)
(TXT) w3m dump (css.oddbird.net)
| ulrischa wrote:
| This is a direction leading to a programming language for css. I
| like these feature, but is this necessary? There is JavaScript
| and it has all needed for programming. Wouldn't it be good if we
| could use JavaScript in the browser for these features?
| lycos wrote:
| This looks terrible. Is this really necessary?
|
| I feel like purists who write CSS by hand don't want this kind of
| stuff, because otherwise they'd have switched to one of thousands
| of preprocessors. And people who use preprocessors and/or
| elaborate styling systems that take care of this stuff already.
|
| Maybe I am getting too old and out of touch though.
| art0rz wrote:
| The benefit of this is that it runs in the browser. E.g. you
| can change a CSS variable and the change would propagate to
| wherever it's being used.
| est wrote:
| Who else remembers the expression() from IE5.5 ?
| lycos wrote:
| Yeah but only in evergreen browsers once they implement it..
| plus now you are making the browser do more work compared to
| just having simple CSS files that don't have to do
| complicated things.
| micromacrofoot wrote:
| "CSS doesn't have to do complicated things" is already a
| thing of the past. There are plenty of pseudo selectors and
| custom properties now that can be quite complex.
| no_wizard wrote:
| Speed can be optimized over time, particularly as they
| collect huge real world usage and can optimize for common
| patterns. That's one unspoken benefit of having features in
| the browser vs pushing them to build tools.
|
| Its not always appropriate but I feel CSS benefits more
| often than not for this
| JoshTriplett wrote:
| > Yeah but only in evergreen browsers
|
| Which browsers that matter _aren 't_ evergreen at this
| point?
|
| EDIT: got an answer downthread, apparently at least some
| sites have to deal with old versions of the mobile Safari
| engine because of old iPhones/iPads that can't be updated
| and can't run other browser engines. Another good reason to
| wish that iPhones/iPads permitted other browsers.
| lycos wrote:
| There is no definitive way to answer your question. It
| depends entirely on your target audience and how much
| effort your company is willing to put towards support a,
| I will admit, likely minority. Some of us need to.
| JoshTriplett wrote:
| I'm genuinely curious to hear which non-evergreen
| browsers people are having to support. Niche mobile
| browsers from ancient Android phones? Some of the more
| obscure mobile browsers from
| https://caniuse.com/ciu/comparison , or even more obscure
| ones that aren't listed there?
|
| To what extent are those platforms unable to support a
| better browser? For instance, Firefox works all the way
| back to Android _5.0_.
| reaperducer wrote:
| _I 'm genuinely curious to hear which non-evergreen
| browsers people are having to support._
|
| Browsers on devices (sometimes iPads, sometimes Android)
| that are inside touch-screen kiosks.
|
| Some of the ones I work with are in places so remote, it
| would take me three or four days to reach them if a
| software update goes wrong. Then another three or four
| days to get back to the office.
| no_wizard wrote:
| The real question is: how many of your users allow the
| browser to auto update?
|
| This is the most important question nowadays. there are
| still organizations where this is tightly controlled,
| they use LTS releases that don't always get the updates
| as fast or the same etc.
| SahAssar wrote:
| Even LTS releases get much more rapid updates than the
| upgrade cycle for browsers used to be. I remember stuff
| getting released in IE8/IE9 and thinking it'd be 10 years
| before I could properly use it on large customer projects
| (and I was right pretty much right).
| realusername wrote:
| > Which browsers that matter aren't evergreen at this
| point?
|
| Safari on iOS, which is still tied to the OS version and
| not evergreen yet.
| robertoandred wrote:
| Except the OS updates automatically so it's effectively
| evergreen.
| realusername wrote:
| While iOS has a quicker update scheme as Android, it's
| nowhere near as fast as an evergreen browser.
|
| If I look at https://iosref.com/ios-usage there's only
| half of the users on last year update and 15% of users
| lagging behind on a 2+ year old browser version.
|
| So expect your average users to have a new Safari version
| ~1.5 year after it's been out. So the answer to that is
| no, it's not fast enough to be considered evergreen.
| kevingadd wrote:
| Parsing a ton of CSS expansions from a preprocessor is
| likely more expensive in both CPU and RAM than evaluating
| simple functions.
| nine_k wrote:
| Also, the downside of it is that it runs in the browser.
|
| The more universally executable code you have to run in a
| low-trust environment which is a WWW document, the more
| interesting vulnerabilities can creep in.
|
| It's too late though:
| https://portswigger.net/research/ublock-i-exfiltrate-
| exploit...
| troupo wrote:
| I use preprocessors, and I want this in regular CSS precisely
| because I don't want to run a preprocessor (as it is a yet
| another tool that I have to set up, configure, update, maintain
| etc.)
|
| SASS is 16 years now. Less is 15. PostCSS is 10. That it took
| CSS WG this long to adopt useful features from those tools
| reflects quite poorly on the browsers.
| micromacrofoot wrote:
| I write a lot of CSS and I'd prefer not to use a preprocessor
| at all, SASS is great for what it is, but "one less dependency"
| sounds wonderful.
| wccrawford wrote:
| When I think of those pre-processors as if they're jQuery, I
| can see the value of just having this in the browser instead.
|
| I wish it was also stacked like SCSS. Maybe some day.
| lycos wrote:
| You mean nesting like this proposal?
| https://www.w3.org/TR/css-nesting-1/
| wccrawford wrote:
| Yeah, that's the word I was looking for. :)
| uallo wrote:
| CSS nesting is available in all the important browsers
| _today_.
|
| https://caniuse.com/css-nesting
| lelanthran wrote:
| > Is this really necessary?
|
| Yes, because the fewer things you depend on outside of the
| standard, the better.
|
| I like standards, but my recent foray into FE development
| showed me that FE is an unmitigated disaster. Standardising
| helps that.
| JoshTriplett wrote:
| Among many other reasons people have given (including
| eliminating the _need_ for preprocessors): building this into
| the browser also allows for optimization, compared to expanding
| into a huge amount of CSS. If people can send one mixin and
| twenty invocations of it, rather than 20x the amount of CSS,
| then that doesn 't just save bytes, it potentially allows the
| browser to directly generate its internal data structures and
| whatever caches/etc it needs, rather than parsing more textual
| CSS.
| mminer237 wrote:
| I feel like eliminating the compilation step adds more
| client-side processing. Instead of knowing this element gets
| this rule with this color, it has to do so many function
| calls just to find out what elements a rule styles, then it
| has to do all the math to compute all the colors needed just
| to get to where they're starting right now. Instead of the
| publisher doing the compilation once as part of its build
| step, this offloads that compilation to every single visitor.
| wrs wrote:
| This will eliminate the need for CSS preprocessors about as
| much as each annual edition of JavaScript eliminates the need
| for JS preprocessors.
| SahAssar wrote:
| There is only one major JS feature that is missing from
| modern browsers IMO: type annotations (like
| https://github.com/tc39/proposal-type-annotations/ or
| similar) since most people don't want to use JSDoc-based
| ones. Some people will want JSX too.
|
| After those the major use-case for JS preprocessors will
| for most use-cases only be bundling and minification.
| wrs wrote:
| [delayed]
| jszymborski wrote:
| I no longer need a framework or build systems for my
| websites because all the features I used in jQuery are part
| of Javascript today.
|
| I wouldn't need Sass if mixins were implemented in CSS.
|
| It might not eliminate it for everyone, but it will for
| those who care.
| assimpleaspossi wrote:
| Agreed. This is what javascript is for.
| snide wrote:
| This is big. Basic functions are a large reason we've had so much
| tooling around CSS for a long time. First with preprocessors,
| then with with CSS-in-JS. Making this native, and able to run at
| the browser level will solve a large portion of the theming and
| CSS-at-scale problems that most of us have jumped to extra
| tooling to solve.
|
| Over the past few years CSS is getting better and better. They're
| really pushing back on removing reasoning for using anything but
| the vanilla defaults.
| karaterobot wrote:
| The market has already spoken: people want a better developer
| experience with CSS. At this point, if you're working on a non-
| trivial app, you're either using some CSS-in-JS solution, or
| using a pre-processor, but you're probably not just writing CSS
| directly. The specification should include the things we know
| people already need to work with it.
|
| The question is how will it be implemented. Personally, I always
| greatly preferred Stylus' approach, and never understood why Sass
| was so well liked. If the CSS-WG doesn't come up with its own
| weird syntax, it'll probably be something like Sass, which will
| be fine I guess.
| ahmedfromtunis wrote:
| I work on a fairly complex application, and use neither of
| those.
|
| Besides, why would the specification for CSS take into
| consideration anything that's not pure CSS. Do JS maintainers
| take into consideration that people are transpiling javascript
| from typescript/dart/...?
| lioeters wrote:
| The ECMAScript standard did consider transpiled languages -
| for example, by incorporating concepts from CoffeeScript like
| classes, destructuring, arrow functions. For sure they're
| considering ideas from TypeScript.
|
| I'd imagine some advances in the CSS specs are influenced by
| concepts from traspiled languages such as Sass, for example,
| variables and nested selectors.
| cqqxo4zV46cp wrote:
| I don't follow this logic at all. An idea can be rained by
| virtue of it first being included in a preprocessor? postcss
| would like to have a word.
| thr33 wrote:
| was just thinking this. work on a variety of complex webapps
| across multiple frameworks and you'd never catch me dead
| using css-in-js or a preprocessor.
| no_wizard wrote:
| I think its due to Ruby on Rails, when Ruby SASS was a thing,
| it was around the same time of "Peak Rails" (mindshare wise
| certainly) and was used as part of the provided build pipeline.
|
| That, more than anything, popularized SASS in my mind
| karaterobot wrote:
| Yeah! Ruby Sass was my first exposure to CSS preprocessing.
| Such an improvement at the time. I used it for a decade. Then
| some intern at a company I was working for said, "y'all tried
| Stylus?" and within about 10 minutes I was converted. But,
| not everybody had that experience I guess.
| chrismorgan wrote:
| The link corresponding to the actual submission title ("CSS WG
| resolved to officially work on native custom functions and
| mixins"):
|
| https://github.com/w3c/csswg-drafts/issues/9350#issuecomment...
|
| > _RESOLVED: Start ED of css-mixins for CSS Custom Functions and
| Mixins_
| ahmedfromtunis wrote:
| Without proper debugging tools this would be pure hell.
|
| Just look how torturous it is today to work with clac()
| directives using more than 3 operands.
| unconed wrote:
| This feels like a particularly bad case of 'every templating
| system eventually turns into a (bad) programming language'. It
| appears to have global+local variables, functions, mixins with
| positional and named arguments, and so on, all mashed together
| with the existing CSS features like media queries and nested
| selectors. But some of it isn't meaningful in combination, as the
| document itself says.
|
| I have two major objections:
|
| - There is no way that people who are currently writing
| conditional CSS-in-JS would switch to a system with a more
| obscure syntax, where they can't just use the same variables as
| their normal code, pull in imports from shared themes and
| libraries, and so on. This proposal includes basic local scoping
| rules, but they are a poor imitation of what we know works in
| real codebases. So the audience is people who use preprocessors,
| and who get around the lack of e.g. arrays or dictionaries by
| generating sequential variable names.
|
| - Once you actually add functions and imperative control flow,
| much of the existing CSS selector machinery becomes obsolete. Why
| should you wrap things in `@media`, when you could just have a
| variable or function to query? What is the criterium for
| determining whether something should be declarative or
| imperative? Will every feature end up being available in both
| forms? Why or why not?
|
| I find it particularly funny that one of the examples involves
| applying a 'clearfix' to an element, which is a technique from
| the proverbial CSS stone age. That is, they are still inserting
| invisible pseudo-elements to make the layout behave, which shows
| markup and styling are tied together anyway.
|
| The main thing CSS-in-JS lets you do is not automate this sort of
| style hackery, it's to create sensible wrappers and components
| that actually decouple layout from content in a way that is
| practical, stacks cleanly, and maps directly to e.g. how a
| designer does it in Figma.
|
| And instead of adding e.g. endless new color manipulation
| functions in CSS, you should use a proper library for this.
| Whatever argument there was for not allowing CSS to call into JS,
| it starts to look ever less convincing when this is the
| alternative.
|
| Maybe all we need is a more sensible interface between JS and
| CSS, perhaps something patterned after declarative frameworks.
| i.e. They should add a Color type to DOM APIs, instead of adding
| control flow to CSS.
| pphysch wrote:
| This seems fine to me. I won't use it much, but it will make CSS
| "frameworks" a lot more sensible from a dependency perspective
| (i.e. just a bag of pure CSS functions someone wrote), and people
| will continue to create abominations of CSS regardless of the
| available tools.
| buildbot wrote:
| I see there is a while keyword - doesn't this make it turing
| complete? You can now loop, call functions, set variables - you
| could build a full processor emulator in pure css!
| Pet_Ant wrote:
| Sorry, but with increasing the complexity of CSS aren't we just
| adding complexity to the web stack ensuring that only
| Chrome/Firefox/Webkit are the only browsers to ever exist again?
|
| I can't imagine this ever being supported in an ePub reader _not_
| based on one of the above.
|
| At this point, why have W3C involved when Apple, Google, and
| Mozilla could just hash it out amongst themselves?
| andrewmcwatters wrote:
| Yeah, but also you can build browsers that only support
| portions of the specifications considering standards like CSS
| are broken up into various modules.
|
| You don't need to build a browser that supports JavaScript,
| either. You could implement any other language you wanted.
| Python! C?! Go? Rust?
|
| Writing a toy browser that supports small subsets of web
| standards is fun, and not too difficult.
| p4bl0 wrote:
| You could build that but it won't be able to browse the
| actual web. You're just building another platform.
| zamadatix wrote:
| > At this point, why have W3C involved when Apple, Google, and
| Mozilla could just hash it out amongst themselves?
|
| The W3C facilitates that for them sow why reinvent that wheel?
| The W3C is not meant to be independent of other organizations
| involved in making the web rather made up by them.
| Pet_Ant wrote:
| Because the W3C and the IETF should be vendor neutral
| organizations that serve the broader good and general
| interoperability. When it's really 2 of the world's largest
| organisations (we'll see how long Firefox lasts) it's really
| just rubber stamping their agenda.
|
| Maybe it's naive, but it seems like just yet another betrayal
| of the open web and HTML as a part of that.
| nine_k wrote:
| Since CSS tries to stay purely declarative, it would be cool if
| for the functions they introduced a purely functional language.
|
| But it is going to end up being JS, of course.
___________________________________________________________________
(page generated 2024-02-13 23:01 UTC)