This assumes that there are no ligatures that span across multiple
words. Since we have a per-word shape cache, this is a safe assumption
as of now. I have left comments to ensure that, if and when this is
revisted, we make sure to handle it properly.
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.)
Groove and Ridge rendering shows a solid border when color is black, that is broken and the current patch will implement a similar behavior as Firefox.
a) If the groove border is different from a black border (the bug that this
patch set fixes);
b) If a ridge border is different from a black border (samething);
c) If groove is different from ridge (they should be inverse of each other).
All 3 new tests passes on OSX Yosemite (10.10).
The ligature disabling code has been manually verified, but I was unable
to reftest it. (The only way I could think of would be to create an
Ahem-like font with a ligature table, but that would be an awful lot of
work.)
Near as I can tell, the method used to apply the spacing (manually
inserting extra advance post-shaping) matches Gecko.
`invert` is not yet supported.
Objects that get layers will not yet display outlines properly. This is
because our overflow calculation doesn't take styles into account and
because layers are always anchored to the top left of the border box.
Since fixing this is work that is not related to outline *per se* I'm
leaving that to a followup and making a note in the code.
The Unicode awareness of `text-transform` is implemented as well as
possible given the Rust standard library's Unicode support. In
particular, the notion of an alphabetic character is used instead of a
letter.
Gecko has a subclass of text run to handle text transforms, but I
implemented this in a simpler way.
Let's build this incrementally. I implemented a `Blob` that can hold a `DOMString`, and has `size` attribute and `slice(...)` method. I'll finish the rest in later PRs.
This exposed some problems in our clipping logic, which was never
properly rewritten for the stacking context reform. The clipping code
worked in terms of a stack of clips, but the new stacking context code
has no concept of a stack of clip regions. Fixing that in turn exposed
some flaky/incorrect tests:
* `borders` had an incorrect reference image, as far as I can tell.
* `negative_margins` had some stray pixels, fixed by changing the text.
Still need to impl `Activatable` on all activatable elements. I'll probably push those changes to this PR, however they can be made separately as well.
This is the Hyper pull request, plus the set up for OpenSSL on Android to make it merge.
Sean's commits have been reviewed in #4065 (My Android changes were reviewed by Glenn)
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.
