Re: [webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Thu, Mar 21, 2019 at 9:42 AM Frédéric Wang  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

Re: [webkit-dev] MathML Refresh Heads up

[Frédéric Wang]

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
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Wed, Mar 20, 2019 at 10:42 AM Ryosuke Niwa  wrote:

>
> On Wed, Mar 20, 2019 at 5:57 AM Frédéric Wang  wrote:
>
>> On 16/03/2019 00:04, Ryosuke Niwa wrote:
>>
>> On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang  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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/web

Re: [webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Wed, Mar 20, 2019 at 5:57 AM Frédéric Wang  wrote:

> On 16/03/2019 00:04, Ryosuke Niwa wrote:
>
> On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang  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.

> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML Refresh Heads up

[Frédéric Wang]

On 16/03/2019 00:04, Ryosuke Niwa wrote:
> On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang  > 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

Re: [webkit-dev] MathML Refresh Heads up

[Frédéric Wang]

On 16/03/2019 00:29, Maciej Stachowiak wrote:
> It’s easier for us to check Apple Books and iOS App compatibility for
> a batch of possible removals at once, instead of one at a time. We can
> start by looking at the set of items below.
>
> It’s helpful to give a heads-up other than the normal review process,
> because our main concern is compatibility, and not all reviewers will
> be able to easily access the corpus of app-specific or books-specific
> content that may be affected. 
>
> We assume web compatibility is not a major issue since MathML isn’t in
> all browsers and in general is not widely used on websites, but there
> might also be some value in doing web usage analysis for these
> features if there’s any meaningful web usage of MathML at all.

We'll try to provide heads-up on this mailing list and will work with
the MathML Refresh CG in order to get more statistics. Having data from
Apple products would be very useful, here are some first questions (this
includes elements/attributes/values raised by the CG for
removal/deprecation but most have not been decided yet):

* Usage statistics for MathML elements used. More specifically, which of
the following elements are used: munder, mover, msub, msup, msubsup,
mlabeledtr, merror, mphantom, maction, mglyph, mfenced, mstyle, ms

* Usage statistics for MathML attributes. More specifically, which of
the following attributes are used: mathvariant, numalign, denomalign,
align (on munderover/munder/mover elements), bevelled, subscripshift,
superscriptshift, other, macros, mode, fontfamily, index, fontfamily,
fontweight, fontstyle, fontsize, color, background,
veryverythinmathspace, verythinmathspace, thinmathspace,
mediummathspace, thickmathspace, verythickmathspace, veryverythickmathspace

* Usage statistics for MathML attributes on the mstyle and math
elements. More specifically, do mstyle elements use any attribute other
than displaystyle, dir, mathsize, mathbackground, mathcolor,
mathvariant, scriptlevel?

* Attribute values. Is any of the following attribute used?
  - linethickness attribute with value "thin", "thick" or "medium"
  - mathsize attribute with value "small", "normal" or "big"
  - attribute with value a nonzero number without unit (e.g. "4") other
than scriptlevel
  - attribute with value "veryverythinmathspace", "verythinmathspace",
"thinmathspace", "mediummathspace", "thickmathspace",
"verythickmathspace" or "veryverythickmathspace".
  - notation attribute containing the value "radical" (e.g.
notation="radical circle")
  - attribute with leading or trailing white space characters (U+0020,
U+0009, U+000A, U+000D or U+000C). For example width=" 5em ".

* Trailing/leading whitespace in token elements (mi, mtext, mn, mo,
mtext, ms). Do token elements contain text content with leading or
trailing white space characters (U+0020, U+0009, U+000A, U+000D or
U+000C). For example  x .


Thanks,

-- 
Frédéric Wang


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML Refresh Heads up

[Maciej Stachowiak]

> On Mar 15, 2019, at 3:33 PM, Frédéric Wang  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? 
> Or is it enough to cc' Apple reviewers on bugs in order to get the approval? 
> Something else?

It’s easier for us to check Apple Books and iOS App compatibility for a batch 
of possible removals at once, instead of one at a time. We can start by looking 
at the set of items below.

It’s helpful to give a heads-up other than the normal review process, because 
our main concern is compatibility, and not all reviewers will be able to easily 
access the corpus of app-specific or books-specific content that may be 
affected. 

We assume web compatibility is not a major issue since MathML isn’t in all 
browsers and in general is not widely used on websites, but there might also be 
some value in doing web usage analysis for these features if there’s any 
meaningful web usage of MathML at all.

> 
> For now, these are the features the CG has already agreed to not include in 
> MathML Core (more to come). We would like to propose to remove them from 
> WebKit:
> 
> * "thin", "thick", "medium" values of mfrac's linethickness attribute ( 
> https://github.com/mathml-refresh/mathml/issues/4 
>  )
> * "small" "normal" "big" values of mathsize attribute ( 
> https://github.com/mathml-refresh/mathml/issues/7 
>  )
> * nonzero unitless values for MathML lengths ( 
> https://github.com/mathml-refresh/mathml/issues/24 
>  )
> * fontfamily, fontweight, fontstyle, fontsize, color, background MathML 
> attributes ( https://github.com/mathml-refresh/mathml/issues/5 
>  )
> 
> In any case, it would be very appreciated to get some analysis about the 
> usage of MathML markup used in Apple's product. How can we proceed to obtain 
> it?
> 
> Thanks,
> 
> [1] https://www.w3.org/community/mathml4/ 
> 
> [2] https://github.com/mathml-refresh/mathml/issues/ 
> 
> 
> On 15/03/2019 22:33, Myles C. Maxfield wrote:
>> 
>> 
>>> On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa >> > wrote:
>>> 
>>> 
>>> On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang >> > wrote:
>>> Hello WebKit developers,
>>> 
>>> As some of you may know, Igalia is working on MathML support in Chromium
>>> this year [1]. As part of that effort we joined a new MathML Refresh
>>> Community Group [2] and one goal is to focus on a core spec for browser
>>> implementations [3] to:
>>> - Remove deprecated/uncommon/duplicate math features that could be
>>> implemented by polyfills (relying on MathML core and other web
>>> technologies).
>>> 
>>> I'd be very much concerned about backwards compatibility here when it come 
>>> to removing any features.
>>> It's important to notice that WebKit is also used by hundreds of thousands 
>>> of iOS apps and macOS apps.
>>> How do we know we won't break those applications?
>>> 
>>> In general, I don't agree with whatever Google said about MathML being too 
>>> complex, etc…
>> 
>> The original sentence doesn’t say they will be removing anything in WebKit. 
>> There are plenty of features that have been removed from specs that we 
>> continue supporting in WebKit for backwards compatibility.
>> 
>> We could also consider migrating our implementation to a JS polyfill if one 
>> exists.
>> 
>> Is there a characterization of which features are planned for deprecation? 
>> We might be able to do some analysis on iBooks' and iOS apps’ content.
>> 
>>> 
>>> - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
>>> help implementation and conformance testing.
>>> - Align MathML with CSS/HTML (parsing, layout...), introducing new web
>>> platform features (CSS, fonts...) for math if necessary.
>> 
>> This sounds wonderful! A more coherent MathML story going forward would be 
>> fantastic.
>> 
>>> 
>>> On the other hand, these seem like very valuable improvements.
>>> 
>>> We expect that this effort will improve browser interoperability and
>>> reduce complexity of current implementations.
>>> 
>>> Given there aren't too many websites that deploy MathML directly on 
>>> production, my concerns are more about existing iOS and madOS apps that 
>>> embed WKWebView or WebView / UIWebView and use MathML.
>>> 
>>> - R. Niwa
>>> 
>>> ___
>

Re: [webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang  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.

Put it another way, what's the benefit of removing features in WebKit
before fixing other MathML bugs? 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.

For now, these are the features the CG has already agreed to not include in
> MathML Core (more to come). We would like to propose to remove them from
> WebKit:
>
> * "thin", "thick", "medium" values of mfrac's linethickness attribute (
> https://github.com/mathml-refresh/mathml/issues/4 )
> * "small" "normal" "big" values of mathsize attribute (
> https://github.com/mathml-refresh/mathml/issues/7 )
> * nonzero unitless values for MathML lengths (
> https://github.com/mathml-refresh/mathml/issues/24 )
> * fontfamily, fontweight, fontstyle, fontsize, color, background MathML
> attributes ( https://github.com/mathml-refresh/mathml/issues/5 )
>

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.

In any case, it would be very appreciated to get some analysis about the
> usage of MathML markup used in Apple's product. How can we proceed to
> obtain it?
>

Unfortunately, there isn't an easy way to do this right now. I wish there
was, and it's something we want to improve over time.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML Refresh Heads up

[Frédéric Wang]

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? Or is it enough to cc' Apple reviewers on
bugs in order to get the approval? Something else?

For now, these are the features the CG has already agreed to not include
in MathML Core (more to come). We would like to propose to remove them
from WebKit:

* "thin", "thick", "medium" values of mfrac's linethickness attribute (
https://github.com/mathml-refresh/mathml/issues/4)
* "small" "normal" "big" values of mathsize attribute (
https://github.com/mathml-refresh/mathml/issues/7)
* nonzero unitless values for MathML lengths (
https://github.com/mathml-refresh/mathml/issues/24)
* fontfamily, fontweight, fontstyle, fontsize, color, background MathML
attributes ( https://github.com/mathml-refresh/mathml/issues/5)

In any case, it would be very appreciated to get some analysis about the
usage of MathML markup used in Apple's product. How can we proceed to
obtain it?

Thanks,

[1] https://www.w3.org/community/mathml4/
[2] https://github.com/mathml-refresh/mathml/issues/

On 15/03/2019 22:33, Myles C. Maxfield wrote:
>
>
>> On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa > > wrote:
>>
>>
>> On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang > > wrote:
>>
>> Hello WebKit developers,
>>
>> As some of you may know, Igalia is working on MathML support in
>> Chromium
>> this year [1]. As part of that effort we joined a new MathML Refresh
>> Community Group [2] and one goal is to focus on a core spec for
>> browser
>> implementations [3] to:
>> - Remove deprecated/uncommon/duplicate math features that could be
>> implemented by polyfills (relying on MathML core and other web
>> technologies).
>>
>>
>> I'd be very much concerned about backwards compatibility here when it
>> come to removing any features.
>> It's important to notice that WebKit is also used by hundreds of
>> thousands of iOS apps and macOS apps.
>> How do we know we won't break those applications?
>>
>> In general, I don't agree with whatever Google said about MathML
>> being too complex, etc…
>
> The original sentence doesn’t say they will be removing anything in
> WebKit. There are plenty of features that have been removed from specs
> that we continue supporting in WebKit for backwards compatibility.
>
> We could also consider migrating our implementation to a JS polyfill
> if one exists.
>
> Is there a characterization of which features are planned for
> deprecation? We might be able to do some analysis on iBooks' and iOS
> apps’ content.
>
>>
>> - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
>> help implementation and conformance testing.
>> - Align MathML with CSS/HTML (parsing, layout...), introducing
>> new web
>> platform features (CSS, fonts...) for math if necessary.
>>
>
> This sounds wonderful! A more coherent MathML story going forward
> would be fantastic.
>
>>
>> On the other hand, these seem like very valuable improvements.
>>
>> We expect that this effort will improve browser interoperability and
>> reduce complexity of current implementations.
>>
>>
>> Given there aren't too many websites that deploy MathML directly on
>> production, my concerns are more about existing iOS and madOS apps
>> that embed WKWebView or WebView / UIWebView and use MathML.
>>
>> - R. Niwa
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>

-- 
Frédéric Wang

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML Refresh Heads up

[Myles C. Maxfield]

> On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa  wrote:
> 
> 
> On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang  > wrote:
> Hello WebKit developers,
> 
> As some of you may know, Igalia is working on MathML support in Chromium
> this year [1]. As part of that effort we joined a new MathML Refresh
> Community Group [2] and one goal is to focus on a core spec for browser
> implementations [3] to:
> - Remove deprecated/uncommon/duplicate math features that could be
> implemented by polyfills (relying on MathML core and other web
> technologies).
> 
> I'd be very much concerned about backwards compatibility here when it come to 
> removing any features.
> It's important to notice that WebKit is also used by hundreds of thousands of 
> iOS apps and macOS apps.
> How do we know we won't break those applications?
> 
> In general, I don't agree with whatever Google said about MathML being too 
> complex, etc…

The original sentence doesn’t say they will be removing anything in WebKit. 
There are plenty of features that have been removed from specs that we continue 
supporting in WebKit for backwards compatibility.

We could also consider migrating our implementation to a JS polyfill if one 
exists.

Is there a characterization of which features are planned for deprecation? We 
might be able to do some analysis on iBooks' and iOS apps’ content.

> 
> - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
> help implementation and conformance testing.
> - Align MathML with CSS/HTML (parsing, layout...), introducing new web
> platform features (CSS, fonts...) for math if necessary.

This sounds wonderful! A more coherent MathML story going forward would be 
fantastic.

> 
> On the other hand, these seem like very valuable improvements.
> 
> We expect that this effort will improve browser interoperability and
> reduce complexity of current implementations.
> 
> Given there aren't too many websites that deploy MathML directly on 
> production, my concerns are more about existing iOS and madOS apps that embed 
> WKWebView or WebView / UIWebView and use MathML.
> 
> - R. Niwa
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML Refresh Heads up

[Ryosuke Niwa]

On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang  wrote:

> Hello WebKit developers,
>
> As some of you may know, Igalia is working on MathML support in Chromium
> this year [1]. As part of that effort we joined a new MathML Refresh
> Community Group [2] and one goal is to focus on a core spec for browser
> implementations [3] to:
> - Remove deprecated/uncommon/duplicate math features that could be
> implemented by polyfills (relying on MathML core and other web
> technologies).
>

I'd be very much concerned about backwards compatibility here when it come
to removing any features.
It's important to notice that WebKit is also used by hundreds of thousands
of iOS apps and macOS apps.
How do we know we won't break those applications?

In general, I don't agree with whatever Google said about MathML being too
complex, etc...

- Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
> help implementation and conformance testing.
> - Align MathML with CSS/HTML (parsing, layout...), introducing new web
> platform features (CSS, fonts...) for math if necessary.
>

On the other hand, these seem like very valuable improvements.

We expect that this effort will improve browser interoperability and
> reduce complexity of current implementations.
>

Given there aren't too many websites that deploy MathML directly on
production, my concerns are more about existing iOS and madOS apps that
embed WKWebView or WebView / UIWebView and use MathML.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] MathML Refresh Heads up

[Frédéric Wang]

Hello WebKit developers,

As some of you may know, Igalia is working on MathML support in Chromium
this year [1]. As part of that effort we joined a new MathML Refresh
Community Group [2] and one goal is to focus on a core spec for browser
implementations [3] to:
- Remove deprecated/uncommon/duplicate math features that could be
implemented by polyfills (relying on MathML core and other web
technologies).
- Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
help implementation and conformance testing.
- Align MathML with CSS/HTML (parsing, layout...), introducing new web
platform features (CSS, fonts...) for math if necessary.

We expect that this effort will improve browser interoperability and
reduce complexity of current implementations.

This is just a heads up to say that we will send patches to
update/remove/add features. For people who are interested, we opened a
meta bug to track these changes [4].

Frédéric Wang and Rob Buis,

[1] https://mathml.igalia.com/
[2] https://mathml-refresh.github.io/
[3] https://mathml-refresh.github.io/mathml-core/
[4] https://bugs.webkit.org/show_bug.cgi?id=195797

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev