To close the loop: the PR to update MDN <https://github.com/mdn/content/pull/38580> got approved just now and should be deployed later today.
On Monday, March 24, 2025 at 7:15:35 PM UTC+1 Alex Russell wrote: > I see there are 3 LGTMs now, and I'm not going to block, but I want to be > extremely clear that this is not precedent and that folks who have asked > for this change should take note that I might block future changes of this > sort if we see this kind of thing become a habit from the CSS WG. > > Best, > > Alex > > On Tuesday, March 18, 2025 at 12:53:13 PM UTC-7 jacka...@gmail.com wrote: > >> On Mon, Mar 17, 2025 at 11:21 AM Alex Russell <sligh...@chromium.org> >> wrote: >> > Why would we change this? We backed the original intent with the usual >> conditions: once the concrete is poured, it's done. I'm not inclined to >> approve. >> >> That is not, as a general rule, how API owner approval is interpreted, >> or (as far as I know) intended. It also drastically conflicts with >> usual practice, which has substantial weight of precedent behind it - >> while we of course balance the cost of any changes with the benefits, >> we are generally *open* to changes requested by other implementors, >> particularly when we're the first to advance an API. >> >> In this particular case, the cost is virtually nil - it's a brand new >> API with minimal usage, and it's a change to a *default* keyword that >> would rarely be written explicitly anyway. (We only have it at all, >> rather than just relying on a keyword being absent, due to my own API >> design preferences, and the fact that it aids us with a small >> back-compat issue.) The benefit of "make other implementors happier >> with the API" definitely outweighs the costs here, by any reasonable >> metric. >> >> But even in more controversial/costly cases, I strongly contest the >> principle you're trying to establish here. We *do* make changes, even >> ones with compat pain, as part of our unofficial contract with other >> implementors, to make it more palatable to everyone when we push ahead >> faster than other implementors are comfortable with or capable of >> matching. It's always a judgement call, but it leans *much* further >> toward acceptance than "once Blink API owners approve, the concrete is >> poured" does. >> >> ~TJ >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/08e3f30f-8118-4acc-902d-a54365f8af72n%40chromium.org.
