search

w3c / mathml

MathML4 editors draft
https://w3c.github.io/mathml/
Other
61 stars 18 forks source link

Remove/Deprecate mglyph element #25

Open fred-wang opened 5 years ago

fred-wang commented 5 years ago

Currently this is not defined in MathML Core, only MathML 4.

In any case, I think the idea of mglyph is a rather hacky temporary workaround. Ideally, people use characters defined in Unicode. These days, they should have enough characters available to write math.

physikerwelt commented 5 years ago

discussed in the telco on 2019-02-25:

pdfion commented 5 years ago

There was apparently a technology proposed for CJK gaiji that would do just fine for supplemental math characters: SING and replace . I have no idea if this is viewed as a current technology. Anyone know? References:

pdfion commented 5 years ago

That should read SING could replace mglyph.

fred-wang commented 5 years ago

@pdfion Thanks for the information. I think someone should investigate more, maybe contact people from CSS / Font WG to see if that's the kind of features already available in browsers ( https://drafts.csswg.org/css-fonts-3/ ). In any case, that aligns with the idea that this is something that has to be provided by CSS/font so we should just rely on it instead of defining our own feature in MathML.

(PS: I've fixed the formatting in your comment)

dani31415 commented 5 years ago

While it is somehow acceptable that MathML4 is MathML3 + CSS - deprecation of attributes, if we remove the mglyph, we loss the capability of inserting images in MathML (for the case that the MathML is not part of an HTML 5).

I suggested Stand-alone MathML profile #58. Just in case we forgot that MathML should also exist outside web pages.

Maybe you are referring to MathML core. In which case the issue should be relaveled to core.

NSoiffer commented 5 years ago

@dani31415: is WIRIS using mglyph? If so, can you elaborate on the use case?

davidcarlisle commented 5 years ago

@dani31415 I agree that we should ensure that mathml is usable in non css environments and that this means we should keep elements such as mglyph in full (not core) unless there is an alternative available.

fred-wang commented 5 years ago

I'm interested in removing it from core (it is already not present, but just to confirm). Then I'll let others decide what to do in other specs, whether to write a polyfill etc

fred-wang commented 5 years ago

From https://lists.w3.org/Archives/Public/public-mathml4/2019Mar/0026.html We decided to keep in full. We should experiment with polyfill to see if we can remove it from core.

For now, nobody reported any use of mglyph in #55

davidcarlisle commented 4 years ago

I think mglyh should definitely be in full (despite the unfortunate "mglyph" name denoting its original motivation) it's needed for image inclusion on non html contexts.

But I agree it can go from core (and so the references to it in html5 can go as well).

NSoiffer commented 4 years ago

This was discussed in the Core CG meeting today.

After the call, @bkardell noted that neither Firefox nor Safari support mglyph.

In #55, no one reports using it.

Given non-support and minuscule(?) usage, I don't see a reason to move toward adding img to full nor to support in core. A polyfill is pretty easy to do.

The CG agreed to come back to this next week and see if anyone comes up with other info.

dginev commented 2 years ago

Adding an example, and a mention of <svg>:

In the TeX-authoring paradigm, authors sometimes interleave diagram code with equation code. For those inputs, tools such as latexml and tex4ht can at times attempt to map both math syntax and diagram syntax into transparent textual formats. Namely, by generating interleaved MathML+SVG (with possibly nested SVG+MathML, and vice versa).

latexml's current preference is to generate an <mtext><svg>...</svg></mtext> for such cases, with the SVG content deposited inline.

That is probably "good enough", but not particularly "clean" in the Presentation MathML sense, as indeed sometimes we have clear indications from the authors that the SVG content stands for an <mi> identifier or an <mo> operator. Here are 4 example screenshots from an arXiv article, for some illustration.

I am uncertain if <mglyph> offers an advantage to <mtext> in theory, but I thought to at least bring an example where we use <svg> directly inline. I am bringing this up today because latexml development refocused on this particular kind of content this week, and I recalled the mglyph discussion here.

We could likely reorganize to use <img src="name.svg"> instead, if need be. The main subtlety I see for that transition is managing href targets to point to an external URL rather than the local document. Why? Think of arrows annotated with a link to the theorem they use for the implied transition (see MathML in the details, but such links can also occur from within SVG diagrams).

```xml ⇒ Thm 2.3 ```

Edit: To make my comment mildly more forward-facing, maybe the point I would bring up for consideration is that if a change is made to allow <img> inside token elements (notably <mi> and <mo>), that we may also consider allowing <svg> as well.

davidcarlisle commented 2 years ago

For your final "Edit" note, in mathml-in-html <img and <svg are already allowed in <mi> (by the spec and the parser, although some validators chose to flag token elements other than mtext) so no change should be necessary.

The main justification for <mglyph as for <maction, is systems supporting MathML but not HTML, as it gives a "native" MathML way to reference an image.

NSoiffer commented 2 weeks ago

Deprecating mglyph was discussed at the 5-9-2024 meeting. The main points were:

We had a straw poll: 4 people were in favor of deprecating it; 2 people were neutral.

NSoiffer commented 2 weeks ago

At the 12-9-2024 meeting, there was not consensus to deprecate or remove mglyph. @davidcarlisle felt that because MS Office uses it (on input, it only uses the alt text and its not clear that it generates it), he felt it would be bad to break office/word's implementation even though it is not used in the web context. @MurrayIII was also on the fence. @davidcarlisle also felt that, like maction, it provides a neutral target for images that can be mapped to other tags in whatever environment contains the math.

The conclusion was to add some text to discourage its use and suggest using img instead if targeting the web.

This issue can be closed once that text is added.