| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is a bit easier on the eye than black.
|
|
Now it actually looks like a classic focus outline and not some
misplaced border :^)
|
|
Instead of using the absolute_rect(), use absolute_border_box_rect() -
at least for PaintableBox - and inflate it by 2px on each side.
This looks much nicer for text input elements, especially when they have
padding, which would be applied outside the focus rect previously.
|
|
It seems like this happens in quite some valid situations, so my
initially sensible failsafe doesn't make sense. As the buffer system is
hopefully gone soon, it won't be an issue in the future either way.
|
|
This was regressed at some point though I never saw it working.
Basically, while jump to slider works correctly it doesn't even get
actioned. While the user is clicking the slider it's very likely that a
buffer finishes playing and the callback for that changes the slider
value. This means that the user click just gets lost. There's some
additional weird behavior where values are lost in even more cases, so
an additional fix that is needed is to store the slider value in the
AutoSlider while we're dragging and apply it on mouse up.
|
|
BFC roots with children_are_inline()==true can still have floating boxes
as well. children_are_inline() is only concerned with in-flow children.
For this reason, we have to always consider floats when calculating
height:auto for BFC roots.
|
|
Sometimes it's really helpful to know if a box considers its children to
be inline or not.
|
|
The SHA384 and SHA512 hashes would produce incorrect results for data
where the length % 128 was in the range 112-119. This was because the
total number of bits in the hashed values was added at the end as a
64-bit number instead of a 128-bit number. In most cases this would not
cause any issues, as this space was padded with zeroes, however in the
case that the length % 128 was 112-119, some incorrect data ended up
where this 128-bit length value was expected.
This change fixes the problems in LibTLS where some websites would
result in a DecryptError on handshake.
|
|
Rather than dividing the rect width and high by the border lengths,
this change multiples those lengths by the reciprocal of the width
and height because this is a faster operation. When mousing around on
the html spec website, the profile showed that inline painting
went from ~15% to ~3%
|
|
This fixes the placement of several background images on Acid2, most
notably the background of the eyes and the red rectangle near the bottom
of the head.
|
|
This is an editorial change in the Temporal spec.
See: https://github.com/tc39/proposal-temporal/commit/c5b645d
This means we now have to pass a global object and construct a BigInt
object just for the assertion, but oh well. We might want to have an
assertion macro that's optimized away in release builds at a later
point, however.
|
|
This is an editorial change in the Temporal spec from a long time ago.
See: https://github.com/tc39/proposal-temporal/commit/e480d40
|
|
|
|
I regressed this at some point by inverting the condition here.
|
|
We were showing the margin-top value for all 4 margin values.
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
|
|
Collect all the preceding block-level siblings whose vertical margins
are collapsible. Both margin-top and margin-bottom now (previously,
we only considered the margin-bottom of siblings.)
Use the right margin in part-negative and all-negative situations.
|
|
|
|
|
|
We now distribute the line-height evenly between the space above and
below inline-level boxes. This noticeably improves our baseline
alignment in many cases.
Note that the "vertical-align: <length>" case is quite awkward, as the
extra height added by the offset baseline must count towards the line
box height.
There's a lot of room for improvement here, but this makes the buckets
container on Acid3 show up in the right place, with the right size.
|
|
This prevents a crash when refreshing or navigating away from the Acid3
test page while it is actively running.
|
|
|
|
|
|
Specifically HTMLIFrameElement and HTMLObjectElement. HTMLEmbedElement
will gain it automatically once it's also converted to inherit from
BrowsingContextContainer.
|
|
|
|
Since this macro was created we gained a couple more parsers in the
system :^)
|
|
This makes the shadow line-up correctly on Acid3. :^)
|
|
|
|
We were not adjusting the fragment baseline for inline-blocks that had
some border and/or padding size up top.
|
|
Make sure we use the create_anonymous_wrapper() helper function whenever
wrapping inline content in anonymous wrapper blocks. We were forgetting
to do this in one case, which led to some wrapper blocks having 0px
font-size and line-height.
|
|
Normally, paintable coordinates are relative to the nearest containing
block, but in the SVG case, since <svg> doesn't form a containing block,
we have to specialize the computation of SVGPaintable::absolute_rect().
|
|
Absolute lengths can be resolved immediately without looking up the
viewport size, etc.
|
|
The specified style was turned into computed style long before it
arrived here (StyleComputer took care of that.)
|
|
|
|
This allows you to call line_height() on any layout node, even if it's a
text node (in which case we'll ask the parent node for its line-height.)
|
|
When I wrote the An+B parser, it was guaranteed to have no
non-whitespace tokens after it. This is no longer true with the `of
foo` syntax, so this patch corrects the logic when there is no `+B`
segment.
This makes this case shown on Twitter work correctly. :^)
https://twitter.com/simevidas/status/1506657566012678151
|
|
We don't yet take the spread-distance parameter into account, since we
don't have a way to "inflate" the text shadow.
Also, I'm not sure if we need to inflate the shadow slightly anyway.
Blurred shadows of our pixel fonts seem very faint. Part of this is
that a blur of < 3px does nothing, see #13231, but even so we might
want to inflate it a little.
|
|
|
|
`text-shadow` does not support this, so this way we can still use the
same parsing code.
It's OK that we still assign a ShadowPlacement value to the
ShadowStyleValue, since it will just get ignored when painting
text-shadows, but if it appears in the property value then that is a
syntax error.
|
|
The `text-shadow` property is almost identical to `box-shadow`:
> Values are interpreted as for box-shadow [CSS-BACKGROUNDS-3].
> (But note that the inset keyword are not allowed.)
So, let's use the same data structures and parsing code for both. :^)
|
|
The HTMLObjectElement spec is set up to ignore application/octet-stream
MIME types only. For this to work, we need to implement the MIME type
sniffing algorithm so that all unknown MIME types become mapped to the
application/octet-stream type. Until then, ignore all application/ MIME
types as we won't be able to display them anyways.
|
|
|
|
|
|
We should only update the object children of an object when the parent's
representation changes to/from falling back to its children.
|
|
We were using the literal string "unknown" as the unknown MIME type,
which caused us to treat the object as a nested browsing context (as
"unknown" does not start with "image/"). Use an Optional instead to
prevent this mishap.
|
|
No functional changes.
|
