I just updated the spec to clarify that unknown mathml elements have display: math by default and in that case just behave like an mrow. The question about whether they should specialize to MathMLUnknownElement is still open.

For the record, SVGUnknownElement has been removed in w3c/svgwg@738f1e8#diff-eb0a191797624dd3a48fa681d3061212

( see also w3c/svgwg#122 )

Custom element discussion is WICG/webcomponents#634

consensus from June 1: we decided to keep that (IDL for unknown) in core level 1 ; we need to update the spec and write tests for these

@bkardell what's the status of this? Can you please propose some spec change & test for what you wanted to do with a MathMLUnknownElement IDL?

@fred-wang in the call today we discussed punting this to level 2 and the group seemed ok with it based on the fact that we have a number of other things and the result will be that the shape of the element, except for the constructor, will be the same either way at this point.

At the core meeting today, consensus was to move to Level 2 and coordinate with SVG group with unified approach to unknown element IDL. For the time being, any element in the MathML namespace will be treated as a MathML element.

Removed "needs spec update" label as that seems to have been done.

Also removed "Core" label as this is level 2 (which implies core in the future)

We had some discussion at the MathML general meeting today about how to write about the relationship between full and core.

One specific question is whether a web platform implementation that extends core by adding support for things in full is an invalid implementation. On the one hand, it is important to define what happens with unknown elements so that all renders handle them the same. SVG does a similar thing.

On the other hand, this means that an implementation that wants to experiment with implementation by adding support for "new" elements such as the elementary math ones (or support attributes like "bevelled" for mfrac) would potentially fail tests. Perhaps the answer is to just make sure any negative test picks names that would never be part of a spec.

A thought that I had while discussing this in my after-meeting with @brucemiller is that one could imagine tests specific for Full to provide two behaviors:

• expected behavior when the feature is implemented
• expected fallback when interpreted only by MathML Core

If a feature makes its way to Core at some point, developers simply need to remove the expected fallback - as the expectation would switch to always implemented.

So, as long as the fallbacks for full reside in a separate test suite/directory/space from the core tests, one could imagine a world without mutual contradictions. Core tests always pass, fallback tests pass when a feature is missing, and full tests pass when full is implemented.

bevelled_fallback and bevelled_full could be two example names of such tests.

This was discussed at the core meeting. There was no general consensus at the meeting other than people should think about the future when writing tests. One example is that the unknown element test should pick an obviously never going to be used name rather than a name like mfenced, which although not part of core, might be part of another implementation that implements some of MathML full also.

From the minutes:

NS: As we move towards level two, new features will come in, what should the tests do about new things? Tests should not decide that new things are failures. Firefox may experiment with new things.

BK: Our tests should declare new things as unknown elements, and these unknowns would not be test failures.

DC: We do not want everyone to define their own subsets of the full spec.

dc: "mfence" was made illegal and caused DC some problems.

NS: Tests should see if implementations conform to core.

NS: should mfence be tested to be illegal?

DG: Yes.

OB: We have tentative tests as well as core test suites. The tentative suite may allow new things to exist.

BK: Anyone can add tentative tests. Not everyone has to agree with those tests.

DG: said that this issue was not a big problem in reality.

NS: Should we close this issue without doing anything?

BK: We have no specific advice for how to handle undefined attributes for now.

BM: When someone is writing tests they should have the future in mind.