[webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Wed, Mar 20, 2019 at 5:57 AM Frédéric Wang <fwang at igalia.com> wrote:

> 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> 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.
>
We can continue to agree to disagree on this point. But I strongly object
to removing any features from MathML implementation of WebKit without
having done comprehensive compatibility testing with various iOS and macOS
apps that use MathML.

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.
>
Then the best way to achieve that will be implementing what WebKit and
Gecko implement in Blink, not remove features from WebKit and Gecko.

> Maintaining WebKits-specific features and tests would be an extra burden,
> so it would be preferable to avoid it when possible.
>
I see why you'd prefer that but making one's job easier by breaking
backwards compatibility with exiting apps and websites is not a good trade
off.

> 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.
>
I really don't care what maintainers of Blink say or do about MathML
because they don't have MathML implementation right now. My primary concern
as I've stated multiple times is iOS and macOS apps that currently use
MathML.

> 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
> ).
>
An existence of a bug in our code is not an evidence that the entire
feature can be removed.

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