For XHTML documents, resolve named character entities (e.g., )
using the HTML entity table via a getEntity SAX callback. This avoids
parsing a large embedded DTD on every document and matches the approach
used by Blink and WebKit.
This also removes the now-unused DTD infrastructure:
- Remove resolve_external_resource callback from Parser::Options
- Remove resolve_xml_resource() function and its ~60KB embedded DTD
- Remove all call sites passing the unused callback
:heading() now matches based on a computed heading level, which is based
on the level of the tag (h1, h2, etc) and then modified by these two new
attributes.
I'm caching this heading level on HTMLHeadingElement, based on the dom
tree version. That's more invalidation than is actually needed, but it
saves us calculating it over and over when the document hasn't changed.
The failing test cases are:
- Implicit headingreset for modal dialogs which is apparently unspecced
and controversial.
- Not walking the flat tree properly. A flat tree ancestor of a
slot-assigned element is its slot, which is something we don't do
anywhere that I could find. I've made a note to look into this later.
We also don't implement the `ReflectRange` IDL attribute yet, which
means we're not clamping the read value of `headingOffset`.
Corresponds to:
e774e8e318
Per the CSS Namespaces spec, an empty string declared in an
@namespace rule represents no namespace.
Fixes WPT:
- css/css-namespaces/prefix-002.xml
- css/css-namespaces/prefix-003.xml
The CSS spec says the baseline of an inline-block should be the bottom
margin when either the overflow property is not 'visible' or there are
no in-flow line boxes. Previously, only the latter case was checked.
This fixes 1 WPT test:
https://wpt.live/css/css-align/baseline-of-scrollable-1a.html
This fixes an issue where text decorations (e.g. underlines) of text
split across multiple fragments would have unintended 1px gaps.
Gains us 2 WPT passes (imported)
Implements `::slotted()` to enough extent we could pass the imported WPT
test and make substantial layout correctness improvement on
https://www.rottentomatoes.com/
If `will-change` is set to a property value where that property could
create a stacking context, then we create a stacking context regardless
of the current value of that property.
We don't yet have a system for "legacy value aliases", but until we have
a lot of them we can handle them manually.
We also have to do this in two places because
parse_css_value_for_property() doesn't call any property-specific
parsing code.
