- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 22:55:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``New name for `app-region` property?``, and agreed to the following: * `RESOLVED: add a note to the spec mentioning that 'app-region' might be a supported alias for the feature` <details><summary>The full IRC log of that discussion</summary> <fantasai> kyerebo: Wanted to revisit the renaming issue wrto compat<br> <emilio> q+<br> <fantasai> kyerebo: We wanted to rename the property, but we're showing .26% of page loads using 'app-region' and .8% are using '-webkit-app-region'<br> <ntim> See https://github.com/w3c/csswg-drafts/issues/13102#issuecomment-4158686161<br> <fantasai> kyerebo: considering the standardized advice for electron, is it worth the web compatibility risk to rename this<br> <astearns> ack emilio<br> <fantasai> emilio: On what percentage of page loads, does that property have an actual effect?<br> <fantasai> emilio: This is maybe electron and maybe installed web-apps, right?<br> <fantasai> emilio: This seems like a much smaller blast radius<br> <TabAtkins> And Electron is locked on a particular chromium rev, right?<br> <fantasai> kyerebo: I did an http archive query, there were a lot of templates using it<br> <fantasai> kyerebo: It goes to show that it's not a non-trival amount of usage<br> <fantasai> kyerebo: Developers using WCO would need to make changes or deal with breaking websites.<br> <fantasai> emilio: My point is, all those things, they're just not doing anything. Is there a counter that actually counts when that property has an actual effect?<br> <fantasai> emilio: That's much more interesting than how often is this property in a stylesheet<br> <astearns> q?<br> <fantasai> iank_: The use counters for standard web won't have an effect.<br> <ntim> like how many times a window has been dragged from that property<br> <TabAtkins> (what is WCO?)<br> <fantasai> iank_: A lot of sites will use the same HTML/CSS for their electron app, which we don't have insight into<br> <fantasai> emilio: Then other quesiton is can you alias the property so 'app-region' is an alias for 'window-drag'<br> <fantasai> kyerebo: It's already alias of '-webkit-app-region'. But the values are different.<br> <fantasai> emilio: There's precedent for that. For example page-break.<br> <fantasai> emilio: Should be pretty doable.<br> <fantasai> kyerebo: Question here is, if this is already implemented and used by web developers already, is it worth the breaking changes with the increased amount of clarity<br> <fantasai> kyerebo: Especially since not a lot of data<br> <fantasai> emilio: Both of those things are fixable. if you alias the property, there's no breakage. And getting data seems generally doable. Maybe harder for electron, but electron could do their own thing if they need to.<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: The usage on this is not very high and it's not very critical feature that'll fundamentally break the app layout<br> <TabAtkins> fantasai: plus we can alias it. Electron could alias it forever if needed<br> <TabAtkins> fantasai: in terms of clarity, I think the previous name was extremely confusing, nobody knew what it was doing<br> <TabAtkins> fantasai: so I think that's a pretty high value for renaming. even with a higher % of usage i'd recommend renaming<br> <TabAtkins> fantasai: we renamed word-wrap to overflow-wrap; it had double-digit usage. it's not often, but we do it when it's worth ti<br> <ntim> +1 to fantasai<br> <TabAtkins> fantasai: so a 0.8% usage is very low here, especially for something that's not layout-breaking.<br> <TabAtkins> fantasai: so we should rename, allow impls to alias if they need<br> <TabAtkins> astearns: I was wondering if you'd convinced diego<br> <TabAtkins> kyerebo: API owners were pretty adamant about any real usage in the wild should cause us to reconsider renaming<br> <TabAtkins> kyerebo: but I'm hearing that it would be worth it even with some usage. i'll take that back to API owners<br> <dandclark> q+ to confirm the API Owner perspective<br> <TabAtkins> astearns: ok, and note that an alias can be done if they think it's needed for compat<br> <fantasai> https://www.w3.org/TR/css-cascade-4/#aliasing<br> <TabAtkins> fantasai: I don't think we should require an alias in the spec. *Blink* can add one themselves, but WebKit and Firefox don't need it.<br> <astearns> ack dandclark<br> <Zakim> dandclark, you wanted to confirm the API Owner perspective<br> <TabAtkins> dandclark: as an API owner, the % is definitely above the removal threshold<br> <TabAtkins> dandclark: alias seems reasonable<br> <TabAtkins> dandclark: what was the word-wrap threshold? did the spec enumerate the alias?<br> <TabAtkins> fantasai: for that one, it had >10% usage across the web. there was no way to remove it.<br> <ntim> q+<br> <TabAtkins> TabAtkins: The spec does mandate the alias<br> <TabAtkins> fantasai: just because Blink has the alias, doesn't mean that other browsers should need to implement it if there's no compat need for it<br> <TabAtkins> TabAtkins: I think it's fine to have a note in the spec about the optional alias<br> <TabAtkins> ntim: agree with a note<br> <ntim> optional note<br> <TabAtkins> dandclark: note seems fine, to make it clearer for devs<br> <TabAtkins> astearns: should we resolve on the optional alias, or wait?<br> <TabAtkins> kyerebo: with Dan here giving the API owners opinion, I think we can just resolve on the optional alias<br> <TabAtkins> astearns: proposed is we add a note to the spec mentioning that 'app-region' might be a supported alias for the feature<br> <TabAtkins> astearns: objection?<br> <TabAtkins> RESOLVED: add a note to the spec mentioning that 'app-region' might be a supported alias for the feature<br> <dandclark> To be clear on the above I don't speak for all Blink API Owners, this is my own perspective only :)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13102#issuecomment-4173439064 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 22:55:53 UTC