- CompoundSelector -> *deleted*
- ComplexSelector -> CompoundSelector
- Relation -> Combinator
Our Selector is really a ComplexSelector, but only the Parser and
SelectorEngine need to know that, so keeping it named Selector makes it
more understandable for users.
Our CompoundSelector is really a CompoundSelectorAndCombinator.
Combining the two makes sense in our codebase, but the accurate name is
so long that I think it makes the code less readable.
Renamed some Combinators to also match the spec terminology:
- AdjacentSibling -> NextSibling
- GeneralSibling -> SubsequentSibling
The previous names are somewhat ambiguous, so hopefully this is clearer.
This was a hack copied over from the old parser, but it was causing
problems with flex-grow, and probably other properties that accept
numbers. Removing it does not seem to break anything, so lets' remove
it! :^)
Also added css-import.html, which tests the 3 syntax variations on
`@import` statements. Note that the optional media-query parameter to
`@import` is not handled yet.
The code handling the rendering of the text-decoration-line got moved
into its own function to reduce clutter.
The CSS property text-decoration-line now supports underline, overline
and line-through.
The previous behavior of mapping a missing value to the "inherit"
state is incompatible. Now, a missing value maps to the "true" state,
which is the expected behavior.
To transparently support multi-frame images, all decoder plugins have
already been updated to return their only bitmap for frame(0).
This patch completes the remaining cleanup work by removing the
ImageDecoder::bitmap() API and having all clients call frame() instead.
Previously, ImageDecoder::create() would return a NonnullRefPtr and
could not "fail", although the returned decoder may be "invalid" which
you then had to check anyway.
The new interface looks like this:
static RefPtr<Gfx::ImageDecoder> try_create(ReadonlyBytes);
This simplifies ImageDecoder since it no longer has to worry about its
validity. Client code gets slightly clearer as well.
We treat all NativeFunctions as strict mode and thus window function
which were called in a global context (i.e. `setTimeout(f, 0)`) got a
null this_value. But we really need to treat all functions not defined
by the ECMAScript specification as non-strict. In most cases this won't
matter however since Window is also the global_object we have an extra
bit of logic.
To fix this more correctly we would need to track the strictness of
NativeFunctions.
Otherwise it will try to convert it to a string later anyway. And as far
as I'm aware there are no style properties with just a number or
JavaScript symbol as name.
We immediately use this in CSSStyleDeclaration to fix that "background"
in element.style did not return true.
This is the mechanism used in css3test.com for detecting support of
features.
Making a bitmap non-volatile after being volatile may fail to allocate
physical pages after the kernel stole the old pages in a purge.
This is different from the pages being purged, but reallocated. In that
case, they are simply replaced with zero-fill-on-demand pages as if
they were freshly allocated.
This patch adds the box-shadow rendering to Boxes. We do parse the
blur-radius of a box-shadow but we don't use it for now as the Filter
in the system don't seem quite powerful enough yet to handle that.
This adds support for box-shadows to the DeprecatedCSSParser. When it
encounters a box-shadow property, the following syntaxes can get parsed:
- box-shadow: <offset_x> <offset_y> <color>
- box-shadow: <offset_x> <offset_y> <blur_radius> <color>
There is other possible data following the property, but those aren't
supported for now.
This patch spreads box-shadows around:
- The Values important to box-shadows are stored in a BoxShadowData
struct
- StyleProperties knows how to construct such a struct from a
BoxShadowStyleValue and a Node knows how to ask for it
- CalculatedValues contain BoxShadowData and expose them
This patch finally adds the actual calculation that goes into calc()
expressions. When the resolution of a Length that is a calculated value
the parsed CalculatedStyleValue gets traversed and appropriate values
get calculated.
This is a bit hackish, but this way the existance of the calc()
becomes transparent to the user who just wants a Length and doesn't
care where it came from.
This patch adds the parsing of previously tokenized calc() expressions
into the CSS-Parser. The tokens are processed into a complete
CalculatedStyleValue.
SignedBigInteger::export() generates sign-magnitude, but the native i64
type uses 2's comp, make this work by exporting it as unsigned and
tweaking the sign later.
This detects and resolves these in the text-decoration property, in any
order:
- text-decoration-color
- text-decoration-line
- text-decoration-style
Only the solid underline renders, but all three sub-properties are
assigned correctly.
The font property now resolves into its various parts:
- font-family
- font-weight
- font-size
- font-style
- line-height
The font-variant and font-stretch parts are left unparsed since LibWeb
doesn't know how to render those.
Added `fonts.html` as a test for various forms of `font` declarations,
based on the examples in the spec.
This resolves the three sub-properties, appearing in any order:
- list-style-image
- list-style-position
- list-style-type
Added `list-style-position` values to support this, though they are not
yet used in rendering.
This was broken when we switched away from using StringStyleValues.
While I was at it, I have implemented hsl/a() and the percentage
syntax for rgb/a().
As a bonus, added `colors.html` as a test page for the various CSS
color syntaxes, since nothing was testing rgb() or rgba() before.
Much of the parsing code in LibGFX/Color.h seems to be centered
around CSS color values, but this is not used by the new Parser.
(And can't be used, because it requires a String value and we have
a list of Tokens of some kind instead.) Maybe that should be removed
from there when the new CSS parser is operational.
This implements a lot of cases, but not all of them. The following
need more infrastructure first:
- Flex
- FlexFlow
- Background
- BackgroundImage
- BackgroundRepeat
- ListStyle and parts
- Font
Also, colors are not parsed correctly. This will be handled next.
Now that StyleResolver is going to deal with StyleComponentValueRules,
it will need to be able to parse those into StyleValues, using
`parse_css_value()`.
Also added StyleValue::is_builtin_or_dynamic(), which returns true for
values that are valid anywhere - things like `initial` and `inherit`,
along with `var()`, `attr()` and `calc()` - which we want to test for
easily.
