Same issue with text-orientation: https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation#formal_definition

https://drafts.csswg.org/css-writing-modes/#text-orientation

Not sure if there's more.

Same issue with unicode-bidi

Discrete animation or not-animatable can be very close.

The question here is: what do browsers do? Do they ignore the rule or do they jump to the new value?

There may be a difference between the spec and the implementations.

@teoli2003 WebKit does not support animations for the properties I cited.

not animatable = jumps directly at 0s
discrete = jumps depending on the animation duration/timing-function

We have numerous discrete usages that are wrong. I'm looking for a way to have the list of properties where this is actually correct, so I can fix the others. Both CSSTree and w3c/webref use our data for this, I believe.

@sideshowbarker @dontcallmedom Any idea how we could extract this info from the spec? I could try an awk script if nothing obvious appears.

webref never uses data from MDN, and it does collect info from specs on this property, e.g. https://github.com/w3c/webref/blob/main/ed/css/css-writing-modes.json says "direction": { "animationType": "not animatable" }

@sideshowbarker @dontcallmedom Any idea how we could extract this info from the spec? I could try an awk script if nothing obvious appears.

webref never uses data from MDN, and it does collect info from specs on this property, e.g. https://github.com/w3c/webref/blob/main/ed/css/css-writing-modes.json says "direction": { "animationType": "not animatable" }

Given that, it seems like walking the https://github.com/w3c/webref/tree/main/ed/css data is way to programmatically get the authoritative data. But I suppose the remaining hard part is to then come up with some way to programmatically audit the corresponding existing data in mdn/data to identify all the places where it’s wrong.

But I guess a higher-level takeaway from this is, for MDN in the long term, it looks like this is another reminder that we need to seriously consider moving away from manually maintaining the data in mdn/data, and instead switch over to just using data from webref directly.

And maybe that’s something that should be considered for adding to the WebDocs prioritization list — and perhaps also for the Steering Committee to discuss. (Or maybe it’s already been discussed and is already on the prioritization list…)

Thanks a lot, both of you! Yes, we want to move away from using mdn/data. This Quarter, the {{CSSSyntax}} macro stopped using it (and used w3c/webref). I will look to fix the current data for the animation entries and study and open a project for generating these tables from w3c/webref instead of mdn/data (Read: updating the {{CSSInfo}} macro).

The work done on the macro by @wbamberg will help a lot to fix this one. Handling l10n is something that is specific to {{CSSInfo}}, which I think a new system is getting added to Yari.

CSSSyntax update is not merged yet but it is so close. I have thought a bit about CSSInfo and it will be tricky to replicate all the same data as we currently have, partly because some of it is really prose masquerading as data. But we should switch to webref anyway, even if we can't support all the same things.

I'm just wonder, what about intermediate, proprietary and legacy extensions to the syntaxes? W3C specs are providing syntaxes in their "ideal" form, which are crystalized over the time even through several spec levels. Browsers implemented some parts of W3C specs during the specs evolution, and some things were discarded from specs but still working in browsers, at the same time some new things (which are by specs in their final form) are not.
Using webref "as is" for MDN web docs or a CSS syntax validation is not appropriate. Current state of mdn/data is more suitable for these purposes. Imho, webref -> mdn/data sync in one way or another is a single working solution here.

Yes, that's another reason to start with webref -> mdn/data.

But using directly webref doesn't prevent us to have an exception list. We do this for specs.

Anyway, we need to be sure not to have circular dependencies MDN -> CSSTree -> MDN (for example).