On Thu, Mar 21, 2019 at 9:42 AM Frédéric Wang <fw...@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 > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
