[webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Wed, Mar 20, 2019 at 10:42 AM Ryosuke Niwa <rniwa at webkit.org> wrote:

>
> 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.
>

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.

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/211ed73d/attachment.html>