If we had a scheduled update of either of these kind, make sure to
cancel it after performing an update. Otherwise we might do a redundant
second update with the same results.
This could happen if something schedules an async layout, and before it
can happen, something requires a sync layout, which we do right away.
A types which have special functions declared with "= default can be
trivially copied. Besides being good practice, the compiler might be
able generate copy and initialize code in a more optimized way.
Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v832/
We now evaluate the conditions of `@media` rules at the same point in
the HTML event loop as evaluation of `MediaQueryList`s. This is not
strictly to spec, but since the spec doesn't actually say when to do
this, it seems to make the most sense. In any case, it works! :^)
The recursive style update function was written a bit strangely and
would only mark descendants of the style update root as not needing a
style update.
With this patch, all nodes in the subtree now have clean style after a
style update finishes.
Layout depends on style (and not the other way around), so if the
document has dirty style when we enter update_layout(), make sure we
call update_style() before proceeding with the layout work.
This has the pleasant effect of coalescing some redundant layouts.
'static' for a function means that the symbol shall not be made public
for the result of the current compilation unit. This does not make sense
in a header, especially not if it's a large function that is used in
more than one place and not that performance-sensitive.
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
Until now, we've internally thought of the CSS "display" property as a
single-value property. In practice, "display" is a much more complex
property that comes in a number of configurations.
The most interesting one is the two-part format that describes the
outside and inside behavior of a box. Switching our own internal
representation towards this model will allow for much cleaner
abstractions around layout and the various formatting contexts.
Note that we don't *parse* two-part "display" yet, this is only about
changing the internal representation of the property.
Spec: https://drafts.csswg.org/css-display
Instead of doing layout synchronously whenever something changes,
we now use a basic event loop timer to defer and coalesce relayouts.
If you did something that requires a relayout of the page, make sure
to call Document::set_needs_layout() and it will get coalesced with all
the other layout updates.
There's lots of room for improvement here, but this already makes many
web pages significantly snappier. :^)
Also, note that this exposes a number of layout bugs where we have been
relying on multiple relayouts to calculate the correct dimensions for
things. Now that we only do a single layout in many cases, these kind of
problems are much more noticeable. That should also make them easier to
figure out and fix. :^)
This method provides the needed information to evaluate media queries.
Every feature in Media Queries Level 4 is present, either as code or as
a FIXME: https://www.w3.org/TR/mediaqueries-4/#media-descriptor-table
There's a draft Level 5 which I have ignored for now.
Some are unimplemented for now since we do not have access to the
requested information. Some require StyleValue types that we do not yet
support. Many are hard-coded for now since we do not (and may never)
support monochrome or text-only displays for Browser.
We now invoke DOM timer callbacks via HTML tasks. This brings callback
sequencing closer to the spec, although there are still many
imperfections in this area.
This introduces 3 classes: NodeList, StaticNodeList and LiveNodeList.
NodeList is the base of the static and live versions. Static is a
snapshot whereas live acts on the underlying data and thus inhibits
the same issues we have currently with HTMLCollection.
They were split into separate classes to not have them weirdly
mis-mashed together.
The create functions for static and live both return a NNRP to the base
class. This is to prevent having to do awkward casting at creation
and/or return, as the bindings expect to see the base NodeList only.
Since we don't support IDL typedefs or unions yet, the responsibility
of verifying the type of the argument is temporarily moved from the
generated Wrapper to the implementation.
This is used surprisingly often. For example, it is used by a core
YouTube library called Structured Page Fragments.
It allows you to manually dispatch an event with arbitrary data
attached to it.
The only thing missing from this implementation is the constructor.
This is because WrapperGenerator is currently missing dictionary
capabilities.
We now fire "pageshow" events at the appropriate time during document
loading (done by the parser.)
Note that there are no corresponding "pagehide" events yet.
This will be used to determine whether "pageshow" and "pagehide" events
are appropriate. We won't actually make use of it until we implement
more of history traversal and document unloading.
The only difference from what we were already doing is that setting the
same ready state twice no longer fires a "readystatechange" event.
I don't think that could happen in practice though.
