Handle available space more carefully when computing a table width, in
order to avoid creating a definite infinite width when available space
width is max-content, as it's the case in calculate_max_content_width.
The constraint is thus correctly propagated by the time we cache the
computed value, which was previously rejected by the hash function due
to being definite but infinite instead of max-content.
Like the piggybacking in CSS, this is also totally ad-hoc, since there's
no spec to follow.
The code here is weird and definitely sub-optimal as we do a second load
if it turns out the loaded resource is an image, but given that object
elements are rarely used nowadays, I doubt we'll even notice.
That said, we should of course improve this code as we move forward.
This is all ad-hoc since no spec currently exists for this behavior.
Basically, ImageStyleValue now uses ImageRequest for fetching and
decoding of images.
This already leads to visible improvements on many websites.
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 specification isn't explicit about it, but the contribution we
compute should be distributed to all columns, not just the first one.
The first reason for it is symmetry, it doesn't make sense for the
increased width of the spanning column to only affect the first column
in the span.
The second reason is the formula for the cell contribution, which is
weighted by the non-spanning width of the cell relative to the total
width of the columns in the same row. This only covers a fraction of the
gap, in order to fully cover it we have to add it to all columns in the
span. For this to be exactly the case when the columns don't all have
the same width, we'd have to add additional weighting based on the width
ratios, but given that the specification doesn't suggest it at all we'll
leave it out for now.
When comparing an ipv6 address against '::1', then compare against
the value object from `IPv6Address::loopback()`, instead of parsing the
string "::1" to an IPv6Address.
Calculate a "preferred aspect ratio" based on the value of
`aspect-ratio` and the presence of a natural aspect ratio, and use that
in layout.
This is by no means complete or perfect, but we do now apply the given
aspect-ratio to things.
The spec is a bit vague, just saying to calculate sizes for
aspect-ratio'ed boxes the same as you would for replaced elements. My
naive solution here is to find everywhere we were checking for a
ReplacedBox, and then also accept a regular Box with a preferred aspect
ratio. This gets us pretty far. :^)
https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all
implemented.
Having this here instead of in ReplacedBox means we can access it when
figuring out what the "preferred aspect ratio" is.
There's some inconsistency between specs about what this is called, but
they're moving towards referring to this as "natural width/height/
aspect-ratio", so let's copy that terminology.
Anywhere that `<number>` appears in the grammar, `calc()` that resolves
to a number is valid, including inside the `<ratio>` grammar.
Thankfully, a calculation that produces a number cannot rely on any
context information for the calculation, so we can resolve them
straight away and just pretend they were a `<number>` the whole
time. :^)
`foo.is(Token::Type::Delim) && foo.token().delim() == '!'` becomes
`foo.is_delim('!')`, which is a lot less verbose. I really should have
done this ages ago.
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."
Prior to this commit, PropertyOwningCSSStyleDeclaration::serialized()
did not include custom properties, which lead to an incomplete
`cssRule.cssText` result.
This commit makes that class also serialize the custom properties and
place them before the regular properties in the rule text.
We began parsing SVG documents as HTML years ago in commit 05be648. This
was long before we had an XML parser, and actually violates the spec.
Since SVG documents have a MIME type of "image/svg+xml", the spec
mandates the document should be parsed as XML.
One impact here is that the SVG document is no longer "fixed" to include
<html>, <head>, and <body> tags. This will have prevented document.title
from detecting the document element is an SVG element.
We were incorrectly returning a "specified size suggestion" for flex
items with a definite main size where that main size was also automatic.
This led to us incorrectly choosing 0 as the automatic minimum size for
that flex item, instead of its min-content size.
The main differences between our current implementation and the spec
are:
* The title element need not be a child of the head element.
* If the title element does not exist, the default value should be
the empty string - we currently return a null string.
* We've since added AOs for several of the spec steps here, so we
do not need to implement those steps inline.
The implementations are correct as-is. The spec comments are mostly to
help point out that an upcoming getter (the title element) is currently
accessed incorrectly. It is currently implemented like the head element
and searches the "expected" parent head element for its first title
element; instead it should search the document itself. This incorrect
behavior becomes clearer if all of these elements have spec comments.
