Definition of MathML Length

[fred-wang]

I think it's not nice that we have a definition of MathML Length different from CSS, but I guess we cannot really solve this.

The RelaxNG pattern is pattern = '\s*((-?[0-9]([0-9].?|.[0-9])[0-9](e[mx]|in|cm|mm|p[xtc]|%)?)|(negative)?((very){0,2}thi(n|ck)|medium)mathspace)\s*'

The definition is https://mathml-refresh.github.io/mathml/chapter2.html#fund.units

Note that "Since some applications are inconsistent about normalization of whitespace, for maximum interoperability it is advisable to use only a single whitespace character for separating parts of a value. Moreover, leading and trailing whitespace in attribute values should be avoided. ". I think we should be more explicit about white spaces...

My proposal is to:

• Be explicit about allowing leading/trailing space characters, as defined in Align definition of space characters with HTML5  #21
• Remove support from nonzero unitless value Remove support for nonzero unitless values for MathML lengths #24
• Replace definition of number with HTML5 Align definition of numbers with CSS #23

Then this definition should go into MathML Core.

Update: Some people proposed to actually removed namedspace values too #75 which would make things even closer to HTML/CSS lengths.

[davidcarlisle]

@fred-wang I added a placeholder section to the core draft, feel free to edit, I sketched out dropping all support for mathml-specific length syntax from core, including named lengths. that may be too aggressive or controversial, I also added markup to allow links back to this issue tracker.

[dani31415]

CSS currently have 3 levels

• https://www.w3.org/TR/CSS22/syndata.html#length-units
• https://www.w3.org/TR/css-values-3/#lengths
• https://www.w3.org/TR/css-values-4/#lengths

If a match between MathML and HTML5 has to be done, a level from the above list has also to be chosen.

[fred-wang]

If a match between MathML and HTML5 has to be done, a level from the above list has also to be chosen.

Yes, I guess we should use whatever is used in browsers... Using definitions in WHATWG's HTML5 could probably avoid the version number issues.

[fred-wang]

@fred-wang I added a placeholder section to the core draft, feel free to edit, I sketched out dropping all support for mathml-specific length syntax from core, including named lengths. that may be too aggressive or controversial, I also added markup to allow links back to this issue tracker.

I opened #75 for the namedspace discussion.

[physikerwelt]

can we also get rid of the string constants

(negative)?((very){0,2}thi(n|ck)|medium)mathspace)

[fred-wang]

can we also get rid of the string constants

(negative)?((very){0,2}thi(n|ck)|medium)mathspace)

That's #75

[NSoiffer]

On 29/4/19 call, agreed to drop unitless values except 0 from core.
The call agreed that the handling of whitespace in attribute values should follow whatever CSS does.

The full spec will continue to allow namedspaces.

[fred-wang]

cc @rwlbuis @bkardell

[rwlbuis]

I am doing an experiment to support MathML lengths using CSS subsystem in chromium, same as SVG does for its attributes. Findings:

• CSS has slightly different parsing rules for numbers, after the decimal dot at least one number should be present, i.e. 7.em would not be accepted. HTML has the same restriction.

• modern CSS has new units, quarter-millimeter (https://www.w3.org/TR/css-values-4/#absolute-lengths) and various viewport units (https://www.w3.org/TR/css-values-4/#viewport-relative-lengths). Right now in my experiment I disable support for that.

• while not enabled in my experiment, it would be trivial to start parsing calc(). But AFAIK SVG does not do that, so maybe so shouldn't we?

[rwlbuis]

Another interesting point is whether to support exponents or not.
For SVG 1.1 it is supported for attributes but not in stylesheets:
https://www.w3.org/TR/SVG11/types.html#DataTypeLength

For SVG 2 it just refers to CSS, so will support exponents:
https://svgwg.org/svg2-draft/geometry.html#Y (length-percentage link)

[NSoiffer]

The decision from the meeting was that MathML core should accept the same values/syntax as CSS. MathML full is similar except that it adds the named spaces. If CSS supports exponents, that MathML should do so also. Same for new units. Potentially, the full spec could discourage viewport relative units because they are not meaningful in not CSS environments.

…

On Thu, May 2, 2019 at 11:41 AM Rob Buis ***@***.***> wrote: Another interesting point is whether to support exponents or not. For SVG 1.1 it is supported for attributes but not in stylesheets: https://www.w3.org/TR/SVG11/types.html#DataTypeLength For SVG 2 it just refers to CSS, so will support exponents: https://svgwg.org/svg2-draft/geometry.html#Y (length-percentage link) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALZM3HCUWPLHPEXKLVBR6TPTMYW7ANCNFSM4G24HP5A> .

[fred-wang]

* while not enabled in my experiment, it would be trivial to start parsing calc(). But AFAIK SVG does not do that, so maybe so shouldn't we?

@rwlbuis What about CSS variables? ( https://drafts.csswg.org/css-variables/ )

I'm wondering whether we can do things like:

mfrac {
  --thin: 50%;
  --medium: 100%;
  --thick: 200%;
}

<mfrac linethickness="var(--thin)">

or even

math {
  --thickmathspace: 4em;
  --thinmathspace: .5em;
}

<mspace width="var(--thickmathspace)" height="calc(var(--thickmathspace) - 2 * var(--thinmathspace) + 1px)"></mspace>

which would give users the possibility to do things removed elsewhere ( #75 #5 #4 ...).

[rwlbuis]

@rwlbuis What about CSS variables? ( https://drafts.csswg.org/css-variables/ )

That is a great find, I forgot about them. I verified that in chromium CSS variables works in the SVG-in-HTML case, so it seems the way to go, but we may want to check with the SVG WG.

[NSoiffer]

Interesting!

First off, caniuse says that this is implemented in all the major modern browsers. So it seems safe to use.

Does this really allow us to keep named quantity such as mediumspace and thick in the spec, or just provide an easy target for polyfills? It seems they would need to have the -- prefix, but maybe that is something that is easy for a browser implementation to do?

[bkardell]

Not sure I'm following so feel free to ignore if I've misunderstood but

-- is supposed to be reserved for author space afaik there's no precedent for browsers setting variables in this particular way (note: should look up recentish discussions about environment properties as the discussion is probably relevant and I could be wrong).. but.. CSS has always had this mechanism for non standard extension of all of it's 'parts' ( properties, pseudoclasses, fns, etc) so that the parser can stay forward compatible. The pattern has always been dash, vendor prefix, dash - like -moz-blah. Custom anything in CSS will follow this same pattern, it's just that there is no vendor prefix, so you get -- meaning author defined rather than vendor defined.

That said, variables in CSS are actually custom properties - and that's a thing vendors have been doing, as I say, forever.

otherwise they are just vendor prefixed things without a vendor (ie -moz-blah becomes -- because there is no vendor).

[fred-wang]

Resolution:

• Definition of MathML Length #63 (comment)
• https://lists.w3.org/Archives/Public/public-mathml4/2019May/0006.html there are some length attributes that only make sense in a browser. ns: we should caution against using them in non-web contexts
• https://lists.w3.org/Archives/Public/public-mathml4/2019Apr/0022.html

[fred-wang]

The core spec now refers to from CSS.

[fred-wang]

There are tests for that, so closing.