The first commit fixes#3624, and the second commit fixes a bug uncovered by the first fix and caught by a reftest (according to CSS 2.1, inline-blocks should have the shrink-to-fit algorithm run on them when size is set to 'auto'). The two new reftests included here fail before the fix and pass afterwards.
Source-Repo: https://github.com/servo/servo
Source-Revision: 986f9cb5432dc51e37e0c47a4f430c0353c6dc75
(Still off by default. Enable with `RUST_LOG=style`.)
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 172aed535be3c34775824dac64ad2b91fc379ad5
This was making `box-shadow` not show up in many cases, in particular,
but the effects were not limited to that.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 499d17f564d699e5e290e8a3859f64e7536827a7
Together these improve a large number of sites: GitHub, Reddit, Wikipedia, etc.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 63a7742d834e9ed44421baa3ce218a5eabce58bf
The rendering is still wrong beause of #2795, but at least we get a rendering.
(This test change is just for readability, it should be equivalent to before.)
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 3cc87165a1279005fa2c12413f33487dee31df96
Only the recommended, comma-separated syntax is supported.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: a80d88897d176630c79f929e8b1fd661b2e1a17c
The exact rendering is ill-spec'd. Some things are ugly (especially the
width and height of list style images) but they are infrequently used
and I believe this implementation matches the spec. Numeric lists are
not supported yet, since they will require a separate layout pass.
The implementation is a subclass of `BlockFlow`, on advice from Robert
O'Callahan.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 112ef5c484e821aa4869aeaf12a12146f2424fe0
I had to use a somewhat unconventional method of computing text
indentation (propagating from blocks down to inlines) because of the way
containing blocks are handled in Servo.
(As a side note, neither Gecko nor WebKit correctly handles percentages
in `text-align`, at least incrementally -- i.e. when the percentages are
relative to the viewport and the viewport is resized.)
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: be6612193786ef22810fd66b3ce244a7e66cbcf4
By "idempotent" I mean that later passes do not stomp on data from
earlier passes, so that we can run the passes individually for
incremental reflow. The main change here was to stop overwriting the
"minimum inline-size" field of each column with the column's computed
inline-size.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 909dd0e80f5c6a9051da6e2f70d77186cc545b1a
This adds the infrastructure necessary to support stacking contexts that
are not containing blocks for absolutely-positioned elements. Our
infrastructure did not support that before. This minor revamp actually
ended up simplifying the logic around display list building and
stacking-relative position computation for absolutely-positioned flows,
which was nice.
This will need this PR: https://github.com/servo/rust-azure/pull/112 I have not updated the Cargo.lock file yet because I want the merge commit.
r? @glennw
f? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 68c90e27970808bddcb8c8a4e782bd4405e67a5c
Fixes the blank spaces showing up in Wikipedia.
r? @kmcallister
Source-Repo: https://github.com/servo/servo
Source-Revision: 9afdce4405f0f5998c81eae83bbb527d0e95ec8e
Attempt to solve #3690
I've re-rolled the changes from https://github.com/servo/servo/pull/2610, and then doen the necessary updates to get this to compile with the current snapshot of rust.
The documentation for values I've added in the bitflag are missing, because I don't know what is the appropriate text.
Source-Repo: https://github.com/servo/servo
Source-Revision: e13873bba1782580db4abe46e883b08da829cbb6
This implements the scheme described here:
https://groups.google.com/forum/#!topic/mozilla.dev.servo/sZVPSfPVfkg
This commit changes Servo to generate one display list per stacking
context instead of one display list per layer. This is purely a
refactoring; there are no functional changes. Performance is essentially
the same as before. However, there should be numerous future benefits
that this is intended to allow for:
* It makes the code simpler to understand because the "new layer needed"
vs. "no new layer needed" code paths are more consolidated.
* It makes it easy to support CSS properties that did not fit into our
previous flat display list model (without unconditionally layerizing
them):
o `opacity` should be easy to support because the stacking context
provides the higher-level grouping of display items to which opacity
is to be applied.
o `transform` can be easily supported because the stacking context
provides a place to stash the transformation matrix. This has the side
benefit of nicely separating the transformation matrix from the
clipping regions.
* The `flatten` logic is now O(1) instead of O(n) and now only needs to
be invoked for pseudo-stacking contexts (right now: just floats),
instead of for every stacking context.
* Layers are now a proper tree instead of a flat list as far as layout
is concerned, bringing us closer to a production-quality
compositing/layers framework.
* This commit opens the door to incremental display list construction at
the level of stacking contexts.
Future performance improvements could come from optimizing allocation of
display list items, and, of course, incremental display list
construction.
r? @glennw
f? @mrobinson @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: 397d8138e7b27541faf03d9635d7648416da4a75
Instead of creating a display list for the entire page, only create one
for an area that expands around the viewport. On my machine this makes
incremental layout of http://timecube.com 50% faster.
Source-Repo: https://github.com/servo/servo
Source-Revision: 26045d7fcbab8851fbefe2851cd904203f8fd8dd
Instead of looking at the display tree, have ContentBox(es)Query consult
the flow tree. This allow optimizing away parts of the display tree
later. To do this we need to be more careful about how we send reflow
requests, only querying the flow tree when possible.
Fixes#3790.
Source-Repo: https://github.com/servo/servo
Source-Revision: c9089c45c4b7d40419233b48a192d85a8ad71c99
This is the last PR and most of the work for the maze solver and RoboHornet.
r? @glennw
cc @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: 035ff19e4a5995989c5fd34928af2a6690bb8062
These were showing up really high in the maze solver profile.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 9f248378f06d4de7c0df01b64e93edcc4de208cf
These should have no effect on functionality.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: 4bdd9a5ec02526b9a407b23dcbf95cc570e6fa56
...n-optimized, debug build of mozjs and rust-mozjs. Update the Cargo snapshot to enable new feature support.
Source-Repo: https://github.com/servo/servo
Source-Revision: e100a1834f40599952a790d2537d2b1262585e82
`layout::fragment` and `layout::block` were getting too big.
r? @mrobinson
Source-Repo: https://github.com/servo/servo
Source-Revision: 01f6a8102dfbb7eaef564acf8891088011905b59
This also enables incremental reflow by default. \o/
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: f6941b35e3b945f4a6dcd2cf03daa345ad2bcaed
This also adds some extra debugging infrastructure which I found useful tracking
this bug down. A regression in the br reftests is also uncovered by this patch,
which I'll work on fixing next.
EDIT: nevermind. no regression, I just tested that before a rebase.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: b86344b697f814b982e52f4a72c26d58c915c37b
Now that DOM/Flow traversals have been refactored out, the `recalc_style_for_subtree`
function in `css/matching.rs` can be removed, in lieu of just running the standard
`recalc_style_for_node` and `construct_flows` traversals sequentially. Now we
no longer have the maintenance headache of duplicating selector matching logic
in two places! \o/
This passes reftests with both default arguments, and with `-y 1`.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 7eaeaeeb217e7cbd083fe318863e7de4b9f38e2b
http://dbaron.org/css/intrinsic/
Column spans are not yet supported.
This effectively adds support for percentage widths, and it also fixes
many bugs, improving the layout of Google and Wikipedia.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: e2d7777c41135b71293c195d2a9d7a1bc2afd0ca
This implements a general framework for legacy presentational attributes
to the DOM and style calculation, so that adding more of them later will
be straightforward.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0aeecfc41d5f0c637960fcddf87cc2db3e5efeea
We push down clipping areas during absolute position calculation. This
makes display items into a flat list, improving cache locality. It
dramatically simplifies the code all around.
Because we need to push down clip rects even for absolutely-positioned
children of non-absolutely-positioned flows, this patch alters the
parallel traversal to compute absolute positions for
absolutely-positioned children at the same time it computes absolute
positions for other children. This doesn't seem to break anything either
in theory (since the overall order remains correct) or in practice. It
simplifies the parallel traversal code quite a bit.
See the relevant Gecko bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=615734
r? @mrobinson
Source-Repo: https://github.com/servo/servo
Source-Revision: fd70b366aeada7f8cb4b2457c04fd07f0ea9b143
This makes layout more idempotent, which is important for incremental
layout.
Also converts `is_root` to a set of flags and fixes a `TODO` concerning
percentage inline heights of images.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 7902ccf8507a7ec31515bfb5824dc4727564fe4d
Extra size from margins should be included in block size, so that
layers are large enough to include the entire block. This is typically
hidden by large tile sizes (512x512), but fitted tiles makes the issue
a lot more common.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7f26c671377dad073da38058c75b2d3b380b6f16
Layers are currently all children of the root layer, so instead of
using coordinates relative to the parent flow we should use coordinates
relative to the page.
Fixes#2061.
Source-Repo: https://github.com/servo/servo
Source-Revision: eff0de0ce12b20ffc4806d14c95777004003f2ae
Although the computed `display` property of elements with `position:
absolute` is `block`, `position: absolute; display: inline` can still
behave differently from `position: absolute; display: block`. This is
because the hypothetical box for `position: absolute` can be at the
position it would have been if it had `display: inline`. CSS 2.1 §
10.3.7 describes this case in a parenthetical:
"The static-position containing block is the containing block of a
hypothetical box that would have been the first box of the element if
its specified 'position' value had been 'static' and its specified
'float' had been 'none'. (Note that due to the rules in section 9.7 this
hypothetical calculation might require also assuming a different
computed value for 'display'.)"
To handle this, I had to change both style computation and layout. For
the former, I added an internal property
`-servo-display-for-hypothetical-box`, which stores the `display` value
supplied by the author, before the computed value is calculated. Flow
construction now uses this value.
As for layout, implementing the proper behavior is tricky because the
position of an inline fragment in the inline direction cannot be
determined until height assignment, which is a parallelism hazard
because in parallel layout widths are computed before heights. However,
in this particular case we can avoid the parallelism hazard because the
inline direction of a hypothetical box only affects the layout if an
absolutely-positioned element is unconstrained in the inline direction.
Therefore, we can just lay out such absolutely-positioned elements with
a bogus inline position and fix it up once the true inline position of
the hypothetical box is computed. The name for this fix-up process is
"late computation of inline position" (and the corresponding fix-up for
the block position is called "late computation of block position").
This improves the header on /r/rust.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: f7d2fb6ff86afff7a5b674f751af9370a5a6b142
So far the changes to layout seem fairly well-contained; I think this is worth integrating to give us a browser that is easier to dogfood (and allows us to work on things like form submission much easier), especially since the long-term viability of WebComponents-as-forms is not assured.
Source-Repo: https://github.com/servo/servo
Source-Revision: f80096069592b864221abe112eaf2ecb6c444fda
