Open Bug 1574751 Opened 7 years ago Updated 1 year ago

Align definition of MathML length values on CSS <length-percentage>

Categories

(Core :: MathML, defect)

Product:
Core
Component:
MathML
Type:
defect

Tracking

()

People

(Reporter: fwang, Assigned: fwang)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, site-compat)

... and use the CSS parser instead.

Main differences:

They are probably a few minor differences that I hope won't affect users:

  • leading/trailing whitespace in attribute value: The MathML CG has not decided about this yet. I guess it's not a big burden to keep supporting it, though.
  • definition of numbers: MathML3 allows things like "5." (no digit after the dot) which are not supported by CSS and conversely CSS allows things like "1E1em" (E notation) which are not supported by MathML3. The MathML CG agrees it should be safe to move to the CSS definition: https://github.com/mathml-refresh/mathml/issues/23

MathML Core defines lengths here, relying on CSS:
https://mathml-refresh.github.io/mathml-core/#types-for-mathml-attribute-values

For now, mpadded still has its own syntax:
https://mathml-refresh.github.io/mathml-core/#attribute-mpadded-width

No longer depends on: 1574749
Depends on: 1574749

Quick analysis: https://searchfox.org/mozilla-central/search?q=ParseNumericValue

*: scripminsize (see bug 1548471) and mathsize (mapped to font-size).
mtable: width (mapped to width)
mo: lspace, rspace, minsize, maxsize (default/reference values involved DOM/operator dictionary)
mfrac@linethickness (default/reference values is read from the font)
msub/msup/msubsup/mmultiscripts: subscriptshift and superscriptshift (see https://github.com/mathml-refresh/mathml/issues/27)
mspace: width, height, depth (default/reference values are 0)

mpadded: width, height and depth. This element has its own syntax and uses nsMathMLElement::ParseNumericValue to parse some token.
mtable/mtr/mtd: rowspacing, columnspacing, framespacing (no idea what we will do with these yet, MathML core only describes simple table layout). This also relies on nsMathMLElement::ParseNumericValue as a helper to parse a more general syntax.

MathML 3:
https://www.w3.org/TR/MathML3/chapter2.html#fund.units

  • a number: an optional prefix of "-" (U+002D), followed by a a string of
    decimal digits with up to one decimal point (U+002E).
    (the RelaxNG schema https://www.w3.org/TR/MathML3/appendixa.html#parsing_length requires at least one digit and that's what we support.)
  • or a number followed by a unit
    • units are em, ex, px, in, cm, mm, pt, pc, %
  • or a namedspace: "thickmathspace" etc.

MathML Core / CSS:
https://mathml-refresh.github.io/mathml-core/#dfn-length-percentage

  • length-percentage:

    • a length: number immediately followed by a unit identifier
      • unit is em, ex, ch, rem, vw, vh, vmin, vmax, cm, mm, Q, in, pc, pt or px.
      • unit is optional for 0.
    • or a percentage: number immediately followed by a '%'

  • number:

    • integer: one or more decimal digits 0 through 9
    • or zero or more decimal digits followed by a dot (.) followed by one or
      more decimal digits and optionally an exponent composed of "e" or "E" and
      an integer.
    • may be immediately preceded by - or +.

@emilio: So if I'm correct after we remove namedspace (bug 1574750) and nonzero unitless (bug 1574749) then the only remaining possible regression is the case when the number has a dot but no digits after it e.g. "123456789." ; In that case, for now we coud just update nsMathMLElement::ParseNumericValue to treat this case as invalid. I wonder if we could just do an "intent to unship" with that change directly rather than using counters / deprecation warning. WDYT?

Flags: needinfo?(emilio)
Depends on: 1575596

CSS has also the case of preceding comments or such right? Is /**/10px supposed to parse or not?

I think changing ParseNumericValue would be fine, but probably would be better with a use counter, or at the very least without a runtime switch.

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

CSS has also the case of preceding comments or such right? Is /**/10px supposed to parse or not?

I copied the definition from here: https://www.w3.org/TR/css-values-3/#typedef-length-percentage
Comments are not part of this definition.

I think changing ParseNumericValue would be fine, but probably would be better with a use counter, or at the very least without a runtime switch.

The tentative change is small: https://phabricator.services.mozilla.com/D42907

Do you mean with a runtime switch?

So you pref to do an intent to deprecate + warning / counter as in bug 1575542?

Flags: needinfo?(emilio)

(In reply to Frédéric Wang (:fredw) from comment #4)

Do you mean with a runtime switch?

Err, yes. Intent to unship for that change + a pref to default-error for that case seems ok to me.

Flags: needinfo?(emilio)

(In reply to Frédéric Wang (:fredw) from comment #0)

  • leading/trailing whitespace in attribute value: The MathML CG has not decided about this yet. I guess it's not a big burden to keep supporting it, though.

For the record, it's https://github.com/mathml-refresh/mathml/issues/122

Idea after discussion with Emilio:

Can you please complete that, pointing to the relevant part of the code?

Flags: needinfo?(emilio)

Yeah, so:

Maybe it'd be worth trying to unify a bit the mapped attribute setup... Boris, do you know why the SVG setup looks like it does rather than reusing nsMappedAttributes? Or vice-versa, couldn't we have a declaration block in the slots in Element and unify all of HTML / SVG / MathML handling of presentation attributes?

I suspect that may also fix the bug where we reorder attributes due to some of them being mapped. This last bit is probably work that shouldn't block the MathML stuff either way (should be done either before that or once that lands).

Flags: needinfo?(emilio) → needinfo?(bzbarsky)

Boris, do you know why the SVG setup looks like it does rather than reusing nsMappedAttributes?

nsMappedAttributes is designed to solve a specific problem: a web page that has 5000 <font face="Arial"> elements on it. nsMappedAttributes, in that setup, produces a single declaration block containing font-family: Arial that is shared by all the elements involved. This made a lot of sense in the early 2000s, because that style of HTML was quite common at the time. I don't know how common it is nowadays; it would be interesting to get some telemetry about how much sharing we get out of nsMappedAttributes in practice.

In SVG, my understanding is that it's not very common to have identical sets of mapped attributes across multiple elements, because in practice that would mean that those elements are positioned on top of each other and look identical or close to it, which is not what SVG authors typically want. So there was no particular reason to add the overhead of nsMappedAttributes there, because there would not be much of a win from doing it, if any.

At least I would say that's the main reason we haven't unified them in the recent past. I don't know whether the initial implementation actually considered any of that or just Did Something Because It Worked.

Flags: needinfo?(bzbarsky)

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #9)

Boris, do you know why the SVG setup looks like it does rather than reusing nsMappedAttributes?

nsMappedAttributes is designed to solve a specific problem: a web page that has 5000 <font face="Arial"> elements on it. nsMappedAttributes, in that setup, produces a single declaration block containing font-family: Arial that is shared by all the elements involved. This made a lot of sense in the early 2000s, because that style of HTML was quite common at the time. I don't know how common it is nowadays; it would be interesting to get some telemetry about how much sharing we get out of nsMappedAttributes in practice.

In SVG, my understanding is that it's not very common to have identical sets of mapped attributes across multiple elements, because in practice that would mean that those elements are positioned on top of each other and look identical or close to it, which is not what SVG authors typically want. So there was no particular reason to add the overhead of nsMappedAttributes there, because there would not be much of a win from doing it, if any.

For what is worth I'm not too clear that it wouldn't be worth sharing in SVG, given <svg:use> and co. See bug 1485402 for example.

Though now that declaration blocks are not stored in a linked list in the rule tree (bug 1493420) the performance impact of having them should be minor, it'd be just a memory optimization (maybe still worth it).

Right, pre-stylo sharing declaration blocks was both a memory optimization and a performance optimization (because it enabled a lot more caching to work). It's possible it's not as much of a win now.

Well I guess with stylo it also enables to share styles across siblings and such, though probably much less indeed...

Depends on: 1793452
Depends on: 1793549
Severity: normal → S3

Simon Fraser reported an interesting bug for WebKit: https://bugs.webkit.org/show_bug.cgi?id=281232

See Also: → https://bugs.webkit.org/show_bug.cgi?id=281232
Depends on: 1924672
You need to log in before you can comment on or make changes to this bug.