Age | Commit message (Collapse) | Author |
|
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. :^)
|
|
The HTML event loop does a check for MQL match-state changes and
dispatches the events. This requires us to keep a list of MQLs on the
Document.
|
|
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.
|
|
This is not entirely to spec, but gets the basic job done.
|
|
|
|
|
|
|
|
This will be used by the event loop processing model.
|
|
The timestamp needs to be consistent with the "current high resolution
time" as reflected by window.performance.now
|
|
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 changes the old child_nodes implementation to children_as_vector
so that can still be used in insert_before.
|
|
|
|
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.
|
|
|
|
|
|
This allows us to include IDL files from other base LibWeb directories
wihout using relative `../foo.idl` references.
|
|
|
|
|
|
|
|
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 returns whether an element matches any of a set of selectors.
|
|
This is "in a document tree" from the DOM spec.
|
|
|
|
|
|
|
|
Some sites query these properties for whatever reason, so let's support
them. (But let's always pretend the screen coordinates are (0, 0))
|
|
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 were already tracking the active element in DOM::Document, so all we
had to do here was add the attribute to Document.idl :^)
|
|
This always returns 1 for now. I've added a FIXME about returning 2 in
HiDPI mode.
|
|
These just act as if the document is always visible for now.
|
|
This marks our entry into the Web::Geometry namespace, based on the
"Geometry" spec at https://drafts.fxtf.org/geometry/
|
|
|
|
|
|
This API allows authors to schedule a serialized JS callback that will
get invoked at the next spec-allowed opportunity.
|
|
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.
|
|
|
|
Let's log "unhandled exception" messages in red text so that they stand
out better among lots of other debug logging.
|
|
We have to mark the EventListener objects so that we can tell them apart
from listeners added via the addEventListener() API.
This makes element.onfoo getters actually return the handler function.
|
|
|
|
We will now spin in "the end" until there are no more "things delaying
the load event". Of course, nothing actually uses this yet, and there
are a lot of things that need to.
|
|
|
|
Style is needed to lay out and paint a document, but we can't do either
those when the document isn't attached to a browsing context.
|