| Age | Commit message (Collapse) | Author |
|---|
|
Not used for anything currently other than exposing it on the Window
object. This allows Web Components Polyfills to patch its prototype.
|
|
This is not used yet, but will be needed for painting shadows on
elements that have a border-radius.
|
|
|
|
|
|
Also moves WebContentClient and the references to the generated IPC
descriptions, since they are all components of OutOfProcessWebView.
This patch has no functional changes.
|
|
|
|
|
|
|
|
|
|
|
|
Most of the pieces were already there, I'd just forgotten to actually
wire them up.
|
|
|
|
This name is what's used in the spec, and is a little less confusing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The goal here is to move the parser-internal classes into this namespace
so they can have more convenient names without causing collisions. The
Parser itself won't collide, and would be more convenient to just
remain `CSS::Parser`, but having a namespace and a class with the same
name makes C++ unhappy.
|
|
|
|
* Similarly to clipPath, this doesn't need to get rendered, so return no
LayoutNode.
|
|
This element doesn't actually support anything at the moment, but it
still massively speeds up painting performance on Wikipedia! :^)
How? Because we no longer paint SVG <path> elements found inside
<clipPath> elements. SVGClipPathElement::create_layout_node() returns
nullptr which stops the layout tree builder from recursing further into
the subtree, and so the <path> element never gets a layout or paint box.
Mousing over Wikipedia now barely break 50% CPU usage on my machine :^)
|
|
This corresponds to `<urange>` in CSS grammar.
|
|
Let's simplify our offering by only having the OutOfProcessWebView.
|
|
|
|
|
|
|
|
For now, this is the bare minimum that's needed: font-family and src.
|
|
The `text-shadow` property is almost identical to `box-shadow`:
> Values are interpreted as for box-shadow [CSS-BACKGROUNDS-3].
> (But note that the inset keyword are not allowed.)
So, let's use the same data structures and parsing code for both. :^)
|
|
We have the same "number and is-integer flag" structure in several
places, so let's put that in a class.
|
|
|
|
There are a few unimplemented features for this type:
1. The value setter should throw a DOMException if it is invoked on an
SVGLength that was declared readonly in another IDL file.
2. SVG::AttributeParser does not parse unit types when it parses lengths
so all SVGLength will have an "unknown" unit for now.
3. Due to (2), methods which convert between units are unimplemented.
|
|
|
|
This is a subtype of `DOM::HTMLCollection` that only holds
`HTMLOptionElement`s. In this stub implementation only `item`,
`namedItem` and `length`, inherited from HTMLCollection, are exposed.
This is good enough for applications that only read the collection.
|
|
|
|
|
|
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
|
|
To prepare for paintable inline content, we take the basic painting
functionality and hoist it into a base class.
|
|
Calling this "Box" made it very confusing to look at code that used both
Layout::Box and Painting::Box. Let's try calling it Paintable instead.
|
|
BlockContainer paint boxes are the only ones that have line boxes
associated, so let's not waste memory on line boxes in all the other
types of boxes.
This also adds Layout::Box::paint_box() and the more tightly typed
Layout::BlockContainer::paint_box() to get at the paint box from the
corresponding layout box.
|
|
|
|
The "paintable" state in Layout::Box was actually not safe to access
until after layout had been performed.
As a first step towards making this harder to mess up accidentally,
this patch moves painting information from Layout::Box to a new class:
Painting::Box. Every layout can have a corresponding paint box, and
it holds the final used metrics determined by layout.
The paint box is created and populated by FormattingState::commit().
I've also added DOM::Node::paint_box() as a convenient way to access
the paint box (if available) of a given DOM node.
Going forward, I believe this will allow us to better separate data
that belongs to layout vs painting, and also open up opportunities
for naturally invalidating caches in the paint box (since it's
reconstituted by every layout.)
|
|
When rules are inserted or removed via the CSSOM API, we now invalidate
document style to ensure that any changes made are reflected.
1% progression on ACID3. :^)
|
|
This patch adds TreeWalker (created via Document.createTreeWalker())
which allows you to traverse a filtered view of the DOM in all
directions.
|
|
This patch adds NodeIterator (created via Document.createNodeIterator())
which allows you to iterate through all the nodes in a subtree while
filtering with a provided NodeFilter callback along the way.
This first cut implements the full API, but does not yet handle nodes
being removed from the document while referenced by the iterator. That
will be done in a subsequent patch.
|
|
A couple steps requiring working relationships between browsing contexts
are currently FIXME'd - see #12917.
|
|
Timers are part of the HTML spec. :^)
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
|
|
The Window object is part of the HTML spec. :^)
https://html.spec.whatwg.org/multipage/window-object.html
|
|
For the time being, the answer is no, or rather: "" :^)
|
