display: math Define what would happen if author sets mathml { display: block; }

[fred-wang]

Just copying this from the hackfest notes by @bkardell @fantasai

• Need to also evaluate Web-compat of introducing display: math, in case authors are already setting display: block etc. and expecting no change to internal contents.

"mathml" is not an element, so I'm not sure what it is about. Also, I don't think MathML authors currently change the CSS display values of MathML elements.

[NSoiffer]

I suspect that what was meant was math {display: block;}, not "mathml".

Someone can set a 'display' attribute with value "block"|"inline" on a math tag. I think that the issue that was raised is how does that interact (if at all) with the CSS 'display' property which can take on those values along with "math" (#56).

[fred-wang]

OK I think that makes more sense for math. We discussed something related with @bfgeek during BlinkOn 11 and our conclusion is that we actually want to introduce two display values "inline-math" and "math" (similar to what is done for other display values) so that it integrates better with the CSS logic & browser implementation. Then the display attribute values "block" and "inline" will be mapped respectively to the CSS "math" and "inline-math" display values.

@rwlbuis uploaded a patch to prepare that: https://chromium-review.googlesource.com/c/chromium/src/+/1917207

[NSoiffer]

Which takes precedence, the attr value display='block' or the CSS property math: {display: inline-math;} if both are specified? The core spec currently only says this:

The dir attribute, if present, must be an ASCII case-insensitive match to ltr or ltr. It is mapped to the direction CSS property. This attribute is used to set the directionality of math formulas, which is often rtl in Arabic speaking world.

I think a similar issue exists for dir="..." and the CSS property direction: ...;. There might be other cases.

I thought we had discussed this (perhaps in general), but I can't find any discussion. I suspect something similar is lurking in HTML docs due to legacy issues, but HTML5 seems to have cleaned up the ones I checked. If true, we should follow that precedent.

[bkardell]

I'd imagine specificity and Cascade would determine which was used. Any author set attribute maps in the UA sheet to a rule. Any author set style should override that origin.

[NSoiffer]

If I have

math { direction: rtl;}

and

<math dir="ltr"> <mtext>Hello </mtext> </math>

which wins? They are both exactly the same specificity. Similarly (without the external style specification):

<math dir="ltr" style="direction: rtl;"> <mtext>Hello </mtext> </math>

Going back to the case with an external style specification on math and markup

<math> <mrow dir="ltr"><mtext>Hello </mtext> </mrow></math>

I would think 'ltr' is used on "Hello".However, in starting in on the polyfill, I don't see a way to find out if there is a CSS rule

mtext{ direction: rtl;}

or not. I can find out if there is a inline CSS rule and I can get the computed style, but the computed style could be coming from something set on an mtext, an mrow, or the math element. If there isn't a way to distinguish these cases, maybe that tells informs the discussion as to how we need to resolve this?

[bkardell]

I'm pretty sure they are different origins in the cascade, so for example.. the hidden attribute in html maps to display: none in the UA rules. If an author sets this to display block, that is in the author origin and so it 'wins' ... https://codepen.io/bkardell/pen/ExVOjoN

Is this different?

[faceless2]

This block is in your proposed user-agent stylesheet

math[display="block" i] {
  display: math;
  text-align: center;
  math-style: display;
}
math[display="inline" i] {
  display: inline-math;
  math-style: inline;
}

So <math display="block" style="display: inline-math"> would see inline-math win, as it has a higher specificity.

Re. directionality, the HTML5 user-agent stylesheet has this:

@namespace url(http://www.w3.org/1999/xhtml);
[dir]:dir(ltr), bdi:dir(ltr), input[type=tel i]:dir(ltr) { direction: ltr; }
[dir]:dir(rtl), bdi:dir(rtl) { direction: rtl; }

Which only applies to the HTML namespace, so you'd probably want something similar for MathML. I believe it's done that way because the HTML dir attribute has an allowable value of "auto", which has functionality which can't be mapped directly to CSS. I don't know if this applies to MathML, if not you could just have

[dir=rtl] { direction: rtl }
[dir=ltr] { direction: ltr }

If there's no stylesheet rule for an attribute then (according to https://mathml-refresh.github.io/mathml/#order-of-processing-attributes-versus-style-sheets) any attribute not explicitly handled in the user-agent stylesheet would be classed as a "non-CSS presentational hint', which references this from CSS2.1:

For other languages, all document language-based styling must be translated to the corresponding CSS and either enter the cascade at the user agent level or, as with HTML presentational hints, be treated as author level rules with a specificity of zero placed at the start of the author style sheet.

That's how it's done in SVG too - <rect fill="red" style="fill:blue"/> will be blue, as the "fill" attribute is classed as a presentational hint, so has a lower specificity.

[fred-wang]

Yes, what @bkardell and @faceless explained, this is defined by CSS cascading rules with "UA-rules" VS "user attribute mapped to style" VS "author-specified rules" specificity. MathML Core does not need to explain that, just how to set the style.

[fred-wang]

I opened #214 and #215