Re: [webkit-dev] MathML Refresh Heads up

2019-03-15 Thread 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

2019-03-15 Thread 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=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

2019-03-15 Thread 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

2019-03-15 Thread 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

2019-03-15 Thread 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

2019-03-15 Thread 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


Re: [webkit-dev] Reminder regarding formatting uint64_t

2019-03-15 Thread Ryosuke Niwa
On Thu, Feb 28, 2019 at 12:40 PM Sam Weinig  wrote:

>
>
> > On Feb 27, 2019, at 4:05 PM, Keith Rollin  wrote:
> >
> >> On Wed, Feb 27, 2019 at 2:36 PM Michael Catanzaro <
> mcatanz...@igalia.com> wrote:
> >> Hi,
> >>
> >> For the past several years, I've been regularly fixing -Wformat
> >> warnings that look like this:
> >>
> >> ../../Source/WebKit/WebProcess/WebPage/WebPage.cpp:3148:46: warning:
> >> format ‘%llu’ expects argument of type ‘long long unsigned
> >> int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned
> >> int’} [-Wformat=]
> >> RELEASE_LOG_ERROR(ProcessSuspension, "%p - WebPage
> >> (PageID=%llu) - LayerTreeFreezeReason::ProcessSuspended was set when
> >> removing LayerTreeFreezeReason::PageTransition; current reasons are %d",
> >>
> >>
> ^~
> >> this, m_pageID, m_LayerTreeFreezeReasons.toRaw());
> >>   
> >>
> >> Problem is that uint64_t is long long unsigned int on Mac, but only
> >> long unsigned int on Linux. It can't be printed with %llu, so please
> >> use PRIu64 instead. E.g.:
> >>
> >> LOG("%llu", pageID); // wrong
> >> LOG("%" PRIu64, pageID); // correct
> >>
> >> This is good to keep in mind for any sized integer types, but uint64_t
> >> in particular since this is what causes problems for us in practice.
> >
> >
> >
> >> On Feb 27, 2019, at 14:47, Ryosuke Niwa  wrote:
> >>
> >> We should probably stop using these formatting strings in favor of
> makeString by making *LOG* functions to use makeString behind the scene.
> >
> > Formatting strings are pretty much required for the RELEASE_LOG* macros.
> These macros require a string literal for the formatting information, so
> you can’t say something like:
> >
> > RELEASE_LOG_ERROR(ProcessSuspension, makeString(this, " - WebPage
> (PageID = ", m_pageID, "), - LayerTreeFreezeReason::ProcessSuspended was
> set when removing LayerTreeFreezeReason::PageTransition; current reasons
> are ", m_LayerTreeFreezeReasons.toRaw()));
> >
> > This would not result in a string literal being passed to RELEASE_LOG,
> and you’d get a compiler error.
> >
> > You could technically get away with passing your created string along
> with a “%s” format specification:
> >
> > RELEASE_LOG_ERROR(ProcessSuspension, "%s", makeString(this, " - WebPage
> (PageID = ", m_pageID, "), - LayerTreeFreezeReason::ProcessSuspended was
> set when removing LayerTreeFreezeReason::PageTransition; current reasons
> are ", m_LayerTreeFreezeReasons.toRaw()));
> >
> > But this is not advised. The underlying Cocoa os_log facility is able to
> greatly compress the logs stored in memory and on disk, as well as get
> corresponding performance benefits, by taking advantage of the fact that
> the formatting string is a literal that can be found in the executable’s
> binary image. When you log with a particular formatting string, that string
> is not included in the log archive, but a reference to it is. In the case
> that Michael gives, a reference to the big formatting string is stored
> along with the pointer, the unsigned long long, and the integer. In the
> above example, a reference to “%s” is stored, along with the
> fully-formatted string. This latter approach takes up a lot more memory.
> >
> > So go wild with the LOG* macros, but understand the restrictions with
> the RELEASE_LOG* macros.
>
> Seems like a fun project would be to attempt to generate the format string
> literal at compile time based on the parameters passed.
>

Hm... os_log_* themselves seem to be macros:
https://developer.apple.com/documentation/os/os_log_debug?language=objc

I wonder if we can still use templates to detect types & generate the
static string though... Assuming, we can iterate over __VA_ARGS__ to
generate something like:
os_log_(ChannelStuff™, GENERATE_FORMAT_STRING(__VA_ARGS__), __VA_ARGS__)
and have GENERATE_FORMAT_STRING generate a sequence of formatString<>(_1) +
formatString<>(_2) + formatString<>(_3) + ...
where formatString generates static string which knows how to
concatenate itself using techniques like these:
https://akrzemi1.wordpress.com/2017/06/28/compile-time-string-concatenation/
https://stackoverflow.com/questions/15858141/conveniently-declaring-compile-time-strings-in-c
https://stackoverflow.com/questions/24783400/concatenate-compile-time-strings-in-a-template-at-compile-time

It's getting a bit too late for me to think straight though...

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