Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
of ShapeInfo so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : 9a083ccd95fd7565112a45e30c15a91b97c7290f
Use move constructor for two reasons. 1) The copy constructor is needed only
when appending FloatInfo to mFloats, so using move constructor will likely
be more efficient if some of the member variables support move constructor.
2) Part 6 will added a UniquePtr member to FloatInfo, so using move
constructor becomes necessary.
Also change the return value of AddFloat() to void to simplify the code,
since all the other callers do not check the return value, and
BlockReflowInput::FloatAndPlaceFloat() only asserts in debug mode. I assume
it's safe to omit the OOM check.
MozReview-Commit-ID: GVbbsdBjr7b
--HG--
extra : rebase_source : e0f647e029278a5033bb9d6d780e73e32de460d3
circle() allows the user to define an empty flow area, so IsEmpty() needs to
be overridden.
The flow area defined by a shape needs to be clipped to the margin-box per
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
In the reftests, both clip-path and shape-outside uses the same value so
that it's easier to debug visually.
Add LogicalPoint::LineRelative() because we need to convert a point's I() to
the line-axis in nsFloatManager. LineRelative() differs from I() in all
'rtl' direction per
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: FxQaFPrEQ73
--HG--
extra : rebase_source : 0d768002a38adbded2a0caa6d3e001eaaca3313d
Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
of ShapeInfo so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : 9a083ccd95fd7565112a45e30c15a91b97c7290f
Use move constructor for two reasons. 1) The copy constructor is needed only
when appending FloatInfo to mFloats, so using move constructor will likely
be more efficient if some of the member variables support move constructor.
2) Part 6 will added a UniquePtr member to FloatInfo, so using move
constructor becomes necessary.
Also change the return value of AddFloat() to void to simplify the code,
since all the other callers do not check the return value, and
BlockReflowInput::FloatAndPlaceFloat() only asserts in debug mode. I assume
it's safe to omit the OOM check.
MozReview-Commit-ID: GVbbsdBjr7b
--HG--
extra : rebase_source : e0f647e029278a5033bb9d6d780e73e32de460d3
With this patch, we shall only maintain one version of the TransformText logic.
MozReview-Commit-ID: JAIksFVqvqf
--HG--
extra : rebase_source : 3187632d7162bba64994b793448314b8323e3d46
This patch is an implementation of CSS Text 3 - 4.1.1 Phase 1 Step 1.
According to the specification, if white space characters are considered
collapsible, they should be removed before applying segment break transformation
rules during the text transform.
In this patch, a refactoring of text transformation logic has been made. Every
run of consecutive document white space characters (spaces/tabs/segment breaks)
is collected first. Then, we could apply the white space processing rules
accordingly.
MozReview-Commit-ID: 1JStjFk5TBs
--HG--
extra : rebase_source : b7a81e08c026d25482dc35994f4595989c8b09c0
Two changes:
In nsIFrame::GetFrameFromDirection, detect frames that are in
a different anonynous content tree than 'this' and then just keep
traversing frames until we get one that isn't.
In nsFrame::GetLastLeaf: the old code did allow the first child frame
to be IsRootOfNativeAnonymousSubtree (it just checked siblings).
I think this was unintentional and that we should check the first
child too (and return its parent in that case, i.e. never return
something that is IsRootOfNativeAnonymousSubtree here).
These were fixed by https://github.com/servo/servo/pull/14922.
MozReview-Commit-ID: 3Ypfq0BmkIY
--HG--
extra : rebase_source : c32e69303826b65059dcae963ddce94f5f4c40f8
These were fixed by https://github.com/servo/servo/pull/14922.
MozReview-Commit-ID: H7s2lGJ8QYU
--HG--
extra : rebase_source : ef104630c7715f2f95539a3bb65e46a480ff2bdb
With this patch, we shall only maintain one version of the TransformText logic.
MozReview-Commit-ID: JAIksFVqvqf
--HG--
extra : rebase_source : 49ec749ae74f872e9749e026affe7f2e22db71f9
This patch is an implementation of CSS Text 3 - 4.1.1 Phase 1 Step 1.
According to the specification, if white space characters are considered
collapsible, they should be removed before applying segment break transformation
rules during the text transform.
In this patch, a refactoring of text transformation logic has been made. Every
run of consecutive document white space characters (spaces/tabs/segment breaks)
is collected first. Then, we could apply the white space processing rules
accordingly.
MozReview-Commit-ID: 1JStjFk5TBs
--HG--
extra : rebase_source : 0c3cd845f12de407558aae4db3f3c75343da7050
circle() allows the user to define an empty flow area, so IsEmpty() needs to
be overridden.
The flow area defined by a shape needs to be clipped to the margin-box per
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
In the reftests, both clip-path and shape-outside uses the same value so
that it's easier to debug visually.
Add LogicalPoint::LineRelative() because we need to convert a point's I() to
the line-axis in nsFloatManager. LineRelative() differs from I() in all
'rtl' direction per
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: FxQaFPrEQ73
--HG--
extra : rebase_source : 02b4eafdff42477ef2c69d604a1650db01f954e4
Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
nsFloatManager so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : c73b0d0be2350db3eedb61b565de194842352ba1
Use move constructor for two reasons. 1) The copy constructor is needed only
when appending FloatInfo to mFloats, so using move constructor will likely
be more efficient if some of the member variables support move constructor.
2) Part 6 will added a UniquePtr member to FloatInfo, so using move
constructor becomes necessary.
Also change the return value of AddFloat() to void to simplify the code,
since all the other callers do not check the return value, and
BlockReflowInput::FloatAndPlaceFloat() only asserts in debug mode. I assume
it's safe to omit the OOM check.
MozReview-Commit-ID: GVbbsdBjr7b
--HG--
extra : rebase_source : 4765bbcf5c2533845bd8f7fb00117983429a622e
I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
--HG--
extra : rebase_source : ac80eaea2474b9ec4b47b1cc9a5bdd2e61f6ec4d
