Re: [webkit-dev] MathML Refresh Heads up

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

Re: [webkit-dev] MathML Refresh Heads up

2019-03-20 Thread 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=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] Style guideline on initializing non-POD types via member initialization

2019-03-20 Thread Simon Fraser
> On Mar 14, 2019, at 1:06 PM, Filip Pizlo  wrote:
> 
> I like to draw this distinction: is the initializer a constant?
> 
> It’s not a constant if it relies on arguments to the constructor. “This” is 
> an argument to the constructor. 
> 
> It’s also not a constant if it involves reading the heap. 
> 
> So, like you, I would want to see this code done in the constructor. But I’m 
> not sure that my general rule is the same as everyone’s. 

This seems like a reasonable proposal to me: only use initializers when their 
input is constant data.

Any objections?

Simon

> 
> -Filip
> 
>> On Mar 14, 2019, at 12:59 PM, Simon Fraser  wrote:
>> 
>> I've seen some code recently that initializes non-POD members via 
>> initializers. For example, SVGAElement has:
>> 
>>   AttributeOwnerProxy m_attributeOwnerProxy { *this };
>> 
>> I find this a little disorientating, and would normally expect to see this 
>> in the constructor as m_attributeOwnerProxy(*this), as it makes it easier to 
>> find places to set breakpoints, and the ordering of initialization is easier 
>> to see.
>> 
>> Are people OK with this pattern, or should we discourage it via the style 
>> guidelines (and style checker)?
>> 
>> Simon
>> 
>> ___
>> 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] Unified source builds and adding or removing files...

2019-03-20 Thread Don . Olmstead
The ability to toggle unified builds on and off was enabled in 
https://trac.webkit.org/changeset/239561/webkit . Immediately afterwards this 
bug was opened https://bugs.webkit.org/show_bug.cgi?id=193073 which needs to 
get resolved. We're open to adding a bot with ENABLE_UNIFIED_BUILDS=OFF if 
things compile.

From: webkit-dev  On Behalf Of Tim Horton
Sent: Tuesday, March 19, 2019 4:02 PM
To: Said Abou-Hallawa 
Cc: WebKit Development Mailing List 
Subject: Re: [webkit-dev] Unified source builds and adding or removing files...

We already had this discussion; see the thread titled "Unified sources have 
broken our #include hygiene"


On Mar 19, 2019, at 3:48 PM, Said Abou-Hallawa 
mailto:sabouhall...@apple.com>> wrote:

I have been working on patches that require adding and removing cpp files from 
WebCore/Sources.txt. Almost every time I add or remove a file, I hit undefined 
symbol compilation error in some unrelated source or header file. Because a 
group of source files are compiled in one unified source file, some 
dependencies get hidden.  The same symbol is defined in another source or 
header file. Once sources are moved to different unified sources, the problem 
gets uncovered.

For example the file svg/graphics/filters/filters/SVGFEImage.h uses the class 
TreeScope without forward declaring it or including its header file. Oddly the 
source file svg/graphics/filters/filters/SVGFEImage.cpp compiles in the trunk 
right now. If a file is added to or removed from WebCore/Sources.txt such that 
this source is moved to another unified source, the compiler will give an error 
that TreeScope is not defined.

Another example is  which fixes a 
compilation error on GTK port. The same file was compiling fine on macOS but it 
failed on GTK.

Can we fix this issue? The fixes for such errors look very mysterious in the 
patches. It can also cause build breaks because the ports do not compile the 
same files.

One naive solution is to have the EWS bots compile without the unified source 
builds. In this case, all the header and source files must have the required 
forward declaration and/or the header file inclusion. So adding or removing 
files should not affect the ability to compile any other source file.

Thanks,
Said

___
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-20 Thread 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=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] Code Style: Opinion on returning void

2019-03-20 Thread Nico Weber
On Thu, Feb 21, 2019 at 12:31 PM Darin Adler  wrote:

> I tried not to weigh in on this, but my view on the materials we should
> use to build the bike shed must be shared!
>
> Generally it seems neat to be able to make the code slightly more tight
> and terse by merging the function call and the return into a single
> statement.
>
> Other than not being accustomed to it, I have noticed three small things I
> don’t like about using “return” with a call to a void-returning function.
>
> - You can’t use this idiom when you want to ignore the result of a
> function, only if the function actually returns void. Often functions are
> designed with ignorable and often ignored return values. For example, it’s
> common to call something that might fail and have a good reason to ignore
> whether it failed or not. The idiom we are discussing requires treating
> those functions differently from ones that return void. If you refactor so
> that a function now returns an ignorable return value you need to visit all
> the call sites using return and change them into the two line form.
>

That works, you just have to spell it `return (void)non_void_fun();` :D


>
> - It works for return, but not for break. I’ve seen at least one case
> where someone filled a switch statement with return statements instead of
> break statements so they could use this more-terse form. Now if we want to
> add one line of code after that switch, we need to convert all those cases
> into multi-line statements with break.
>
> - Unless it’s mandatory, it’s a case where two programmers can make
> different style choices. If both forms are acceptable, then it introduces a
> little bit of disorder into our code.
>
> One thing I like about it is that since “pass along the return value from
> this inner function to this outer function” can be written this way, the
> code can then survive refactorings where both the inner and outer functions
> might gain or lose the return value.
>
> — Darin
> ___
> 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-20 Thread 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