Table columns should be layed out according to the 'direction' property of the
table flow, regardless of the 'direction' property of any table-row,
table-rowgroup, etc. flows.
This fixes a number of the `direction-applies-to-*` tests in the CSS2.1 test
suite.
This also simplifies `propagate_column_inline_sizes_to_child` by separating
the code used for table cells from the code for non-cell flows.
r? @pcwalton
blocks.
* Stop double-counting border and padding for inline-block fragments.
(Test case: `inline_block_border_intrinsic_size_a.html`.)
* Take clearance into account when determining intrinsic widths of
blocks containing floats.
Improves the Amazon headers.
* Fix queries involving stacking contexts
* The code was double accumulating stacking context origins.
* Handle queries of inline elements.
* The node addresses being compared were incorrect (CharacterData vs. Span)
* Handle ScriptQuery reflows correctly.
* The layout task was skipping the compute absolute positions traversal, so failed before window.onload.
This add some properties to the style system and a new flow type, but the larger issues of dealing with fragmentation in the flow tree is still an open question.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/5480)
<!-- Reviewable:end -->
Known issues:
* Collapsed borders do not correctly affect the border-box of the table
itself.
* The content widths of all cells in a column and the content height of
all cells in a row is the same in this patch, but not in Gecko and
WebKit.
* Corners are not painted well. The spec does not say what to do here.
* Column spans are not handled well. The spec does not say what to do
here either.
"Links to the multipage version of the specification are unfortunately
likely to break over time."
-- https://html.spec.whatwg.org/multipage/asefij.html
This commit removes all references to the specific pages when viewing
WHATWG using multipage mode. I went through all these links and they
redirect fine.
Regex used to generate this commit:
`s_whatwg.org/multipage/.*#_whatwg.org/multipage/#_g`
flows and static positions of hypothetical boxes.
Before this change, Servo used one code path that computed the position
of flows with `position: static` or `position: relative` and another
separate code path that computed the position of flows with `position:
absolute` or `position: fixed`. The latter code attempted to duplicate
the former code to determine the static position of hypothetical boxes,
but this was both fragile and incorrect in the case of hypothetical
boxes nested inside floats. In fact, it's impossible to determine the
static position of an absolute flow relative to its containing block at
inline-size assignment time, because that static position could depend
on a float that cannot be placed until block-size assignment!
This patch changes block layout to use the same code path for static
positioning of regular flows and static positioning of absolute flows
where applicable. This both simplifies the code and improves its
efficiency, since it allows the `hypothetical_position` field and
`static_block_offsets` data structure to be removed. Moreover, it
improves correctness in the above case (which the new reftest checks).
This allows the sidebar in Facebook Timeline to be positioned properly.
As the float ceiling is relative to the border box, not the margin box,
of the parent flow, top margin must not be included.
This exposed a pre-existing bug whereby margins are discarded if a block
contains only floats and no content, affecting the tests
`float_intrinsic_height.html` and `margins_inside_floats_a.html`. As a
workaround, some invisible content has been added to the bodies of both
tests.
r? @mbrubeck
`assign_block_size_for_inorder_child_if_necessary` logic from table
wrapper flows.
As far as I can tell, this is a cut-and-paste of old buggy code from
block flows. Delegating to the correct block flow code fixes the sidebar
float placement on Guardians of the Galaxy.
the float ceiling.
As the float ceiling is relative to the border box, not the margin box,
of the parent flow, top margin must not be included.
This exposed a pre-existing bug whereby margins are discarded if a block
contains only floats and no content, affecting the tests
`float_intrinsic_height.html` and `margins_inside_floats_a.html`. As a
workaround, some invisible content has been added to the bodies of both
tests.
when estimating the inline size of block formatting contexts.
The speculated inline-size of the preceding floats was forced to zero at
the wrong time if the float was itself cleared, causing it to overwrite
the speculated value. Shuffling the code around a bit fixes the problem.
I think this should have been changed in #3618 but was missed. r? @pcwalton
I wasn't able to come up with a good test case for this, partly because of other bugs related to floats and formatting contexts.
This fixes a bug in finding the top left corner of an RTL block in physical
coordinates. (The old code used the `start` point of the `position` rect,
which is not always the top left.)
It also fixes the setting of `position.start.i` in certain mixed LTR/RTL
cases.
There is still a bug related to `position.size` for RTL blocks with margins.
See the FIXME comments for details.
`cellspacing` attribute per HTML5 § 14.3.9.
Table layout code has been refactored to push the spacing down to
rowgroups and rows; this will aid the implementation of
`border-collapse` as well.
This commit also fixes two nasty issues in table layout:
* In fixed layout, extra space would not be divided among columns that
had auto width but had nonzero minimum width.
* In automatic layout, extra space would be distributed to constrained
columns as well even if unconstrained columns with percentage equal to
zero were present.
§ 12.3-12.5.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
...and vice-versa. This is not a complete fix for all mixed-direction layout
cases, but it fixes enough problems to make some simple test cases pass, like
tha attached reftest.
There are FIXME comments for many of the remaining issues. In particular,
this does not yet handle RTL layout of fixed/absolute elements.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
Moved from #4544, because Critic.
Fixes#4544.
§ 12.3-12.5.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
