From the meeting minutes:

The implementation report is linked in the spec.

BK: thinks the implementation report is useful, but it should not be linked to the spec.

ACTION: Review the test and implementation report.

Also discussed was that this is being served by Igalia servers. That needs to change also.

@bkardell agreed to look into this.

Alternatively, or maybe in tandem with, getting the implementation report working: is there a page someone can go to to get an idea of when "OK-enough" MathML support will land in say, Chrome/Edge (without flags), to use for, say, undergraduate-level maths notes?

I know of wpt.fyi and chrome bug 6606, but it doesn't really help answer these questions.

I understand predictions change, but it would be good to have a page with regular updates to the predicted timeline.

I know there are several observers (particularly, posters on the KaTeX github) that a would find such a rough prediction useful.

As an outsider, it's difficult to guess these timelines as we don't have great visibility of the blockers or when these might be resolved.

One possible solution to this is to use, as most specs that do this do, a link to WPT itself. The 'simplest' answer is something like https://wpt.fyi/results/?label=master&label=experimental&aligned&q=mathml - this arguably includes the HTML parser integrations and things that are really CSS specified as well (non-MathML elements), but we can get more creative as the query is fairly powerful.

It seems to me that our data in the margins comes from the same data source though, so I need to look into updating that also with calls to the wpt apis directly. This will involve an extra hop (you have to make. a call to an API to get aligned run ids and then base your actual query on that) and a bit more work, but I think it's ok, that's what others do here too... The real question, either way is what the basic query should contain - if we agree to one, I can send a PR with both

Resolved that this seems done and we should close it in the WG meeting