There is no good reason to have the two types.
This also means that the result of LayoutTask::profiler_metadata no longer
borrows the LayoutTask, which I'll need later.
Move Stylesheet loading and ownership from the layout task into HTML elements
Stylesheets for `HTMLLinkElement`s are now loaded by the resource task, triggered by the element in question. Stylesheets are owned by the elements they're associated with, which can be `HTMLStyleElement`, `HTMLLinkElement`, and `HTMLMetaElement` (for `<meta name="viewport">).
Additionally, the quirks mode stylesheet (just as the user and user agent stylesheets a couple of commits ago), is implemented as a lazy static, loaded once per process and shared between all documents.
This all has various nice consequences:
- Stylesheet loading becomes a non-blocking operation.
- Stylesheets are removed when the element they're associated with is removed from the document.
- It'll be possible to implement the CSSOM APIs that require direct access to the stylesheets (i.e., ~ all of them).
- Various subtle correctness issues are fixed.
One piece of interesting follow-up work would be to move parsing of external stylesheets to the resource task, too. Right now, it happens in the link element once loading is complete, so blocks the script task. Moving it to the resource task would probably be fairly straight-forward as it doesn't require access to any external state.
Depends on #7979 because without that loading stylesheets asynchronously breaks lots of content.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8039)
<!-- Reviewable:end -->
Stylesheets for `HTMLLinkElement`s are now loaded by the resource task, triggered by the element in question. Stylesheets are owned by the elements they're associated with, which can be `HTMLStyleElement`, `HTMLLinkElement`, and `HTMLMetaElement` (for `<meta name="viewport">).
Additionally, the quirks mode stylesheet (just as the user and user agent stylesheets a couple of commits ago), is implemented as a lazy static, loaded once per process and shared between all documents.
This all has various nice consequences:
- Stylesheet loading becomes a non-blocking operation.
- Stylesheets are removed when the element they're associated with is removed from the document.
- It'll be possible to implement the CSSOM APIs that require direct access to the stylesheets (i.e., ~ all of them).
- Various subtle correctness issues are fixed.
One piece of interesting follow-up work would be to move parsing of external stylesheets to the resource task, too. Right now, it happens in the link element once loading is complete, so blocks the script task. Moving it to the resource task would probably be fairly straight-forward as it doesn't require access to any external state.
Remove DisplayListBuildingResult
Always produce a DisplayList when processing nodes for display list
construction. StackingContexts are now added to the positioned content
section of DisplayLists. This makes the code a bit simpler and opens up
the possibility of producing a StackingContext in another section of
the DisplayList. This doesn't change behavior, but is a cleanup
prerequisite for proper inline stacking context support.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8337)
<!-- Reviewable:end -->
This is the strategy we'll need to take for attributes, and so this change
puts us in a position to handle attributes and state the same way.
This does mean that we stop taking care to track the situations where our
state has reverted to the original state, with no net change. I think that's
probably of negligible value though.
This flag is no longer necessary, because stacking contexts can now
create layers lazily for content that needs to be stacked above a
layer. This should reduce the number of layers on pages, hopefully
reducing overdraw.
Always produce a DisplayList when processing nodes for display list
construction. StackingContexts are now added to the positioned content
section of DisplayLists. This makes the code a bit simpler and opens up
the possibility of producing a StackingContext in another section of
the DisplayList. This doesn't change behavior, but is a cleanup
prerequisite for proper inline stacking context support.
This should make it somewhat easier to experiment with alternative
representations in the future. To reduce churn, this commit leaves the String
field public, though.
Also, this will allow us to use the default String type to represent the IDL
USVString type, which explicitly forbids unpaired surrogates, ans as such is
a better match to the Rust String type.
