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

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

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

webkit-dev mailing list

Reply via email to