[webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Thu, Mar 21, 2019 at 9:42 AM Frédéric Wang <fwang at igalia.com> wrote:

> On 20/03/2019 20:45, Ryosuke Niwa wrote:
>
> 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.
>>
>> I'm also happy with more testing with iOS / macOS apps. I was just
> concerned by the "for now" and the "there isn't any easy way to do it" in
> your initial emails, it seems you were not open to accept any change for an
> undetermined period of time, just because of your ports...
>
Yes, in general, I don't think we should be any feature from WebKit unless
there is a good evidence that the removal won't affect any website or apps.
This topic comes up of wanting to remove a feature comes up every now and
then, and my answer is always that we should never remove a feature. The
corollary of this position is that we should never add a feature unless
it's absolutely necessary because we can never remove it once it's added.

> I guess one way to satisfy your desire without breaking WebKit in iOS and
>>> macOS would be to add a runtime feature flag which disables the parts of
>>> MathML that's not a part of core MathML, and then only enable this feature
>>> in your own port. That would allow you to have the same set of features
>>> between your products without breaking our ports.
>>>
>>
> ...however that proposal from you last email sounds more constructive.
> That would still be extra burden for us to manage deprecated MathML code
> and the corresponding tests, but at least that will give us the opportunity
> to start disabling features & run tests without them, to better see which
> parts we can ignore when comparing code between web engines and even to
> have beta testers providing feedback. So that seems a good trade off until
> Apple is ready to accept the changes (or not).
>
> 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.
>>>
>> Again, you are the one who brought up that topic in this thread. If you
> really don't care about Blink maintainers or Google's opinion then please
> just don't mention them.
>
Well, you're the one who brought up Chromium in the very first email:

> As some of you may know, Igalia is working on MathML support in Chromium
> this year


I think it would have been best if you didn't mention it if you didn't talk
to talk about.

> 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.
>>
> That was not my point. I was just trying to explain that there are more
> issues involved when you analyze carefully each case, you cannot just rely
> on generic claims, quick searches or unilateral approaches in order to make
> a decision. Anyway that was just a side note, it's probably not worth
> entering into details on this mailing list.
>
> Thank you,
>
> --
> Frédéric Wang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20190321/cc5bd45c/attachment.html>