Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-20 08:03:21 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/CSS/StyleValue.h

1286 lines
42 KiB
C
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
Everywhere: Use tobyase@serenityos.org for my copyright headers
2021-08-09 21:28:56 +02:00
* Copyright (c) 2021, Tobias Christiansen <tobyase@serenityos.org>
Everywhere: Use my shiny new serenityos.org email :^)
2021-09-03 11:14:37 +01:00
* Copyright (c) 2021, Sam Atkins <atkinssj@serenityos.org>
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*/
LibHTML: Add the outline of a CSS stylesheet object graph.
2019-06-20 23:25:25 +02:00
#pragma once
LibWeb: Absolutize internal lengths in all StyleValues StyleValue now has a virtual visit_lengths() that allows us to update all CSS lengths during the absolutization phase.
2021-09-23 20:15:26 +02:00
#include <AK/Function.h>
LibWeb: Add CalculatedStyleValue to the CSS StyleValues This adds the CalculatedStyleValue and all the structs needed to work with the calc() expressions.
2021-07-22 23:01:39 +02:00
#include <AK/NonnullOwnPtr.h>
#include <AK/NonnullOwnPtrVector.h>
LibWeb: Add CSS ValueListStyleValue As the new CSS parser tokenizes its input, we can no longer easily rely on a StringStyleValue for multi-value properties. (eg, border) ValueListStyleValue lets us wrap all of the ComponentValues that the Parser produced for one declaration, as a single StyleValue, to then be parsed into StyleValues by the StyleResolver. Originally, I wanted it to be a list of StyleValues, but several properties use syntax that makes use of non-StyleValue tokens, eg: ```css /* Syntax using a / */ font: 12px/14px sans-serif; /* Multiple values separated by commas */ background: url(catdog.png), url(another-image.jpg), blue; ``` Passing the ComponentValue tokens themselves means that all that information is carried over. The alternative might be to create a StyleValue subclass for each property and parse them fully inside the Parser. (eg, `FontStyleValue`) I decided against `ListStyleValue` as a name, to avoid confusion with list styles. It's not ideal, but names are hard.
2021-07-13 16:50:58 +01:00
#include <AK/NonnullRefPtrVector.h>
AK: Rename Retainable.h => RefCounted.h.
2019-06-21 18:58:45 +02:00
#include <AK/RefCounted.h>
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
#include <AK/RefPtr.h>
LibHTML: Respect the CSS "color" property for text Also remove the color values from the ComputedStyle object and get them via StyleProperties instead. At the moment, we only handle colors that Color::from_string() parses.
2019-09-28 22:18:19 +02:00
#include <AK/String.h>
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
#include <AK/StringView.h>
LibHTML: Implement basic tiled background image support It's now possible to set a page background image via <body background>. Also, HtmlView now officially handles rendering the body element's background (color, image or both.) LayoutBox is responsible for all other background rendering. Note that it's not yet possible to use CSS background-image properties directly, since we can't parse them yet. :^)
2019-10-19 11:49:46 +02:00
#include <AK/URL.h>
LibWeb: Add CalculatedStyleValue to the CSS StyleValues This adds the CalculatedStyleValue and all the structs needed to work with the calc() expressions.
2021-07-22 23:01:39 +02:00
#include <AK/Variant.h>
#include <AK/Vector.h>
LibHTML: Implement basic tiled background image support It's now possible to set a page background image via <body background>. Also, HtmlView now officially handles rendering the body element's background (color, image or both.) LayoutBox is responsible for all other background rendering. Note that it's not yet possible to use CSS background-image properties directly, since we can't parse them yet. :^)
2019-10-19 11:49:46 +02:00
#include <AK/WeakPtr.h>
LibGfx: Rename GraphicsBitmap.{cpp,h} => Bitmap.{cpp,h}
2020-02-06 12:07:05 +01:00
#include <LibGfx/Bitmap.h>
LibWeb: Port ImageStyleValue to the ResourceClient interface
2020-06-02 13:51:30 +02:00
#include <LibGfx/Color.h>
LibWeb: Start work towards modern CSS "display" values Until now, we've internally thought of the CSS "display" property as a single-value property. In practice, "display" is a much more complex property that comes in a number of configurations. The most interesting one is the two-part format that describes the outside and inside behavior of a box. Switching our own internal representation towards this model will allow for much cleaner abstractions around layout and the various formatting contexts. Note that we don't *parse* two-part "display" yet, this is only about changing the internal representation of the property. Spec: https://drafts.csswg.org/css-display
2021-10-06 17:57:44 +02:00
#include <LibWeb/CSS/Display.h>
LibWeb: Rename directory LibHTML => LibWeb Let's rename this to LibWeb since it aims to provide more parts of the web platform than just HTML. :^)
2020-03-07 10:32:51 +01:00
#include <LibWeb/CSS/Length.h>
#include <LibWeb/CSS/PropertyID.h>
LibWeb: Generate the CSS::ValueID enum and its helper functions
2020-12-15 20:39:09 +01:00
#include <LibWeb/CSS/ValueID.h>
LibWeb: Use "namespace Web::Foo {" since C++20 allows it :^) Thanks @nico for teaching me about this!
2020-07-21 16:23:08 +02:00
#include <LibWeb/Forward.h>
LibWeb: Fix mismatching Resource subclass types This was a confusing bug: ImageStyleValue loaded its image resource as a Generic resource, while HTMLImageElement loaded as Image. This patch fixes the issue and adds an assertion to verify that we only share resources that have the same C++ client class type.
2020-06-05 23:32:23 +02:00
#include <LibWeb/Loader/ImageResource.h>
LibHTML: Add the outline of a CSS stylesheet object graph.
2019-06-20 23:25:25 +02:00
LibWeb: Use "namespace Web::Foo {" since C++20 allows it :^) Thanks @nico for teaching me about this!
2020-07-21 16:23:08 +02:00
namespace Web::CSS {
LibHTML: Respect the link color set via <body link> The default style for "a" tags now has { color: -libhtml-link; }. We implement this vendor-specific property by querying the containing document for the appropriate link color. Currently we only use the basic link color, but in the future this can be extended to remember visited links, etc.
2019-10-06 10:25:08 +02:00
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
enum class AlignItems {
FlexStart,
FlexEnd,
LibWeb: Cache the used CSS text-align property on LayoutNodeWithStyle
2020-06-23 23:28:40 +02:00
Center,
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
Baseline,
Stretch,
LibWeb: Add the 'float' CSS property to LayoutStyle Note that we don't use the property for anything yet, as I'm still wrapping my head around how to implement floats.
2020-06-26 15:08:42 +02:00
};
LibWeb: Make things aware of box-sizing Of course, we don't actually *use* the box-sizing property yet, but the value is applied and shows up in the computed style.
2021-10-05 16:55:02 +01:00
enum class BoxSizing {
BorderBox,
ContentBox,
};
LibWeb: Naively implement the CSS clear property This is definitely not fully-featured, but basically we now handle the clear property by forcing the cleared box below the bottom-most floated box on the relevant side.
2020-12-06 01:45:51 +01:00
enum class Clear {
None,
Left,
Right,
Both,
};
LibWeb: Parese the CSS "cursor" property
2021-02-21 17:41:00 +00:00
enum class Cursor {
Auto,
Default,
None,
ContextMenu,
Help,
Pointer,
Progress,
Wait,
Cell,
Crosshair,
Text,
VerticalText,
Alias,
Copy,
Move,
NoDrop,
NotAllowed,
Grab,
Grabbing,
EResize,
NResize,
NeResize,
NwResize,
SResize,
SeResize,
SwResize,
WResize,
EwResize,
NsResize,
NeswResize,
NwseResize,
ColResize,
RowResize,
AllScroll,
ZoomIn,
ZoomOut,
};
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
enum class FlexBasis {
Content,
Length,
Auto,
};
enum class FlexDirection {
Row,
RowReverse,
Column,
ColumnReverse,
};
enum class FlexWrap {
Nowrap,
Wrap,
WrapReverse
};
enum class Float {
None,
Left,
Right,
};
enum class JustifyContent {
FlexStart,
FlexEnd,
Center,
SpaceBetween,
SpaceAround,
};
LibWeb: Compute the final border-style property before painting Instead of doing a CSS property lookup for the line style of each border edge during paint, we now cache the final CSS::LineStyle to use in the Layout::BorderData.
2020-12-04 16:11:55 +01:00
enum class LineStyle {
None,
Hidden,
Dotted,
Dashed,
Solid,
Double,
Groove,
Ridge,
Inset,
Outset,
};
LibWeb: Use IdentifierStyleValue for CSS 'list-style-type'
2020-12-15 16:50:39 +01:00
enum class ListStyleType {
None,
Disc,
Circle,
Square,
Decimal,
LibWeb: Add list-style-type: decimal-leading-zero support This doesn't exactly do what you would think from its name: It surely adds an extra leading zero to the front of a number, but only if the number is less than 10. CSS is weird sometimes.
2021-04-22 22:14:24 +02:00
DecimalLeadingZero,
LibWeb: Add list-style-type: lower-alpha and lower-latin support They achieve the same, a list which markers are lowercase (latin) characters.
2021-04-22 23:39:18 +02:00
LowerAlpha,
LowerLatin,
LibWeb: Add roman numerals as a list-style for ol's This patch adds support for the identifiers upper-roman and lower-roman of the list-style property.
2021-07-04 17:17:23 +02:00
LowerRoman,
LibWeb: Add list-style-type: upper-latin and upper-alpha support
2021-04-22 23:52:15 +02:00
UpperAlpha,
UpperLatin,
LibWeb: Add roman numerals as a list-style for ol's This patch adds support for the identifiers upper-roman and lower-roman of the list-style property.
2021-07-04 17:17:23 +02:00
UpperRoman,
LibWeb: Use IdentifierStyleValue for CSS 'list-style-type'
2020-12-15 16:50:39 +01:00
};
LibWeb: Add parsing and application of CSS "overflow" property We don't actually do anything with the values yet, but now they are available for layout nodes once we are ready to implement them.
2021-02-22 15:20:31 +01:00
enum class Overflow : u8 {
Auto,
Clip,
Hidden,
Scroll,
Visible,
};
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
enum class Position {
Static,
Relative,
Absolute,
Fixed,
Sticky,
};
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
enum class PositionEdge {
Left,
Right,
Top,
Bottom,
};
LibWeb: Store computed CSS value of background-repeat
2021-04-02 15:41:29 -04:00
enum class Repeat : u8 {
NoRepeat,
Repeat,
Round,
Space,
};
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
enum class TextAlign {
Left,
LibWeb: Add parsing for the justify-content property
2021-07-16 18:38:26 +02:00
Center,
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
Right,
Justify,
LibwebCenter,
LibWeb: Add parsing for the justify-content property
2021-07-16 18:38:26 +02:00
};
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
enum class TextDecorationLine {
None,
Underline,
Overline,
LineThrough,
Blink,
};
enum class TextTransform {
None,
Capitalize,
Uppercase,
Lowercase,
FullWidth,
FullSizeKana,
LibWeb: Add proper parsing of the AlignItems property This teaches all the relevant places about 'align-items'.
2021-09-15 18:27:20 +02:00
};
LibWeb: Add transform property to the system This patch adds parsing support as well as all the needed stuctures all over LibWeb to pass Transformations around.
2021-09-18 17:20:00 +02:00
enum class TransformFunction {
TranslateY,
};
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
enum class WhiteSpace {
Normal,
Pre,
Nowrap,
PreLine,
PreWrap,
};
LibWeb: Add initial version of pointer-events CSS property
2021-10-05 19:47:13 +01:00
enum class PointerEvents {
Auto,
None
};
AK: Rename Retainable => RefCounted. (And various related renames that go along with it.)
2019-06-21 15:29:31 +02:00
class StyleValue : public RefCounted<StyleValue> {
LibHTML: Add the outline of a CSS stylesheet object graph.
2019-06-20 23:25:25 +02:00
public:
virtual ~StyleValue();
LibHTML: Add LengthStyleValue and create those when parsing number values.
2019-07-03 07:55:22 +02:00
enum class Type {
LibWeb: Implement and use BackgroundStyleValue 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.
2021-08-03 14:56:08 +01:00
Background,
LibWeb: Implement and use BackgroundRepeatStyleValue 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.
2021-08-10 10:21:42 +01:00
BackgroundRepeat,
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
Border,
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
BorderRadius,
LibWeb: Add BoxShadowStyleType as a CSS StyleType This new StyleType stores values related to box-shadows, since they consist of multiple parts that isn't just a shorthand for other properties.
2021-07-23 21:17:09 +02:00
BoxShadow,
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Calculated,
Color,
CombinedBorderRadius,
CustomProperty,
LibWeb: Implement and use FlexStyleValue 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.
2021-08-04 17:48:08 +01:00
Flex,
LibWeb: Implement and use FlexFlowStyleValue
2021-08-05 17:19:29 +01:00
FlexFlow,
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
Font,
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Identifier,
Image,
Inherit,
Initial,
Invalid,
Length,
LibWeb: Implement and use ListStyleStyleValue 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.
2021-08-03 15:56:51 +01:00
ListStyle,
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Numeric,
LibWeb: Implement and use OverflowStyleValue Also added a test page for the `overflow` properties. They apparently don't work, but at least they do parse.
2021-08-09 14:54:40 +01:00
Overflow,
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
Position,
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
String,
LibWeb: Implement and use TextDecorationStyleValue 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.
2021-08-04 12:34:14 +01:00
TextDecoration,
LibWeb: Add transform property to the system This patch adds parsing support as well as all the needed stuctures all over LibWeb to pass Transformations around.
2021-09-18 17:20:00 +02:00
Transformation,
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Unset,
ValueList,
LibHTML: Add the outline of a CSS stylesheet object graph.
2019-06-20 23:25:25 +02:00
};
Type type() const { return m_type; }
LibWeb: Implement and use BackgroundStyleValue 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.
2021-08-03 14:56:08 +01:00
bool is_background() const { return type() == Type::Background; }
LibWeb: Implement and use BackgroundRepeatStyleValue 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.
2021-08-10 10:21:42 +01:00
bool is_background_repeat() const { return type() == Type::BackgroundRepeat; }
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
bool is_border() const { return type() == Type::Border; }
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
bool is_border_radius() const { return type() == Type::BorderRadius; }
LibWeb: Implement new StyleValueList 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.
2021-08-06 11:02:42 +01:00
bool is_box_shadow() const { return type() == Type::BoxShadow; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool is_calculated() const { return type() == Type::Calculated; }
bool is_color() const { return type() == Type::Color; }
bool is_custom_property() const { return type() == Type::CustomProperty; }
LibWeb: Implement and use FlexStyleValue 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.
2021-08-04 17:48:08 +01:00
bool is_flex() const { return type() == Type::Flex; }
LibWeb: Implement and use FlexFlowStyleValue
2021-08-05 17:19:29 +01:00
bool is_flex_flow() const { return type() == Type::FlexFlow; }
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
bool is_font() const { return type() == Type::Font; }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
bool is_identifier() const { return type() == Type::Identifier; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool is_image() const { return type() == Type::Image; }
bool is_inherit() const { return type() == Type::Inherit; }
bool is_initial() const { return type() == Type::Initial; }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
bool is_length() const { return type() == Type::Length; }
LibWeb: Implement and use ListStyleStyleValue 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.
2021-08-03 15:56:51 +01:00
bool is_list_style() const { return type() == Type::ListStyle; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool is_numeric() const { return type() == Type::Numeric; }
LibWeb: Implement and use OverflowStyleValue Also added a test page for the `overflow` properties. They apparently don't work, but at least they do parse.
2021-08-09 14:54:40 +01:00
bool is_overflow() const { return type() == Type::Overflow; }
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
bool is_position() const { return type() == Type::Position; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool is_string() const { return type() == Type::String; }
LibWeb: Implement and use TextDecorationStyleValue 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.
2021-08-04 12:34:14 +01:00
bool is_text_decoration() const { return type() == Type::TextDecoration; }
LibWeb: Add transform property to the system This patch adds parsing support as well as all the needed stuctures all over LibWeb to pass Transformations around.
2021-09-18 17:20:00 +02:00
bool is_transformation() const { return type() == Type::Transformation; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool is_unset() const { return type() == Type::Unset; }
bool is_value_list() const { return type() == Type::ValueList; }
LibWeb: Expose StyleValue parsing method in CSS Parser 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.
2021-07-18 17:12:23 +01:00
LibWeb: Implement CSS `unset` builtin value This is equivalent to `initial` or `inherit`, depending on if the property is inherited by default.
2021-08-20 19:52:36 +01:00
bool is_builtin() const { return is_inherit() || is_initial() || is_unset(); }
LibWeb: Add StyleValue.is_builtin() convenience function
2021-08-10 12:23:27 +01:00
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
BackgroundStyleValue const& as_background() const;
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
BackgroundRepeatStyleValue const& as_background_repeat() const;
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
BorderRadiusStyleValue const& as_border_radius() const;
BorderStyleValue const& as_border() const;
BoxShadowStyleValue const& as_box_shadow() const;
CalculatedStyleValue const& as_calculated() const;
ColorStyleValue const& as_color() const;
CustomStyleValue const& as_custom_property() const;
FlexFlowStyleValue const& as_flex_flow() const;
FlexStyleValue const& as_flex() const;
FontStyleValue const& as_font() const;
IdentifierStyleValue const& as_identifier() const;
ImageStyleValue const& as_image() const;
InheritStyleValue const& as_inherit() const;
InitialStyleValue const& as_initial() const;
LengthStyleValue const& as_length() const;
ListStyleStyleValue const& as_list_style() const;
NumericStyleValue const& as_numeric() const;
OverflowStyleValue const& as_overflow() const;
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
PositionStyleValue const& as_position() const;
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
StringStyleValue const& as_string() const;
TextDecorationStyleValue const& as_text_decoration() const;
TransformationStyleValue const& as_transformation() const;
UnsetStyleValue const& as_unset() const;
StyleValueList const& as_value_list() const;
BackgroundStyleValue& as_background() { return const_cast<BackgroundStyleValue&>(const_cast<StyleValue const&>(*this).as_background()); }
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
BackgroundRepeatStyleValue& as_background_repeat() { return const_cast<BackgroundRepeatStyleValue&>(const_cast<StyleValue const&>(*this).as_background_repeat()); }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
BorderRadiusStyleValue& as_border_radius() { return const_cast<BorderRadiusStyleValue&>(const_cast<StyleValue const&>(*this).as_border_radius()); }
BorderStyleValue& as_border() { return const_cast<BorderStyleValue&>(const_cast<StyleValue const&>(*this).as_border()); }
BoxShadowStyleValue& as_box_shadow() { return const_cast<BoxShadowStyleValue&>(const_cast<StyleValue const&>(*this).as_box_shadow()); }
CalculatedStyleValue& as_calculated() { return const_cast<CalculatedStyleValue&>(const_cast<StyleValue const&>(*this).as_calculated()); }
ColorStyleValue& as_color() { return const_cast<ColorStyleValue&>(const_cast<StyleValue const&>(*this).as_color()); }
CustomStyleValue& as_custom_property() { return const_cast<CustomStyleValue&>(const_cast<StyleValue const&>(*this).as_custom_property()); }
FlexFlowStyleValue& as_flex_flow() { return const_cast<FlexFlowStyleValue&>(const_cast<StyleValue const&>(*this).as_flex_flow()); }
FlexStyleValue& as_flex() { return const_cast<FlexStyleValue&>(const_cast<StyleValue const&>(*this).as_flex()); }
FontStyleValue& as_font() { return const_cast<FontStyleValue&>(const_cast<StyleValue const&>(*this).as_font()); }
IdentifierStyleValue& as_identifier() { return const_cast<IdentifierStyleValue&>(const_cast<StyleValue const&>(*this).as_identifier()); }
ImageStyleValue& as_image() { return const_cast<ImageStyleValue&>(const_cast<StyleValue const&>(*this).as_image()); }
InheritStyleValue& as_inherit() { return const_cast<InheritStyleValue&>(const_cast<StyleValue const&>(*this).as_inherit()); }
InitialStyleValue& as_initial() { return const_cast<InitialStyleValue&>(const_cast<StyleValue const&>(*this).as_initial()); }
LengthStyleValue& as_length() { return const_cast<LengthStyleValue&>(const_cast<StyleValue const&>(*this).as_length()); }
ListStyleStyleValue& as_list_style() { return const_cast<ListStyleStyleValue&>(const_cast<StyleValue const&>(*this).as_list_style()); }
NumericStyleValue& as_numeric() { return const_cast<NumericStyleValue&>(const_cast<StyleValue const&>(*this).as_numeric()); }
OverflowStyleValue& as_overflow() { return const_cast<OverflowStyleValue&>(const_cast<StyleValue const&>(*this).as_overflow()); }
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
PositionStyleValue& as_position() { return const_cast<PositionStyleValue&>(const_cast<StyleValue const&>(*this).as_position()); }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
StringStyleValue& as_string() { return const_cast<StringStyleValue&>(const_cast<StyleValue const&>(*this).as_string()); }
TextDecorationStyleValue& as_text_decoration() { return const_cast<TextDecorationStyleValue&>(const_cast<StyleValue const&>(*this).as_text_decoration()); }
TransformationStyleValue& as_transformation() { return const_cast<TransformationStyleValue&>(const_cast<StyleValue const&>(*this).as_transformation()); }
UnsetStyleValue& as_unset() { return const_cast<UnsetStyleValue&>(const_cast<StyleValue const&>(*this).as_unset()); }
StyleValueList& as_value_list() { return const_cast<StyleValueList&>(const_cast<StyleValue const&>(*this).as_value_list()); }
virtual bool has_auto() const { return false; }
virtual bool has_color() const { return false; }
virtual bool has_identifier() const { return false; }
virtual bool has_length() const { return false; }
virtual bool has_number() const { return false; }
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
virtual bool has_integer() const { return false; }
LibWeb: Add range-checking to property_accepts_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`.
2021-09-23 12:45:08 +01:00
LibWeb: Make StyleValue::to_color() take a Node instead of the Document This is in preparation for the `currentcolor` value, which needs to know what Node it's on so it can check the `color`.
2021-09-16 19:20:20 +01:00
virtual Color to_color(Layout::NodeWithStyle const&) const { return {}; }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
virtual CSS::ValueID to_identifier() const { return ValueID::Invalid; }
virtual Length to_length() const { return {}; }
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
virtual float to_number() const { return 0; }
virtual float to_integer() const { return 0; }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
virtual String to_string() const = 0;
LibHTML: Finish the block width calculation Also add horizontal box values to the layout tree dump.
2019-08-18 08:09:56 +02:00
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
bool operator==(StyleValue const& other) const { return equals(other); }
bool operator!=(StyleValue const& other) const { return !(*this == other); }
LibWeb: Virtualize StyleValue equality check And use this to simplify comparing two IdentifierStyleValues.
2020-12-14 15:04:13 +01:00
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
virtual bool equals(StyleValue const& other) const
LibWeb: Virtualize StyleValue equality check And use this to simplify comparing two IdentifierStyleValues.
2020-12-14 15:04:13 +01:00
{
if (type() != other.type())
return false;
return to_string() == other.to_string();
}
LibWeb: Absolutize internal lengths in all StyleValues StyleValue now has a virtual visit_lengths() that allows us to update all CSS lengths during the absolutization phase.
2021-09-23 20:15:26 +02:00
virtual void visit_lengths(Function<void(CSS::Length&)>) { }
LibHTML: Add the outline of a CSS stylesheet object graph.
2019-06-20 23:25:25 +02:00
protected:
explicit StyleValue(Type);
private:
Type m_type { Type::Invalid };
};
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class BackgroundStyleValue final : public StyleValue {
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
public:
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
static NonnullRefPtr<BackgroundStyleValue> create(
NonnullRefPtr<StyleValue> color,
NonnullRefPtr<StyleValue> image,
NonnullRefPtr<StyleValue> repeat_x,
NonnullRefPtr<StyleValue> repeat_y)
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
{
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
return adopt_ref(*new BackgroundStyleValue(color, image, repeat_x, repeat_y));
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual ~BackgroundStyleValue() override { }
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
NonnullRefPtr<StyleValue> color() const { return m_color; }
NonnullRefPtr<StyleValue> image() const { return m_image; }
NonnullRefPtr<StyleValue> repeat_x() const { return m_repeat_x; }
NonnullRefPtr<StyleValue> repeat_y() const { return m_repeat_y; }
virtual String to_string() const override
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
{
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
return String::formatted("{} {} {} {}", m_color->to_string(), m_image->to_string(), m_repeat_x->to_string(), m_repeat_y->to_string());
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
private:
BackgroundStyleValue(
NonnullRefPtr<StyleValue> color,
NonnullRefPtr<StyleValue> image,
NonnullRefPtr<StyleValue> repeat_x,
NonnullRefPtr<StyleValue> repeat_y)
: StyleValue(Type::Background)
, m_color(color)
, m_image(image)
, m_repeat_x(repeat_x)
, m_repeat_y(repeat_y)
{
}
NonnullRefPtr<StyleValue> m_color;
NonnullRefPtr<StyleValue> m_image;
// FIXME: background-position
// FIXME: background-size
NonnullRefPtr<StyleValue> m_repeat_x;
NonnullRefPtr<StyleValue> m_repeat_y;
// FIXME: background-attachment
// FIXME: background-clip
// FIXME: background-origin
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
};
LibWeb: Parse CSS `background-position` property This is done a bit differently from other properties: using a TokenStream instead of just a Vector of ComponentValues. The reason for this is, we can then use call the same function when parsing the `background` shorthand. Otherwise, we would have to know in advance how many values to pass down, which basically would involve duplicating the `background-position` parsing code inside `background`. The StyleValue is PositionStyleValue, since it represents a `<position>`: https://www.w3.org/TR/css-values-4/#typedef-position Unfortunately, background-position's parsing is a bit different from `<position>`'s, (background-position allows 3-value syntax and `<position>` doesn't) so we'll need to come back and write a different parsing function for that later.
2021-10-31 16:02:29 +00:00
class PositionStyleValue final : public StyleValue {
public:
static NonnullRefPtr<PositionStyleValue> create(PositionEdge edge_x, Length const& offset_x, PositionEdge edge_y, Length const& offset_y)
{
return adopt_ref(*new PositionStyleValue(edge_x, offset_x, edge_y, offset_y));
}
virtual ~PositionStyleValue() override { }
PositionEdge edge_x() const { return m_edge_x; }
Length const& offset_x() const { return m_offset_x; }
PositionEdge edge_y() const { return m_edge_y; }
Length const& offset_y() const { return m_offset_y; }
virtual String to_string() const override;
private:
PositionStyleValue(PositionEdge edge_x, Length const& offset_x, PositionEdge edge_y, Length const& offset_y)
: StyleValue(Type::Position)
, m_edge_x(edge_x)
, m_offset_x(offset_x)
, m_edge_y(edge_y)
, m_offset_y(offset_y)
{
}
PositionEdge m_edge_x;
Length m_offset_x;
PositionEdge m_edge_y;
Length m_offset_y;
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class BackgroundRepeatStyleValue final : public StyleValue {
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
public:
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
static NonnullRefPtr<BackgroundRepeatStyleValue> create(NonnullRefPtr<StyleValue> repeat_x, NonnullRefPtr<StyleValue> repeat_y)
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
{
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
return adopt_ref(*new BackgroundRepeatStyleValue(repeat_x, repeat_y));
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual ~BackgroundRepeatStyleValue() override { }
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
NonnullRefPtr<StyleValue> repeat_x() const { return m_repeat_x; }
NonnullRefPtr<StyleValue> repeat_y() const { return m_repeat_y; }
LibWeb: Make '0' always be both a number and a length in CSS A '0' token can be interpreted both as a Number, and as a Length. This is problematic as in our CSS parser, we often call parse_css_value() first, to figure out what something is, and then assign it. So we do not know in advance whether we want a Length or not. Previously, it always got parsed as a Length, and then every place that expected a NumericStyleValue had to also check for a Length(0), which is easy to forget to do. In particular, this was causing issues with the `flex` property parsing. To solve this, we now always parse 0 as a NumericStyleValue, and NSVs of 0 pretend to be a Length(0px) when asked. In two places, we were casting to a LengthStyleValue* based on is_length(), which no longer works, so those have been adjusted to use `StyleValue::to_length()` instead. They also now check for `is_numeric()` first, to avoid the extra conversion to a Length and back. Possibly this opens up new issues elsewhere. In my testing it seems fine, but until we can get CSS test suites running, it's hard to know for certain.
2021-08-05 15:26:04 +01:00
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual String to_string() const override
{
return String::formatted("{} {}", m_repeat_x->to_string(), m_repeat_y->to_string());
}
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
private:
BackgroundRepeatStyleValue(NonnullRefPtr<StyleValue> repeat_x, NonnullRefPtr<StyleValue> repeat_y)
: StyleValue(Type::BackgroundRepeat)
, m_repeat_x(repeat_x)
, m_repeat_y(repeat_y)
LibWeb: Add a specialized NumericStyleValue::equals() This allows fast comparison of two NumericStyleValues.
2021-09-21 11:30:36 +02:00
{
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
}
NonnullRefPtr<StyleValue> m_repeat_x;
NonnullRefPtr<StyleValue> m_repeat_y;
};
class BorderStyleValue final : public StyleValue {
public:
static NonnullRefPtr<BorderStyleValue> create(
NonnullRefPtr<StyleValue> border_width,
NonnullRefPtr<StyleValue> border_style,
NonnullRefPtr<StyleValue> border_color)
{
return adopt_ref(*new BorderStyleValue(border_width, border_style, border_color));
}
virtual ~BorderStyleValue() override { }
NonnullRefPtr<StyleValue> border_width() const { return m_border_width; }
NonnullRefPtr<StyleValue> border_style() const { return m_border_style; }
NonnullRefPtr<StyleValue> border_color() const { return m_border_color; }
virtual String to_string() const override
{
return String::formatted("Border border_width: {}, border_style: {}, border_color: {}", m_border_width->to_string(), m_border_style->to_string(), m_border_color->to_string());
LibWeb: Add a specialized NumericStyleValue::equals() This allows fast comparison of two NumericStyleValues.
2021-09-21 11:30:36 +02:00
}
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
private:
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
BorderStyleValue(
NonnullRefPtr<StyleValue> border_width,
NonnullRefPtr<StyleValue> border_style,
NonnullRefPtr<StyleValue> border_color)
: StyleValue(Type::Border)
, m_border_width(border_width)
, m_border_style(border_style)
, m_border_color(border_color)
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
{
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
NonnullRefPtr<StyleValue> m_border_width;
NonnullRefPtr<StyleValue> m_border_style;
NonnullRefPtr<StyleValue> m_border_color;
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class BorderRadiusStyleValue final : public StyleValue {
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
public:
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
static NonnullRefPtr<BorderRadiusStyleValue> create(Length const& horizontal_radius, Length const& vertical_radius)
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
{
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
return adopt_ref(*new BorderRadiusStyleValue(horizontal_radius, vertical_radius));
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual ~BorderRadiusStyleValue() override { }
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Length const& horizontal_radius() const { return m_horizontal_radius; }
Length const& vertical_radius() const { return m_vertical_radius; }
bool is_elliptical() const { return m_is_elliptical; }
// FIXME: Remove this once we support elliptical border-radius in Layout/Node.
virtual Length to_length() const override { return horizontal_radius(); }
virtual String to_string() const override
{
return String::formatted("{} / {}", m_horizontal_radius.to_string(), m_vertical_radius.to_string());
}
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
auto& other_value = static_cast<BorderRadiusStyleValue const&>(other);
return m_is_elliptical == other_value.m_is_elliptical
&& m_horizontal_radius == other_value.m_horizontal_radius
&& m_vertical_radius == other_value.m_vertical_radius;
}
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
private:
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
BorderRadiusStyleValue(Length const& horizontal_radius, Length const& vertical_radius)
: StyleValue(Type::BorderRadius)
, m_horizontal_radius(horizontal_radius)
, m_vertical_radius(vertical_radius)
LibHTML: Move CSS value parsing to CSSParser.
2019-07-04 15:49:16 +02:00
{
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
m_is_elliptical = (m_horizontal_radius != m_vertical_radius);
LibHTML: Move CSS value parsing to CSSParser.
2019-07-04 15:49:16 +02:00
}
LibWeb: Absolutize internal lengths in all StyleValues StyleValue now has a virtual visit_lengths() that allows us to update all CSS lengths during the absolutization phase.
2021-09-23 20:15:26 +02:00
virtual void visit_lengths(Function<void(CSS::Length&)> visitor) override
{
visitor(m_horizontal_radius);
visitor(m_vertical_radius);
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool m_is_elliptical;
Length m_horizontal_radius;
Length m_vertical_radius;
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
};
LibHTML: Add LengthStyleValue and create those when parsing number values.
2019-07-03 07:55:22 +02:00
LibWeb: Absolutize internal lengths in all StyleValues StyleValue now has a virtual visit_lengths() that allows us to update all CSS lengths during the absolutization phase.
2021-09-23 20:15:26 +02:00
class BoxShadowStyleValue final : public StyleValue {
LibWeb: Add BoxShadowStyleType as a CSS StyleType This new StyleType stores values related to box-shadows, since they consist of multiple parts that isn't just a shorthand for other properties.
2021-07-23 21:17:09 +02:00
public:
static NonnullRefPtr<BoxShadowStyleValue> create(Length const& offset_x, Length const& offset_y, Length const& blur_radius, Color const& color)
{
return adopt_ref(*new BoxShadowStyleValue(offset_x, offset_y, blur_radius, color));
}
virtual ~BoxShadowStyleValue() override { }
Length const& offset_x() const { return m_offset_x; }
Length const& offset_y() const { return m_offset_y; }
Length const& blur_radius() const { return m_blur_radius; }
Color const& color() const { return m_color; }
String to_string() const override { return String::formatted("BoxShadow offset_x: {}, offset_y: {}, blur_radius: {}, color: {}",
m_offset_x.to_string(), m_offset_y.to_string(), m_blur_radius.to_string(), m_color.to_string()); }
private:
explicit BoxShadowStyleValue(Length const& offset_x, Length const& offset_y, Length const& blur_radius, Color const& color)
: StyleValue(Type::BoxShadow)
, m_offset_x(offset_x)
, m_offset_y(offset_y)
, m_blur_radius(blur_radius)
, m_color(color)
{
}
LibWeb: Absolutize internal lengths in all StyleValues StyleValue now has a virtual visit_lengths() that allows us to update all CSS lengths during the absolutization phase.
2021-09-23 20:15:26 +02:00
virtual void visit_lengths(Function<void(CSS::Length&)> visitor) override
{
visitor(m_offset_x);
visitor(m_offset_y);
visitor(m_blur_radius);
}
LibWeb: Add BoxShadowStyleType as a CSS StyleType This new StyleType stores values related to box-shadows, since they consist of multiple parts that isn't just a shorthand for other properties.
2021-07-23 21:17:09 +02:00
Length m_offset_x;
Length m_offset_y;
Length m_blur_radius;
Color m_color;
};
LibWeb: Add CalculatedStyleValue to the CSS StyleValues This adds the CalculatedStyleValue and all the structs needed to work with the calc() expressions.
2021-07-22 23:01:39 +02:00
class CalculatedStyleValue : public StyleValue {
public:
struct CalcSum;
struct CalcSumPartWithOperator;
struct CalcProduct;
struct CalcProductPartWithOperator;
struct CalcNumberSum;
struct CalcNumberSumPartWithOperator;
struct CalcNumberProduct;
struct CalcNumberProductPartWithOperator;
using CalcNumberValue = Variant<float, NonnullOwnPtr<CalcNumberSum>>;
using CalcValue = Variant<float, CSS::Length, NonnullOwnPtr<CalcSum>>;
LibWeb: Use W3C urls for CSS-VALUES-3 spec links
2021-10-15 19:47:32 +01:00
// This represents that: https://www.w3.org/TR/css-values-3/#calc-syntax
LibWeb: Add CalculatedStyleValue to the CSS StyleValues This adds the CalculatedStyleValue and all the structs needed to work with the calc() expressions.
2021-07-22 23:01:39 +02:00
struct CalcSum {
CalcSum(NonnullOwnPtr<CalcProduct> first_calc_product, NonnullOwnPtrVector<CalcSumPartWithOperator> additional)
: first_calc_product(move(first_calc_product))
, zero_or_more_additional_calc_products(move(additional)) {};
NonnullOwnPtr<CalcProduct> first_calc_product;
NonnullOwnPtrVector<CalcSumPartWithOperator> zero_or_more_additional_calc_products;
};
struct CalcNumberSum {
CalcNumberSum(NonnullOwnPtr<CalcNumberProduct> first_calc_number_product, NonnullOwnPtrVector<CalcNumberSumPartWithOperator> additional)
: first_calc_number_product(move(first_calc_number_product))
, zero_or_more_additional_calc_number_products(move(additional)) {};
NonnullOwnPtr<CalcNumberProduct> first_calc_number_product;
NonnullOwnPtrVector<CalcNumberSumPartWithOperator> zero_or_more_additional_calc_number_products;
};
struct CalcProduct {
CalcValue first_calc_value;
NonnullOwnPtrVector<CalcProductPartWithOperator> zero_or_more_additional_calc_values;
};
struct CalcSumPartWithOperator {
enum Operation {
Add,
Subtract,
};
CalcSumPartWithOperator(Operation op, NonnullOwnPtr<CalcProduct> calc_product)
: op(op)
, calc_product(move(calc_product)) {};
Operation op;
NonnullOwnPtr<CalcProduct> calc_product;
};
struct CalcProductPartWithOperator {
enum {
Multiply,
Divide,
} op;
Variant<CalcValue, CalcNumberValue> value;
};
struct CalcNumberProduct {
CalcNumberValue first_calc_number_value;
NonnullOwnPtrVector<CalcNumberProductPartWithOperator> zero_or_more_additional_calc_number_values;
};
struct CalcNumberProductPartWithOperator {
enum {
Multiply,
Divide,
} op;
CalcNumberValue value;
};
struct CalcNumberSumPartWithOperator {
enum Operation {
Add,
Subtract,
};
CalcNumberSumPartWithOperator(Operation op, NonnullOwnPtr<CalcNumberProduct> calc_number_product)
: op(op)
, calc_number_product(move(calc_number_product)) {};
Operation op;
NonnullOwnPtr<CalcNumberProduct> calc_number_product;
};
static NonnullRefPtr<CalculatedStyleValue> create(String const& expression_string, NonnullOwnPtr<CalcSum> calc_sum)
{
return adopt_ref(*new CalculatedStyleValue(expression_string, move(calc_sum)));
}
String to_string() const override { return m_expression_string; }
NonnullOwnPtr<CalcSum> const& expression() const { return m_expression; }
private:
explicit CalculatedStyleValue(String const& expression_string, NonnullOwnPtr<CalcSum> calc_sum)
: StyleValue(Type::Calculated)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
, m_expression_string(expression_string)
, m_expression(move(calc_sum))
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
{
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
String m_expression_string;
NonnullOwnPtr<CalcSum> m_expression;
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class ColorStyleValue : public StyleValue {
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
public:
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
static NonnullRefPtr<ColorStyleValue> create(Color color)
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
{
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
return adopt_ref(*new ColorStyleValue(color));
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual ~ColorStyleValue() override { }
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Color color() const { return m_color; }
LibWeb: Make ColorStyleValue serialization spec compliant [CSS Color 4] tells us to use either rgb() or rgba() notation, depending on the color's alpha value.
2021-10-03 17:56:01 +02:00
virtual String to_string() const override;
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
virtual bool has_color() const override { return true; }
virtual Color to_color(Layout::NodeWithStyle const&) const override { return m_color; }
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
virtual bool equals(StyleValue const& other) const override
LibWeb: Add a specialized BorderRadiusStyleValue::equals() This allows fast comparison of two BorderRadiusStyleValues.
2021-09-21 11:31:03 +02:00
{
if (type() != other.type())
return false;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
return m_color == static_cast<const ColorStyleValue&>(other).m_color;
LibWeb: Add a specialized BorderRadiusStyleValue::equals() This allows fast comparison of two BorderRadiusStyleValues.
2021-09-21 11:31:03 +02:00
}
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
private:
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
explicit ColorStyleValue(Color color)
: StyleValue(Type::Color)
, m_color(color)
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
{
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Color m_color;
LibWeb: Implement and use BorderRadiusStyleValue 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.
2021-08-06 16:55:08 +01:00
};
LibWeb: Add CombinedBoderRadiusStyleValue for CSS `border-radius` This style value can hold all four border radii and format them into valid CSS for the `border-radius` property.
2021-09-14 00:37:43 +02:00
class CombinedBorderRadiusStyleValue final : public StyleValue {
public:
static NonnullRefPtr<CombinedBorderRadiusStyleValue> create(NonnullRefPtr<BorderRadiusStyleValue> top_left, NonnullRefPtr<BorderRadiusStyleValue> top_right, NonnullRefPtr<BorderRadiusStyleValue> bottom_right, NonnullRefPtr<BorderRadiusStyleValue> bottom_left)
{
return adopt_ref(*new CombinedBorderRadiusStyleValue(top_left, top_right, bottom_right, bottom_left));
}
virtual ~CombinedBorderRadiusStyleValue() override { }
NonnullRefPtr<BorderRadiusStyleValue> top_left() const { return m_top_left; }
NonnullRefPtr<BorderRadiusStyleValue> top_right() const { return m_top_right; }
NonnullRefPtr<BorderRadiusStyleValue> bottom_right() const { return m_bottom_right; }
NonnullRefPtr<BorderRadiusStyleValue> bottom_left() const { return m_bottom_left; }
virtual String to_string() const override
{
return String::formatted("{} {} {} {} / {} {} {} {}", m_top_left->horizontal_radius().to_string(), m_top_right->horizontal_radius().to_string(), m_bottom_right->horizontal_radius().to_string(), m_bottom_left->horizontal_radius().to_string(), m_top_left->vertical_radius().to_string(), m_top_right->vertical_radius().to_string(), m_bottom_right->vertical_radius().to_string(), m_bottom_left->vertical_radius().to_string());
}
private:
CombinedBorderRadiusStyleValue(NonnullRefPtr<BorderRadiusStyleValue> top_left, NonnullRefPtr<BorderRadiusStyleValue> top_right, NonnullRefPtr<BorderRadiusStyleValue> bottom_right, NonnullRefPtr<BorderRadiusStyleValue> bottom_left)
: StyleValue(Type::CombinedBorderRadius)
, m_top_left(top_left)
, m_top_right(top_right)
, m_bottom_right(bottom_right)
, m_bottom_left(bottom_left)
{
}
NonnullRefPtr<BorderRadiusStyleValue> m_top_left;
NonnullRefPtr<BorderRadiusStyleValue> m_top_right;
NonnullRefPtr<BorderRadiusStyleValue> m_bottom_right;
NonnullRefPtr<BorderRadiusStyleValue> m_bottom_left;
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
// FIXME: Allow for fallback
class CustomStyleValue : public StyleValue {
public:
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
static NonnullRefPtr<CustomStyleValue> create(String const& custom_property_name)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
{
return adopt_ref(*new CustomStyleValue(custom_property_name));
}
String custom_property_name() const { return m_custom_property_name; }
String to_string() const override { return m_custom_property_name; }
private:
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
explicit CustomStyleValue(String const& custom_property_name)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
: StyleValue(Type::CustomProperty)
, m_custom_property_name(custom_property_name)
{
}
String m_custom_property_name {};
};
LibWeb: Implement and use FlexStyleValue 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.
2021-08-04 17:48:08 +01:00
class FlexStyleValue final : public StyleValue {
public:
static NonnullRefPtr<FlexStyleValue> create(
NonnullRefPtr<StyleValue> grow,
NonnullRefPtr<StyleValue> shrink,
NonnullRefPtr<StyleValue> basis)
{
return adopt_ref(*new FlexStyleValue(grow, shrink, basis));
}
virtual ~FlexStyleValue() override { }
NonnullRefPtr<StyleValue> grow() const { return m_grow; }
NonnullRefPtr<StyleValue> shrink() const { return m_shrink; }
NonnullRefPtr<StyleValue> basis() const { return m_basis; }
virtual String to_string() const override
{
return String::formatted("Flex grow: {}, shrink: {}, basis: {}", m_grow->to_string(), m_shrink->to_string(), m_basis->to_string());
}
private:
FlexStyleValue(
NonnullRefPtr<StyleValue> grow,
NonnullRefPtr<StyleValue> shrink,
NonnullRefPtr<StyleValue> basis)
: StyleValue(Type::Flex)
, m_grow(grow)
, m_shrink(shrink)
, m_basis(basis)
{
}
NonnullRefPtr<StyleValue> m_grow;
NonnullRefPtr<StyleValue> m_shrink;
NonnullRefPtr<StyleValue> m_basis;
};
LibWeb: Implement and use FlexFlowStyleValue
2021-08-05 17:19:29 +01:00
class FlexFlowStyleValue final : public StyleValue {
public:
static NonnullRefPtr<FlexFlowStyleValue> create(NonnullRefPtr<StyleValue> flex_direction, NonnullRefPtr<StyleValue> flex_wrap)
{
return adopt_ref(*new FlexFlowStyleValue(flex_direction, flex_wrap));
}
virtual ~FlexFlowStyleValue() override { }
NonnullRefPtr<StyleValue> flex_direction() const { return m_flex_direction; }
NonnullRefPtr<StyleValue> flex_wrap() const { return m_flex_wrap; }
virtual String to_string() const override
{
return String::formatted("FlexFlow flex_direction: {}, flex_wrap: {}", m_flex_direction->to_string(), m_flex_wrap->to_string());
}
private:
FlexFlowStyleValue(NonnullRefPtr<StyleValue> flex_direction, NonnullRefPtr<StyleValue> flex_wrap)
: StyleValue(Type::FlexFlow)
, m_flex_direction(flex_direction)
, m_flex_wrap(flex_wrap)
{
}
NonnullRefPtr<StyleValue> m_flex_direction;
NonnullRefPtr<StyleValue> m_flex_wrap;
};
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
class FontStyleValue final : public StyleValue {
public:
LibWeb: Parse multiple font-family values 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(). :^)
2021-08-10 17:01:26 +01:00
static NonnullRefPtr<FontStyleValue> create(NonnullRefPtr<StyleValue> font_style, NonnullRefPtr<StyleValue> font_weight, NonnullRefPtr<StyleValue> font_size, NonnullRefPtr<StyleValue> line_height, NonnullRefPtr<StyleValue> font_families) { return adopt_ref(*new FontStyleValue(font_style, font_weight, font_size, line_height, font_families)); }
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
virtual ~FontStyleValue() override { }
NonnullRefPtr<StyleValue> font_style() const { return m_font_style; }
NonnullRefPtr<StyleValue> font_weight() const { return m_font_weight; }
NonnullRefPtr<StyleValue> font_size() const { return m_font_size; }
NonnullRefPtr<StyleValue> line_height() const { return m_line_height; }
LibWeb: Parse multiple font-family values 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(). :^)
2021-08-10 17:01:26 +01:00
NonnullRefPtr<StyleValue> font_families() const { return m_font_families; }
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
virtual String to_string() const override
{
LibWeb: Parse multiple font-family values 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(). :^)
2021-08-10 17:01:26 +01:00
return String::formatted("Font style: {}, weight: {}, size: {}, line_height: {}, families: {}",
m_font_style->to_string(), m_font_weight->to_string(), m_font_size->to_string(), m_line_height->to_string(), m_font_families->to_string());
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
}
private:
LibWeb: Parse multiple font-family values 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(). :^)
2021-08-10 17:01:26 +01:00
FontStyleValue(NonnullRefPtr<StyleValue> font_style, NonnullRefPtr<StyleValue> font_weight, NonnullRefPtr<StyleValue> font_size, NonnullRefPtr<StyleValue> line_height, NonnullRefPtr<StyleValue> font_families)
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
: StyleValue(Type::Font)
, m_font_style(font_style)
, m_font_weight(font_weight)
, m_font_size(font_size)
, m_line_height(line_height)
LibWeb: Parse multiple font-family values 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(). :^)
2021-08-10 17:01:26 +01:00
, m_font_families(font_families)
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
{
}
NonnullRefPtr<StyleValue> m_font_style;
NonnullRefPtr<StyleValue> m_font_weight;
NonnullRefPtr<StyleValue> m_font_size;
NonnullRefPtr<StyleValue> m_line_height;
LibWeb: Parse multiple font-family values 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(). :^)
2021-08-10 17:01:26 +01:00
NonnullRefPtr<StyleValue> m_font_families;
LibWeb: Implement and use FontStyleValue 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.
2021-08-03 11:37:24 +01:00
// FIXME: Implement font-stretch and font-variant.
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class IdentifierStyleValue final : public StyleValue {
public:
static NonnullRefPtr<IdentifierStyleValue> create(CSS::ValueID id)
{
return adopt_ref(*new IdentifierStyleValue(id));
}
virtual ~IdentifierStyleValue() override { }
CSS::ValueID id() const { return m_id; }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
virtual bool has_auto() const override { return m_id == ValueID::Auto; }
virtual bool has_identifier() const override { return true; }
virtual CSS::ValueID to_identifier() const override { return m_id; }
virtual bool has_color() const override;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual Color to_color(Layout::NodeWithStyle const& node) const override;
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
virtual String to_string() const override;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
virtual bool equals(StyleValue const& other) const override
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
{
if (type() != other.type())
return false;
return m_id == static_cast<const IdentifierStyleValue&>(other).m_id;
}
private:
explicit IdentifierStyleValue(CSS::ValueID id)
: StyleValue(Type::Identifier)
, m_id(id)
{
}
CSS::ValueID m_id { CSS::ValueID::Invalid };
};
class ImageStyleValue final
: public StyleValue
, public ImageResourceClient {
public:
LibWeb: Move image resource request out of ImageStyleValue constructor This always felt awkward to me, and required a few other hacks to make it work. Now, the request is only started when `load_bitmap()` is called, which we do inside `NodeWithStyle::apply_style()`.
2021-10-22 20:55:27 +01:00
static NonnullRefPtr<ImageStyleValue> create(AK::URL const& url) { return adopt_ref(*new ImageStyleValue(url)); }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual ~ImageStyleValue() override { }
String to_string() const override { return String::formatted("Image({})", m_url.to_string()); }
LibWeb: Move image resource request out of ImageStyleValue constructor This always felt awkward to me, and required a few other hacks to make it work. Now, the request is only started when `load_bitmap()` is called, which we do inside `NodeWithStyle::apply_style()`.
2021-10-22 20:55:27 +01:00
void load_bitmap(DOM::Document& document);
Gfx::Bitmap const* bitmap() const { return m_bitmap; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
private:
LibWeb: Move image resource request out of ImageStyleValue constructor This always felt awkward to me, and required a few other hacks to make it work. Now, the request is only started when `load_bitmap()` is called, which we do inside `NodeWithStyle::apply_style()`.
2021-10-22 20:55:27 +01:00
ImageStyleValue(AK::URL const&);
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
// ^ResourceClient
virtual void resource_did_load() override;
AK::URL m_url;
WeakPtr<DOM::Document> m_document;
RefPtr<Gfx::Bitmap> m_bitmap;
};
class InheritStyleValue final : public StyleValue {
public:
static NonnullRefPtr<InheritStyleValue> the()
{
static NonnullRefPtr<InheritStyleValue> instance = adopt_ref(*new InheritStyleValue);
return instance;
}
virtual ~InheritStyleValue() override { }
String to_string() const override { return "inherit"; }
private:
InheritStyleValue()
: StyleValue(Type::Inherit)
{
}
};
class InitialStyleValue final : public StyleValue {
public:
static NonnullRefPtr<InitialStyleValue> the()
{
static NonnullRefPtr<InitialStyleValue> instance = adopt_ref(*new InitialStyleValue);
return instance;
}
virtual ~InitialStyleValue() override { }
String to_string() const override { return "initial"; }
private:
InitialStyleValue()
: StyleValue(Type::Initial)
{
}
};
class LengthStyleValue : public StyleValue {
public:
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
static NonnullRefPtr<LengthStyleValue> create(Length const& length)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
{
return adopt_ref(*new LengthStyleValue(length));
}
virtual ~LengthStyleValue() override { }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
Length const& length() const { return m_length; }
virtual bool has_auto() const override { return m_length.is_auto(); }
virtual bool has_length() const override { return true; }
LibWeb: Make 'auto' LengthStyleValues return 'auto' identifier I think I broke this in my previous StyleValue clean-up. This prevented properties like `foo: auto;` from parsing, if they did not accept Lengths.
2021-10-18 15:26:56 +01:00
virtual bool has_identifier() const override { return has_auto(); }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual String to_string() const override { return m_length.to_string(); }
virtual Length to_length() const override { return m_length; }
LibWeb: Make 'auto' LengthStyleValues return 'auto' identifier I think I broke this in my previous StyleValue clean-up. This prevented properties like `foo: auto;` from parsing, if they did not accept Lengths.
2021-10-18 15:26:56 +01:00
virtual ValueID to_identifier() const override { return has_auto() ? ValueID::Auto : ValueID::Invalid; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
virtual bool equals(StyleValue const& other) const override
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
{
if (type() != other.type())
return false;
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
return m_length == static_cast<LengthStyleValue const&>(other).m_length;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
}
private:
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
explicit LengthStyleValue(Length const& length)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
: StyleValue(Type::Length)
, m_length(length)
{
}
LibWeb: Absolutize internal lengths in all StyleValues StyleValue now has a virtual visit_lengths() that allows us to update all CSS lengths during the absolutization phase.
2021-09-23 20:15:26 +02:00
virtual void visit_lengths(Function<void(CSS::Length&)> visitor) override
{
visitor(m_length);
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
Length m_length;
};
LibWeb: Implement and use ListStyleStyleValue 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.
2021-08-03 15:56:51 +01:00
class ListStyleStyleValue final : public StyleValue {
public:
static NonnullRefPtr<ListStyleStyleValue> create(
NonnullRefPtr<StyleValue> position,
NonnullRefPtr<StyleValue> image,
NonnullRefPtr<StyleValue> style_type)
{
return adopt_ref(*new ListStyleStyleValue(position, image, style_type));
}
virtual ~ListStyleStyleValue() override { }
NonnullRefPtr<StyleValue> position() const { return m_position; }
NonnullRefPtr<StyleValue> image() const { return m_image; }
NonnullRefPtr<StyleValue> style_type() const { return m_style_type; }
virtual String to_string() const override
{
return String::formatted("ListStyle position: {}, image: {}, style_type: {}", m_position->to_string(), m_image->to_string(), m_style_type->to_string());
}
private:
ListStyleStyleValue(
NonnullRefPtr<StyleValue> position,
NonnullRefPtr<StyleValue> image,
NonnullRefPtr<StyleValue> style_type)
: StyleValue(Type::ListStyle)
, m_position(position)
, m_image(image)
, m_style_type(style_type)
{
}
NonnullRefPtr<StyleValue> m_position;
NonnullRefPtr<StyleValue> m_image;
NonnullRefPtr<StyleValue> m_style_type;
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class NumericStyleValue : public StyleValue {
public:
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
static NonnullRefPtr<NumericStyleValue> create_float(float value)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
{
return adopt_ref(*new NumericStyleValue(value));
}
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
static NonnullRefPtr<NumericStyleValue> create_integer(i64 value)
{
return adopt_ref(*new NumericStyleValue(value));
}
virtual bool has_length() const override { return to_number() == 0; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual Length to_length() const override { return Length(0, Length::Type::Px); }
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
virtual bool has_number() const override { return true; }
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
virtual float to_number() const override
{
return m_value.visit(
[](float value) { return value; },
[](i64 value) { return (float)value; });
}
LibWeb: Clarify StyleValue API with new naming scheme 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.
2021-09-23 19:54:19 +01:00
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
virtual bool has_integer() const override { return m_value.has<i64>(); }
virtual float to_integer() const override { return m_value.get<i64>(); }
String to_string() const override
{
return m_value.visit(
[](float value) {
return String::formatted("{}", value);
},
[](i64 value) {
return String::formatted("{}", value);
});
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
if (has_integer() != other.has_integer())
return false;
if (has_integer())
return m_value.get<i64>() == static_cast<NumericStyleValue const&>(other).m_value.get<i64>();
return m_value.get<float>() == static_cast<NumericStyleValue const&>(other).m_value.get<float>();
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
}
private:
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
explicit NumericStyleValue(Variant<float, i64> value)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
: StyleValue(Type::Numeric)
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
, m_value(move(value))
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
{
}
LibWeb: Distinguish between integer and float in NumericStyleValue We have this information when parsing, and some properties specifically only allow integers, so it makes sense to keep that around.
2021-10-19 16:43:56 +01:00
Variant<float, i64> m_value { (i64)0 };
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
};
LibWeb: Implement and use OverflowStyleValue Also added a test page for the `overflow` properties. They apparently don't work, but at least they do parse.
2021-08-09 14:54:40 +01:00
class OverflowStyleValue final : public StyleValue {
public:
static NonnullRefPtr<OverflowStyleValue> create(NonnullRefPtr<StyleValue> overflow_x, NonnullRefPtr<StyleValue> overflow_y)
{
return adopt_ref(*new OverflowStyleValue(overflow_x, overflow_y));
}
virtual ~OverflowStyleValue() override { }
NonnullRefPtr<StyleValue> overflow_x() const { return m_overflow_x; }
NonnullRefPtr<StyleValue> overflow_y() const { return m_overflow_y; }
virtual String to_string() const override
{
return String::formatted("{} {}", m_overflow_x->to_string(), m_overflow_y->to_string());
}
private:
OverflowStyleValue(NonnullRefPtr<StyleValue> overflow_x, NonnullRefPtr<StyleValue> overflow_y)
: StyleValue(Type::Overflow)
, m_overflow_x(overflow_x)
, m_overflow_y(overflow_y)
{
}
NonnullRefPtr<StyleValue> m_overflow_x;
NonnullRefPtr<StyleValue> m_overflow_y;
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class StringStyleValue : public StyleValue {
public:
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
static NonnullRefPtr<StringStyleValue> create(String const& string)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
{
return adopt_ref(*new StringStyleValue(string));
}
virtual ~StringStyleValue() override { }
String to_string() const override { return m_string; }
private:
LibWeb: Use east const in StyleValue.{h,cpp}
2021-10-18 15:26:38 +01:00
explicit StringStyleValue(String const& string)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
: StyleValue(Type::String)
, m_string(string)
{
}
String m_string;
};
LibWeb: Implement and use TextDecorationStyleValue 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.
2021-08-04 12:34:14 +01:00
class TextDecorationStyleValue final : public StyleValue {
public:
static NonnullRefPtr<TextDecorationStyleValue> create(
NonnullRefPtr<StyleValue> line,
NonnullRefPtr<StyleValue> style,
NonnullRefPtr<StyleValue> color)
{
return adopt_ref(*new TextDecorationStyleValue(line, style, color));
}
virtual ~TextDecorationStyleValue() override { }
NonnullRefPtr<StyleValue> line() const { return m_line; }
NonnullRefPtr<StyleValue> style() const { return m_style; }
NonnullRefPtr<StyleValue> color() const { return m_color; }
virtual String to_string() const override
{
return String::formatted("TextDecoration line: {}, style: {}, color: {}", m_line->to_string(), m_style->to_string(), m_color->to_string());
}
private:
TextDecorationStyleValue(
NonnullRefPtr<StyleValue> line,
NonnullRefPtr<StyleValue> style,
NonnullRefPtr<StyleValue> color)
: StyleValue(Type::TextDecoration)
, m_line(line)
, m_style(style)
, m_color(color)
{
}
NonnullRefPtr<StyleValue> m_line;
NonnullRefPtr<StyleValue> m_style;
NonnullRefPtr<StyleValue> m_color;
};
LibWeb: Add transform property to the system This patch adds parsing support as well as all the needed stuctures all over LibWeb to pass Transformations around.
2021-09-18 17:20:00 +02:00
class TransformationStyleValue final : public StyleValue {
public:
static NonnullRefPtr<TransformationStyleValue> create(CSS::TransformFunction transform_function, NonnullRefPtrVector<StyleValue>&& values)
{
return adopt_ref(*new TransformationStyleValue(transform_function, move(values)));
}
virtual ~TransformationStyleValue() override { }
CSS::TransformFunction transform_function() const { return m_transform_function; }
NonnullRefPtrVector<StyleValue> values() const { return m_values; }
virtual String to_string() const override
{
return String::formatted("TransformationStyleValue");
}
private:
TransformationStyleValue(CSS::TransformFunction transform_function, NonnullRefPtrVector<StyleValue>&& values)
: StyleValue(Type::Transformation)
, m_transform_function(transform_function)
, m_values(move(values))
{
}
CSS::TransformFunction m_transform_function;
NonnullRefPtrVector<StyleValue> m_values;
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
class UnsetStyleValue final : public StyleValue {
public:
static NonnullRefPtr<UnsetStyleValue> the()
{
static NonnullRefPtr<UnsetStyleValue> instance = adopt_ref(*new UnsetStyleValue);
return instance;
}
virtual ~UnsetStyleValue() override { }
String to_string() const override { return "unset"; }
private:
UnsetStyleValue()
: StyleValue(Type::Unset)
{
}
};
LibWeb: Implement new StyleValueList 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.
2021-08-06 11:02:42 +01:00
class StyleValueList final : public StyleValue {
public:
static NonnullRefPtr<StyleValueList> create(NonnullRefPtrVector<StyleValue>&& values) { return adopt_ref(*new StyleValueList(move(values))); }
NonnullRefPtrVector<StyleValue> const& values() const { return m_values; }
virtual String to_string() const
{
StringBuilder builder;
builder.appendff("List[{}](", m_values.size());
for (size_t i = 0; i < m_values.size(); ++i) {
if (i)
builder.append(',');
builder.append(m_values[i].to_string());
}
builder.append(')');
return builder.to_string();
}
private:
StyleValueList(NonnullRefPtrVector<StyleValue>&& values)
: StyleValue(Type::ValueList)
, m_values(move(values))
{
}
NonnullRefPtrVector<StyleValue> m_values;
};
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
Reference in a new issue Copy permalink