This property determines the background positioning area, that is the position of
the origin of an image specified using the 'background-image' CSS property.
'background-origin' is ignored when background-attachment is fixed.
Spec: http://dev.w3.org/csswg/css-backgrounds-3/#background-originFixes#6045.
r? @pcwalton
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: 8c402728247c73268df9389948ee9a9d9e4063b2
Attempt to not panic as much if the resources/ dir is not where it's expected to be.
Source-Repo: https://github.com/servo/servo
Source-Revision: 76225bdccb5105764d979b4d739d4d8edfc98bfe
This uses some dependencies from crates.io instead of git where the crates.io copy was already used in some other part of the dependency tree, so we had two copies of the same library.
The `android_glue` crate is the only one left where we have two copies, but solving that is more tricky since we hard-code a path in `components/servo/.cargo/config`.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 59cb1b03968a55dcce1774088890a3ecf4de0037
Spec: http://dev.w3.org/csswg/css-device-adapt/
Currently, the actual viewport is used by the layout task as part of the reflow, and the compositor uses the zoom constraints. I'm not sure if anywhere else currently needs access to the constraints (i.e. there's no CSSOM as far as I can tell).
I did not implement sections 9 (viewport <META>) or 10 (handling 'auto' for 'zoom').
Source-Repo: https://github.com/servo/servo
Source-Revision: ccf1e6b9a701cf4ff010fa1f1b4ba9d656d962af
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.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1e150140bd12624ad357e3168fb496079fb8ec7c
Fixes#5300, which it is a rebase of.
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.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8a4555cc53bc1bbb21a08eb6f010cb1215034419
HTML5 § 4.10.5.3.2 doesn't explicitly say to do this, but all other
browser engines seem to do it.
Improves the Google home page.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: f010c8331304dcdd40f40fe844087399078532d0
"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`
Source-Repo: https://github.com/servo/servo
Source-Revision: d90fe2b0889dee4eb27693aca7670969d5253424
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.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: bdcf606f4802e5b1ab3ee251b45ee1e81800359a
This allows things like `<sup><span>Foo</span></sup>` to work and
improves Wikipedia.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: d7b6961104b517a22e01c192d4bb6a7ad5934ce8
On my laptop, running `./mach test-unit` goes from about 11 minutes to 22 seconds, when run after `./mach build`.
Fix#5291.
Source-Repo: https://github.com/servo/servo
Source-Revision: 017d1053617f6769d7f355e4a97d52ae67e53d1c
There are several optimizations here:
* We make font families atoms, to allow for quicker comparisons.
* We precalculate an FNV hash of the relevant fields of the font style
structure.
* When obtaining a platform font group, we first check pointer equality
for the font style. If there's no match, we go to the FNV hash. Only
if both caches miss do we construct and cache a font group. Note that
individual fonts are *also* cached; thus there are two layers of
caching here.
15% improvement in total layout thread time for Facebook Timeline.
r? @glennw (since you last worked on `get_layout_font_group_for_style()` IIRC)
Source-Repo: https://github.com/servo/servo
Source-Revision: ba0d28e0023fce2003d64b9caf97fcdbeb7cdb28
Transition events are not yet supported, and the only animatable
properties are `top`, `right`, `bottom`, and `left`. However, all other
features of transitions are supported. There are no automated tests at
present because I'm not sure how best to test it, but three manual tests
are included.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: ebdf1d494b6c986e6dfcb7d8fd3f0ffa126523ed
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.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e811229bae6b338fabcd7df602079730c942889
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.
Reconstructed from #5138 via raw diffing.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: fd1bb49a65dd998c8ef9890a1576aaf62ddfdba1
