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

1720 lines
56 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>
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
* Copyright (c) 2021-2022, 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: Support more CSS image-rendering values This patch adds support for "crisp-edges", "high-quality" and "smooth" for the CSS image-rendering property. "crisp-edges" maps to nearest-neighbor scaling for <canvas> and <img> elements, while "high-quality" and "smooth" both use bilinear blending.
2022-03-06 18:17:50 +01:00
#include <LibGfx/Painter.h>
LibWeb: Implement CSS Angle class This corresponds to `<angle>` in the grammar.
2022-02-21 17:43:30 +00:00
#include <LibWeb/CSS/Angle.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: Implement CSS Frequency class This corresponds to `<frequency>` in the grammar.
2022-02-21 17:49:47 +00:00
#include <LibWeb/CSS/Frequency.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>
LibWeb: Use CSS::Number for CalculatedStyleValue numbers
2022-03-21 21:03:17 +00:00
#include <LibWeb/CSS/Number.h>
LibWeb: Add new UnresolvedStyleValue class This represents a property value that hasn't been converted to a "proper" StyleValue yet. That is, it's either a custom property's value, or a value that includes `var()` references, (or both!) since neither of those can be fully resolved at parse time.
2021-12-03 12:28:14 +00:00
#include <LibWeb/CSS/Parser/StyleComponentValueRule.h>
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
#include <LibWeb/CSS/Percentage.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/PropertyID.h>
LibWeb: Implement CSS Resolution class This corresponds to `<resolution>` in the grammar.
2022-02-21 17:51:01 +00:00
#include <LibWeb/CSS/Resolution.h>
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
#include <LibWeb/CSS/Time.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: Store all background properties in BackgroundLayerData All of this is now passed along to `paint_background()`. :^) (As always, "all" excludes the background-color since that's not a layer property.)
2021-11-12 16:30:21 +00:00
enum class BackgroundAttachment {
Fixed,
Local,
Scroll,
};
enum class BackgroundBox {
BorderBox,
ContentBox,
PaddingBox,
};
enum class BackgroundSize {
Contain,
Cover,
LengthPercentage,
};
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: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
enum class BoxShadowPlacement {
Outer,
Inner,
};
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,
LibWeb: Convert flex-basis to LengthPercentage The flexbox logic confuses me so regressions are possible, though our test page looks the same as before so it should be fine. Renamed FlexBasis::Length -> LengthPercentage too, for clarity.
2022-01-19 11:52:01 +00:00
LengthPercentage,
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
Auto,
};
enum class FlexDirection {
Row,
RowReverse,
Column,
ColumnReverse,
};
enum class FlexWrap {
Nowrap,
Wrap,
WrapReverse
};
enum class Float {
None,
Left,
Right,
};
LibWeb: Add support for CSS image-rendering property Currently only "auto" and "pixelated" values are supported.
2022-02-18 12:21:27 +01:00
enum class ImageRendering {
Auto,
LibWeb: Support more CSS image-rendering values This patch adds support for "crisp-edges", "high-quality" and "smooth" for the CSS image-rendering property. "crisp-edges" maps to nearest-neighbor scaling for <canvas> and <img> elements, while "high-quality" and "smooth" both use bilinear blending.
2022-03-06 18:17:50 +01:00
CrispEdges,
HighQuality,
Pixelated,
Smooth,
LibWeb: Add support for CSS image-rendering property Currently only "auto" and "pixelated" values are supported.
2022-02-18 12:21:27 +01:00
};
LibWeb: Support more CSS image-rendering values This patch adds support for "crisp-edges", "high-quality" and "smooth" for the CSS image-rendering property. "crisp-edges" maps to nearest-neighbor scaling for <canvas> and <img> elements, while "high-quality" and "smooth" both use bilinear blending.
2022-03-06 18:17:50 +01:00
// FIXME: Find a better place for this helper.
inline Gfx::Painter::ScalingMode to_gfx_scaling_mode(CSS::ImageRendering css_value)
{
switch (css_value) {
case CSS::ImageRendering::Auto:
case CSS::ImageRendering::HighQuality:
case CSS::ImageRendering::Smooth:
return Gfx::Painter::ScalingMode::BilinearBlend;
case CSS::ImageRendering::CrispEdges:
case CSS::ImageRendering::Pixelated:
return Gfx::Painter::ScalingMode::NearestNeighbor;
}
VERIFY_NOT_REACHED();
}
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
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: Store Repeat values directly in BackgroundRepeatStyleValue ...as opposed to storing StyleValues, which we have to later check are IdentifierStyleValues, which store identifiers that we can convert to Repeat values later. It's fewer allocations, and we can't end up with invalid values by mistake. :^)
2021-11-04 17:38:11 +00:00
constexpr StringView to_string(Repeat value)
{
switch (value) {
case Repeat::NoRepeat:
return "no-repeat"sv;
case Repeat::Repeat:
return "repeat"sv;
case Repeat::Round:
return "round"sv;
case Repeat::Space:
return "space"sv;
default:
VERIFY_NOT_REACHED();
}
}
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,
};
LibWeb: Add new property 'text-decoration-style' This patch makes the property 'text-decoration-style' known throughout all the places in LibWeb that care.
2022-01-20 20:27:55 +01:00
enum class TextDecorationStyle {
Solid,
Double,
Dotted,
Dashed,
Wavy,
};
LibWeb: Add support for the text-justify property This commit adds the text-justify property as defined in: https://drafts.csswg.org/css-text/#propdef-text-justify
2022-03-12 19:31:32 +00:00
enum class TextJustify {
Auto,
None,
InterWord,
InterCharacter,
};
LibWeb: Sort StyleValue enums alphabetically I was finding it impossible to find them.
2021-09-22 19:59:40 +01:00
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 {
LibWeb: Add parsing support for the remaining transform functions
2022-03-17 16:53:19 +01:00
Matrix,
Translate,
TranslateX,
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
TranslateY,
LibWeb: Add parsing support for the remaining transform functions
2022-03-17 16:53:19 +01:00
Scale,
ScaleX,
ScaleY,
Rotate,
Skew,
SkewX,
SkewY,
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
};
LibWeb: Add vertical-align to ComputedValues
2022-02-26 01:34:07 +01:00
enum class VerticalAlign {
Baseline,
Bottom,
Middle,
Sub,
Super,
TextBottom,
TextTop,
Top,
};
LibWeb: Pick up the CSS "visibility" property an honor it when painting
2022-03-21 15:42:57 +01:00
enum class Visibility {
Visible,
Hidden,
Collapse,
};
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,
LibWeb: Add `pointer-events: all` This is basically the same as `auto` in the spec, so let's just treat them as identical for now. Gets rid of some Discord CSS parser spam. :^)
2022-02-07 17:19:33 +00:00
All,
LibWeb: Add initial version of pointer-events CSS property
2021-10-05 19:47:13 +01:00
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:
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~StyleValue() = default;
LibHTML: Add the outline of a CSS stylesheet object graph.
2019-06-20 23:25:25 +02:00
LibHTML: Add LengthStyleValue and create those when parsing number values.
2019-07-03 07:55:22 +02:00
enum class Type {
LibWeb: Implement CSS Angle class This corresponds to `<angle>` in the grammar.
2022-02-21 17:43:30 +00:00
Angle,
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: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
BackgroundSize,
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,
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 19:56:25 +00:00
Content,
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: Implement CSS Frequency class This corresponds to `<frequency>` in the grammar.
2022-02-21 17:49:47 +00:00
Frequency,
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: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
Percentage,
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: Implement CSS Resolution class This corresponds to `<resolution>` in the grammar.
2022-02-21 17:51:01 +00:00
Resolution,
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: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
Time,
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: Add new UnresolvedStyleValue class This represents a property value that hasn't been converted to a "proper" StyleValue yet. That is, it's either a custom property's value, or a value that includes `var()` references, (or both!) since neither of those can be fully resolved at parse time.
2021-12-03 12:28:14 +00:00
Unresolved,
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 CSS Angle class This corresponds to `<angle>` in the grammar.
2022-02-21 17:43:30 +00:00
bool is_angle() const { return type() == Type::Angle; }
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: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
bool is_background_size() const { return type() == Type::BackgroundSize; }
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; }
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 19:56:25 +00:00
bool is_content() const { return type() == Type::Content; }
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: Implement CSS Frequency class This corresponds to `<frequency>` in the grammar.
2022-02-21 17:49:47 +00:00
bool is_frequency() const { return type() == Type::Frequency; }
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: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
bool is_percentage() const { return type() == Type::Percentage; }
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: Implement CSS Resolution class This corresponds to `<resolution>` in the grammar.
2022-02-21 17:51:01 +00:00
bool is_resolution() const { return type() == Type::Resolution; }
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: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
bool is_time() const { return type() == Type::Time; }
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: Add new UnresolvedStyleValue class This represents a property value that hasn't been converted to a "proper" StyleValue yet. That is, it's either a custom property's value, or a value that includes `var()` references, (or both!) since neither of those can be fully resolved at parse time.
2021-12-03 12:28:14 +00:00
bool is_unresolved() const { return type() == Type::Unresolved; }
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: Implement CSS Angle class This corresponds to `<angle>` in the grammar.
2022-02-21 17:43:30 +00:00
AngleStyleValue const& as_angle() 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
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: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
BackgroundSizeStyleValue const& as_background_size() 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;
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 19:56:25 +00:00
ContentStyleValue const& as_content() 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
FlexFlowStyleValue const& as_flex_flow() const;
FlexStyleValue const& as_flex() const;
FontStyleValue const& as_font() const;
LibWeb: Implement CSS Frequency class This corresponds to `<frequency>` in the grammar.
2022-02-21 17:49:47 +00:00
FrequencyStyleValue const& as_frequency() 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
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: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
PercentageStyleValue const& as_percentage() 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: Implement CSS Resolution class This corresponds to `<resolution>` in the grammar.
2022-02-21 17:51:01 +00:00
ResolutionStyleValue const& as_resolution() 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;
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
TimeStyleValue const& as_time() 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
TransformationStyleValue const& as_transformation() const;
LibWeb: Add new UnresolvedStyleValue class This represents a property value that hasn't been converted to a "proper" StyleValue yet. That is, it's either a custom property's value, or a value that includes `var()` references, (or both!) since neither of those can be fully resolved at parse time.
2021-12-03 12:28:14 +00:00
UnresolvedStyleValue const& as_unresolved() 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
UnsetStyleValue const& as_unset() const;
StyleValueList const& as_value_list() const;
LibWeb: Implement CSS Angle class This corresponds to `<angle>` in the grammar.
2022-02-21 17:43:30 +00:00
AngleStyleValue& as_angle() { return const_cast<AngleStyleValue&>(const_cast<StyleValue const&>(*this).as_angle()); }
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& 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: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
BackgroundSizeStyleValue& as_background_size() { return const_cast<BackgroundSizeStyleValue&>(const_cast<StyleValue const&>(*this).as_background_size()); }
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()); }
LibWeb: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 19:56:25 +00:00
ContentStyleValue& as_content() { return const_cast<ContentStyleValue&>(const_cast<StyleValue const&>(*this).as_content()); }
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
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()); }
LibWeb: Implement CSS Frequency class This corresponds to `<frequency>` in the grammar.
2022-02-21 17:49:47 +00:00
FrequencyStyleValue& as_frequency() { return const_cast<FrequencyStyleValue&>(const_cast<StyleValue const&>(*this).as_frequency()); }
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
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: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
PercentageStyleValue& as_percentage() { return const_cast<PercentageStyleValue&>(const_cast<StyleValue const&>(*this).as_percentage()); }
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: Implement CSS Resolution class This corresponds to `<resolution>` in the grammar.
2022-02-21 17:51:01 +00:00
ResolutionStyleValue& as_resolution() { return const_cast<ResolutionStyleValue&>(const_cast<StyleValue const&>(*this).as_resolution()); }
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()); }
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
TimeStyleValue& as_time() { return const_cast<TimeStyleValue&>(const_cast<StyleValue const&>(*this).as_time()); }
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
TransformationStyleValue& as_transformation() { return const_cast<TransformationStyleValue&>(const_cast<StyleValue const&>(*this).as_transformation()); }
LibWeb: Add new UnresolvedStyleValue class This represents a property value that hasn't been converted to a "proper" StyleValue yet. That is, it's either a custom property's value, or a value that includes `var()` references, (or both!) since neither of those can be fully resolved at parse time.
2021-12-03 12:28:14 +00:00
UnresolvedStyleValue& as_unresolved() { return const_cast<UnresolvedStyleValue&>(const_cast<StyleValue const&>(*this).as_unresolved()); }
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
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 absolutization non-destructive Instead of awkwardly visiting and mutating lengths inside StyleValues, we now simply create a new StyleValue instead. This fixes an issue where inherited relative lengths could get absolutized using a parent as reference, and then not having the correct values when used in a child context.
2022-02-26 01:35:25 +01:00
virtual NonnullRefPtr<StyleValue> absolutized(Gfx::IntRect const& viewport_rect, Gfx::FontMetrics const& font_metrics, float font_size, float root_font_size) const;
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; }
LibWeb: VERIFY when getting a length from an invalid StyleValue
2022-02-18 14:48:01 +00:00
virtual Length to_length() const { VERIFY_NOT_REACHED(); }
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();
}
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: Implement CSS Angle class This corresponds to `<angle>` in the grammar.
2022-02-21 17:43:30 +00:00
class AngleStyleValue : public StyleValue {
public:
static NonnullRefPtr<AngleStyleValue> create(Angle angle)
{
return adopt_ref(*new AngleStyleValue(move(angle)));
}
virtual ~AngleStyleValue() override { }
Angle const& angle() const { return m_angle; }
virtual String to_string() const override { return m_angle.to_string(); }
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
return m_angle == static_cast<AngleStyleValue const&>(other).m_angle;
}
private:
explicit AngleStyleValue(Angle angle)
: StyleValue(Type::Angle)
, m_angle(move(angle))
{
}
Angle m_angle;
};
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,
LibWeb: Add `background-position` to `background` property This required modifying the background-parsing code to use a TokenStream, but that turned out to be pretty simple.
2021-11-03 16:30:55 +00:00
NonnullRefPtr<StyleValue> position,
LibWeb: Parse background-size as part of background shorthand
2021-11-05 16:15:02 +00:00
NonnullRefPtr<StyleValue> size,
LibWeb: Use BackgroundRepeatStyleValue in `background` shorthand This is step 1 in removing the two `background-repeat-x/y` pseudo-properties. Since adding the concept of compound StyleValues, we don't need `background-repeat` to be split in two any more.
2021-11-04 15:56:10 +00:00
NonnullRefPtr<StyleValue> repeat,
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 20:28:34 +00:00
NonnullRefPtr<StyleValue> attachment,
NonnullRefPtr<StyleValue> origin,
NonnullRefPtr<StyleValue> clip)
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 background-size as part of background shorthand
2021-11-05 16:15:02 +00:00
return adopt_ref(*new BackgroundStyleValue(color, image, position, size, repeat, attachment, origin, clip));
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~BackgroundStyleValue() override = default;
LibWeb: Add CustomStyleValue This extends StyleValue and can hold the identifier of the custom property.
2021-05-24 22:46:19 +02:00
LibWeb: Bring BackgroundStyleValue::to_string() to spec This now outputs valid CSS representing the background, instead of confusing debug info. We can't guarantee that all the longhands have the same number of values, since while that's always the case when parsing, we also create BackgroundStyleValues when producing the resolved style, which just combines the longhands together.
2021-11-11 11:47:31 +00:00
size_t layer_count() const { return m_layer_count; }
LibWeb: Parse `background-attachment` as part of `background` property
2021-11-03 17:46:45 +00:00
NonnullRefPtr<StyleValue> attachment() const { return m_attachment; }
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 20:28:34 +00:00
NonnullRefPtr<StyleValue> clip() const { return m_clip; }
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; }
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 20:28:34 +00:00
NonnullRefPtr<StyleValue> origin() const { return m_origin; }
LibWeb: Add `background-position` to `background` property This required modifying the background-parsing code to use a TokenStream, but that turned out to be pretty simple.
2021-11-03 16:30:55 +00:00
NonnullRefPtr<StyleValue> position() const { return m_position; }
LibWeb: Use BackgroundRepeatStyleValue in `background` shorthand This is step 1 in removing the two `background-repeat-x/y` pseudo-properties. Since adding the concept of compound StyleValues, we don't need `background-repeat` to be split in two any more.
2021-11-04 15:56:10 +00:00
NonnullRefPtr<StyleValue> repeat() const { return m_repeat; }
LibWeb: Parse background-size as part of background shorthand
2021-11-05 16:15:02 +00:00
NonnullRefPtr<StyleValue> size() const { return m_size; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
LibWeb: Bring BackgroundStyleValue::to_string() to spec This now outputs valid CSS representing the background, instead of confusing debug info. We can't guarantee that all the longhands have the same number of values, since while that's always the case when parsing, we also create BackgroundStyleValues when producing the resolved style, which just combines the longhands together.
2021-11-11 11:47:31 +00:00
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
private:
BackgroundStyleValue(
NonnullRefPtr<StyleValue> color,
NonnullRefPtr<StyleValue> image,
LibWeb: Add `background-position` to `background` property This required modifying the background-parsing code to use a TokenStream, but that turned out to be pretty simple.
2021-11-03 16:30:55 +00:00
NonnullRefPtr<StyleValue> position,
LibWeb: Parse background-size as part of background shorthand
2021-11-05 16:15:02 +00:00
NonnullRefPtr<StyleValue> size,
LibWeb: Use BackgroundRepeatStyleValue in `background` shorthand This is step 1 in removing the two `background-repeat-x/y` pseudo-properties. Since adding the concept of compound StyleValues, we don't need `background-repeat` to be split in two any more.
2021-11-04 15:56:10 +00:00
NonnullRefPtr<StyleValue> repeat,
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 20:28:34 +00:00
NonnullRefPtr<StyleValue> attachment,
NonnullRefPtr<StyleValue> origin,
LibWeb: Bring BackgroundStyleValue::to_string() to spec This now outputs valid CSS representing the background, instead of confusing debug info. We can't guarantee that all the longhands have the same number of values, since while that's always the case when parsing, we also create BackgroundStyleValues when producing the resolved style, which just combines the longhands together.
2021-11-11 11:47:31 +00:00
NonnullRefPtr<StyleValue> clip);
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
NonnullRefPtr<StyleValue> m_color;
NonnullRefPtr<StyleValue> m_image;
LibWeb: Add `background-position` to `background` property This required modifying the background-parsing code to use a TokenStream, but that turned out to be pretty simple.
2021-11-03 16:30:55 +00:00
NonnullRefPtr<StyleValue> m_position;
LibWeb: Parse background-size as part of background shorthand
2021-11-05 16:15:02 +00:00
NonnullRefPtr<StyleValue> m_size;
LibWeb: Use BackgroundRepeatStyleValue in `background` shorthand This is step 1 in removing the two `background-repeat-x/y` pseudo-properties. Since adding the concept of compound StyleValues, we don't need `background-repeat` to be split in two any more.
2021-11-04 15:56:10 +00:00
NonnullRefPtr<StyleValue> m_repeat;
LibWeb: Parse `background-attachment` as part of `background` property
2021-11-03 17:46:45 +00:00
NonnullRefPtr<StyleValue> m_attachment;
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 20:28:34 +00:00
NonnullRefPtr<StyleValue> m_origin;
NonnullRefPtr<StyleValue> m_clip;
LibWeb: Bring BackgroundStyleValue::to_string() to spec This now outputs valid CSS representing the background, instead of confusing debug info. We can't guarantee that all the longhands have the same number of values, since while that's always the case when parsing, we also create BackgroundStyleValues when producing the resolved style, which just combines the longhands together.
2021-11-11 11:47:31 +00:00
size_t m_layer_count;
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
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: Store Repeat values directly in BackgroundRepeatStyleValue ...as opposed to storing StyleValues, which we have to later check are IdentifierStyleValues, which store identifiers that we can convert to Repeat values later. It's fewer allocations, and we can't end up with invalid values by mistake. :^)
2021-11-04 17:38:11 +00:00
static NonnullRefPtr<BackgroundRepeatStyleValue> create(Repeat repeat_x, Repeat 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
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~BackgroundRepeatStyleValue() override = default;
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
LibWeb: Store Repeat values directly in BackgroundRepeatStyleValue ...as opposed to storing StyleValues, which we have to later check are IdentifierStyleValues, which store identifiers that we can convert to Repeat values later. It's fewer allocations, and we can't end up with invalid values by mistake. :^)
2021-11-04 17:38:11 +00:00
Repeat repeat_x() const { return m_repeat_x; }
Repeat 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: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
LibWeb: Add parsing for NumericStyleValue This StyleValue can hold an arbitrary float value.
2021-06-03 21:59:41 +02:00
LibWeb: Add equals() override to a bunch of StyleValue subclasses The less we fall back to string-based equality testing, the better.
2022-03-14 00:23:58 +01:00
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
auto& other_value = static_cast<BackgroundRepeatStyleValue const&>(other);
return m_repeat_x == other_value.m_repeat_x && m_repeat_y == other_value.m_repeat_y;
}
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
private:
LibWeb: Store Repeat values directly in BackgroundRepeatStyleValue ...as opposed to storing StyleValues, which we have to later check are IdentifierStyleValues, which store identifiers that we can convert to Repeat values later. It's fewer allocations, and we can't end up with invalid values by mistake. :^)
2021-11-04 17:38:11 +00:00
BackgroundRepeatStyleValue(Repeat repeat_x, Repeat repeat_y)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
: 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
}
LibWeb: Store Repeat values directly in BackgroundRepeatStyleValue ...as opposed to storing StyleValues, which we have to later check are IdentifierStyleValues, which store identifiers that we can convert to Repeat values later. It's fewer allocations, and we can't end up with invalid values by mistake. :^)
2021-11-04 17:38:11 +00:00
Repeat m_repeat_x;
Repeat m_repeat_y;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
};
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
// NOTE: This is not used for identifier sizes, like `cover` and `contain`.
class BackgroundSizeStyleValue final : public StyleValue {
public:
LibWeb: Convert background-size from Length to LengthPercentage Checking these for `auto` is awkward, but separating that will come later. :^)
2022-01-16 20:24:35 +00:00
static NonnullRefPtr<BackgroundSizeStyleValue> create(LengthPercentage size_x, LengthPercentage size_y)
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
{
return adopt_ref(*new BackgroundSizeStyleValue(size_x, size_y));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~BackgroundSizeStyleValue() override = default;
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
LibWeb: Convert background-size from Length to LengthPercentage Checking these for `auto` is awkward, but separating that will come later. :^)
2022-01-16 20:24:35 +00:00
LengthPercentage size_x() const { return m_size_x; }
LengthPercentage size_y() const { return m_size_y; }
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
LibWeb: Add equals() override to a bunch of StyleValue subclasses The less we fall back to string-based equality testing, the better.
2022-03-14 00:23:58 +01:00
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
auto& other_value = static_cast<BackgroundSizeStyleValue const&>(other);
return m_size_x == other_value.m_size_x && m_size_y == other_value.m_size_y;
}
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
private:
LibWeb: Convert background-size from Length to LengthPercentage Checking these for `auto` is awkward, but separating that will come later. :^)
2022-01-16 20:24:35 +00:00
BackgroundSizeStyleValue(LengthPercentage size_x, LengthPercentage size_y)
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
: StyleValue(Type::BackgroundSize)
, m_size_x(size_x)
, m_size_y(size_y)
{
}
LibWeb: Convert background-size from Length to LengthPercentage Checking these for `auto` is awkward, but separating that will come later. :^)
2022-01-16 20:24:35 +00:00
LengthPercentage m_size_x;
LengthPercentage m_size_y;
LibWeb: Add BackgroundSizeStyleValue There's nothing really background-size-specific about this, but since there is no `<size>` value type defined in the CSS spec at this time, and background-size is the only user of it, I think this name makes more sense. But I'm not 100% convinced.
2021-11-05 12:18:23 +00:00
};
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~BorderStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
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; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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: Convert border-radii from Length to LengthPercentage :^) The visit_lengths() code is a bit awkward but we'll clean that up later.
2022-01-14 20:49:06 +00:00
static NonnullRefPtr<BorderRadiusStyleValue> create(LengthPercentage const& horizontal_radius, LengthPercentage 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
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~BorderRadiusStyleValue() override = default;
LibHTML: Implement enough of the CSS parser to parse the default stylesheet.
2019-06-22 21:48:21 +02:00
LibWeb: Convert border-radii from Length to LengthPercentage :^) The visit_lengths() code is a bit awkward but we'll clean that up later.
2022-01-14 20:49:06 +00:00
LengthPercentage const& horizontal_radius() const { return m_horizontal_radius; }
LengthPercentage const& vertical_radius() const { return m_vertical_radius; }
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool is_elliptical() const { return m_is_elliptical; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00: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
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: Convert border-radii from Length to LengthPercentage :^) The visit_lengths() code is a bit awkward but we'll clean that up later.
2022-01-14 20:49:06 +00:00
BorderRadiusStyleValue(LengthPercentage const& horizontal_radius, LengthPercentage const& vertical_radius)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
: 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: Make StyleValue absolutization non-destructive Instead of awkwardly visiting and mutating lengths inside StyleValues, we now simply create a new StyleValue instead. This fixes an issue where inherited relative lengths could get absolutized using a parent as reference, and then not having the correct values when used in a child context.
2022-02-26 01:35:25 +01:00
virtual NonnullRefPtr<StyleValue> absolutized(Gfx::IntRect const& viewport_rect, Gfx::FontMetrics const& font_metrics, float font_size, float root_font_size) const override;
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
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
bool m_is_elliptical;
LibWeb: Convert border-radii from Length to LengthPercentage :^) The visit_lengths() code is a bit awkward but we'll clean that up later.
2022-01-14 20:49:06 +00:00
LengthPercentage m_horizontal_radius;
LengthPercentage 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:
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
static NonnullRefPtr<BoxShadowStyleValue>
create(Color const& color, Length const& offset_x, Length const& offset_y, Length const& blur_radius, Length const& spread_distance, BoxShadowPlacement placement)
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
{
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
return adopt_ref(*new BoxShadowStyleValue(color, offset_x, offset_y, blur_radius, spread_distance, placement));
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
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~BoxShadowStyleValue() override = default;
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
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
Color const& color() const { return m_color; }
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 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; }
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
Length const& spread_distance() const { return m_spread_distance; }
BoxShadowPlacement placement() const { return m_placement; }
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
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
LibWeb: Add equals() override to a bunch of StyleValue subclasses The less we fall back to string-based equality testing, the better.
2022-03-14 00:23:58 +01:00
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
auto& other_value = static_cast<BoxShadowStyleValue const&>(other);
return m_color == other_value.m_color
&& m_offset_x == other_value.m_offset_x
&& m_offset_y == other_value.m_offset_y
&& m_blur_radius == other_value.m_blur_radius
&& m_spread_distance == other_value.m_spread_distance
&& m_placement == other_value.m_placement;
}
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
private:
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
explicit BoxShadowStyleValue(Color const& color, Length const& offset_x, Length const& offset_y, Length const& blur_radius, Length const& spread_distance, BoxShadowPlacement placement)
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
: StyleValue(Type::BoxShadow)
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
, m_color(color)
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
, m_offset_x(offset_x)
, m_offset_y(offset_y)
, m_blur_radius(blur_radius)
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
, m_spread_distance(spread_distance)
, m_placement(placement)
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
{
}
LibWeb: Make StyleValue absolutization non-destructive Instead of awkwardly visiting and mutating lengths inside StyleValues, we now simply create a new StyleValue instead. This fixes an issue where inherited relative lengths could get absolutized using a parent as reference, and then not having the correct values when used in a child context.
2022-02-26 01:35:25 +01:00
virtual NonnullRefPtr<StyleValue> absolutized(Gfx::IntRect const& viewport_rect, Gfx::FontMetrics const& font_metrics, float font_size, float root_font_size) const override;
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
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
Color m_color;
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;
LibWeb: Parse spread-distance and `inset` parts of box-shadow We do not actually use these when rendering the shadow yet.
2022-02-08 13:47:11 +00:00
Length m_spread_distance;
BoxShadowPlacement m_placement;
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
};
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:
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
enum class ResolvedType {
Angle,
Frequency,
Integer,
Length,
Number,
Percentage,
Time,
};
LibWeb: Implement CalculationResult type for calc() results calc() sub-expressions can return a variety of different types, which then can be combined using the basic arithmetic operators. This class should make that easier to deal with, instead of having to handle all the possible combinations at each call site. :^) We take the Layout::Node as a pointer not a reference, since later we'll need to call these functions when resolving to `<number>` or `<integer>` which don't use those, and we don't want to force users to pass them in unnecessarily.
2022-01-27 14:50:31 +00:00
enum class SumOperation {
Add,
Subtract,
};
enum class ProductOperation {
Multiply,
Divide,
};
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
using PercentageBasis = Variant<Empty, Angle, Frequency, Length, Time>;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
LibWeb: Implement CalculationResult type for calc() results calc() sub-expressions can return a variety of different types, which then can be combined using the basic arithmetic operators. This class should make that easier to deal with, instead of having to handle all the possible combinations at each call site. :^) We take the Layout::Node as a pointer not a reference, since later we'll need to call these functions when resolving to `<number>` or `<integer>` which don't use those, and we don't want to force users to pass them in unnecessarily.
2022-01-27 14:50:31 +00:00
class CalculationResult {
public:
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
using Value = Variant<Number, Angle, Frequency, Length, Percentage, Time>;
CalculationResult(Value value)
LibWeb: Implement CalculationResult type for calc() results calc() sub-expressions can return a variety of different types, which then can be combined using the basic arithmetic operators. This class should make that easier to deal with, instead of having to handle all the possible combinations at each call site. :^) We take the Layout::Node as a pointer not a reference, since later we'll need to call these functions when resolving to `<number>` or `<integer>` which don't use those, and we don't want to force users to pass them in unnecessarily.
2022-01-27 14:50:31 +00:00
: m_value(move(value))
{
}
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
void add(CalculationResult const& other, Layout::Node const*, PercentageBasis const& percentage_basis);
void subtract(CalculationResult const& other, Layout::Node const*, PercentageBasis const& percentage_basis);
LibWeb: Implement CalculationResult type for calc() results calc() sub-expressions can return a variety of different types, which then can be combined using the basic arithmetic operators. This class should make that easier to deal with, instead of having to handle all the possible combinations at each call site. :^) We take the Layout::Node as a pointer not a reference, since later we'll need to call these functions when resolving to `<number>` or `<integer>` which don't use those, and we don't want to force users to pass them in unnecessarily.
2022-01-27 14:50:31 +00:00
void multiply_by(CalculationResult const& other, Layout::Node const*);
void divide_by(CalculationResult const& other, Layout::Node const*);
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
Value const& value() const { return m_value; }
LibWeb: Implement CalculationResult type for calc() results calc() sub-expressions can return a variety of different types, which then can be combined using the basic arithmetic operators. This class should make that easier to deal with, instead of having to handle all the possible combinations at each call site. :^) We take the Layout::Node as a pointer not a reference, since later we'll need to call these functions when resolving to `<number>` or `<integer>` which don't use those, and we don't want to force users to pass them in unnecessarily.
2022-01-27 14:50:31 +00:00
private:
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
void add_or_subtract_internal(SumOperation op, CalculationResult const& other, Layout::Node const*, PercentageBasis const& percentage_basis);
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
Value m_value;
LibWeb: Implement CalculationResult type for calc() results calc() sub-expressions can return a variety of different types, which then can be combined using the basic arithmetic operators. This class should make that easier to deal with, instead of having to handle all the possible combinations at each call site. :^) We take the Layout::Node as a pointer not a reference, since later we'll need to call these functions when resolving to `<number>` or `<integer>` which don't use those, and we don't want to force users to pass them in unnecessarily.
2022-01-27 14:50:31 +00:00
};
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;
struct CalcSumPartWithOperator;
struct CalcProduct;
struct CalcProductPartWithOperator;
struct CalcNumberSum;
struct CalcNumberSumPartWithOperator;
struct CalcNumberProduct;
struct CalcNumberProductPartWithOperator;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
struct CalcNumberValue {
LibWeb: Distinguish between Integer and Number calc() values
2022-02-02 12:34:32 +00:00
Variant<Number, NonnullOwnPtr<CalcNumberSum>> value;
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
};
struct CalcValue {
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
Variant<Number, Angle, Frequency, Length, Percentage, Time, NonnullOwnPtr<CalcSum>> value;
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
};
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
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;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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 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;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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 CalcProduct {
CalcValue first_calc_value;
NonnullOwnPtrVector<CalcProductPartWithOperator> zero_or_more_additional_calc_values;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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 CalcSumPartWithOperator {
LibWeb: Combine the two sets of calc() operator enums
2022-01-25 14:25:11 +00:00
CalcSumPartWithOperator(SumOperation op, NonnullOwnPtr<CalcProduct> calc_product)
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
: op(op)
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
, value(move(calc_product)) {};
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
LibWeb: Combine the two sets of calc() operator enums
2022-01-25 14:25:11 +00:00
SumOperation op;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
NonnullOwnPtr<CalcProduct> value;
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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 CalcProductPartWithOperator {
LibWeb: Combine the two sets of calc() operator enums
2022-01-25 14:25:11 +00:00
ProductOperation op;
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
Variant<CalcValue, CalcNumberValue> value;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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 CalcNumberProduct {
CalcNumberValue first_calc_number_value;
NonnullOwnPtrVector<CalcNumberProductPartWithOperator> zero_or_more_additional_calc_number_values;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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 CalcNumberProductPartWithOperator {
LibWeb: Combine the two sets of calc() operator enums
2022-01-25 14:25:11 +00:00
ProductOperation op;
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
CalcNumberValue value;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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 CalcNumberSumPartWithOperator {
LibWeb: Combine the two sets of calc() operator enums
2022-01-25 14:25:11 +00:00
CalcNumberSumPartWithOperator(SumOperation op, NonnullOwnPtr<CalcNumberProduct> calc_number_product)
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
: op(op)
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
, value(move(calc_number_product)) {};
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
LibWeb: Combine the two sets of calc() operator enums
2022-01-25 14:25:11 +00:00
SumOperation op;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
NonnullOwnPtr<CalcNumberProduct> value;
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
Optional<ResolvedType> resolved_type() const;
LibWeb: Use a Variant for calc() percentage_basis Depending on the type of the calc() expression, the percentage_basis has to be the same dimension type. Several places were already passing ` {}` for this, so let's make that an empty Variant instead of an undefined Length. :^)
2022-02-18 12:07:09 +00:00
CalculationResult resolve(Layout::Node const*, PercentageBasis const& percentage_basis) const;
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
};
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
static NonnullRefPtr<CalculatedStyleValue> create(NonnullOwnPtr<CalcSum> calc_sum, ResolvedType resolved_type)
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
{
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
return adopt_ref(*new CalculatedStyleValue(move(calc_sum), resolved_type));
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
}
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
String to_string() const override;
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
ResolvedType resolved_type() const { return m_resolved_type; }
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
NonnullOwnPtr<CalcSum> const& expression() const { return m_expression; }
LibWeb: Implement CSS Angle class This corresponds to `<angle>` in the grammar.
2022-02-21 17:43:30 +00:00
Optional<Angle> resolve_angle() const;
Optional<AnglePercentage> resolve_angle_percentage(Angle const& percentage_basis) const;
LibWeb: Implement CSS Frequency class This corresponds to `<frequency>` in the grammar.
2022-02-21 17:49:47 +00:00
Optional<Frequency> resolve_frequency() const;
Optional<FrequencyPercentage> resolve_frequency_percentage(Frequency const& percentage_basis) const;
LibWeb: Move calc()-resolution code from Length to CalculatedStyleValue The code is unchanged, just moved.
2022-01-24 17:38:29 +00:00
Optional<Length> resolve_length(Layout::Node const& layout_node) const;
LibWeb: Refactor calc() resolution logic using CalculationResult The previous static functions are now methods of their respective CalcFoo structs, but the logic has not changed, only that they work with CalculationResults instead of converting everything to floats.
2022-01-27 14:51:51 +00:00
Optional<LengthPercentage> resolve_length_percentage(Layout::Node const&, Length const& percentage_basis) const;
LibWeb: Add resolving calc() to a number/integer/percentage None of these require any outside metrics, which is nice! I believe the Values-4 spec would have us simplify them down into a single value at parse time, but that's a yak for another day.
2022-01-27 15:46:24 +00:00
Optional<Percentage> resolve_percentage() const;
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
Optional<Time> resolve_time() const;
Optional<TimePercentage> resolve_time_percentage(Time const& percentage_basis) const;
LibWeb: Add resolving calc() to a number/integer/percentage None of these require any outside metrics, which is nice! I believe the Values-4 spec would have us simplify them down into a single value at parse time, but that's a yak for another day.
2022-01-27 15:46:24 +00:00
Optional<float> resolve_number();
Optional<i64> resolve_integer();
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
private:
LibWeb: Implement CalculatedStyleValue::to_string()
2022-02-02 15:34:13 +00:00
explicit CalculatedStyleValue(NonnullOwnPtr<CalcSum> calc_sum, ResolvedType resolved_type)
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
: StyleValue(Type::Calculated)
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
, m_resolved_type(resolved_type)
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
, m_expression(move(calc_sum))
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
{
}
LibWeb: Resolve type of calc() expressions at parse-time See https://www.w3.org/TR/css-values-3/#calc-type-checking If the sub-expressions' types are incompatible, we discard the calc() as invalid. Had to do some minor rearranging/renaming of the Calc structs to make the `resolve_foo_type()` templates work too.
2022-01-25 14:45:08 +00:00
ResolvedType m_resolved_type;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
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: Cache and reuse some very common StyleValue objects Length values: auto, 0px, 1px Color values: black, white, transparent
2022-02-18 20:26:09 +01:00
static NonnullRefPtr<ColorStyleValue> create(Color color);
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~ColorStyleValue() override = default;
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~CombinedBorderRadiusStyleValue() override = default;
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
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; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
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: Parse the `content` property For now, we only understand `none`, `normal`, `<image>` and `<string>`. The various other functions and identifiers can be added later. We can *almost* use a StyleValueList for this, except it's divided into two parts - the content, and the optional "alt text". So, I've added a new StyleValue for it.
2022-02-23 19:56:25 +00:00
class ContentStyleValue final : public StyleValue {
public:
static NonnullRefPtr<ContentStyleValue> create(NonnullRefPtr<StyleValueList> content, RefPtr<StyleValueList> alt_text)
{
return adopt_ref(*new ContentStyleValue(move(content), move(alt_text)));
}
StyleValueList const& content() const { return *m_content; }
bool has_alt_text() const { return !m_alt_text.is_null(); }
StyleValueList const* alt_text() const { return m_alt_text; }
virtual String to_string() const override;
private:
ContentStyleValue(NonnullRefPtr<StyleValueList> content, RefPtr<StyleValueList> alt_text)
: StyleValue(Type::Content)
, m_content(move(content))
, m_alt_text(move(alt_text))
{
}
NonnullRefPtr<StyleValueList> m_content;
RefPtr<StyleValueList> m_alt_text;
};
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~FlexStyleValue() override = default;
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
NonnullRefPtr<StyleValue> grow() const { return m_grow; }
NonnullRefPtr<StyleValue> shrink() const { return m_shrink; }
NonnullRefPtr<StyleValue> basis() const { return m_basis; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~FlexFlowStyleValue() override = default;
LibWeb: Implement and use FlexFlowStyleValue
2021-08-05 17:19:29 +01:00
NonnullRefPtr<StyleValue> flex_direction() const { return m_flex_direction; }
NonnullRefPtr<StyleValue> flex_wrap() const { return m_flex_wrap; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
LibWeb: Implement and use FlexFlowStyleValue
2021-08-05 17:19:29 +01:00
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)); }
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~FontStyleValue() override = default;
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> 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
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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: Implement CSS Frequency class This corresponds to `<frequency>` in the grammar.
2022-02-21 17:49:47 +00:00
class FrequencyStyleValue : public StyleValue {
public:
static NonnullRefPtr<FrequencyStyleValue> create(Frequency frequency)
{
return adopt_ref(*new FrequencyStyleValue(move(frequency)));
}
virtual ~FrequencyStyleValue() override { }
Frequency const& frequency() const { return m_frequency; }
virtual String to_string() const override { return m_frequency.to_string(); }
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
return m_frequency == static_cast<FrequencyStyleValue const&>(other).m_frequency;
}
private:
explicit FrequencyStyleValue(Frequency frequency)
: StyleValue(Type::Frequency)
, m_frequency(move(frequency))
{
}
Frequency m_frequency;
};
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~IdentifierStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
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)); }
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~ImageStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00: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: 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;
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~InheritStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
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;
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~InitialStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
String to_string() const override { return "initial"; }
private:
InitialStyleValue()
: StyleValue(Type::Initial)
{
}
};
class LengthStyleValue : public StyleValue {
public:
LibWeb: Cache and reuse some very common StyleValue objects Length values: auto, 0px, 1px Color values: black, white, transparent
2022-02-18 20:26:09 +01:00
static NonnullRefPtr<LengthStyleValue> create(Length const&);
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~LengthStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +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
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: Make StyleValue absolutization non-destructive Instead of awkwardly visiting and mutating lengths inside StyleValues, we now simply create a new StyleValue instead. This fixes an issue where inherited relative lengths could get absolutized using a parent as reference, and then not having the correct values when used in a child context.
2022-02-26 01:35:25 +01:00
virtual NonnullRefPtr<StyleValue> absolutized(Gfx::IntRect const& viewport_rect, Gfx::FontMetrics const& font_metrics, float font_size, float root_font_size) 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;
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)
{
}
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~ListStyleStyleValue() override = default;
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
NonnullRefPtr<StyleValue> position() const { return m_position; }
NonnullRefPtr<StyleValue> image() const { return m_image; }
NonnullRefPtr<StyleValue> style_type() const { return m_style_type; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
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>(); }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00: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
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~OverflowStyleValue() override = default;
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
NonnullRefPtr<StyleValue> overflow_x() const { return m_overflow_x; }
NonnullRefPtr<StyleValue> overflow_y() const { return m_overflow_y; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
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: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
class PercentageStyleValue final : public StyleValue {
public:
LibWeb: Convert flex-basis to LengthPercentage The flexbox logic confuses me so regressions are possible, though our test page looks the same as before so it should be fine. Renamed FlexBasis::Length -> LengthPercentage too, for clarity.
2022-01-19 11:52:01 +00:00
static NonnullRefPtr<PercentageStyleValue> create(Percentage percentage)
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
{
return adopt_ref(*new PercentageStyleValue(move(percentage)));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~PercentageStyleValue() override = default;
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
Percentage const& percentage() const { return m_percentage; }
Percentage& percentage() { return m_percentage; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
LibWeb: Add PercentageStyleValue, and parse it This is in a slightly weird state, where Percentages are sometimes Lengths and sometimes not, which I will be cleaning up in subsequent commits, in an attempt not to change all of LibWeb in one go. :^)
2022-01-14 17:09:02 +00:00
private:
PercentageStyleValue(Percentage&& percentage)
: StyleValue(Type::Percentage)
, m_percentage(percentage)
{
}
Percentage m_percentage;
};
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
class PositionStyleValue final : public StyleValue {
public:
LibWeb: Convert background-position to LengthPercentage Not much needed changing this time, hurrah! :^)
2022-01-19 11:20:40 +00:00
static NonnullRefPtr<PositionStyleValue> create(PositionEdge edge_x, LengthPercentage const& offset_x, PositionEdge edge_y, LengthPercentage const& offset_y)
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
{
return adopt_ref(*new PositionStyleValue(edge_x, offset_x, edge_y, offset_y));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~PositionStyleValue() override = default;
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
PositionEdge edge_x() const { return m_edge_x; }
LibWeb: Convert background-position to LengthPercentage Not much needed changing this time, hurrah! :^)
2022-01-19 11:20:40 +00:00
LengthPercentage const& offset_x() const { return m_offset_x; }
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
PositionEdge edge_y() const { return m_edge_y; }
LibWeb: Convert background-position to LengthPercentage Not much needed changing this time, hurrah! :^)
2022-01-19 11:20:40 +00:00
LengthPercentage const& offset_y() const { return m_offset_y; }
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
virtual String to_string() const override;
LibWeb: Add StyleValue::equals() override for PositionStyleValue
2022-03-09 17:10:56 +01:00
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
auto const& typed_other = static_cast<PositionStyleValue const&>(other);
return m_edge_x == typed_other.m_edge_x
&& m_offset_x == typed_other.m_offset_x
&& m_edge_y == typed_other.m_edge_y
&& m_offset_y == typed_other.m_offset_y;
}
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
private:
LibWeb: Convert background-position to LengthPercentage Not much needed changing this time, hurrah! :^)
2022-01-19 11:20:40 +00:00
PositionStyleValue(PositionEdge edge_x, LengthPercentage const& offset_x, PositionEdge edge_y, LengthPercentage const& offset_y)
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
: 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;
LibWeb: Convert background-position to LengthPercentage Not much needed changing this time, hurrah! :^)
2022-01-19 11:20:40 +00:00
LengthPercentage m_offset_x;
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
PositionEdge m_edge_y;
LibWeb: Convert background-position to LengthPercentage Not much needed changing this time, hurrah! :^)
2022-01-19 11:20:40 +00:00
LengthPercentage m_offset_y;
LibWeb: Alphabetize StyleValue classes
2022-01-14 12:29:09 +00:00
};
LibWeb: Implement CSS Resolution class This corresponds to `<resolution>` in the grammar.
2022-02-21 17:51:01 +00:00
class ResolutionStyleValue : public StyleValue {
public:
static NonnullRefPtr<ResolutionStyleValue> create(Resolution resolution)
{
return adopt_ref(*new ResolutionStyleValue(move(resolution)));
}
virtual ~ResolutionStyleValue() override { }
Resolution const& resolution() const { return m_resolution; }
virtual String to_string() const override { return m_resolution.to_string(); }
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
return m_resolution == static_cast<ResolutionStyleValue const&>(other).m_resolution;
}
private:
explicit ResolutionStyleValue(Resolution resolution)
: StyleValue(Type::Resolution)
, m_resolution(move(resolution))
{
}
Resolution m_resolution;
};
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));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~StringStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
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,
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
NonnullRefPtr<StyleValue> thickness,
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
NonnullRefPtr<StyleValue> style,
NonnullRefPtr<StyleValue> color)
{
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
return adopt_ref(*new TextDecorationStyleValue(line, thickness, style, color));
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
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~TextDecorationStyleValue() override = default;
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
NonnullRefPtr<StyleValue> line() const { return m_line; }
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
NonnullRefPtr<StyleValue> thickness() const { return m_thickness; }
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
NonnullRefPtr<StyleValue> style() const { return m_style; }
NonnullRefPtr<StyleValue> color() const { return m_color; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
private:
TextDecorationStyleValue(
NonnullRefPtr<StyleValue> line,
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
NonnullRefPtr<StyleValue> thickness,
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
NonnullRefPtr<StyleValue> style,
NonnullRefPtr<StyleValue> color)
: StyleValue(Type::TextDecoration)
, m_line(line)
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
, m_thickness(thickness)
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
, m_style(style)
, m_color(color)
{
}
NonnullRefPtr<StyleValue> m_line;
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
NonnullRefPtr<StyleValue> m_thickness;
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
NonnullRefPtr<StyleValue> m_style;
NonnullRefPtr<StyleValue> m_color;
};
LibWeb: Implement CSS Time class This corresponds to `<time>` in the grammar.
2022-02-21 19:29:43 +00:00
class TimeStyleValue : public StyleValue {
public:
static NonnullRefPtr<TimeStyleValue> create(Time time)
{
return adopt_ref(*new TimeStyleValue(move(time)));
}
virtual ~TimeStyleValue() override { }
Time const& time() const { return m_time; }
virtual String to_string() const override { return m_time.to_string(); }
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
return m_time == static_cast<TimeStyleValue const&>(other).m_time;
}
private:
explicit TimeStyleValue(Time time)
: StyleValue(Type::Time)
, m_time(move(time))
{
}
Time m_time;
};
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)));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~TransformationStyleValue() override = default;
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
CSS::TransformFunction transform_function() const { return m_transform_function; }
NonnullRefPtrVector<StyleValue> values() const { return m_values; }
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
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: Add new UnresolvedStyleValue class This represents a property value that hasn't been converted to a "proper" StyleValue yet. That is, it's either a custom property's value, or a value that includes `var()` references, (or both!) since neither of those can be fully resolved at parse time.
2021-12-03 12:28:14 +00:00
class UnresolvedStyleValue final : public StyleValue {
public:
static NonnullRefPtr<UnresolvedStyleValue> create(Vector<StyleComponentValueRule>&& values, bool contains_var)
{
return adopt_ref(*new UnresolvedStyleValue(move(values), contains_var));
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~UnresolvedStyleValue() override = default;
LibWeb: Add new UnresolvedStyleValue class This represents a property value that hasn't been converted to a "proper" StyleValue yet. That is, it's either a custom property's value, or a value that includes `var()` references, (or both!) since neither of those can be fully resolved at parse time.
2021-12-03 12:28:14 +00:00
virtual String to_string() const override;
Vector<StyleComponentValueRule> const& values() const { return m_values; }
bool contains_var() const { return m_contains_var; }
private:
UnresolvedStyleValue(Vector<StyleComponentValueRule>&& values, bool contains_var)
: StyleValue(Type::Unresolved)
, m_values(move(values))
, m_contains_var(contains_var)
{
}
Vector<StyleComponentValueRule> m_values;
bool m_contains_var { false };
};
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;
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~UnsetStyleValue() override = default;
LibWeb: Alphabetically sort StyleValues The random order keeps confuzing me!
2021-09-23 16:30:40 +01:00
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:
LibWeb: Allow comma- or space-separated StyleValueLists This lets us produce valid CSS in its to_string() method, instead of always adding commas as before. :^) Also, finally added a Formatter for StyleValues.
2022-02-02 20:53:55 +00:00
enum class Separator {
Space,
Comma,
};
static NonnullRefPtr<StyleValueList> create(NonnullRefPtrVector<StyleValue>&& values, Separator separator) { return adopt_ref(*new StyleValueList(move(values), separator)); }
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
LibWeb: Bring BackgroundStyleValue::to_string() to spec This now outputs valid CSS representing the background, instead of confusing debug info. We can't guarantee that all the longhands have the same number of values, since while that's always the case when parsing, we also create BackgroundStyleValues when producing the resolved style, which just combines the longhands together.
2021-11-11 11:47:31 +00:00
size_t size() const { return m_values.size(); }
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
NonnullRefPtrVector<StyleValue> const& values() const { return m_values; }
LibWeb: Bring BackgroundStyleValue::to_string() to spec This now outputs valid CSS representing the background, instead of confusing debug info. We can't guarantee that all the longhands have the same number of values, since while that's always the case when parsing, we also create BackgroundStyleValues when producing the resolved style, which just combines the longhands together.
2021-11-11 11:47:31 +00:00
NonnullRefPtr<StyleValue> value_at(size_t i, bool allow_loop) const
{
if (allow_loop)
return m_values[i % size()];
return m_values[i];
}
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
LibWeb: Move non-trivial StyleValue to_string() methods to cpp file Many of these will need to change in the future in order to include features we don't yet support, and touching StyleValue.h is a great way to have to wait for all of LibWeb to rebuild. I'm hoping this saves me time in the long run. :^)
2022-02-02 20:39:04 +00:00
virtual String to_string() const override;
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
LibWeb: Add equals() override to a bunch of StyleValue subclasses The less we fall back to string-based equality testing, the better.
2022-03-14 00:23:58 +01:00
virtual bool equals(StyleValue const& other) const override
{
if (type() != other.type())
return false;
auto& other_value = static_cast<StyleValueList const&>(other);
if (m_separator != other_value.m_separator)
return false;
if (m_values.size() != other_value.m_values.size())
return false;
for (size_t i = 0; i < m_values.size(); ++i) {
if (!m_values[i].equals(other_value.m_values[i]))
return false;
}
return true;
}
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
private:
LibWeb: Allow comma- or space-separated StyleValueLists This lets us produce valid CSS in its to_string() method, instead of always adding commas as before. :^) Also, finally added a Formatter for StyleValues.
2022-02-02 20:53:55 +00:00
StyleValueList(NonnullRefPtrVector<StyleValue>&& values, Separator separator)
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
: StyleValue(Type::ValueList)
LibWeb: Allow comma- or space-separated StyleValueLists This lets us produce valid CSS in its to_string() method, instead of always adding commas as before. :^) Also, finally added a Formatter for StyleValues.
2022-02-02 20:53:55 +00:00
, m_separator(separator)
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
, m_values(move(values))
{
}
LibWeb: Allow comma- or space-separated StyleValueLists This lets us produce valid CSS in its to_string() method, instead of always adding commas as before. :^) Also, finally added a Formatter for StyleValues.
2022-02-02 20:53:55 +00:00
Separator m_separator;
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
NonnullRefPtrVector<StyleValue> m_values;
};
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
LibWeb: Allow comma- or space-separated StyleValueLists This lets us produce valid CSS in its to_string() method, instead of always adding commas as before. :^) Also, finally added a Formatter for StyleValues.
2022-02-02 20:53:55 +00:00
template<>
struct AK::Formatter<Web::CSS::StyleValue> : Formatter<StringView> {
ErrorOr<void> format(FormatBuilder& builder, Web::CSS::StyleValue const& style_value)
{
return Formatter<StringView>::format(builder, style_value.to_string());
}
};
Reference in a new issue Copy permalink