[webkit-dev] MathML Refresh Heads up

[Frédéric Wang]

On 16/03/2019 00:04, Ryosuke Niwa wrote:
> On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang <fwang at igalia.com
> <mailto:fwang at igalia.com>> wrote:
>
>     Hi Ryosuke and Myles,
>
>     Thank you for your reply. First, the exact thing about what will
>     be in MathML Core is still open, people are welcome to join and
>     participate to the MathML CG [1] or comment on the GitHub tracker [2].
>
>     Our plan was also to remove features from WebKit but of course
>     ultimately the consensus has to be made in the WebKit community
>     (hence our heads up email). What do you suggest? Should we send
>     "intent to remove" to this mailing list?
>
>
> Ultimately, we need some testing to ensure whatever iOS and macOS
> apps, or websites that specifically target WebKit and Gecko that use
> MathML don't get broken by those removals. Because there isn't an easy
> way to do that right now, my suggestion is not remove any features for
> now.
>
I agree on the goal but disagree on the suggestion. At minimum, we
should decide each case separately and try to collect some data before.

> Put it another way, what's the benefit of removing features in WebKit
> before fixing other MathML bugs?

This question sounds rhetorical, but basically this is already said in
the initial email: improve browser interoperability and reduce
complexity of current implementations. Especially, at Igalia we are
working on several engines in parallel and it's much easier if the
implementation logic and set of WPT tests is consistent in order to
compare the code, fix bugs and implement new features. Maintaining
WebKits-specific features and tests would be an extra burden, so it
would be preferable to avoid it when possible.

> If the only benefit is that Blink may have an easier time implementing
> the rest and therefore might be more interoperable, I really don't buy
> that argument given MathML isn't supported at all in Blink today.

Note that you are the only one who suggested on this thread that our
WebKit announcement is made according to Google's opinion or Blink's
development plan... I get that having more features in Gecko/WebKit
might be an interoperability concern and maybe Apple actually has more
information from Google, but so far Google people actually seem more
interested in the two other points of the initial email.

FWIW, the removal/deprecation discussions are currently led by the
MathML Refresh CG (which include browser implementers from
Mozilla/Igalia, people from the former Math WG, scholars, publishers,
a11y experts, authors of MathML tools...) and rely heavily on the
experience from WebKit/Gecko/Stylo implementations.

> These all seem like something out in the wild might be
> using. https://github.com/search?q=mathml+fontweight&type=Code yields
> quite a few examples in which fontweight content attribute is being
> used for example.

MathML is used as an exchange format in various tools, standards and
documents so that's not really surprising to get matches. However, the
MathML Core spec targets usage in web engines so what we need instead is
to check content that is actually served to web engines in general and
to WebKit in particular.

Note: There are straighforward CSS polyfills for the attributes
previously mentioned. A JS polyfill would be needed for MathML nonzero
unitless lengths (if they are really used) but removing the possibility
to write "5" instead of "500%" is part of the general goal to align more
with HTML/CSS. Regarding fontweight, it is known to require some extra
code/tests in Gecko/Stylo in order to handle conflicts with mathvariant
( WebKit doesn't handle such conflicts
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122
).

-- 
Frédéric Wang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20190320/30d78b71/attachment.html>