Re: [w3ctag/design-reviews] Review MathML (#313)

We have discussed this during out Tokyo F2F - here is our official response. Apologies that this took so long.

----

Hey MathML fans!

We appreciate the feedback posted above and the passion for the technology which is apparent in your responses. We also appreciate the great work that is currently ongoing in the community and the MathML in HTML5 document is a fantastic example of this.

We’d like to see this community rally around creating the next iteration of the official MathML specification. As you know, there is currently no W3C Math Working Group, but that shouldn’t stop good innovation from proceeding to incubate the next iteration of the spec, for example in a Community Group.

We also have some high-level feedback from an architectural level that we’d like to offer.

**MathML layering.** In recent years, we’ve focused a lot on understanding and exposing the primitives that underpin higher levels of the web platform, and making those available to web developers in order to improve the platform’s extensibility. For examples, Web Components continue to make progress into explaining how HTML works. It’s important to us that the web platform have good layering, so that high-level MathML has as little “magic” as possible. 

As the next version of MathML is developed, we encourage the designers to be mindful of places where a MathML element requires special platform behavior that is not available through any other means, and consider what primitives are missing that could generally make that behavior available (to reduce or eliminate) the “magic”. Of course, this may not be possible in all cases, but the places that do require it should be well understood and documented.

It looks like many folks are already thinking about how MathML can better integrate into the existing platform, and what redundant concepts can be removed, what minimal new features are necessary, etc. Of particular concern is the relationship between MathML and CSS. If MathML takes layout dependencies on concepts that are not supported in CSS, we would expect these concepts to be raised in the CSS working group for discussion. We appreciate the thinking that has already taken place and look forward to seeing the ensuing discussions.

**Improved interoperability requirements:** The previous MathML spec was developed before the evolution to more prescriptive and detailed specifications which has become the new norm for specifications. This increased level of detail helps avoid ambiguity in interpreting the spec, which in turn helps users and web developers avoid problems with interoperability between rendering engines. We’d like to see the MathML spec embrace this new spec-authoring norm for its next iteration. Case-in-point, many of us pointed out the Rendering section of the spec has an example where it would be extremely unlikely that multiple implementations could arrive at interoperable behavior based on the current spec’s content.

**Tests:** The other major factor that helps avoid interoperability problems between rendering engines is having a thorough set of conformance tests. It is becoming a de facto requirement for new standards to have accompanying tests anyway, so starting early for a language as large and complex as MathML will be essential.

We’re excited to see MathML take its next step forward. We believe that by following these architectural principles, implementers will be able to see the value and opportunity for interoperable Math in the web platform and join the effort. Thanks again for all your comments on this thread, and good luck!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527