Use of XHTML or HTML-like syntax in MNX text elements

[samuelbradshaw]

Per @mdgood's suggestion in #278 (comment) to create a separate issue about whether MNX should adopt or borrow from XHTML/HTML, here are three questions that come to mind:

1. Should MNX borrow from XHTML/HTML at all?
2. If yes for (1), should we fully incorporate the XHTML schema, or should we borrow a specific subset of tags/elements?
3. If yes for (1), which MNX elements should be allowed to contain XHTML or HTML-like content?

[samuelbradshaw]

These are my initial thoughts:

1. HTML is a successful markup language similar to XML with broad familiarity, so I think it makes sense to borrow from it.
2. My opinion is that we should allow all XHTML elements, so that 1) we can benefit from XHTML validation, 2) we don't have to copy-paste the definitions of these elements from a different schema (risking divergence in the future), and 3) browser-based MNX rendering applications can use the browser's built-in HTML rendering without additional effort. However, to not put an undue burden on non-browser-based applications, I think we should also provide a smaller list of elements* that all MNX rendering applications are expected to handle, while still leaving the door open for full HTML support.
3. Any MNX element that contains string content should allow HTML or HTML-like content. To make things easier for MNX parsers, we might consider consolidating these elements into a single element, or adding an attribute to let the parser know that the element contains HTML.

*Here is my initial recommendation for a "smaller list of elements" that we should call out as being important to support:

• <strong></strong>, <em></em>, <sup></sup>, <sub></sub>, <mark></mark>, <span></span>
• <a href=""></a>
• <br> (or <br /> in XHTML)
• <p></p>, <div></div>

The above list is under the assumption that we could support a class attribute on HTML elements for styling. If we do not support a class attribute, then we might add additional formatting elements like these: <b></b>, <i></i>, <u></u>, <strike></strike>, <big></big>, <small></small>

[GeorgeTailor]

what is the point of HTML elements in MNX since no browser will ever support some such kind of thing?
The whole point of HTML tags is that the browsers know how to render them, plus some additional restriction on which child element are allowed for a specific element, for example, tbody can only have tr, while div can have literally anything.
Although the syntax is forgiving (meaning if you supply an invalid child, the page still renders without puking errors at you), some unexpected problems are still there (mainly slot from web-components family of standards).

The content of the MNX element is always a string, so we can put there literally anything, including standard HTML tags and just feed it to DOMParser which is available in every browser and get a valid HTML with user-agent styling of elements like strong, em etc.

Specific way of rendering a particular element seems like a work for a JS library and is out of scope of the spec for MNX.

[samuelbradshaw]

what is the point of HTML elements in MNX since no browser will ever support some such kind of thing? The whole point of HTML tags is that the browsers know how to render them, …

Renderers that transform sheet music from MNX to SVG (SVG and HTML Canvas are the two most common technologies I've seen for rendering sheet music on the web) would be able to use the native HTML rendering in a browser by putting the text/HTML content into SVG <foreignObject> elements (example). This isn't the only reason why I think HTML would be a good standard (see my earlier post) but it's a good side benefit.