Add contenteditable to the list of attributes shared by all MathML elements

[dani31415]

Since contenteditable (HTML spec) is a valid attribute for any HTML element, it make sense to add it to the list of attributes shared by all MathML elements (MathML spec).

I do not assume any specific behavior for the UA when the contenteditable is present. The only requirement is that the attribute be valid and available in the DOM. From this point of view, this has a null impact on any implementation of MathML. For example, the current implementation of MathML on Firefox allows a clumsy edition of formulas when contenteditable is inherited as true.

The attribute contenteditable can be used a as convenient way to express that some parts of a formula are (or are not) editable. This is an HTML5 friendly way to allow blanks inside a Math formula (for example, it is easy to imagine a fill-the-blank math questionnaire), respect to an alternative solution based on an maction.

[NSoiffer]

In 2012, the MathML WG started to work on a group note Fill In the Blank with MathML <https://www.w3.org/Math/Documents/Notes/blanks/fill_in_the_blank.html#Blanks_in_HTML_Pages>. This presents an alternative idea of using a class (*MathML_Blank*) to flag "blanks". The note was never finished and has no official status. However, it is something to look at when thinking about the issue. The lack of a standard on how to represent a "blank" is a hole in the spec IMHO.

…

On Fri, Feb 15, 2019 at 10:41 AM Daniel Marques ***@***.***> wrote: Since contenteditable (HTML spec <https://www.w3.org/TR/2008/WD-html5-20080610/editing.html>) is a valid attribute for any HTML element, it make sense to add it to the list of attributes shared by all MathML elements (MathML spec <https://www.w3.org/TR/MathML3/chapter2.html#fund.globatt>). I do not assume any specific behavior for the UA when the contenteditable is present. The only requirement is that the attribute be valid and available in the DOM. From this point of view, this has a null impact on any implementation of MathML. For example, the current implementation of MathML on Firefox allows a clumsy edition of formulas when contenteditable is inherited as true. The attribute contenteditable can be used a as convenient way to express that some parts of a formula are (or are not) editable. This is an HTML5 friendly way to allow blanks inside a Math formula (for example, it is easy to imagine a fill-the-blank math questionnaire), respect to an alternative solution based on an maction. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/mathml-refresh/mathml-core/issues/7>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABeWbKXxZHc879KsnIyGDw3JsvkTCq3Eks5vNv9rgaJpZM4a-N1W> .

[fred-wang]

I believe this kind of extension with vague implementation requirement should go to the bigger MathML 4 spec https://github.com/mathml-refresh/mathml , not the MathML core spec.

[dani31415]

The issue does not require implementation. The vagueness does not came from the MathML implementation but from the browser itself.

You can enable contenteditable currently in Firefox and affects also MathML Whether you want it or not, contenteditable is there and inherited from any parent that sets it.

That the issue should be part of MathML 4, that's probably true. Do you know whether it is possible to move issues in github?

[davidcarlisle]

Issues can be moved between the repositories but as discussed on the email list just now, I think the current proposal is to move most of this kind of issue here (and then label it if it also impacts on full mathml) personally I'd like to see such global html attributes allowed, we make use of it here, allowing annotation of pages (which works so much more naturally in firefox with contenteditable mathml than in browsers where you are interacting with the mathjax rendering)

…

On Tue, 19 Feb 2019 at 16:16, Daniel Marques ***@***.***> wrote: The issue does not require implementation. The vagueness does not came from the MathML implementation but from the browser itself. You can enable contenteditable currently in Firefox and affects also MathML Whether you want it or not, contenteditable is there and inherited from any parent that sets it. That the issue should be part of MathML 4, that's probably true. Can we move the issue? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/mathml-refresh/mathml-core/issues/7#issuecomment-465199640>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNcAh09tENfEyHBcoVJ1xMqdR1Ek2h1ks5vPCNlgaJpZM4a-N1W> .

[fred-wang]

@davidcarlisle please remove the "core" tag for now.

[fred-wang]

cc @bkardell @rwlbuis

Content editable is in the IDL https://html.spec.whatwg.org/multipage/interaction.html#elementcontenteditable so this relates a bit to w3c/mathml-core#129

The native HTML editing features of browsers is not really actively developed and has many interoperability issues. So it would be annoying to me to introduce MathML editing that will likely to have the same problem, be more complex and even less supported.

However, @javifernandez mentioned to me some weeks ago that there is a spec to allow web developers to override the editing commands (delete, insert, etc) and implement their own in Javascript. So it makes sense for me to specify/implement a default/trivial/interoperable behavior (e.g. ignoring all editing commands) and let web developers implement their custom math editing in Javascript.

If we are interested in interoperability of non-native features, people from the CG could also specify all the DOM transforms for MathML editing outside the core spec (e.g. a dedicated MathML editing module).

[fred-wang]

@bkardell said it's likely https://w3c.github.io/editing