| Age | Commit message (Collapse) | Author |
|---|
|
These two were called by Discord while loading:
- float getTotalLength();
- DOMPoint getPointAtLength(float distance);
|
|
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
|
|
|
|
Instead of using Optional<LengthPercentage>, we now use LengthPercentage
for these values. The initial values are all `auto`.
This avoids having to check `has_value()` in a ton of places.
|
|
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 :^)
|
|
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.
|
|
|
|
|
|
Regressed in 7df62c64b7116842e43f2c8fcd1a7b0e71f456b7.
Thanks to Dex for spotting this! :^)
|
|
These are part of HTML, not CSS, so let's not confuse things.
|
|
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 replaces the unused width() and height() methods. The size now
defaults to 100% by 100% as in the spec.
|
|
|
|
Otherwise, modifying the `d` attribute would not cause any visual
changes to the path.
|
|
This is mostly a style thing, but it matches the other APIs.
|
|
This saves copying the string data, since the AttributeParser is always
temporary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
This fits better since it's now used by all SVGGeometryElements.
|
|
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. :^)
|
|
These were being parsed, but skipped when rendering. With this fix, the
SVG on discord's invite screen looks pretty nice! :^)
|
|
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.
|
|
This is a guinea pig. So far so good?
|
|
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.
|
|
|
