One point to note is that I am not entirely sure what the result
of the pre-existing valueAsNumber test should be for this strange
case which does not lie exactly on a week/day boundary. Chrome
gives a negative timestamp, which seems more wrong than the result
we give, and neither gecko or WebKit appear to support the 'week'
type. So I'm considering this result acceptable for now, and this
may be something that will need more WPT tests added in the future.
For example, in the following abbreviated test HTML:
<span>some text</span>
<script>println("whf")</script>
We would have to craft the expectation file to include the "some text"
segment, usually with some leading whitespace. This is a bit annoying,
and makes it difficult to manually craft expectation files.
So instead of comparing the expectation against the entire DOM inner
text, we now send the inner text of just the <pre> element containing
the test output when we invoke `internals.signalTextTestIsDone`.
This change ensures that the value sanitization algorithm is run and
the text cursor is set to the correct position when the type attribute
of an input is changed.
This patch makes a few changes to the way we calculate line-height:
- `line-height: normal` is now resolved using metrics from the used
font (specifically, round(A + D + lineGap)).
- `line-height: calc(...)` is now resolved at style compute time.
- `line-height` values are now absolutized at style compute time.
As a consequence of the above, we no longer need to walk the DOM
ancestor chain looking for line-heights during style computation.
Instead, values are inherited, resolved and absolutized locally.
This is not only much faster, but also makes our line-height metrics
match those of other engines like Gecko and Blink.
