On 16/03/2019 00:04, Ryosuke Niwa wrote: > On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang <fw...@igalia.com > <mailto:fw...@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.
> 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. Maintaining WebKits-specific features and tests would be an extra burden, so it would be preferable to avoid it when possible. > 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. FWIW, the removal/deprecation discussions are currently led by the MathML Refresh CG (which include browser implementers from Mozilla/Igalia, people from the former Math WG, scholars, publishers, a11y experts, authors of MathML tools...) and rely heavily on the experience from WebKit/Gecko/Stylo implementations. > 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 ). -- Frédéric Wang
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
