As part of this move properties/methods to the correct subclass
(position related properties go under SVGTextPositioningElement).
SVG text element hierarchy:
SVGTextContentElement
^- SVGTextPositioningElement
^- SVGTextElement
^- SVGTSpanElement
^- SVGTextPathElement (TODO)
^- SVGTRefElement (TODO)
This prevents SVG elements referenced by "use" being repeatedly cloned
in many redundant cases. Pages that use a large svg "sprite" that then
is referenced many times with "use" elements would load extremely
slowly, or crash the page.
The `document_fully_loaded` event should use the adjective "completely"
so as to match the spec and code convention. See
`Document::is_completely_loaded` and `m_completely_loaded_time`.
The SVGContext is a leftover from when SVG properties were more ad-hoc.
All properties are now (for better or worse) treated as CSS properties
(or handled elsewhere). This makes the SVGContext's fill/stroke
inheritance handling unnecessary.
Return error when input svg is not valid and SVGSVGElement is not
present in the tree instead of doing svg_root nullptr dereference.
Fixes crash on https://apps.kde.org/en-gb/
The fix here has two parts:
1. Don't use the fallback viewBox at all if we're not in SVG-as-image.
2. Don't make a fallback viewBox with zero width and/or height.
This fixes a crash on Bandcamp pages. Thanks Tim Flynn for reporting!
When embedding an SVG in an img element, if the external SVG's root
element has both width and height attributes, but no viewBox attribute,
we now create a fallback viewBox with "0 0 width height".
This appears to match the behavior of other browsers. Inspired by
discussion on Mozilla's bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=614649
The translation to the bounding box location is handled by the gradient
transform, also doing it here breaks things.
This fixes the MDN <radialGradient> example.
Although DistinctNumeric, which is supposed to abstract the underlying
type, was used to represent CSSPixels, we have a whole bunch of places
in the layout code that assume CSSPixels::value() returns a
floating-point type. This assumption makes it difficult to replace the
underlying type in CSSPixels with a non-floating type.
To make it easier to transition CSSPixels to fixed-point math, one step
we can take is to prevent access to the underlying type using value()
and instead use explicit conversions with the to_float(), to_double(),
and to_int() methods.
This forces us to diverge from the spec, but it's for a good cause:
by moving it into ImageRequest, we'll be able to reuse fetching and
decoding logic from CSS and other places.
This patch also makes ImageRequests shareable, currently keyed by
the URL (this part needs improvement!)
Previously, we did an evenodd fill for everything which while for most
SVGs works, it is not correct default (it should be nonzero), and broke
some SVGs. This fixes a few of the icons on https://shopify.com/.
The implementation of painting for SVG text follows the same pattern
as the implementation of painting for SVG geometries. However, instead
of reusing the existing PaintableWithLines to draw text, a new class
called SVGTextPaintable is introduced. because everything that is
painted inside an SVG is expected to inherit from SVGGraphicsPaintable.
Therefore reusing the text painting from regular text nodes would
require significant refactoring.
The `<style>` element is allowed to be in the SVG namespace, so we now
support this element.
It has the same behaviour as the HTML namespace `<style>` element as
described in the spec.
"The semantics and processing of a ‘style’ and its attributes must be
the same as is defined for the HTML ‘style’ element."
The spec for the `<use>` element requires a shadow tree for the
rendered content, so we need to be able to escape shadow trees when
rendering svg content.
Previously, this would blindly use parse_number() without checking if
there was a number to parse. This meant we would crash on transforms
like:
rotate(BAD 32 0)
Now the attribute just gracefully fails to parse.
This was crashing on google.com with the linux chrome user agent,
interestingly it seems like this behavior may have been accidental as
only two of the three `parse_number()` were changed in f7dbcb6
This fixes a plethora of rounding problems on many websites.
In the future, we may want to replace this with fixed-point arithmetic
(bug #18566) for performance (and consistency with other engines),
but in the meantime this makes the web look a bit better. :^)
There's a lot more things that could be converted to doubles, which
would reduce the amount of casting necessary in this patch.
We can do that incrementally, however.
This finally makes SVG-as-image show up visually! :^)
We should find a way to share this logic with Layout::SVGSVGBox, but
that will require some finesse since they have to work at different
points in the layout/paint timeline.
In order to separate the SVG content from the rest of the engine, it
gets its very own Page, PageClient, top-level browsing context, etc.
Unfortunately, we do have to get the palette and CSS/device pixel ratios
from the host Page for now, maybe that's something we could refactor in
the future.
Note that this doesn't work visually yet, since we don't calculate the
intrinsic sizes & ratio for SVG images. That comes next. :^)
This allows the painting subsystem to request a bitmap with the exact
size needed for painting, instead of being limited to "just give me a
bitmap" (which was perfectly enough for raster images, but not for
vector graphics).
This implements the stop-opacity, fill-opacity, and stroke-opacity
properties (in CSS). This replaces the existing more ad-hoc
fill-opacity attribute handling.
This follows on from the SVG linear gradients. It supports the same
features (xlink:href, gradientUnits, gradientTransform).
With this commit I have now implemented all web gradients :^)
(Though we are still missing a few parameters for SVG gradients,
e.g. spreadMethod).
