Re: [webkit-dev] MathML layout refactor proposal

[Frédéric WANG]

Hi Dave,

Thank you for your message. It's good to see that you are still
interested in what's happening in WebKit MathML. I believe we agree with
the goals you state, however most of your claims on flexbox VS a
separate renderer class seemed to be assumptions you made 3 years ago.
People (including me) have tried to maintain the MathML code after you
left and these assumptions turned out to be at least inaccurate. With
Alejandro's approach, I believe that in the upcoming months we can at
the same time get a good MathML implementation and address all of
reviewer's concerns on your original code. At the moment, I do not think
there is an alternative proposal with these features, and even less
someone willing to work on any other approach...

More replies inline.

Le 23/12/2015 08:11, dbar...@mathscribe.com a écrit :
> 1. Ideally, we want most webkit developers to not even have to think about 
> MathML. If you make some change to the rendering and layout code and it 
> doesn't break non-MathML layout features, including flexbox, then ideally 
> that should almost always mean that MathML layout is still ok.
However when a legitimate change elsewhere does break something in
MathML (Alejandro mentioned one bug but I have seen several of them) it
becomes a burden for the non-MathML developers. This is especially true
because it's hard to understand the code given the complexity of the
current flexbox-based implementation and the vagueness of the MathML
spec (which we are trying to solve by using
http://www.mathml-association.org/MathMLinHTML5 and
http://tests.mathml-association.org/).

Using an independent renderer class allows to isolate the MathML
implementation and reduces the risk of breaking the MathML code while
changing another part of the code. This has been confirmed with the
experience in Gecko (actually, such an issue only happened twice in
Gecko in the past decade and that was due to changes in graphics and
font modules, not layout).
> 2. Conversely, it would be ideal if the MathML layout code didn't have to 
> worry about a lot of non-math things - floats, columns, margin collapsing, 
> internal RenderBlock voodoo, etc. We just want good fast MathML layout, that 
> integrates well with HTML, CSS, and JavaScript.
By using our own renderer class we can actually ignore CSS properties
that we consider irrelevant (see
https://github.com/MathML/MathMLinHTML5/issues/9). As Alejandro said in
his initial message, we now only care about math features and not about
the whole flexbox rules. Hence that's less code executed and we hope it
would actually improve performance.
> 3. MathML must introduce few or no bugs, and especially no security bugs.
With a separate renderer class, the layout code essentially becomes
arithmetic computations (of box coordinates and size). This is more
reliable than manipulation of anonymous renderers and style that need to
be kept updated with respect to dynamic tree/style changes. See for
example the current implementation of mmultiscripts which is just crazy
(http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/mathml/RenderMathMLScripts.cpp).
If I understand correctly, one of the improvements you obtained by using
flexboxes was that you removed some of the (potentially unsafe)
manipulations of margin / border style that used to be necessary for box
alignments. With the new approach, we go even farther and expect to
remove all the anonymous renderers and style, so that these are no
longer a problem.
> At the end of 2012, the webkit MathML code was around 2,500 lines (admittedly 
> it didn't implement all of MathML). In comparison, the MathPlayer plugin for 
> Internet Explorer, MathML implementation inside Gecko, and the MathJax 
> javascript library, were each about 20,000-40,000+ lines of code. Another 
> comparison is that the webkit rendering/svg source code folder then contained 
> about 17,700 lines. If we try to implement MathML from scratch, sort of like 
> SVG, then I think it will take many developer-years to do, which frankly may 
> never happen.
I'm not sure the comparison is really relevant, given the limited MathML
implementations in WebKit and the fact that the coding style are very
different (e.g. MathJax is written in Javascript and has various hacks
to workaround CSS bugs from old browsers, Gecko has a 80 characters
limit for lines and has fallback code when a MATH font is not
available). Instead, let's compare the two approaches in WebKit. The
flexbox-based implementation is really naive and just aligns the edges
of base and scripts (see attachment integrals.png) ; implementing
mmultiscripts that way was overly complex as I said above. As a
comparison, in only a single day, Alejandro and I were able to get an
implementation of msub/msup/msubsup/mmultiscripts using the TeX rules
and a decade of parameters from the OpenType MATH table (see
http://www.mathml-association.org/MathMLinHTML5/S3.html#SS4.SSS1).
Moreover, RenderMathMLScripts.[h|cpp] went down 

Re: [webkit-dev] MathML layout refactor proposal

[Alejandro Garcia Castro]

Hi Dave,

thanks very much for your comments and feedback, this information is
great to document the whole design process of the code.

I agree with the goals you are pointing out, actually I think the
change to use flexbox was a good option to try at that point. But
currently considering the result of the design in the code we can see
that the devil is in the detail.

Trying to use box spacing to create complex anonymous render trees
that produce the complex layout result of some mathml formula, brings
a complex code difficult to improve to get the best math render
possible. That is the main reason for this change, you can see bugs
such as this were developers are not even sure how the whole layout is
happening:

https://bugs.webkit.org/show_bug.cgi?id=137330

The problem is worse if we try to add more complex layout calculations
to match best formula rendering.

Also we can find flexbox changes just avoiding mathml tests because
it is not clear how the anonymous nodes structure is handled for some
cases.

So this takes us to the current proposal, if we do not get more
feedback probably we will start asking for reviews in the next weeks,
and we can discuss in more detail in the bugs the pros and cons of the
change.

Thanks again,

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

Re: [webkit-dev] MathML layout refactor proposal

[Dave Barton]

Since I was the one who changed RenderMathMLBlock to derive from RenderFlexibleBox instead of RenderBlock back in 2012, I thought I should reply to the recent question on it and give my reasons for doing so.1. Ideally, we want most webkit developers to not even have to think about MathML. If you make some change to the rendering and layout code and it doesn't break non-MathML layout features, including flexbox, then ideally that should almost always mean that MathML layout is still ok.2. Conversely, it would be ideal if the MathML layout code didn't have to worry about a lot of non-math things - floats, columns, margin collapsing, internal RenderBlock voodoo, etc. We just want good fast MathML layout, that integrates well with HTML, CSS, and _javascript_.3. MathML must introduce few or no bugs, and especially no security bugs.Basically, I think deriving from RenderFlexibleBox helped with all 3 points. Besides helping directly with these points, I think it also allows the MathML implementation to be thousands of lines of code, instead of tens of thousands, which also helps with all 3 points. (I think that also will help with convincing other browser vendors to implement MathML, if and when they consider doing so.) At the end of 2012, the webkit MathML code was around 2,500 lines (admittedly it didn't implement all of MathML). In comparison, the MathPlayer plugin for Internet Explorer, MathML implementation inside Gecko, and the MathJax _javascript_ library, were each about 20,000-40,000+ lines of code. Another comparison is that the webkit rendering/svg source code folder then contained about 17,700 lines. If we try to implement MathML from scratch, sort of like SVG, then I think it will take many developer-years to do, which frankly may never happen.Gecko MathML doesn't use flexbox, but that's because flexbox didn't exist when Gecko's MathML code was orginally written. Another point is that webkit MathML's use of anonymous blocks predates its use of flexbox, and is somewhat independent of it. Finally, using flexbox (and also anonymous blocks) had nothing to do with Google's decision to turn off MathML, and eventually delete the code.From http://www.w3.org/TR/css-flexbox-1/#overview we have:Flex layout is superficially similar to block layout. It lacks many of the more complex text- or document-centric properties that can be used in block layout, such as floats and columns [and margin collapsing]. In return it gains simple and powerful tools for distributing space and aligning content in ways that webapps and complex web pages often need. The contents of a flex container:can be laid out in any flow direction (leftwards, rightwards, downwards, or even upwards!)can have their display order reversed or rearranged at the style layer (i.e., visual order can be independent of source and speech order)can be laid out linearly along a single (main) axis or wrapped into multiple lines along a secondary (cross) axiscan “flex” their sizes to respond to the available spacecan be aligned with respect to their container or each othercan be dynamically collapsed or uncollapsed along the main axis while preserving the container’s cross sizeMathML may not absolutely need all these, but several (like changing the order for mroot) are very useful, and outlawing floats and columns and margin collapsing is great for avoiding bugs or unintended interactions with other code. So again by using flexbox, I think MathML can be thousands of lines instead of tens of thousands of lines, and will need a lot less new tricky lines to avoid buggy interactions with existing layout features and voodoo.Finally, I'd like to say that I think it's great that you guys are asking for feedback on this. There are obviously webkit layout and rendering experts that know a lot more than I do, and I urge you very strongly to try to get one of them to help you with this design decision. Otherwise someone else in a few years may delete your code, as has happened to me. :)___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[dbarton]

2nd try - hopefully as raw text, not an html attachment this time:

Since I was the one who changed RenderMathMLBlock to derive from 
RenderFlexibleBox instead of RenderBlock back in 2012, I thought I should reply 
to the recent question on it and give my reasons for doing so.

1. Ideally, we want most webkit developers to not even have to think about 
MathML. If you make some change to the rendering and layout code and it doesn't 
break non-MathML layout features, including flexbox, then ideally that should 
almost always mean that MathML layout is still ok.

2. Conversely, it would be ideal if the MathML layout code didn't have to worry 
about a lot of non-math things - floats, columns, margin collapsing, internal 
RenderBlock voodoo, etc. We just want good fast MathML layout, that integrates 
well with HTML, CSS, and JavaScript.

3. MathML must introduce few or no bugs, and especially no security bugs.

Basically, I think deriving from RenderFlexibleBox helped with all 3 points. 
Besides helping directly with these points, I think it also allows the MathML 
implementation to be thousands of lines of code, instead of tens of thousands, 
which also helps with all 3 points. (I think that also will help with 
convincing other browser vendors to implement MathML, if and when they consider 
doing so.) At the end of 2012, the webkit MathML code was around 2,500 lines 
(admittedly it didn't implement all of MathML). In comparison, the MathPlayer 
plugin for Internet Explorer, MathML implementation inside Gecko, and the 
MathJax javascript library, were each about 20,000-40,000+ lines of code. 
Another comparison is that the webkit rendering/svg source code folder then 
contained about 17,700 lines. If we try to implement MathML from scratch, sort 
of like SVG, then I think it will take many developer-years to do, which 
frankly may never happen.

Gecko MathML doesn't use flexbox, but that's because flexbox didn't exist when 
Gecko's MathML code was orginally written. Another point is that webkit 
MathML's use of anonymous blocks predates its use of flexbox, and is somewhat 
independent of it. Finally, using flexbox (and also anonymous blocks) had 
nothing to do with Google's decision to turn off MathML, and eventually delete 
the code.

From http://www.w3.org/TR/css-flexbox-1/#overview we have:

Flex layout is superficially similar to block layout. It lacks many of the more 
complex text- or document-centric properties that can be used in block layout, 
such as floats and columns [and margin collapsing]. In return it gains simple 
and powerful tools for distributing space and aligning content in ways that 
webapps and complex web pages often need. The contents of a flex container:

can be laid out in any flow direction (leftwards, rightwards, downwards, or 
even upwards!)

can have their display order reversed or rearranged at the style layer (i.e., 
visual order can be independent of source and speech order)

can be laid out linearly along a single (main) axis or wrapped into multiple 
lines along a secondary (cross) axis

can “flex” their sizes to respond to the available space

can be aligned with respect to their container or each other

can be dynamically collapsed or uncollapsed along the main axis while 
preserving the container’s cross size

MathML may not absolutely need all these, but several (like changing the order 
for mroot) are very useful, and outlawing floats and columns and margin 
collapsing is great for avoiding bugs or unintended interactions with other 
code. So again by using flexbox, I think MathML can be thousands of lines 
instead of tens of thousands of lines, and will need a lot less new tricky 
lines to avoid buggy interactions with existing layout features and voodoo.

Finally, I'd like to say that I think it's great that you guys are asking for 
feedback on this. There are obviously webkit layout and rendering experts that 
know a lot more than I do, and I urge you very strongly to try to get one of 
them to help you with this design decision. Otherwise someone else in a few 
years may delete your code, as has happened to me. :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[Ryosuke Niwa]

Hi Alex,

I think this refactoring makes a lot of sense.  This is very close to
what I wanted to do with MathML four years ago so I'm very happy to
hear that you're taking the initiative here.

- R. Niwa

On Wed, Dec 9, 2015 at 3:35 AM, Alejandro Garcia Castro  wrote:
>
> Hi,
>
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
>
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community.  If so, we will start pushing the initial patches from our
> branch to upstream.
>
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
>
>- Reduce code complexity: Adapting FlexBox layout (which is already
>  complex) in order to create the MahtML layout made the code too
>  complex, a big technical debt that made the improvement of MathML
>  more difficult every day.
>
>- Avoid just another FlexBox dependent code: When we had to add
>  general layout alignment support we had a lot of problems trying
>  to solve some the MathML issues because it was not clear how it
>  worked with the FlexBox.
>
>- Improve performance: We do not need all the features FlexBox
>  layout adds for most of the MathML blocks but we are executing
>  all that code. We also can simplify the render tree structures
>  that were created to make the FlexBox layout work.
>
>- Make easier to improve the MathML implementation: Using
>  independent renderer classes gives more flexibility to get exact
>  positioning and spacing required to get high-quality math
>  rendering based on TeX rules and the OpenType MATH table.  (cf
>  http://www.mathml-association.org/MathMLinHTML5/)
>
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
>
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
>
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
>
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
>keep the RenderTree structure. This is basically done, and we just
>need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
>created to make FlexBox work and all the code that it was
>required. We already have the Fractions and Underover implemented
>and the code is much clearer. This will break the tests relying on
>a PNG image or a render tree reference. Hence we will do it also
>per renderer and rebasing the tests after each commit.
>
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
>
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
>
> Greetings,
>
> Alex
> ___
> 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 layout refactor proposal

[Zalan Bujtas]

It’s great to hear that MathML is getting some proper cleanup. I think the 
proposal sounds good and I am looking forward to the patches. 

Minor observation: I noticed that, since MathML block is no longer a flexbox, 
but it still needs some of the flexbox functionality, the following pattern has 
been introduced to the generic renderbox/block code. 
-if (parent()->isFlexibleBox()) {
+if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
I just wish there was another way to handle this.

Zalan.

> On Dec 9, 2015, at 3:35 AM, Alejandro Garcia Castro  wrote:
> 
> 
> Hi,
> 
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
> 
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community.  If so, we will start pushing the initial patches from our
> branch to upstream.
> 
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
> 
>   - Reduce code complexity: Adapting FlexBox layout (which is already
> complex) in order to create the MahtML layout made the code too
> complex, a big technical debt that made the improvement of MathML
> more difficult every day.
> 
>   - Avoid just another FlexBox dependent code: When we had to add
> general layout alignment support we had a lot of problems trying
> to solve some the MathML issues because it was not clear how it
> worked with the FlexBox.
> 
>   - Improve performance: We do not need all the features FlexBox
> layout adds for most of the MathML blocks but we are executing
> all that code. We also can simplify the render tree structures
> that were created to make the FlexBox layout work.
> 
>   - Make easier to improve the MathML implementation: Using
> independent renderer classes gives more flexibility to get exact
> positioning and spacing required to get high-quality math
> rendering based on TeX rules and the OpenType MATH table.  (cf
> http://www.mathml-association.org/MathMLinHTML5/)
> 
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
> 
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
> 
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
> 
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
>   keep the RenderTree structure. This is basically done, and we just
>   need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
>   created to make FlexBox work and all the code that it was
>   required. We already have the Fractions and Underover implemented
>   and the code is much clearer. This will break the tests relying on
>   a PNG image or a render tree reference. Hence we will do it also
>   per renderer and rebasing the tests after each commit.
> 
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
> 
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
> 
> Greetings,
> 
> Alex
> ___
> 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 layout refactor proposal

[Frédéric WANG]

Le 14/12/2015 19:39, Zalan Bujtas a écrit :
> It’s great to hear that MathML is getting some proper cleanup. I think the 
> proposal sounds good and I am looking forward to the patches. 
>
> Minor observation: I noticed that, since MathML block is no longer a flexbox, 
> but it still needs some of the flexbox functionality, the following pattern 
> has been introduced to the generic renderbox/block code. 
> -if (parent()->isFlexibleBox()) {
> +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> I just wish there was another way to handle this.
>
> Zalan.
Alex will correct me if I'm wrong, but I think the changes in RenderBox
are just a temporary solution to avoid breaking tests while we continue
to rewrite the MathML layout code. Hopefully, these won't be needed
anymore when we are done.

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[Alejandro Garcia Castro]

On Mon, Dec 14, 2015 at 08:03:12PM +0100, Frédéric WANG wrote:
> Le 14/12/2015 19:39, Zalan Bujtas a écrit :
> > It’s great to hear that MathML is getting some proper cleanup. I think the 
> > proposal sounds good and I am looking forward to the patches. 
> >
> > Minor observation: I noticed that, since MathML block is no longer a 
> > flexbox, but it still needs some of the flexbox functionality, the 
> > following pattern has been introduced to the generic renderbox/block code.  
> >
> > -if (parent()->isFlexibleBox()) {
> > +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> > I just wish there was another way to handle this.
> >
> > Zalan.
> Alex will correct me if I'm wrong, but I think the changes in RenderBox
> are just a temporary solution to avoid breaking tests while we continue
> to rewrite the MathML layout code. Hopefully, these won't be needed
> anymore when we are done.
> 

Exactly, we need those to keep the width and height overrides working
like the flexbox did. This is the way layouts such us the flexbox or
the grid can force sizes in the children even if they do not request
it. Until we remove the old nodes structure in every renderer we have
to keep it, but I think we can remove all of them because MathML is
not a general layout so we control every layout and we can change its
size based on what their parent sets, even if that means using the
size of a sibling.

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

Re: [webkit-dev] MathML layout refactor proposal

[Javier Fernandez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 12/14/2015 08:03 PM, Frédéric WANG wrote:
> Le 14/12/2015 19:39, Zalan Bujtas a écrit :
>> It’s great to hear that MathML is getting some proper cleanup. I 
>> think the proposal sounds good and I am looking forward to the 
>> patches.
>> 
>> Minor observation: I noticed that, since MathML block is no 
>> longer a flexbox, but it still needs some of the flexbox 
>> functionality, the following pattern has been introduced to the 
>> generic renderbox/block code. -if
>> (parent()->isFlexibleBox()) { +if (parent()->isFlexibleBox()
>> || parent()->isRenderMathMLBlock()) { I just wish there was
>> another way to handle this.
>> 
>> Zalan.
> Alex will correct me if I'm wrong, but I think the changes in 
> RenderBox are just a temporary solution to avoid breaking tests 
> while we continue to rewrite the MathML layout code. Hopefully, 
> these won't be needed anymore when we are done.
> 

Fred is totally right. That's just legacy code from the old Flexbox
functionality, which we had to adopt temporary in order to keep
passing the current layout tests. We won't need it anymore in the new
layout logic.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlZvKusACgkQoNRbE6zycrm/QACeMthQoiPUoVL7KBBLn1c9+irj
1SQAnj4703KlHyMnsxLzKDmMSN8KW5wJ
=MBbI
-END PGP SIGNATURE-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MathML layout refactor proposal

[Myles C. Maxfield]

I can't comment for the rest of the team, but I am very excited to see this! 

-- Myles

> On Dec 9, 2015, at 3:35 AM, Alejandro Garcia Castro  wrote:
> 
> 
> Hi,
> 
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
> 
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community.  If so, we will start pushing the initial patches from our
> branch to upstream.
> 
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
> 
>   - Reduce code complexity: Adapting FlexBox layout (which is already
> complex) in order to create the MahtML layout made the code too
> complex, a big technical debt that made the improvement of MathML
> more difficult every day.
> 
>   - Avoid just another FlexBox dependent code: When we had to add
> general layout alignment support we had a lot of problems trying
> to solve some the MathML issues because it was not clear how it
> worked with the FlexBox.
> 
>   - Improve performance: We do not need all the features FlexBox
> layout adds for most of the MathML blocks but we are executing
> all that code. We also can simplify the render tree structures
> that were created to make the FlexBox layout work.
> 
>   - Make easier to improve the MathML implementation: Using
> independent renderer classes gives more flexibility to get exact
> positioning and spacing required to get high-quality math
> rendering based on TeX rules and the OpenType MATH table.  (cf
> http://www.mathml-association.org/MathMLinHTML5/)
> 
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
> 
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
> 
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
> 
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
>   keep the RenderTree structure. This is basically done, and we just
>   need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
>   created to make FlexBox work and all the code that it was
>   required. We already have the Fractions and Underover implemented
>   and the code is much clearer. This will break the tests relying on
>   a PNG image or a render tree reference. Hence we will do it also
>   per renderer and rebasing the tests after each commit.
> 
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
> 
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
> 
> Greetings,
> 
> Alex
> ___
> 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

[webkit-dev] MathML layout refactor proposal

[Alejandro Garcia Castro]

Hi,

In the last months we have been working on refactoring the MathML
layout code to make it more maintainable, because in the current point
fixing issues or adding new features has been too complex.

We have reached the point where we think we have to discuss whether
this work makes sense and whether it is interesting for the WebKit
community.  If so, we will start pushing the initial patches from our
branch to upstream.

The idea behind the refactor is to remove FlexBox dependency and
create its own layout MathML methods. The main reasons to do this are:

   - Reduce code complexity: Adapting FlexBox layout (which is already
 complex) in order to create the MahtML layout made the code too
 complex, a big technical debt that made the improvement of MathML
 more difficult every day.

   - Avoid just another FlexBox dependent code: When we had to add
 general layout alignment support we had a lot of problems trying
 to solve some the MathML issues because it was not clear how it
 worked with the FlexBox.

   - Improve performance: We do not need all the features FlexBox
 layout adds for most of the MathML blocks but we are executing
 all that code. We also can simplify the render tree structures
 that were created to make the FlexBox layout work.

   - Make easier to improve the MathML implementation: Using
 independent renderer classes gives more flexibility to get exact
 positioning and spacing required to get high-quality math
 rendering based on TeX rules and the OpenType MATH table.  (cf
 http://www.mathml-association.org/MathMLinHTML5/)

We have a working prototype that basically passes the current MathML
tests and removes the FlexBox dependency in:

https://github.com/alexgcastro/webkit/tree/MathMLLayout

We have basically one commit per MathML renderer that we had to
replace. This is still initial code and we need more work and add more
tests to make sure we are improving the situation.

We want to do it incrementally with 2 steps:
1. Remove FlexBox dependency but do not break the tests, this means
   keep the RenderTree structure. This is basically done, and we just
   need review and try to push them.
2. Refactor the RenderTree structure, removing the anonymous nodes
   created to make FlexBox work and all the code that it was
   required. We already have the Fractions and Underover implemented
   and the code is much clearer. This will break the tests relying on
   a PNG image or a render tree reference. Hence we will do it also
   per renderer and rebasing the tests after each commit.

The main con of the change that the code could be bigger in some parts
of the renderers, but more direct and simple, so it should be actually
good regarding maintenance.

If you have any question, proposal or comment just send it, it would
be great to hear some more feedback, and check if we should proceed
with this effort.

Greetings,

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