WICG

construct-stylesheets

Bikeshed2019–2024

WICG / construct-stylesheets

construct-stylesheets

API for constructing CSS stylesheet objects

Web Development

Explore on GitHub Read Hacker News discussions

5Distinct people

12Mentions

0Explicit recommenders

138GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

API for constructing CSS stylesheet objects

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

mozilla/standards-positions · linked in 3 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2019-04-12 05:11:33 UTC to 2024-11-02 22:11:20 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	3	3
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	2	2
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	4	4
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	1	1

What Hacker News says

12 sources

troupo·Nov 2, 2024

> Frankly put, I think that rule is entirely BS and needs to be completely removed. That's what Google is essentially doing: they put up a "spec", and then just ship their own implementation, all others be damned. Here's the most egregious example: WebHID https://github.com/mozilla/standards-positions/issues/459 --- start quote --- - Asked for position on Dec 1, 2020 - One month later, on Jan 4, 2021, received input: this is not even close to being even a draft for a standard - Two months later, on March 9, 2021, enabled by default and shipped in Chrome 89, and advertised it as fait accompli on web.dev - Two more months later: added 2669 lines of text, "hey, there's this "standard" that we enabled by default, so we won't be able to change it since people probably already depend on it, why don't you take a look at it?" --- end quote --- Th

Read the rest

e requirement to have at least two independent implementations is there to try and prevent this thing exactly: the barreling through of single-vendor or vendor-specific implementations. Another good example: Constructible Stylesheets https://github.com/WICG/construct-stylesheets/issues/45 Even though several implementations existed, the API was still in flux, and the spec had a trivially reproduced race condition. Despite that, Google said that their own project needed it and shipped it as is, and they wouldn't revert it. Of course over the course of several years since then they changed/updated the API to reflect consensus, and fixed the race condition. Again, the process is supposed to make such behavior rare. What we have instead is Google shitting all over standards processes and people cheering them on because "moving the web forward" or something. --- As for WebSQL: I'm also sad it didn't become a standard, but ultimately I came to understand and support Mozilla's position. Short version here: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... Long story here: https://nolanlawson.com/2014/04/26/web-sql-database-in-memor... There's no actual specification for SQLite. You could say "fuck it, we ship SQLite", but then... which version? Which features would you have enabled? What would be your upgrade path alongside SQLite? etc.

In Direct Sockets API in Chrome 131

illiarian·Apr 3, 2023

> With adoptedStyleSheets they're objecting to making backwards incompatible changes Which would not be backwards incompatible if they hadn't shipped something that wasn't agreed on in the first place. Again, slowly: they literally shipped that to production despite loud and explicit objections from both Firefox and Safari. When asked to hide it back behind the flag, "but backwards incompatible change, the framework we're developing is already depending on it" And since you're quoting rniwa, here's the relevant quote https://github.com/WICG/construct-stylesheets/issues/45#issu...: --- start quote --- I feel like I’ve put so much time & energy into making this feature something sane & useful, and all you did was basically to dismiss many of my feedbacks and go with whatever you like and just ship it. And now you’re saying you can’t make ch

Read the rest

anges because you shipped it? I’m sorry but that’s just not how standards work. --- end quote --- > With WebMIDI they're saying they want to do an announcement before making the change. Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely on this behaviour, which they implicitly acknowledge.

In Safari releases are development hell

jefftk·Apr 3, 2023

In both of your examples they're not saying they "cannot hide it behind a flag because people are already using it": * With adoptedStyleSheets they're objecting to making backwards incompatible changes, which is reasonable: everyone hates browsers breaking sites. But there are ways to do this safely, like changing the name of the property (as rniwa suggested https://github.com/WICG/construct-stylesheets/issues/45#issu...) and if that were the only issue I think they'd have done something like that. * With WebMIDI they're saying they want to do an announcement before making the change. (I do think it's nuts how long they're taking to fix this, and if you look on the blink-api-owners-discuss thread you linked you'll see I've been bugging them about it.)

In Safari releases are development hell

illiarian·Apr 3, 2023

Constructible Stylesheets was released despite objections from both Safari and Firefox when it had both badly designed API and an easily reproduced race condition. Literally "Note that .adoptedStyleSheets is used on about ~.8% of page loads in Chrome now. Backwards-incompatible changes are definitely an issue here." https://github.com/WICG/construct-stylesheets/issues/45#issu... --- WebMIDI allows enumeration of devices without asking the user for permission: https://twitter.com/denschub/status/1582730988118867968 (note this is a part of a whole bunch of hardware APIs that Chrome just shipped, no consensus needed) Well, what do you know https://groups.google.com/a/chromium.org/g/blink-api-owners-... "this is a case where we're going from no permission prompt to a permission prompt, I think a PSA and developer communication is a good idea.

Read the rest

Other chromium-based browsers may want to know as well, via these channels." Thankfully, there will be a change. At some point. === These are two I know of, that's why I said "sometimes". As Chrome releases 400 new APIs each year, it's impossible to track them all.

In Safari releases are development hell

dmitriid·Jan 12, 2023

I literally provided just some of the examples. Those are easily verifiable. Web Transport is shipped by default. What was the input from other browsers? Here's the timeline for HID: https://github.com/mozilla/standards-positions/issues/459#is... Constructible Stylesheets: the spec contained a trivially reproducible race condition, the API was badly specified. Google shipped against any objections and refused to bring it back under the flag. Full discussion here: https://github.com/WICG/construct-stylesheets/issues/45. Shipped in Chrome https://github.com/WICG/construct-stylesheets/issues/45#issu... (may be hidden on mobile) despite multiple unresolved issues. Two years later Chrome did add a better API that people originally requested, other issues potentially remain. You may believe in benevolent Google working hand in hand with others

Read the rest

for the betterment of the web. The reality is radically different. Edit: more about hardware APIs: https://news.ycombinator.com/item?id=34356651 Edit2: As to the number of APIs, Chrome actually tracks how much they ship: https://web-confluence.appspot.com/#!/confluence

In SQLite Wasm in the browser backed by the Origin Private File System

dmitriid·Jun 24, 2022

> If there are examples of 'Apple ignoring standards' actually meaning Chrome-only features please tell me one. Easy. The most obvious/glaring one is WebHID. Enjoy the timeline: https://github.com/mozilla/standards-positions/issues/459 It's not just HID, of course. All/most of the hardware APIs are considered harmful by both Safari and Mozilla. Chrome is shipping them enabled by default, and there's no end to clueless developers moaning about this and calling Safari (mostly) and Firefox (from time to time) too slow in "moving the web forward". Needless to say that all those non-standards are pushed forward by Chrome. The less obvious one is Constructable Stylesheets. The spec had an obvious flaw that could lead to easily reproducible deadlocks. And that is on top with other issues with design, API naming etc. A team within Google (lit-htm

Read the rest

l) wanted this feature, so Chrome shipped it against clear objections from both Safari and Firefox. And then refused to move the feature back under a flag because "0.8% of page views in Chrome" were suddenly using this feature. And proceded to gaslight other browsers' developers https://github.com/WICG/construct-stylesheets/issues/45. See e.g. a response to that https://github.com/WICG/construct-stylesheets/issues/45#issu... Of course there's now a "looking ahead" that wants to do exactly what Safari and Mozilla wanted to do in the first place: https://web.dev/constructable-stylesheets/#looking-ahead In general, Chrome pushes 40 to over 100 new Web APIs with each release (that is, every two months). How many of them are actual standards that had actual input from other browser developers? In how many Chrome actually listened and implemented suggestions? https://web-confluence.appspot.com/#!/confluence

In Apple is not defending browser engine choice

dmitriid·Sep 29, 2021

Yeah, the whole thing about Web Components is weird. And is getting increasingly weirder. Quite recently Constructible Stylesheets were released in Chrome: - because lit wanted them - despite Firefox and Safari being against the state of the spec - despite Safari clearly stating they are not going to implement the spec, ever (there was a trivially reproducible race condition in the spec) The entire discussion here: https://github.com/WICG/construct-stylesheets/issues/45#issu...

In What's New in React 18?

dmitriid·Jul 31, 2021

> The negatives are often theoretical They are not theoretical. Too bad webapicontroversy.com has been shut down (it looked like this [1]), but you can scroll down to "defer" and "considered harmful" in Mozilla's positions here: [2] There are more, of course, but they are not visible unless you're willing to follow thousands of issues across hundreds of GitHub repositories. One that springs to mind is, of course Constructible Stylesheets. Mozilla and Safari: the spec describes an algorithm that leads to deadlock in trivial code, we wont implement it until this is fixed. [3] Chrome: ship it, because lit-html (developed by Google) wants it and is already using it. And then procedes to gaslight people and misrepresent their positions (cant' find the relevant link, but at this point I can't find the will to dive into the cesspool). [1] https:

Read the rest

//user-images.githubusercontent.com/32768/108985355-3f... [2] https://mozilla.github.io/standards-positions/ [3] https://github.com/WICG/construct-stylesheets/issues/45#issu...

In “Safari's buggy” is valid criticism, “Safari's behind Chrome in features” is not

dmitriid·Nov 1, 2020

> One could argue whether a feature that has existed for over a decade and is only used by 1-2% of page views is worth improving, but that is not the argument that domenic is making here. > It's interesting that these refer only to the implementation cost to Google, and does not make any reference to costs or benefits to other users of the web platform, which are discussed by other comments. A few months back Chrome shipped Constructible Stylesheets. The proposed specification was strictly opposed by other browser vendors, with Safari stating that they will not ever consider implementing them in the current state [1]. Chrome not only shipped it enabled by default, but refused to bring it back under a flag because "is used on about ~.8% of page loads in Chrome now" [1] (safe to assume, all of them are Google users and users of Google-devel

Read the rest

oped libraries). It's the most recent example (also backed up by numbers provided by Google themselves). I won't even mention the plethora of standards that other browser vendors consider harmful, but are enabled by default in Google. So yes, Google is only concerned by the cost to Chrome, never by the costs or benefits to other users of the web platform. > it looks like the process of discussion does not exist at WhatWG anymore, and that Google basically dictates terms. That is true. The standards process (both w3c/whatwg and tc39) is hijacked by the same 3-4 people from Google, and decisions are rammed through irregardless of anyone. [1] https://github.com/WICG/construct-stylesheets/issues/45#issu... [2] https://github.com/WICG/construct-stylesheets/issues/45#issu...

In Chrome unlikely to support XPath 3.1

dmitriid·Jan 24, 2020

It's about Constructable Stylesheets. The entire discussion is here: https://github.com/WICG/construct-stylesheets/issues/45

In Chrome Is the New IE

dmitriid·Jan 14, 2020

Chrome published a draft of User-Agent Client Hints only a month ago. They are already moving ahead to deprecate user Agent string and saying "Where feature detection fails developers, UA Client Hints are the right path forward" (a thing that's not even a standard yet). Safari has been very wary of this break-neck speed of how Chrome imposes Google's view of standards onto the world. WebKit team has even walked away from proposals when concerns were not addressed (sadly, I can't find the link in GitHub issues right now. Edit: [1]). And yes, lack of manpower is another pressing concern. [1] https://github.com/WICG/construct-stylesheets/issues/45#issu... "Now I consider this issue as an absolute show stopper. I don't think we want to ever implement this feature in WebKit unless this issue is resolved."

In Blink-Dev – Intent to Deprecate and Freeze: The User-Agent string

lstamour·Apr 12, 2019

True, I don’t have benchmarks, but there was a time period where shadow DOM was popularly disabled due to performance hits, but perhaps it was all the performance hit of polyfills and less efficient implementations in browsers. https://github.com/WICG/construct-stylesheets/blob/gh-pages/... is interesting, though Sass still looks unlikely to be added to the browser so we’ll always need some amount of CSS compilation if you want CSS nesting the way you expect it in Sass. Here’s more documentation on constructible stylesheets: https://developers.google.com/web/updates/2019/02/constructa... I wasn’t aware of this because this stuff is being developed and released so dang quickly! (I do worry that APIs developed in relative haste might be replaced or iterated on in relative haste, especially if they aren’t adopted widely first...)

In Web Components could replace frontend frameworks?