This does a few things, that are hard to separate. For a while now, it's
been confuzing what `StyleValue::is_foo()` actually means. It sometimes
was used to check the type, and sometimes to see if it could return a
certain value type. The new naming scheme is:
- `is_length()` - is it a LengthStyleValue?
- `as_length()` - casts it to LengthStyleValue
- `has_length()` - can it return a Length?
- `to_length()` - gets the internal value out (eg, Length)
This also means, no more `static_cast<LengthStyleValue const&>(*this)`
stuff when dealing with StyleValues. :^)
Hopefully this will be a bit clearer going forward. There are lots of
places using the original methods, so I'll be going through them to
hopefully catch any issues.
FontPickerWeightModel is no longer necessary as variants contain
weight as part of a complete typeface description. This fixes fonts
not inventorying correctly in picker when they contained more than
bold and regular typefaces. Weight mapping has been moved into
LibGfx/FontStyleMapping.h
Previously the algorithm was being performed from the start of the
string to the end, which was a little more convenient when writing
the code, but made it more annoying to be able to properly talk
about the "start" of where the changes were happening, since we
can only re-construct the changes in reverse order of the initial
traversal.
Basically, doing the initial pass in reverse lets us reconstruct
the hunks in the correct order to begin with, and not have to worry
about reversing the hunks / lines within the hunks
Previously any children would be layout using a BlockFormattingContext.
Now we at least differentiate between IFC and BFC if the sizes in
question are not constrained by other things.
Calling `is_identifier()` here was wrong, since it just means you can
get an Identifier from it. This meant that an `auto` LengthStyleValue
would return true, then it would get `static_cast` to the wrong class,
and return a garbage value.
Basically, I really need to tidy up the API for StyleValue, so it's
clear whether `is_foo()` means the object is a `FooStyleValue`, or it
can just return a `foo` value.
For `number` and `integer` types, you can add a range afterwards to add
a range check, using similar syntax to that used in the CSS specs. For
example:
```json
"font-weight": {
...
"valid-types": [
"number [1,1000]"
],
...
}
```
This limits any numbers to the range `1 <= n <= 1000`.
This brings us a few nice benefits:
- We only generate a `StyleValueList` for properties that accept
multiple values.
- We reject declarations that have too many values.
- We check the type of each value that is parsed, to make sure it's
acceptable to the property.
Probably there are some regressions here, since this is
Later, we can also replace many of the `is_foo()` functions and lambas
inside the Parser with more calls to `property_accepts_value()`. Also we
can remove some checks when resolving styles, since only valid types of
values will get to that point. But one step at a time. :^)
We don't want a property like `background` to fall back to parsing as a
single value or StyleValueList if `parse_background_style_value()`
fails. We just want it to fail.
Negative margins are a headache anyways, and allowing them to be
negative lead to weird behavior.
This patch avoids vasty wrong height-calculations by limiting the
allowed margins to positive numbers when evaluating the height of a
block.
Large enough content ranges produced unclamped scrubbers sized zero,
effectively clamped by their integer type. This led to zero sized
page_increments and scrubbers which didn't budge on gutter events.
This fixes broken gutters in FontEditor and TextEditor for large
files.
This is a helpful option to prevent unwanted side effects, distinguish
between user and programmatic input, etc. Sliders and SpinBoxes were
implementing it idiosyncratically, so let's generalize the API and
give Buttons and TextEditors the same ability.
This also moves getElementsByTagName to ParentNode to remove the code
duplication between Document and Element. This additionally fixes a bug
where getElementsByTagName did not check if the element was a
descendant, meaning it would also include the context element if the
condition matched.
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. :^)
