Add CSS properties defined in MathML Core

[teoli2003]

Hi!

On MDN, we are using w3c/webref (instead of our old mdn/data) to extract the formal syntax of CSS properties.

In mdn/content#18641, we have noticed that the formal syntax of the properties defined in the MathML Core spec is missing from w3c/webref: math-style and math-def (and maybe others)

Spec where these are defined: https://w3c.github.io/mathml-core/#css-extensions-for-math-layout

(MathML Core is a subset of the original MathML specs)

cc/ @fred-wang who is adapting MDN's MathML documentation to match MathML-core.

[tidoust]

The formal syntax is missing because the spec currently does not follow the usual syntax conventions used in CSS specs to define properties. For instance, the table that defines math-style does not have the the propdef class that the crawler uses to detect that this is a property definition (e.g. as in https://drafts.csswg.org/css-flexbox-1/#flex-grow-property), and new values of text-transform should be defined using a table as well (e.g. as in https://drafts.csswg.org/css-contain-3/#contain-property).

Would you be able to file a PR against the spec by any chance?

[teoli2003]

I can (and would be happy to do this: I've never created a PR towards a spec; so it would be a useful experiment for me), unless @fred-wang prefers to do it himself.

[fred-wang]

@teoli2003 I plan to take a look at this. Thanks for the reminder.

[fred-wang]

@teoli2003 @tidoust I updated https://w3c.github.io/mathml-core/#css-extensions-for-math-layout ; below this is the output of reffy --spec mathml-core --module css. Hopefully this is enough for w3c/webref & MDN:

"css": {
   "properties": {
     "display-inside": {
       "name": "display-inside",
       "newValues": "math"
     },
     "text-transform": {
       "name": "text-transform",
       "newValues": "math-auto | math-bold | math-italic | math-bold-italic | math-double-struck | math-bold-fraktur | math-script | math-bold-script | math-fraktur | math-sans-serif | math-bold-sans-serif | math-sans-serif-italic | math-sans-serif-bold-italic | math-monospace | math-initial | math-tailed | math-looped | math-stretched"
     },
     "math-style": {
       "name": "math-style",
       "value": "normal | compact",
       "initial": "normal",
       "appliesTo": "All elements",
       "inherited": "yes",
       "percentages": "n/a",
       "computedValue": "specified keyword",
       "canonicalOrder": "n/a",
       "animationType": "not animatable",
       "media": "visual"
     },
     "math-shift": {
       "name": "math-shift",
       "value": "normal | compact",
       "initial": "normal",
       "appliesTo": "All elements",
       "inherited": "yes",
       "percentages": "n/a",
       "computedValue": "specified keyword",
       "canonicalOrder": "n/a",
       "animationType": "not animatable",
       "media": "visual"
     },
     "math-depth": {
       "name": "math-depth",
       "value": "auto-add | add(<integer>) | <integer>",
       "initial": "0",
       "appliesTo": "All elements",
       "inherited": "yes",
       "percentages": "n/a",
       "computedValue": "an integer, see below",
       "canonicalOrder": "n/a",
       "animationType": "not animatable",
       "media": "visual"
     }
   },

[dontcallmedom]

now reflected in https://github.com/w3c/webref/blob/main/ed/css/mathml-core.json - it should land in the next release of the CSS package (probably early next week)

[dontcallmedom]

@fred-wang looking at it in more details, there is a problem: the spec markup implies that display-inside is a property to which you add a new possible value, whereas you're in fact adding a possible value to valuespace that describes the display property. I don't think there is a convention to extend a valuespace - so you would either have to update the markup to make it a value space and describe the full set of values (i.e. the ones in css-display + math), or you would have to upstream the addition of the math value in CSS display (which is probably the best way to avoid potential monkey patching issues).

(meanwhile, I think we'll find a way to fix this in webref while this gets fixed upstream)

[fred-wang]

@dontcallmedom Thanks. I pushed a fix to instead add new values to display.