Resolved style is a spec concept that refers to the weird mix of
computed style and used style reflected by getComputedStyle().
The purpose of this class is to produce the *computed* style for a given
element, so let's call it StyleComputer.
Once we've performed the cascade on a set of values for an element,
we should have enough information to resolve/absolutize some lengths.
Basically, any CSS length that isn't "auto" or a percentage can be
turned into an absolute length (in pixels) as long as we have the
following information:
- The viewport rect
- The parent element's font
- The document element's font
- The element's own font
To ensure that we can absolutize lengths relative to the element's own
font, we now do a separate first pass where font-related properties are
defaulted (in the cascade spec sense of the word) and become usable.
There's a lot more work to do here, but this should open up a lot of
simplification in layout code, since it will no longer need to care
about relative lengths. Layout still needs to resolve percentages, since
we can't do that for some properties until the containing block
dimensions are known.
In StyleResolver, we were rejecting single values for properties that
take 1-4: `border-color`, `border-style`, and `border-width`. Now, we
handle them correctly. I also added support for `calc()` and `var()` to
`padding` and `margin`.
This fixes the orange border on Acid2, which now correctly appears
black. :^)
We already expand shorthands in the cascade, so there's no need to
preserve them in the output.
This patch reorganizes the CSS::PropertyID enum values so that we can
easily iterate over all shorthand or longhand properties.
The 'C' in "CSS" is for Cascade, so let's actually implement the cascade
in LibWeb. :^)
StyleResolver::resolve_style() now begins by collecting all the matching
CSS rules for the given DOM::Element. Rules are then processed in the
spec's cascade order (instead of in the order we encounter them.)
With this, "!important" is now honored on CSS properties.
After performing the cascade, we do another pass of what the spec calls
"defaulting" where we resolve "inherit" and "initial" values.
I've left a FIXME about supporting correct "initial" values for every
property, since we're currently lacking some coverage there.
Note that this mechanism now resolves every known CSS property. This is
*not* space-efficient and we'll eventually need to come up with some
strategies to reduce memory usage around this. However, this will do
fine until we have more of the engine working correctly. :^)
This doesn't capture the whole picture as shorthands are not considered
in a careful way.
A very dirty hack is included to not try to resolve 'font' as the amount
of debug spam it generated ("No inital value found for...") was
unhelpful.
This patch moves the CSS property+value storage down to a new subclass
of CSSStyleDeclaration called PropertyOwningCSSStyleDeclaration.
The JavaScript wrapper for CSSStyleDeclaration now calls virtual
functions on the C++ object.
This is preparation for supporting computed style CSSStyleDeclaration
objects which won't have internal property storage, but rather an
internal element pointer. :^)
If the font-family property is set to a StyleValueList, we now iterate
through it, looking up each font in turn until one is found.
StyleResolver no longer needs to handle FontFamily specifically, which
is a nice bonus.
Serenity's current dependence on bitmap fonts leads to some weirdness
here - for example, the `if (!found_font)` path can trigger even if a
generic font family like "sans-serif" is used, since our default
sans-serif font might not be available in the desired size or weight.
The `monospace` variable only exists for that reason.
This is not a complete solution, by a long way! Serenity's font support
is still quite basic, so more work needs to be done there before we can
start implementing the spec's font-matching algorithm. But this is still
an improvement. :^)
We already include the inheritance for each property in Properties.json,
so made sense to use that instead of a list in StyleResolver.
Added `inherited: true` to a couple of properties to match the previous
code's behavior. One of those had a FIXME which I've moved to the JSON
file, which is hacky, but it works.
Apart from now gathering comma-separated font-family names into a
StyleValueList, this also corrects the logic for parsing a single
font-family. Previously, we did not handle unquoted font names at all,
and now they are handled including when they are several words separated
by whitespace.
Modified the logic for `font` to use `parse_font_family_value()`.
`FontStyleValue.font_families()` is now a StyleValueList instead of a
vector, so that it can be better handled in StyleResolver.
We also finally remove the CSS::ParsingContext in
set_property_expanding_shorthands(). :^)
This wraps an x and y background-repeat value. Potentially, we could use
this in place of the background-repeat-x and background-repeat-y
pseudo-properties, but for now StyleResolver splits it into those
properties, like it did before.
This parses the elliptical border-radius values, though currently we
only support circular ones. So, to_length() is overloaded to return the
horizontal-radius. This means the code in Layout/Node.cpp does not need
to change for now.
This is not just moving the code from StyleResolver to Parser. The logic
has changed to allow for the `flex-basis` to come before or after the
`flex-grow/shrink` values, as well as handle the special one-value
cases.
Also added test cases to flex.html to check the parsing. It does parse
correctly, but elements with `flex-basis: auto` do not calculate their
width correctly.
Modified text-decoration.html to better test that the values can be in
any order, and that it adopts the color from the `color` property if no
decoration color is specified. Right now, it always does because we do
not support a different decoration color. Later, we need to support the
`currentcolor` special CSS value for this purpose.
Yes, the name is silly, but it's a StyleValue for list-style, so...
yeah. :^)
Since `list-style-type` and `list-style-image` can both have `none` as a
value, and can appear in any order, we have to handle it separately, and
then assign either or both of those to `none` depending on how many
`none`s there are, and whether those sub-properties already have values.
Added some extra test cases to lists.html to cover list-style-image and
list-style-position parts of the list-style shorthand, and the `none`
values.
This one represents one secton of a `background` property, since it can
have multiple background values separated by commas. Eventually, we will
represent that as a List of BackgroundStyleValues.
Also modified some background-foo properties in StyleResolver so that
the is_background_x() functions could be removed.
I realized that our handling of var() in shorthand properties is wrong,
so have been removing the is_builtin_or_dynamic() calls from the parsing
code for shorthands. This broke our var() test page, so I have replaced
the use of 'background' with 'background-color' there.
After working with the code for a while, it makes more sense to put all
the parsing in Parser, instead of some of it living in StyleResolver.
That means our current ValueListStyleValue needs to be replaced with
specific StyleValue types for the properties that are shorthands or
otherwise combine several values together.
Here we implement FontStyleProperty, which represents a `font` CSS
property.
Also adjusted the fonts.html test page so that font-weights are featured
in test cases without things we do not yet support.
StyleValueList is a list of StyleValues of the same type, for use in
properties like `margin` which accept a variable number of arguments.
I had originally hoped to simply swap the old ValueListStyleValue from
being a list of ComponentValues to one of StyleValues, but I can see now
that I will need to have both for a little while, so renamed the old
is_value_list() to is_component_value_list() temporarily.
Change all the places that were including the deprecated parser, to
include the new one instead, and then delete the old parser code.
`ParentNode::query_selector[_all]()` now treat their input as a
comma-separated list of selectors, instead of just one, and return
elements that match any of the selectors in that list. This is according
to these specs:
- querySelector/querySelectorAll:
https://dom.spec.whatwg.org/#ref-for-dom-parentnode-queryselector%E2%91%A0
- selector matching algorithm:
https://www.w3.org/TR/selectors-4/#match-against-tree
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 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.
The new one is the same as the old one, just in the new Parser's
source files. This isn't the most elegant solution but it seemed
like the best option. And it's all temporary, after all.
We already do this in most places, so the style should be consistent.
Also, Clang does not like it, as this could cause an unexpected compile
error if some statements are added to the default label or a new label
is added above it.
This patch removes some FIXMEs from the StyleResolver, specifically
adding the proper float-parsing to the flex: shorthand. The
functionality was already there it just didn't get plumbed in before.
This takes care of the 1, 2, 3 and 4 parameter shorthand of the border-
radius identifier.
There are more as well as the ominous '/' character but that is for
another time. The 2 and 3 parameter versions are weird enough already.
I don't think anybody uses anything other than the 1 or 4 parameter
version or even the elliptical stuff.
