- Don't add multiple numbers to nested steps, just the innermost one
(as rendered in the HTML document)
- "Otherwise" comments go before the else, not after it
- "FIXME:" goes before step number, not between it and the comment text
- Always add a period between number and comment text
The majority of these were introduced in #13756, but some unrelated ones
have been updated as well.
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.
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 :^)
There were two main issues with these functions:
1. They were not updating layout before inspecting metrics.
2. They were not returning viewport metrics for the root and body
elements when appropriate.
Block the replacement of the favicon by the default favicon loader
when a favicon that is loaded through a link tag is already active.
This way, the favicon in the link tags will be prioritized against
the default favicons from `/favicon.ico` or the seranity default icon.
When a favicon has been loaded, trigger a favicon update on
document level. Of all the link tags in the header, the last
favicon that is load should be shown.
When the favicon could not be loaded, load the next icon in reverse tree
order.
If the font resource finishes loading we need to make sure the element
using it gets a chance to re-layout, even if the font-family property
didn't change.
This is now the source of truth for 'user enabled/disabled scripting',
but it has to ask the window's page, which actually stores the setting.
Also use this new functionality in two places where it was previously
marked as a FIXME.
There's no need to have a custom is_scripting_enabled() for the
Document class, as it (indirectly) inherits from Node.
Also, let's not hardcode false here :^)
When parsing the "style" attribute on elements, we'd previously ask the
CSS parser for a PropertyOwningCSSStyleDeclaration. Then we'd create a
new ElementCSSInlineStyleDeclaration and transfer the properties from
the first object to the second object.
This patch teaches the parser to make ElementCSSInlineStyleDeclaration
objects directly.
HTMLObjectElement will need to be both a FormAssociatedElement and a
BrowsingContextContainer. Currently, both of these classes inherit from
HTMLElement. This can work in C++, but is generally frowned upon, and
doesn't play particularly well with the rest of LibWeb.
Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement
from FormAssociatedElement's hierarchy. This means that objects such as
HTMLObjectElement individually inherit from FormAssociatedElement and
HTMLElement now.
Some caveats are:
* FormAssociatedElement still needs to know when the HTMLElement is
inserted into and removed from the DOM. This hook is automatically
injected via a macro now, while still allowing classes like
HTMLInputElement to also know when the element is inserted.
* Casting from a DOM::Element to a FormAssociatedElement is now a
sideways cast, rather than directly following an inheritance chain.
This means static_cast cannot be used here; but we can safely use
dynamic_cast since the only 2 instances of this already use RTTI to
verify the cast.
If invoking a NodeFilter ends up deleting a node from the DOM, it's not
enough to only adjust the NodeIterator reference nodes in the
pre-removing steps. We must also adjust the current traversal pointer.
This is not in the spec, but it's how other engines behave, so let's do
the same.
I've encapsulated the Node + before-or-after-flag in a struct called
NodePointer so that we can use the same pre-removing steps for both the
traversal pointer and for the NodeIterator's reference node.
Note that when invoking the NodeFilter, we have to remember the node we
passed to the filter function, so that we can return it if accepted by
the filter.
This gets us another point on Acid3. :^)
This will help reduce the quite repetitive pattern of:
auto result_or_error = dom_node->do_something();
if (result_or_error.is_exception())
return result_or_error.exception();
auto result = result_or_error.release_value();
Similar to LibJS completions, this adds an alias to the error accessors.
This also removes the requirement on release_value() for ValueType to
not be Empty, which we also had to do for TRY compatibility in LibJS.
