Check if the immediate node is an element before looking at ancestors when clicking, and flush pending layout changes after dispatching the event.
Add average advance width to the font metrics structure, using the X glyph as a best guess.
Implement simple layout for text, button, radio, and checkbox inputs. Implement simple interaction for checkboxes and radio buttons.
Disallow toggling radio buttons. Use generated content for checkboxes and radio buttons. Switching to the glyph 0 for the average advance width.
Disallow wrapping on input elements.
Remove unneeded input type information from layout.
Split a long line.
Fix linux build error.
auto merge of #3520 : jdm/servo/formcontrols, r=pcwalton

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.
layout: Implement the correct hypothetical box behavior for
absolutely-positioned elements declared with `display: inline`.

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.
auto merge of #3546 : pcwalton/servo/absolute-inline, r=glennw

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
layout: Implement `box-sizing: border-box`.

Improves GitHub.
gfx: Fix imprecision in `float_to_fixed`.

Improves text rendering a lot.
auto merge of #3549 : pcwalton/servo/fix-float-to-fixed, r=zwarich

Improves text rendering a lot.

r? @zwarich
auto merge of #3556 : pcwalton/servo/box-sizing, r=SimonSapin

Improves GitHub.
Move find_fragment_node to Document.
Remove the fragment_node field from Page (fixes #3543).

Since Page isn't reflected, it cannot be rooted, and pointers to JS-managed
objects inside it are not guaranteed to be traced. This may cause the pointer
to become dangling.
gfx: Use subpixel positioning for glyphs.

Improves text rendering significantly.
auto merge of #3560 : pcwalton/servo/subpixel-glyph-positioning, r=mbrubeck

Improves text rendering significantly.

r? @mbrubeck
Clear the fragment_name field when resizing.

This reinstates the behaviour from before the change in
a1bf49c1ce61e4df1b788960826b45c6469ad976.