[Webkit-unassigned] [Bug 179682] Incorrect bounds inside <mover>/<munder> when a stretchy operator is present

[bugzilla-daemon at webkit.org]

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

--- Comment #38 from Minsheng Liu <lambda at liu.ms> ---
On the one hand, it is much harder than I thought to keep a logicalWidthWithoutStretchyOperators. On the other hand, it seems that space surrounding an operator shall only be considered when it is in a <mrow>, as the spec says:

> The amount of horizontal space added around an operator (or embellished operator), when it occurs in an mrow, can be directly specified by the lspace and rspace attributes.

Therefore, the edge case is really beyond the scope of this patch, and I shall open a new bug handling it. If that is the case, then my code has properly handled all cases, with the additional flexibility to adapt to different interpretation of stretch widths fairly easily. Once we make up decision on that front, I suggest we freeze the discussion on the layout algorithm and enters the next step.

In the mean time, I will convert the manual test file into a JavaScript based test file that compares stretchy operators’ widths. I will also try to add a performance test, but I might need some help from you guys.

So again, @fred, out of the following three definitions, which one should we put into this patch:

// my proposal, it is the middle column of this picture: https://camo.githubusercontent.com/606494a142955188301373ca36780293faa669d7/68747470733a2f2f692e696d6775722e636f6d2f583631524b594e2e706e67

base.stretchWidth = max(over.width, under.width, base.width)
under.stretchWidth = base.width
over.stretchWidth = base.width

// the standard:
base.stretchWidth = max(over.width, under.width)
under.stretchWidth = max(base.width, over.width)
over.stretchWidth = max(base.width, under.width)

// Firefox: it is the left column of this picture: https://camo.githubusercontent.com/606494a142955188301373ca36780293faa669d7/68747470733a2f2f692e696d6775722e636f6d2f583631524b594e2e706e67
base.stretchWidth = max(over.width, under.width, base.width)
under.stretchWidth = max(base.width, over.width)
over.stretchWidth = max(base.width, under.width)

I do not think we should wait for the committee, as again in the future we could change our decision fairly easily, but future patches should crucially rely on a sensible logical bounds of <munderover>.

(In reply to Minsheng Liu from comment #37)
> To handle the latest edge case I provided, I think we really could benefit a
> lot from a logicalWidthWithoutStretchyOperators() virtual method. With that,
> we could have something like:
> 
> for (child : children)
>   layout child if needed
> 
> this->m_logicalWidthWithoutStretchyOperator = max(children’s)
> 
> for (child : children that are embellished operators)
>   let operator = ...
>   stretch operator
>   fixLayout(parent node = child, bad node = operator)
> 
> layout children
> set logical width
> et cetera 
> 
> This way we can combine the method we are working on with layoutBlock.
> 
> Also I suspect our existing fixLayout (setNeedsLayout() then layout()) is
> problematic for cases like an operator embellished with multiple
> subscript/superscript.
> 
> — Sent from my iPhone.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171130/df2ae3be/attachment.html>