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 :^)
Percentage stroke widths are resolved against the scaled viewport size
which we were retrieving by calling client_width() and client_height()
on the element. Now that those accessors may trigger layout, this means
that we can't use them from the stroke_width() getter, which is itself
used *from within* layout.
This might not be entirely correct, but neither was using the completely
ad-hoc parse_html_length(), and this is the last user of that API so
let's move off of it.
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.
We were calculating the reflected control points in the svg smooth
curve instructions incorrectly, and this issue was masked by the fact
that we were treating it as a relative coordinate in relative mode.
This makes the selected-in-the-inspector outline appear in the right
place. We take the stroke-width into account when producing the
bounding box, which makes the fit nice and snug. :^)
This is all still quite ad-hoc. Eventually these will both need to
support units (like with CSS Lengths) but for now we can continue only
using numbers.
I've chosen the name `AttributeParser` since it parses data from
attributes. Rather than duplicate the parsing of numbers and other
basic types, let's make use of this existing parsing code for parsing
the data for `<line>`, `<polyline>`, etc.
From the spec:
> Interface SVGGeometryElement represents SVG elements whose rendering
> is defined by geometry with an equivalent path, and which can be
> filled and stroked. This includes paths and the basic shapes.
- https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement
Making them all create an SVGPathBox, and return a Path from get_path(),
means we can implement the "basic shapes" using the path system we
already have. :^)
Instead of making each Layout::Node compute style for itself, we now
compute it in TreeBuilder before even calling create_layout_node().
For non-element DOM nodes, we create the style and layout tree node
in TreeBuilder. This allows us to move create_layout_node() from
DOM::Node to DOM::Element.
Most of the time, we cannot resolve a `calc()` expression until we go to
use it. Since any `<length-percentage>` can legally be a `calc
()`, let's store it in `LengthPercentage` rather than make every single
user care about this distinction.
Rather than having separate systems for the attributes and their CSS
equivalents, we can treat the attributes as presentational hints and
convert them to CSS properties. This means they can be inherited, as
they should. :^)
As noted, the `fill` and `stroke` attributes do not fully match the
`fill` and `stroke` properties. The CSS spec is still an early draft and
not entirely helpful, so we can just pretend they are the same for now.
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
If the first element of an SVG path spec uses relative coordinates,
we'll now treat them as absolute. This is achieved by defaulting to
(0,0) as the initial "last point" in the path.
Resolved style is a spec concept that refers to the weird mix of
computed style and used style reflected by getComputedStyle().
The purpose of this class is to produce the *computed* style for a given
element, so let's call it StyleComputer.
In the spec, `fill` and `stroke` are supposed to be a shorthands for
various properties. But since the spec is still a working draft, and
neither Firefox or Chrome support the `fill-color` or `stroke-color`
properties, we'll stick with `fill` and `stroke` as simple colors for
now.
Also, note that SVG expects things in "user units", and we are assuming
that 1px = 1 user unit for now.
