| Age | Commit message (Collapse) | Author |
|---|
|
|
|
If a box has a negative margin-left, it may have a negative effective
offset within its parent BFC root coordinate system.
We can account for this when calculating the amount of left-side float
intrusion by flooring the X offset at 0.
|
|
Wrap the parsing of numbers, integers, and dimensions in a transaction,
which we only commit if that parsed value was actually accepted by the
property.
This fixes `font: 0/0 a;` failing to parse.
|
|
...instead of looping forever. Oops! :^)
|
|
To abort the processing of any nested invocations of the tokenizer,
just return is enough in this case.
During the process of pending parsing blocking script, the
is_ready_to_be_parser_executed() check should be applied on the
blocking script, not the original script.
|
|
... instead of crashing :^)
|
|
|
|
|
|
The SVG <use> element is used to be able to reuse other SVG graphics
without having to re-write the svg element.
We now support this feature! :^)
|
|
SVGUseElement needs to be able to query the fully loaded document for
its referenced 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.
|
|
|
|
|
|
This makes sure we actually render an equilateral triangle
inside a square.
|
|
This moves the ::marker inside of <summary> actually inside. :^)
|
|
This makes it possible to set a pseudo-element as the inspected node
using Document::set_inspected_node(), Document then provides
inspected_layout_node() for the painting related functions.
|
|
These markers are rendered as equilateral triangles pointing right and
down respectively. As we currently don't implement writing-mode the
closed marker does not respect it.
|
|
|
|
...except those related to `grid`, because I can't figure out how the 17
different properties interact with each other, and what values apply to
which ones. 😅
All but 1 of these are the infinite range `[-∞,∞]`. As such, specifying
that range does not change anything, but it does make it explicit that
we've looked at what the range should be, instead of just not having
added it.
|
|
Now that we have a way to resolve calc() lengths without a layout node,
we can finally support calc() values in font-size.
This wasn't possible before because font-related properties have to be
resolved eagerly in StyleComputer due to font-relative CSS length units
depending on the computed font being known.
|
|
Instead of a layout node, you can pass a new Length::ResolutionContext
struct which contains everything needed to resolve calc() lengths.
|
|
Use contains_percentage() that works for calc() values instead of
is_percentage().
This fixes issue when tracks with calc() that has percentages where
considered as "fixed" tracks with resolvable size which led to
incorrectly resolved infinite final track sizes.
|
|
This reintroduces bounds-checking for the CSS `<angle>`, `<frequency>`,
`<integer>`, `<length>`, `<number>`, `<percentage>`, `<resolution>`,
and `<time>` types.
I regressed this around 6b8f4841145a53553c0007a6ff4feefec98a426a when
changing how we parsed StyleValues.
This is an improvement from before though, since we now allow the bounds
of a dimension type to have units.
Added a test to make sure we don't regress this again. :^)
|
|
This is to make it easier to bounds-check their values during parsing.
Length is left out because many length units are relative to the
context in which they are used, and so we cannot easily compare `10px`
and `1em`, for example.
|
|
If a flex item's main size is a CSS calc() value that resolves to a
length and contains a percentage, we can only resolve it when we have
the corresponding reference size for the containing block.
|
|
Stacking contexts are sorted after building a tree of them. They are
sorted by z-index first, DOM tree order second.
Sorting was previously *very* slow on pages with many stacking contexts.
That was because the sort() function used Node::is_before() in the
quick_sort comparator to see if one StackingContext was before another.
is_before() does tree traversal and can take quite a long time per call.
This patch avoids all that by letting StackingContext know its index
among all StackingContexts within the same document in tree order.
There's a noticeable snappiness increase on the CSS-FLEXBOX-1 spec page,
for instance. :^)
|
|
|
|
|
|
|
|
|
|
Somewhere the path bounding box in the layout and the actual draw path
are getting slightly mismatched. This results in partly clipped bits of
SVGs. The paths are already clipped to the containing SVG, and the size
of the path in the layout is computed from the bounding box, so it is
probably safe just to remove this clipping for now.
|
|
Previously, we would always respect the `text-align` property, even if
the text being aligned was too long for its line box and would be
clipped. This led to seeing the clipped middle/end of strings when we
should instead always see the beginning of the text.
|
|
We have double precision in the parser, and currently use doubles for
most of layout, so we might as well keep that extra precision inside
NumberStyleValue too.
|
|
Use IntegerStyleValue where we should; remove the ability of
NumberStyleValue to hold integers, and add integer interpolation for
animations.
|
|
Having one StyleValue for `<number>` and `<integer>` is making user code
more complicated than it needs to be. We know based on the property
being parsed, whether it wants a `<number>` or an `<integer>`, so we
can use separate StyleValue types for these.
|
|
This is in preparation of splitting off a separate IntegerStyleValue.
|
|
This is a hack to emulate the behavior of other engines that use
fixed-point math. By rounding to 3 decimals, we retain a fair amount of
detail, while still allowing overshooting 100% without breaking lines.
This is both gross and slow, but it fixes real sites. Notably, the
popular Bootstrap library uses overshooting percentages in their
12-column grid system.
This hack can be removed when CSSPixels is made a fixed-point type.
|
|
If the flex container is being sized under a max-content main size
constraint, there is effectively infinite space available for flex
items. Thus, flex lines should be allowed to be infinitely long.
This is a little awkward, because the spec doesn't mention specifics
about how to resolve flexible lengths during intrninsic sizing.
I've marked the spec deviations with big "AD-HOC" comments.
|
|
|
|
|
|
|
|
Instead of just measuring the layout viewport, we now measure overflow
in every box that is a scroll container.
This has the side effect of no longer creating paintables for layout
boxes that didn't participate in layout. (For example, empty/anonymous
boxes that were ignored by flex itemization.)
Such boxes are now marked as "(not painted)" in the layout tree dumps,
as they have no paintable to dump geometry from.
|
|
We were only clipping for hidden, when we should be clipping for hidden,
clip, scroll and auto. Basically everything but visible. :^)
|
|
This will allow us to have a shared code path for overflow calculation.
|
|
|
|
This is used on GitHub and many other websites.
|
|
|
|
|
|
We already clamp these values to zero, so it's actually pretty harmless
when this happens. If someone wants to investigate these issues deeper
and see if they can be fixed earlier in the layout pipeline, they can
enable the spam locally.
|
|
The textContent setter changes the structure of the DOM, therefore the
layout tree becomes invalid.
|
