Other Embedded Content

[bkardell]

Description

The HTML specification contains a section on "Other Embedded Content", specifically integrating SVG and MathML into the parser. However, these co-evolved and were radically different in many ways from the rest of the platform which got all of the attention. For the last 4 years or so, much work has gone into alignment with the platform (DOM/IDL, CSS) and both internal and developer-facing improvements, as well as spec updates.

Things are very much improved, generally, but we still have ragged edges that need attention. This would focus on increasing interoperability of MathML-Core support and specific new platform integrations, as well as improving SVG interop.

Rationale

I believe that 2023 is an ideal time to focus on interoperability improvements in both, with so much aligning in terms of new implementations and internal improvements finally making it possible to set these other two forms back on a stable footing as part of one platform. They are, in my opinion, super important and historically unique - being the only other languages that have gained wide support.

Specification

• https://w3c.github.io/mathml-core/ (about to CR, but it is partially a subset with much of it having wide implementation for years in 2/3 engines)
• https://www.w3.org/TR/SVG/
• https://html.spec.whatwg.org/
• https://www.w3.org/TR/css-fonts-4/

Tests

https://wpt.fyi/results/mathml?label=master&label=experimental&aligned&view=subtest&q=mathml

https://wpt.fyi/results/?label=master&label=experimental&aligned&view=subtest&q=svg (we could chose a subset, as I did with MathML tests above)

[gsnedders]

Rationale

I believe that 2023 is an ideal time to focus on interoperability improvements in both, with so much aligning in terms of new implementations and internal improvements finally making it possible to set these other two forms back on a stable footing as part of one platform. They are, in my opinion, super important and historically unique - being the only other languages that have gained wide support.

Hey—when it comes to rational we're primarily interested in web developer and/or end user impact, not the mere existence of bugs (or omitted features); one of the goals of the Interop projects is to focus on things that matter, not just to enumerate every incompatibility out there.

I've opened #151 to try and clarify that in the template, but if you could expand on why you believe this feature is important that would be great!

(To be fair, I do think it's clear that SVG interop issues can and do cause problems, but it's less clear that applies to MathML to the same degree.)

[gsnedders]

Things are very much improved, generally, but we still have ragged edges that need attention. This would focus on increasing interoperability of MathML-Core support and specific new platform integrations, as well as improving SVG interop.

Personally, I'm a bit concerned about the scope of this proposal. It sounds like this—practically—is proposing all of MathML and SVG and their integration into the platform. This is a vast scope. I think it might be easier to come to agreement here if this was split into several smaller focus areas?

[bkardell]

We could split it into smaller focus areas or just pick specific aspects/test areas within (or both). I was going to limit this to MathML-Core interop where the overall scores are actually already close, but some specific gaps exist in presentation markup and css integration and it seems very doable and an opportune moment - but I guess I was thinking I know google recently had some focus on some svg stuff and apple also seems interested in improving those gaps - again, we could pick subsets of those we are interested in and it just seemed more compelling as a coordinated focus on getting the "Other Embedded" stuff into generally better shape.

I'm happy to break it up or keep it the same overall topic but work to provide a specific list of tests... just advise what y'all would prefer

[foolip]

@bkardell I think it would be best to split this into multiple smaller proposals, perhaps one for MathML-Core, and one for SVG. For SVG, there are lots of tests, so either a careful review of them would be needed, or you could pick some subset.

[ydaniv]

I did a quick check of tests for SVG, looks messy, e.g. most path tests on WebKit are failing &c.
I'll be happy to help with the SVG proposal and with review on tests, probably later today or over the weekend.

[ydaniv]

So, this is the state of tests for SVG:

SVG 1.1

Old tests (in obsolete format) are located in the import directory (not visible on the site) with notes in the README:

The import directory contains tests imported from the SVG 1.1 Second Edition test suite, with tests renamed to contain -manual in their name. These tests need review to verify that they are still correct for the latest version of SVG (which at the time of writing is SVG 2) and then need to be converted to reftests or testharness.js-based tests.
...

And further instructions on how to handle those, and with @heycam as point of contact 🙂

To summarize: state of SVG 1.1 is currently unknown, and there are also many reported bugs (some ancient) which probably could use some curation and reference in a single place.

SVG 2

All of the tests at wpt.fyi/results/svg are for SVG 2, which was left comatose according to this.
But, there is plenty there which could be very valuable for the platform, e.g. extending integration w/ CSS, CORS, embedded content, fonts, etc.

To summarize: state of SVG 2 is partially implemented (and there's not much point to look at adoption by developers), there's partial tests coverage, but it's also not clear what's the stand of impls. and SVGWG.

So, not sure what would be the best steps for an SVG proposal.
@bkardell WAYT?

[bkardell]

I've split MathML-Core into #197. I'm not sure on SVG.. maybe @heycam or @smfr or even @AmeliaBR have thoughts? Going to close this one, but comments can hopefully answer the question on SVG and maybe that also leads to another issue