| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
See #6376
|
|
|
|
| |
https://github.com/servo/rust-geom/pull/81
|
|\
| |
| |
| |
| |
| |
| |
| | |
r? @pcwalton
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6328)
<!-- Reviewable:end -->
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reasons behind existing unstable features:
alloc:
- `make_unique()`
- direct calls into `heap::allocate()`, etc
- `boxed::into_raw()` (naming)
collections:
- `slice_chars()` (needs to prove its worth)
core:
- lots and lots of pointer manip
- `raw` stuff
std_misc:
- Handle stuff
- hasher stuff
str_char:
- CharRange
|
|
|
|
|
|
| |
for items outside it.
This improves Servo's performance on large pages.
|
|
|
|
| |
Improves Twitter.
|
|
|
|
| |
Fixes #6113 (assertion failures caused by floats in mixed-direction pages).
|
|
|
|
| |
Fixes #5856
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
absolutely-positioned elements.
This also implements a little bit of the infrastructure needed to
support for fragmentation via support for multiple positioned fragments
in one flow.
Improves Google.
|
|
|
|
| |
Improves linux.com.
|
|
|
|
| |
Improves Hacker News.
|
|
|
|
| |
Improves Twitter.
|
|
|
|
|
|
|
|
|
| |
Improves the Google SERPs.
We mark `html/rendering/replaced-elements/images/space.html` as failing.
This test tested whether `<img hspace>` and inline margins do the same
thing. Since this was trivially the case before (since we implemented
neither) and now is not, this test now fails.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=glennw
Improves Amazon.
r? @glennw
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/5805)
<!-- Reviewable:end -->
|
| |
| |
| |
| |
| |
| | |
intrinsic sizes of inline flows.
Improves Amazon.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
This allows things like `<sup><span>Foo</span></sup>` to work and
improves Wikipedia.
r? @glennw
|
| |
| |
| |
| |
| |
| |
| | |
values properly in simple cases.
This allows things like `<sup><span>Foo</span></sup>` to work and
improves Wikipedia.
|
|/
|
|
|
|
| |
line height computation logic as final block size assignment.
Improves Wikipedia.
|
|
|
|
|
|
|
|
|
| |
text layout, and unify the inline layout paths for pre- and
normally-formatted text.
This fixes a lot of "jumpiness" and removes the `new_line_pos` stuff.
Closes #2260.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
The new `Vec::append` method is clearer and potentially faster.
|
| |
| |
| |
| | |
The new `Vec::append` method is clearer and potentially faster.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
§ 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.
|
|
|
|
|
| |
This is necessary for correctly converting `relative_containing_block_size`
to physical coordinates.
|
|
|
|
|
|
|
|
|
| |
...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.
|
| |
|
|
|
|
| |
This reverts commit 30fd28d1077fbb3f47140f6ab1252c0d24f44d23.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|