Checked the websites with potential breakages, don't observe any breakages. The only website with visual differences is https://css3test.com/#css-values-5, but it "checks which CSS3 features the browser recognizes, not whether they are implemented correctly." (pasted from the website) and links to CSS Values 5 attr() spec: https://www.w3.org/TR/css-values-5/#attr-notation, so should be updated accordingly.
Updated the doc <https://docs.google.com/document/d/1xrREMWVQiQbDr6OvALHvBko7hokpM44nTPxzEGE7PSs/edit?usp=sharing> with the findings. On Tue, Mar 18, 2025 at 8:52 PM Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Mon, Mar 17, 2025 at 11:21 AM Alex Russell <slightly...@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/CAAO7W_CFxpEZk%2BsdK3b8pfOX%3DPo0bdXxNnHWYvB8j2TeiqEVDw%40mail.gmail.com.
