Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/CSS/StyleComputer.cpp

1494 lines
65 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
/*
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
* Copyright (c) 2018-2022, Andreas Kling <kling@serenityos.org>
LibWeb: Create base class CSSRule for all CSS rules This is a foundation for handling other ("at") CSS rules.
2021-02-21 13:45:26 +02:00
* Copyright (c) 2021, the SerenityOS developers.
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +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
*/
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
#include <AK/Debug.h>
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
#include <AK/Error.h>
LibWeb: Handle <absolute-size> values in the `font-size` CSS property
2022-11-30 16:17:57 +01:00
#include <AK/HashMap.h>
LibWeb: Apply style rules in order of specificity (kinda) We now sort the matched rules by the specificity of the first selector in them. This is not perfect, since a rule can have multiple selectors, but it is a nice chin-related progression on ACID2. :^)
2020-06-10 16:41:30 +02:00
#include <AK/QuickSort.h>
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
#include <AK/TemporaryChange.h>
LibGfx: Move other font-related files to LibGfx/Font/
2022-04-09 09:28:38 +02:00
#include <LibGfx/Font/Font.h>
#include <LibGfx/Font/FontDatabase.h>
#include <LibGfx/Font/FontStyleMapping.h>
LibGfx: Rename TTF/TrueType to OpenType OpenType is the backwards-compatible successor to TrueType, and the format we're actually parsing in LibGfx. So let's call it that.
2022-12-19 12:26:27 +01:00
#include <LibGfx/Font/OpenType/Font.h>
LibGfx: Move ScaledFont and new base class VectorFont out of TTF
2022-04-09 10:14:58 +02:00
#include <LibGfx/Font/ScaledFont.h>
LibWeb: Migrate SC::FontLoader from TTF::Font to Gfx::VectorFont
2022-04-09 11:18:46 +02:00
#include <LibGfx/Font/VectorFont.h>
LibWeb: Support WOFF in font-face
2022-04-09 21:34:58 +02:00
#include <LibGfx/Font/WOFF/Font.h>
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
#include <LibWeb/CSS/CSSFontFaceRule.h>
LibWeb: Rename StyleRule => CSSStyleRule This matches the CSSOM specification.
2021-03-07 15:00:02 +01:00
#include <LibWeb/CSS/CSSStyleRule.h>
LibWeb: Handle ValueListStyleValues in StyleResolver This implements a lot of cases, but not all of them. The following need more infrastructure first: - Flex - FlexFlow - Background - BackgroundImage - BackgroundRepeat - ListStyle and parts - Font Also, colors are not parsed correctly. This will be handled next.
2021-07-14 19:57:02 +01:00
#include <LibWeb/CSS/Parser/Parser.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/SelectorEngine.h>
LibWeb: Rename CSS::StyleResolver => StyleComputer Resolved style is a spec concept that refers to the weird mix of computed style and used style reflected by getComputedStyle(). The purpose of this class is to produce the *computed* style for a given element, so let's call it StyleComputer.
2021-09-24 13:49:57 +02:00
#include <LibWeb/CSS/StyleComputer.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/StyleSheet.h>
#include <LibWeb/DOM/Document.h>
#include <LibWeb/DOM/Element.h>
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
#include <LibWeb/FontCache.h>
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
#include <LibWeb/HTML/HTMLHtmlElement.h>
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
#include <LibWeb/Loader/ResourceLoader.h>
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
#include <LibWeb/Platform/FontPlugin.h>
LibHTML: Implement some very simple selector matching. We walk the entire DOM and check all selectors against all elements. Only id, class and tag name are checked right now. There's no ancestor stack or compound selectors. All in good time :^)
2019-06-27 20:40:21 +02:00
#include <stdio.h>
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
namespace Web::CSS {
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Rename CSS::StyleResolver => StyleComputer Resolved style is a spec concept that refers to the weird mix of computed style and used style reflected by getComputedStyle(). The purpose of this class is to produce the *computed* style for a given element, so let's call it StyleComputer.
2021-09-24 13:49:57 +02:00
StyleComputer::StyleComputer(DOM::Document& document)
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
: m_document(document)
{
}
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
StyleComputer::~StyleComputer() = default;
class StyleComputer::FontLoader : public ResourceClient {
public:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
explicit FontLoader(StyleComputer& style_computer, DeprecatedFlyString family_name, AK::URL url)
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
: m_style_computer(style_computer)
, m_family_name(move(family_name))
{
LoadRequest request;
request.set_url(move(url));
set_resource(ResourceLoader::the().load_resource(Resource::Type::Generic, request));
}
virtual ~FontLoader() override { }
virtual void resource_did_load() override
{
LibWeb: Support WOFF in font-face
2022-04-09 21:34:58 +02:00
auto result = try_load_font();
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
if (result.is_error())
return;
LibWeb: Migrate SC::FontLoader from TTF::Font to Gfx::VectorFont
2022-04-09 11:18:46 +02:00
m_vector_font = result.release_value();
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
m_style_computer.did_load_font(m_family_name);
}
virtual void resource_did_fail() override
{
}
RefPtr<Gfx::Font> font_with_point_size(float point_size) const
{
LibWeb: Migrate SC::FontLoader from TTF::Font to Gfx::VectorFont
2022-04-09 11:18:46 +02:00
if (!m_vector_font)
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
return nullptr;
LibWeb: Cache scaled web fonts instead of recreating them every time Previously, we would create a new Gfx::ScaledFont whenever we needed one for an element's computed style. This worked fine on Acid3 since the use of web fonts was extremely limited. In the wild, web fonts obviously get used a lot more, so let's have a per-point-size font cache for them.
2022-04-10 12:32:16 +02:00
if (auto it = m_cached_fonts.find(point_size); it != m_cached_fonts.end())
return it->value;
// FIXME: It might be nicer to have a global cap on the number of fonts we cache
// instead of doing it at the per-font level like this.
constexpr size_t max_cached_font_size_count = 64;
if (m_cached_fonts.size() > max_cached_font_size_count)
m_cached_fonts.remove(m_cached_fonts.begin());
auto font = adopt_ref(*new Gfx::ScaledFont(*m_vector_font, point_size, point_size));
m_cached_fonts.set(point_size, font);
return font;
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
}
private:
LibWeb: Support WOFF in font-face
2022-04-09 21:34:58 +02:00
ErrorOr<NonnullRefPtr<Gfx::VectorFont>> try_load_font()
{
// FIXME: This could maybe use the format() provided in @font-face as well, since often the mime type is just application/octet-stream and we have to try every format
auto mime_type = resource()->mime_type();
if (mime_type == "font/ttf"sv || mime_type == "application/x-font-ttf"sv)
LibGfx: Rename TTF/TrueType to OpenType OpenType is the backwards-compatible successor to TrueType, and the format we're actually parsing in LibGfx. So let's call it that.
2022-12-19 12:26:27 +01:00
return TRY(OpenType::Font::try_load_from_externally_owned_memory(resource()->encoded_data()));
LibWeb: Support WOFF in font-face
2022-04-09 21:34:58 +02:00
if (mime_type == "font/woff"sv)
return TRY(WOFF::Font::try_load_from_externally_owned_memory(resource()->encoded_data()));
LibGfx: Rename TTF/TrueType to OpenType OpenType is the backwards-compatible successor to TrueType, and the format we're actually parsing in LibGfx. So let's call it that.
2022-12-19 12:26:27 +01:00
auto ttf = OpenType::Font::try_load_from_externally_owned_memory(resource()->encoded_data());
LibWeb: Support WOFF in font-face
2022-04-09 21:34:58 +02:00
if (!ttf.is_error())
return ttf.release_value();
auto woff = WOFF::Font::try_load_from_externally_owned_memory(resource()->encoded_data());
if (!woff.is_error())
return woff.release_value();
return ttf.release_error();
}
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
StyleComputer& m_style_computer;
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString m_family_name;
LibWeb: Migrate SC::FontLoader from TTF::Font to Gfx::VectorFont
2022-04-09 11:18:46 +02:00
RefPtr<Gfx::VectorFont> m_vector_font;
LibWeb: Cache scaled web fonts instead of recreating them every time Previously, we would create a new Gfx::ScaledFont whenever we needed one for an element's computed style. This worked fine on Acid3 since the use of web fonts was extremely limited. In the wild, web fonts obviously get used a lot more, so let's have a per-point-size font cache for them.
2022-04-10 12:32:16 +02:00
HashMap<float, NonnullRefPtr<Gfx::ScaledFont>> mutable m_cached_fonts;
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
};
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
static CSSStyleSheet& default_stylesheet()
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
{
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
static JS::Handle<CSSStyleSheet> sheet;
if (!sheet.cell()) {
LibWeb: Convert StyleResolver.{h,cpp} to east const
2021-07-14 16:56:11 +01:00
extern char const default_stylesheet_source[];
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
DeprecatedString css = default_stylesheet_source;
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
sheet = JS::make_handle(parse_css_stylesheet(CSS::Parser::ParsingContext(), css));
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
}
return *sheet;
}
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
static CSSStyleSheet& quirks_mode_stylesheet()
LibWeb: Add a separate UA style sheet for documents in quirks mode We need to make some additional tweaks to the default UA style when displaying documents in quirks mode.
2020-09-24 10:33:33 +02:00
{
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
static JS::Handle<CSSStyleSheet> sheet;
if (!sheet.cell()) {
LibWeb: Convert StyleResolver.{h,cpp} to east const
2021-07-14 16:56:11 +01:00
extern char const quirks_mode_stylesheet_source[];
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
DeprecatedString css = quirks_mode_stylesheet_source;
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
sheet = JS::make_handle(parse_css_stylesheet(CSS::Parser::ParsingContext(), css));
LibWeb: Add a separate UA style sheet for documents in quirks mode We need to make some additional tweaks to the default UA style when displaying documents in quirks mode.
2020-09-24 10:33:33 +02:00
}
return *sheet;
}
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
template<typename Callback>
LibWeb: Rename CSS::StyleResolver => StyleComputer Resolved style is a spec concept that refers to the weird mix of computed style and used style reflected by getComputedStyle(). The purpose of this class is to produce the *computed* style for a given element, so let's call it StyleComputer.
2021-09-24 13:49:57 +02:00
void StyleComputer::for_each_stylesheet(CascadeOrigin cascade_origin, Callback callback) const
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
{
LibWeb: Remove unused CascadeOrigin::Any This was an ad-hoc concept from before we implemented the CSS cascade.
2022-02-11 12:08:27 +01:00
if (cascade_origin == CascadeOrigin::UserAgent) {
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
callback(default_stylesheet());
if (document().in_quirks_mode())
callback(quirks_mode_stylesheet());
}
LibWeb: Remove unused CascadeOrigin::Any This was an ad-hoc concept from before we implemented the CSS cascade.
2022-02-11 12:08:27 +01:00
if (cascade_origin == CascadeOrigin::Author) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
for (auto const& sheet : document().style_sheets().sheets()) {
LibWeb: Keep CSS sheets sorted in document tree order This ensures that style is applied consistently, even if the document has external CSS resources that don't always arrive in the same order.
2022-09-09 11:08:56 +02:00
callback(*sheet);
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
}
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
}
}
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
Vector<MatchingRule> StyleComputer::collect_matching_rules(DOM::Element const& element, CascadeOrigin cascade_origin, Optional<CSS::Selector::PseudoElement> pseudo_element) const
LibHTML: Implement some very simple selector matching. We walk the entire DOM and check all selectors against all elements. Only id, class and tag name are checked right now. There's no ancestor stack or compound selectors. All in good time :^)
2019-06-27 20:40:21 +02:00
{
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
if (cascade_origin == CascadeOrigin::Author) {
Vector<MatchingRule> rules_to_run;
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
if (pseudo_element.has_value()) {
if (auto it = m_rule_cache->rules_by_pseudo_element.find(pseudo_element.value()); it != m_rule_cache->rules_by_pseudo_element.end())
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
rules_to_run.extend(it->value);
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
} else {
for (auto const& class_name : element.class_names()) {
if (auto it = m_rule_cache->rules_by_class.find(class_name); it != m_rule_cache->rules_by_class.end())
rules_to_run.extend(it->value);
}
if (auto id = element.get_attribute(HTML::AttributeNames::id); !id.is_null()) {
if (auto it = m_rule_cache->rules_by_id.find(id); it != m_rule_cache->rules_by_id.end())
rules_to_run.extend(it->value);
}
if (auto it = m_rule_cache->rules_by_tag_name.find(element.local_name()); it != m_rule_cache->rules_by_tag_name.end())
LibWeb: Add "ID" buckets to StyleComputer::RuleCache We can skip rules that require a specific ID when matching against any element that doesn't have that ID.
2022-02-10 18:50:58 +01:00
rules_to_run.extend(it->value);
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
rules_to_run.extend(m_rule_cache->other_rules);
LibWeb: Add "ID" buckets to StyleComputer::RuleCache We can skip rules that require a specific ID when matching against any element that doesn't have that ID.
2022-02-10 18:50:58 +01:00
}
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
Vector<MatchingRule> matching_rules;
LibWeb: Add a Vector::ensure_capacity() in collect_matching_rules() Avoid some incremental Vector growth by pre-allocating enough capacity to cover the case where every single selector matches an element.
2022-03-13 19:55:08 +01:00
matching_rules.ensure_capacity(rules_to_run.size());
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
for (auto const& rule_to_run : rules_to_run) {
auto const& selector = rule_to_run.rule->selectors()[rule_to_run.selector_index];
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
if (SelectorEngine::matches(selector, element, pseudo_element))
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
matching_rules.append(rule_to_run);
}
return matching_rules;
}
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
Vector<MatchingRule> matching_rules;
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
size_t style_sheet_index = 0;
LibWeb: Rename a CascadeOrigin parameter in StyleComputer
2022-02-09 20:06:16 +01:00
for_each_stylesheet(cascade_origin, [&](auto& sheet) {
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
size_t rule_index = 0;
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
sheet.for_each_effective_style_rule([&](auto const& rule) {
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
size_t selector_index = 0;
LibHTML: Implement some very simple selector matching. We walk the entire DOM and check all selectors against all elements. Only id, class and tag name are checked right now. There's no ancestor stack or compound selectors. All in good time :^)
2019-06-27 20:40:21 +02:00
for (auto& selector : rule.selectors()) {
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
if (SelectorEngine::matches(selector, element, pseudo_element)) {
LibWeb: Make CSSRule and all its subclasses GC-allocated
2022-08-07 15:46:44 +02:00
matching_rules.append({ &rule, style_sheet_index, rule_index, selector_index, selector.specificity() });
LibHTML: Implement some very simple selector matching. We walk the entire DOM and check all selectors against all elements. Only id, class and tag name are checked right now. There's no ancestor stack or compound selectors. All in good time :^)
2019-06-27 20:40:21 +02:00
break;
}
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
++selector_index;
LibHTML: Implement some very simple selector matching. We walk the entire DOM and check all selectors against all elements. Only id, class and tag name are checked right now. There's no ancestor stack or compound selectors. All in good time :^)
2019-06-27 20:40:21 +02:00
}
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
++rule_index;
LibWeb: Create base class CSSRule for all CSS rules This is a foundation for handling other ("at") CSS rules.
2021-02-21 13:45:26 +02:00
});
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
++style_sheet_index;
LibWeb: Fix clang-format issue in CSS/StyleResolver.cpp
2021-03-07 17:53:20 +01:00
});
LibHTML: Hide debugging output unless HTML_DEBUG is defined
2019-09-25 12:42:10 +03:00
LibHTML: Implement some very simple selector matching. We walk the entire DOM and check all selectors against all elements. Only id, class and tag name are checked right now. There's no ancestor stack or compound selectors. All in good time :^)
2019-06-27 20:40:21 +02:00
return matching_rules;
}
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
static void sort_matching_rules(Vector<MatchingRule>& matching_rules)
LibWeb: Add a simple StyleInvalidator class This patch adds a simple, naive & inefficient class for document-wide style invalidation, e.g. after element attribute updates. During construction it collects a HashMap of a document's elements and their matching rules, during destruction it does the same and then compares the results; dirtying all elements that have a different number or order of matching rules afterwards. Much room for improvement, but it solves the problem of stale element styling after attribute updates for now :^) Fixes #4404.
2020-12-14 21:31:10 +00:00
{
quick_sort(matching_rules, [&](MatchingRule& a, MatchingRule& b) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& a_selector = a.rule->selectors()[a.selector_index];
auto const& b_selector = b.rule->selectors()[b.selector_index];
LibWeb: Add a simple StyleInvalidator class This patch adds a simple, naive & inefficient class for document-wide style invalidation, e.g. after element attribute updates. During construction it collects a HashMap of a document's elements and their matching rules, during destruction it does the same and then compares the results; dirtying all elements that have a different number or order of matching rules afterwards. Much room for improvement, but it solves the problem of stale element styling after attribute updates for now :^) Fixes #4404.
2020-12-14 21:31:10 +00:00
auto a_specificity = a_selector.specificity();
auto b_specificity = b_selector.specificity();
if (a_selector.specificity() == b_selector.specificity()) {
if (a.style_sheet_index == b.style_sheet_index)
return a.rule_index < b.rule_index;
return a.style_sheet_index < b.style_sheet_index;
}
return a_specificity < b_specificity;
});
}
LibWeb: Expand border-{top,right,bottom-left} CSS shorthand properties This code is pretty rough, but it's something that will also improve with the eventual new CSS parser.
2020-06-10 16:14:31 +02:00
enum class Edge {
Top,
Right,
Bottom,
Left,
All,
};
static bool contains(Edge a, Edge b)
{
return a == b || b == Edge::All;
}
LibWeb: Remove concept of CSS pseudo-properties We don't need them any more, so they're gone. :^)
2021-11-04 17:10:12 +00:00
static void set_property_expanding_shorthands(StyleProperties& style, CSS::PropertyID property_id, StyleValue const& value, DOM::Document& document)
LibHTML: Implement the "margin" shorthand property This is a very bulky way of doing this, and doesn't seem sustainable to implement every shorthand property this way, but it's a place to start. The "margin" CSS property now expands into its four longhands as far as my understanding of the specs. Note that shorthand expansion happens when we *resolve* style, not when we parse CSS. I'm not sure this is correct anymore, I think other UA's may actually expand shorthands into the declaration directly at parse these days. If so, we should do this at parsing as well.
2019-11-18 11:49:19 +01:00
{
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
auto assign_edge_values = [&style](PropertyID top_property, PropertyID right_property, PropertyID bottom_property, PropertyID left_property, auto const& values) {
if (values.size() == 4) {
style.set_property(top_property, values[0]);
style.set_property(right_property, values[1]);
style.set_property(bottom_property, values[2]);
style.set_property(left_property, values[3]);
} else if (values.size() == 3) {
style.set_property(top_property, values[0]);
style.set_property(right_property, values[1]);
style.set_property(bottom_property, values[2]);
style.set_property(left_property, values[1]);
} else if (values.size() == 2) {
style.set_property(top_property, values[0]);
style.set_property(right_property, values[1]);
style.set_property(bottom_property, values[0]);
style.set_property(left_property, values[1]);
} else if (values.size() == 1) {
style.set_property(top_property, values[0]);
style.set_property(right_property, values[0]);
style.set_property(bottom_property, values[0]);
style.set_property(left_property, values[0]);
}
};
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 13:36:27 +01:00
if (property_id == CSS::PropertyID::TextDecoration) {
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
if (value.is_text_decoration()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& text_decoration = value.as_text_decoration();
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
style.set_property(CSS::PropertyID::TextDecorationLine, text_decoration.line());
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
style.set_property(CSS::PropertyID::TextDecorationThickness, text_decoration.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
style.set_property(CSS::PropertyID::TextDecorationStyle, text_decoration.style());
style.set_property(CSS::PropertyID::TextDecorationColor, text_decoration.color());
LibWeb: Resolve CSS text-decoration from value list This detects and resolves these in the text-decoration property, in any order: - text-decoration-color - text-decoration-line - text-decoration-style Only the solid underline renders, but all three sub-properties are assigned correctly.
2021-07-22 14:56:44 +01:00
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::TextDecorationLine, value);
LibWeb: Parse CSS `text-decoration-thickness` property
2022-03-06 02:09:00 +01:00
style.set_property(CSS::PropertyID::TextDecorationThickness, value);
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::TextDecorationStyle, value);
style.set_property(CSS::PropertyID::TextDecorationColor, value);
LibWeb: Use IdentifierStyleValue for CSS 'text-decoration-line' Also 'text-decoration' is actually a shorthand, so treat it that way.
2020-12-15 13:36:27 +01:00
return;
}
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
if (property_id == CSS::PropertyID::Overflow) {
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
if (value.is_overflow()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& overflow = value.as_overflow();
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
style.set_property(CSS::PropertyID::OverflowX, overflow.overflow_x());
style.set_property(CSS::PropertyID::OverflowY, overflow.overflow_y());
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::OverflowX, value);
style.set_property(CSS::PropertyID::OverflowY, value);
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
return;
}
LibWeb: Add CSS property 'border' This makes it possible to write shorter CSS. Instead of writing .foo { border-width: 3px; border-style: solid; border-color: blue; } it is now possible to write .foo { border: 3px solid blue; } while the order of values is irrelevant. Currently only the basic values are supported. More values should be added in the future. Three more value specific parse functions were added: parse_line_width, parse_color, and parse_line_style Additionally a few test cases were added to borders.html.
2020-03-20 20:29:39 +01:00
if (property_id == CSS::PropertyID::Border) {
LibWeb: Expand "background: url()" into "background-image: url()" This gives us a yellow forehead on ACID2! :^)
2020-06-10 17:47:04 +02:00
set_property_expanding_shorthands(style, CSS::PropertyID::BorderTop, value, document);
set_property_expanding_shorthands(style, CSS::PropertyID::BorderRight, value, document);
set_property_expanding_shorthands(style, CSS::PropertyID::BorderBottom, value, document);
set_property_expanding_shorthands(style, CSS::PropertyID::BorderLeft, value, document);
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
// FIXME: Also reset border-image, in line with the spec: https://www.w3.org/TR/css-backgrounds-3/#border-shorthands
LibWeb: Don't leave "border" CSS property around after expansion The "border" property is a shorthand that expands into multiple longhand properties. We shouldn't leave it set in a StyleProperties after expanding it.
2020-12-19 19:30:49 +01:00
return;
LibWeb: Expand border-{top,right,bottom-left} CSS shorthand properties This code is pretty rough, but it's something that will also improve with the eventual new CSS parser.
2020-06-10 16:14:31 +02:00
}
LibWeb: Resolve shorthand for border-radius This takes care of the 1, 2, 3 and 4 parameter shorthand of the border- radius identifier. There are more as well as the ominous '/' character but that is for another time. The 2 and 3 parameter versions are weird enough already. I don't think anybody uses anything other than the 1 or 4 parameter version or even the elliptical stuff.
2021-05-14 22:31:52 +02:00
if (property_id == CSS::PropertyID::BorderRadius) {
LibWeb: Actually use BorderRadiusShorthandStyleValue Somehow we were never actually using this before, but parsing the property as a StyleValueList instead.
2022-04-18 17:10:50 +01:00
if (value.is_border_radius_shorthand()) {
auto const& shorthand = value.as_border_radius_shorthand();
style.set_property(CSS::PropertyID::BorderTopLeftRadius, shorthand.top_left());
style.set_property(CSS::PropertyID::BorderTopRightRadius, shorthand.top_right());
style.set_property(CSS::PropertyID::BorderBottomRightRadius, shorthand.bottom_right());
style.set_property(CSS::PropertyID::BorderBottomLeftRadius, shorthand.bottom_left());
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
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::BorderTopLeftRadius, value);
style.set_property(CSS::PropertyID::BorderTopRightRadius, value);
style.set_property(CSS::PropertyID::BorderBottomRightRadius, value);
style.set_property(CSS::PropertyID::BorderBottomLeftRadius, value);
LibWeb: Resolve shorthand for border-radius This takes care of the 1, 2, 3 and 4 parameter shorthand of the border- radius identifier. There are more as well as the ominous '/' character but that is for another time. The 2 and 3 parameter versions are weird enough already. I don't think anybody uses anything other than the 1 or 4 parameter version or even the elliptical stuff.
2021-05-14 22:31:52 +02:00
return;
}
LibWeb: Expand border-{top,right,bottom-left} CSS shorthand properties This code is pretty rough, but it's something that will also improve with the eventual new CSS parser.
2020-06-10 16:14:31 +02:00
if (property_id == CSS::PropertyID::BorderTop
|| property_id == CSS::PropertyID::BorderRight
|| property_id == CSS::PropertyID::BorderBottom
|| property_id == CSS::PropertyID::BorderLeft) {
Edge edge = Edge::All;
switch (property_id) {
case CSS::PropertyID::BorderTop:
edge = Edge::Top;
break;
case CSS::PropertyID::BorderRight:
edge = Edge::Right;
break;
case CSS::PropertyID::BorderBottom:
edge = Edge::Bottom;
break;
case CSS::PropertyID::BorderLeft:
edge = Edge::Left;
break;
default:
break;
}
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
if (value.is_border()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& border = value.as_border();
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
if (contains(Edge::Top, edge)) {
style.set_property(PropertyID::BorderTopWidth, border.border_width());
style.set_property(PropertyID::BorderTopStyle, border.border_style());
style.set_property(PropertyID::BorderTopColor, border.border_color());
LibWeb: Handle ValueListStyleValues in StyleResolver This implements a lot of cases, but not all of them. The following need more infrastructure first: - Flex - FlexFlow - Background - BackgroundImage - BackgroundRepeat - ListStyle and parts - Font Also, colors are not parsed correctly. This will be handled next.
2021-07-14 19:57:02 +01:00
}
LibWeb: Implement and use BorderStyleValue
2021-08-05 21:11:38 +01:00
if (contains(Edge::Right, edge)) {
style.set_property(PropertyID::BorderRightWidth, border.border_width());
style.set_property(PropertyID::BorderRightStyle, border.border_style());
style.set_property(PropertyID::BorderRightColor, border.border_color());
}
if (contains(Edge::Bottom, edge)) {
style.set_property(PropertyID::BorderBottomWidth, border.border_width());
style.set_property(PropertyID::BorderBottomStyle, border.border_style());
style.set_property(PropertyID::BorderBottomColor, border.border_color());
}
if (contains(Edge::Left, edge)) {
style.set_property(PropertyID::BorderLeftWidth, border.border_width());
style.set_property(PropertyID::BorderLeftStyle, border.border_style());
style.set_property(PropertyID::BorderLeftColor, border.border_color());
LibWeb: Add CSS property 'border' This makes it possible to write shorter CSS. Instead of writing .foo { border-width: 3px; border-style: solid; border-color: blue; } it is now possible to write .foo { border: 3px solid blue; } while the order of values is irrelevant. Currently only the basic values are supported. More values should be added in the future. Three more value specific parse functions were added: parse_line_width, parse_color, and parse_line_style Additionally a few test cases were added to borders.html.
2020-03-20 20:29:39 +01:00
}
return;
}
return;
}
LibHTML: Add shorthand expansion for border-{style,width,color} This is going to be quite boring to do by hand for every single CSS property. We'll probably want to come up with a way to auto-generate some/most of the shorthand expansion code.
2019-11-27 20:51:15 +01:00
if (property_id == CSS::PropertyID::BorderStyle) {
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
if (value.is_value_list()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& values_list = value.as_value_list();
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
assign_edge_values(PropertyID::BorderTopStyle, PropertyID::BorderRightStyle, PropertyID::BorderBottomStyle, PropertyID::BorderLeftStyle, values_list.values());
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::BorderTopStyle, value);
style.set_property(CSS::PropertyID::BorderRightStyle, value);
style.set_property(CSS::PropertyID::BorderBottomStyle, value);
style.set_property(CSS::PropertyID::BorderLeftStyle, value);
LibHTML: Add shorthand expansion for border-{style,width,color} This is going to be quite boring to do by hand for every single CSS property. We'll probably want to come up with a way to auto-generate some/most of the shorthand expansion code.
2019-11-27 20:51:15 +01:00
return;
}
if (property_id == CSS::PropertyID::BorderWidth) {
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
if (value.is_value_list()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& values_list = value.as_value_list();
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
assign_edge_values(PropertyID::BorderTopWidth, PropertyID::BorderRightWidth, PropertyID::BorderBottomWidth, PropertyID::BorderLeftWidth, values_list.values());
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::BorderTopWidth, value);
style.set_property(CSS::PropertyID::BorderRightWidth, value);
style.set_property(CSS::PropertyID::BorderBottomWidth, value);
style.set_property(CSS::PropertyID::BorderLeftWidth, value);
LibHTML: Add shorthand expansion for border-{style,width,color} This is going to be quite boring to do by hand for every single CSS property. We'll probably want to come up with a way to auto-generate some/most of the shorthand expansion code.
2019-11-27 20:51:15 +01:00
return;
}
if (property_id == CSS::PropertyID::BorderColor) {
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
if (value.is_value_list()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& values_list = value.as_value_list();
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
assign_edge_values(PropertyID::BorderTopColor, PropertyID::BorderRightColor, PropertyID::BorderBottomColor, PropertyID::BorderLeftColor, values_list.values());
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::BorderTopColor, value);
style.set_property(CSS::PropertyID::BorderRightColor, value);
style.set_property(CSS::PropertyID::BorderBottomColor, value);
style.set_property(CSS::PropertyID::BorderLeftColor, value);
LibHTML: Add shorthand expansion for border-{style,width,color} This is going to be quite boring to do by hand for every single CSS property. We'll probably want to come up with a way to auto-generate some/most of the shorthand expansion code.
2019-11-27 20:51:15 +01:00
return;
}
LibWeb: Naive support for CSS "background" shorthand Many sites simply use "background" as an alias for "background-color" so let's at least support that.
2020-05-30 11:58:05 +02:00
if (property_id == CSS::PropertyID::Background) {
LibWeb: Handle multiple backgrounds in StyleComputer This actually involves doing *less*, because we now just pass the StyleValueLists through instead of needing to grab their first layer's value. :^)
2021-11-11 11:52:33 +00:00
if (value.is_background()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& background = value.as_background();
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
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundColor, background.color(), document);
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundImage, background.image(), document);
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
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundPosition, background.position(), document);
LibWeb: Parse background-size as part of background shorthand
2021-11-05 16:15:02 +00:00
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundSize, background.size(), document);
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
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundRepeat, background.repeat(), document);
LibWeb: Parse `background-attachment` as part of `background` property
2021-11-03 17:46:45 +00:00
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundAttachment, background.attachment(), document);
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 20:28:34 +00:00
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundOrigin, background.origin(), document);
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundClip, background.clip(), document);
LibWeb: Resolve background properties from ValueListStyleValue As before, there are several sub-properties that we do not support, and we ignore anything after the first comma.
2021-07-21 17:47:50 +01:00
return;
}
LibWeb: Handle ValueListStyleValues in StyleResolver This implements a lot of cases, but not all of them. The following need more infrastructure first: - Flex - FlexFlow - Background - BackgroundImage - BackgroundRepeat - ListStyle and parts - Font Also, colors are not parsed correctly. This will be handled next.
2021-07-14 19:57:02 +01:00
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundColor, value, document);
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundImage, value, document);
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
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundPosition, value, document);
LibWeb: Parse background-size as part of background shorthand
2021-11-05 16:15:02 +00:00
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundSize, value, document);
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
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundRepeat, value, document);
LibWeb: Parse `background-attachment` as part of `background` property
2021-11-03 17:46:45 +00:00
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundAttachment, value, document);
LibWeb: Parse `background-clip` and `background-origin` Including as part of the `background` shorthand. :^)
2021-11-03 20:28:34 +00:00
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundOrigin, value, document);
set_property_expanding_shorthands(style, CSS::PropertyID::BackgroundClip, value, document);
LibWeb: Parse `background-attachment` as part of `background` property
2021-11-03 17:46:45 +00:00
return;
}
LibHTML: Implement the "margin" shorthand property This is a very bulky way of doing this, and doesn't seem sustainable to implement every shorthand property this way, but it's a place to start. The "margin" CSS property now expands into its four longhands as far as my understanding of the specs. Note that shorthand expansion happens when we *resolve* style, not when we parse CSS. I'm not sure this is correct anymore, I think other UA's may actually expand shorthands into the declaration directly at parse these days. If so, we should do this at parsing as well.
2019-11-18 11:49:19 +01:00
if (property_id == CSS::PropertyID::Margin) {
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
if (value.is_value_list()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& values_list = value.as_value_list();
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
assign_edge_values(PropertyID::MarginTop, PropertyID::MarginRight, PropertyID::MarginBottom, PropertyID::MarginLeft, values_list.values());
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::MarginTop, value);
style.set_property(CSS::PropertyID::MarginRight, value);
style.set_property(CSS::PropertyID::MarginBottom, value);
style.set_property(CSS::PropertyID::MarginLeft, value);
LibHTML: Implement the "margin" shorthand property This is a very bulky way of doing this, and doesn't seem sustainable to implement every shorthand property this way, but it's a place to start. The "margin" CSS property now expands into its four longhands as far as my understanding of the specs. Note that shorthand expansion happens when we *resolve* style, not when we parse CSS. I'm not sure this is correct anymore, I think other UA's may actually expand shorthands into the declaration directly at parse these days. If so, we should do this at parsing as well.
2019-11-18 11:49:19 +01:00
return;
}
LibHTML: Expand the "padding" shorthand property This expands in the same way as "margin".
2019-11-18 12:25:22 +01:00
if (property_id == CSS::PropertyID::Padding) {
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
if (value.is_value_list()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& values_list = value.as_value_list();
LibWeb: Use new StyleValueList for simple properties Also, moved the repeated code for assigning 1-4 values to top/right/bottom/left properties, into an assign_edge_values() lambda, for convenience.
2021-08-06 14:34:59 +01:00
assign_edge_values(PropertyID::PaddingTop, PropertyID::PaddingRight, PropertyID::PaddingBottom, PropertyID::PaddingLeft, values_list.values());
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::PaddingTop, value);
style.set_property(CSS::PropertyID::PaddingRight, value);
style.set_property(CSS::PropertyID::PaddingBottom, value);
style.set_property(CSS::PropertyID::PaddingLeft, value);
LibHTML: Expand the "padding" shorthand property This expands in the same way as "margin".
2019-11-18 12:25:22 +01:00
return;
}
LibWeb: Don't render list item markers for "list-style-type: none"
2020-05-30 12:04:15 +02:00
if (property_id == CSS::PropertyID::ListStyle) {
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
if (value.is_list_style()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& list_style = value.as_list_style();
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
style.set_property(CSS::PropertyID::ListStylePosition, list_style.position());
style.set_property(CSS::PropertyID::ListStyleImage, list_style.image());
style.set_property(CSS::PropertyID::ListStyleType, list_style.style_type());
LibWeb: Handle ValueListStyleValues in StyleResolver This implements a lot of cases, but not all of them. The following need more infrastructure first: - Flex - FlexFlow - Background - BackgroundImage - BackgroundRepeat - ListStyle and parts - Font Also, colors are not parsed correctly. This will be handled next.
2021-07-14 19:57:02 +01:00
return;
LibWeb: Don't render list item markers for "list-style-type: none"
2020-05-30 12:04:15 +02:00
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::ListStylePosition, value);
style.set_property(CSS::PropertyID::ListStyleImage, value);
style.set_property(CSS::PropertyID::ListStyleType, value);
LibWeb: Don't render list item markers for "list-style-type: none"
2020-05-30 12:04:15 +02:00
return;
}
LibWeb: Start parsing font property
2021-04-13 20:41:57 +03:00
if (property_id == CSS::PropertyID::Font) {
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
if (value.is_font()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& font_shorthand = value.as_font();
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
style.set_property(CSS::PropertyID::FontSize, font_shorthand.font_size());
LibWeb: Implement font-fallback If the font-family property is set to a StyleValueList, we now iterate through it, looking up each font in turn until one is found. StyleResolver no longer needs to handle FontFamily specifically, which is a nice bonus. Serenity's current dependence on bitmap fonts leads to some weirdness here - for example, the `if (!found_font)` path can trigger even if a generic font family like "sans-serif" is used, since our default sans-serif font might not be available in the desired size or weight. The `monospace` variable only exists for that reason. This is not a complete solution, by a long way! Serenity's font support is still quite basic, so more work needs to be done there before we can start implementing the spec's font-matching algorithm. But this is still an improvement. :^)
2021-08-14 21:05:15 +01:00
style.set_property(CSS::PropertyID::FontFamily, font_shorthand.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
style.set_property(CSS::PropertyID::FontStyle, font_shorthand.font_style());
style.set_property(CSS::PropertyID::FontWeight, font_shorthand.font_weight());
style.set_property(CSS::PropertyID::LineHeight, font_shorthand.line_height());
// FIXME: Implement font-stretch and font-variant
LibWeb: Resolve CSS font property from value list The font property now resolves into its various parts: - font-family - font-weight - font-size - font-style - line-height The font-variant and font-stretch parts are left unparsed since LibWeb doesn't know how to render those. Added `fonts.html` as a test for various forms of `font` declarations, based on the examples in the spec.
2021-07-21 15:39:40 +01:00
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::FontSize, value);
style.set_property(CSS::PropertyID::FontFamily, value);
style.set_property(CSS::PropertyID::FontStyle, value);
style.set_property(CSS::PropertyID::FontWeight, value);
style.set_property(CSS::PropertyID::LineHeight, value);
// FIXME: Implement font-stretch and font-variant
LibWeb: Resolve CSS font property from value list The font property now resolves into its various parts: - font-family - font-weight - font-size - font-style - line-height The font-variant and font-stretch parts are left unparsed since LibWeb doesn't know how to render those. Added `fonts.html` as a test for various forms of `font` declarations, based on the examples in the spec.
2021-07-21 15:39:40 +01:00
return;
}
LibWeb: Resolve CSS flex/flex-flow from value list Also moved the 'flex' code in StyleResolver to be next to the 'flex-flow' code, because that seemed more reasonable.
2021-07-20 12:05:43 +01:00
if (property_id == CSS::PropertyID::Flex) {
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
if (value.is_flex()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& flex = value.as_flex();
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
style.set_property(CSS::PropertyID::FlexGrow, flex.grow());
style.set_property(CSS::PropertyID::FlexShrink, flex.shrink());
style.set_property(CSS::PropertyID::FlexBasis, flex.basis());
LibWeb: Resolve CSS flex/flex-flow from value list Also moved the 'flex' code in StyleResolver to be next to the 'flex-flow' code, because that seemed more reasonable.
2021-07-20 12:05:43 +01:00
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::FlexGrow, value);
style.set_property(CSS::PropertyID::FlexShrink, value);
style.set_property(CSS::PropertyID::FlexBasis, value);
LibWeb: Resolve CSS flex/flex-flow from value list Also moved the 'flex' code in StyleResolver to be next to the 'flex-flow' code, because that seemed more reasonable.
2021-07-20 12:05:43 +01:00
return;
}
LibWeb: Parse and resolve flex-flow property
2021-05-30 12:25:10 +02:00
if (property_id == CSS::PropertyID::FlexFlow) {
LibWeb: Implement and use FlexFlowStyleValue
2021-08-05 17:19:29 +01:00
if (value.is_flex_flow()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& flex_flow = value.as_flex_flow();
LibWeb: Implement and use FlexFlowStyleValue
2021-08-05 17:19:29 +01:00
style.set_property(CSS::PropertyID::FlexDirection, flex_flow.flex_direction());
style.set_property(CSS::PropertyID::FlexWrap, flex_flow.flex_wrap());
return;
}
LibWeb: Remove type checking from set_property_expanding_shorthands() Now that the Parser checks that StyleValues are valid, we don't need to do the checks here, since any value here is guaranteed to be acceptable.
2021-09-23 15:23:04 +01:00
style.set_property(CSS::PropertyID::FlexDirection, value);
style.set_property(CSS::PropertyID::FlexWrap, value);
LibWeb: Handle ValueListStyleValues in StyleResolver This implements a lot of cases, but not all of them. The following need more infrastructure first: - Flex - FlexFlow - Background - BackgroundImage - BackgroundRepeat - ListStyle and parts - Font Also, colors are not parsed correctly. This will be handled next.
2021-07-14 19:57:02 +01:00
return;
}
LibWeb: Parse grid-column and grid-row CSS values
2022-08-23 20:00:16 +02:00
if (property_id == CSS::PropertyID::GridColumn) {
if (value.is_grid_track_placement_shorthand()) {
auto const& shorthand = value.as_grid_track_placement_shorthand();
style.set_property(CSS::PropertyID::GridColumnStart, shorthand.start());
style.set_property(CSS::PropertyID::GridColumnEnd, shorthand.end());
return;
}
style.set_property(CSS::PropertyID::GridColumnStart, value);
style.set_property(CSS::PropertyID::GridColumnEnd, value);
return;
}
if (property_id == CSS::PropertyID::GridRow) {
if (value.is_grid_track_placement_shorthand()) {
auto const& shorthand = value.as_grid_track_placement_shorthand();
style.set_property(CSS::PropertyID::GridRowStart, shorthand.start());
style.set_property(CSS::PropertyID::GridRowEnd, shorthand.end());
return;
}
style.set_property(CSS::PropertyID::GridRowStart, value);
style.set_property(CSS::PropertyID::GridRowEnd, value);
return;
}
LibWeb: Parse CSS gap property Including the legacy grid-gap, grid-column-gap and grid-row-gap properties.
2022-11-06 12:42:22 +01:00
if (property_id == CSS::PropertyID::Gap || property_id == CSS::PropertyID::GridGap) {
if (value.is_value_list()) {
auto const& values_list = value.as_value_list();
style.set_property(CSS::PropertyID::RowGap, values_list.values()[0]);
style.set_property(CSS::PropertyID::ColumnGap, values_list.values()[1]);
return;
}
style.set_property(CSS::PropertyID::RowGap, value);
style.set_property(CSS::PropertyID::ColumnGap, value);
return;
}
if (property_id == CSS::PropertyID::RowGap || property_id == CSS::PropertyID::GridRowGap) {
style.set_property(CSS::PropertyID::RowGap, value);
return;
}
if (property_id == CSS::PropertyID::ColumnGap || property_id == CSS::PropertyID::GridColumnGap) {
style.set_property(CSS::PropertyID::ColumnGap, value);
return;
}
LibHTML: Implement the "margin" shorthand property This is a very bulky way of doing this, and doesn't seem sustainable to implement every shorthand property this way, but it's a place to start. The "margin" CSS property now expands into its four longhands as far as my understanding of the specs. Note that shorthand expansion happens when we *resolve* style, not when we parse CSS. I'm not sure this is correct anymore, I think other UA's may actually expand shorthands into the declaration directly at parse these days. If so, we should do this at parsing as well.
2019-11-18 11:49:19 +01:00
style.set_property(property_id, value);
}
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
static RefPtr<StyleValue> get_custom_property(DOM::Element const& element, DeprecatedFlyString const& custom_property_name)
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
{
for (auto const* current_element = &element; current_element; current_element = current_element->parent_element()) {
if (auto it = current_element->custom_properties().find(custom_property_name); it != current_element->custom_properties().end())
return it->value.value;
}
return nullptr;
}
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
bool StyleComputer::expand_variables(DOM::Element& element, StringView property_name, HashMap<DeprecatedFlyString, NonnullRefPtr<PropertyDependencyNode>>& dependencies, Parser::TokenStream<Parser::ComponentValue>& source, Vector<Parser::ComponentValue>& dest) const
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
{
LibWeb: Mitigate the billion-laughs attack on CSS variables We now stop processing variables once a length of 16384 tokens is reached. This is an arbitrary number, but should be far beyond what anyone will reasonably use, and small enough to not crash.
2021-12-03 13:10:21 +00:00
// Arbitrary large value chosen to avoid the billion-laughs attack.
// https://www.w3.org/TR/css-variables-1/#long-variables
const size_t MAX_VALUE_COUNT = 16384;
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
if (source.remaining_token_count() + dest.size() > MAX_VALUE_COUNT) {
LibWeb: Mitigate the billion-laughs attack on CSS variables We now stop processing variables once a length of 16384 tokens is reached. This is an arbitrary number, but should be far beyond what anyone will reasonably use, and small enough to not crash.
2021-12-03 13:10:21 +00:00
dbgln("Stopped expanding CSS variables: maximum length reached.");
return false;
}
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
auto get_dependency_node = [&](auto name) -> NonnullRefPtr<PropertyDependencyNode> {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
if (auto existing = dependencies.get(name); existing.has_value())
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
return *existing.value();
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto new_node = PropertyDependencyNode::create(name);
dependencies.set(name, new_node);
return new_node;
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
};
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
while (source.has_next_token()) {
auto const& value = source.next_token();
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
if (!value.is_function()) {
dest.empend(value);
continue;
}
if (!value.function().name().equals_ignoring_case("var"sv)) {
auto const& source_function = value.function();
Vector<Parser::ComponentValue> function_values;
Parser::TokenStream source_function_contents { source_function.values() };
if (!expand_variables(element, property_name, dependencies, source_function_contents, function_values))
return false;
NonnullRefPtr<Parser::Function> function = Parser::Function::create(source_function.name(), move(function_values));
dest.empend(function);
continue;
}
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
Parser::TokenStream var_contents { value.function().values() };
var_contents.skip_whitespace();
if (!var_contents.has_next_token())
return false;
auto const& custom_property_name_token = var_contents.next_token();
if (!custom_property_name_token.is(Parser::Token::Type::Ident))
return false;
auto custom_property_name = custom_property_name_token.token().ident();
if (!custom_property_name.starts_with("--"sv))
return false;
// Detect dependency cycles. https://www.w3.org/TR/css-variables-1/#cycles
// We do not do this by the spec, since we are not keeping a graph of var dependencies around,
// but rebuilding it every time.
if (custom_property_name == property_name)
return false;
auto parent = get_dependency_node(property_name);
auto child = get_dependency_node(custom_property_name);
parent->add_child(child);
if (parent->has_cycles())
return false;
if (auto custom_property_value = get_custom_property(element, custom_property_name)) {
VERIFY(custom_property_value->is_unresolved());
Parser::TokenStream custom_property_tokens { custom_property_value->as_unresolved().values() };
if (!expand_variables(element, custom_property_name, dependencies, custom_property_tokens, dest))
return false;
continue;
}
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
// Use the provided fallback value, if any.
var_contents.skip_whitespace();
if (var_contents.has_next_token()) {
auto const& comma_token = var_contents.next_token();
if (!comma_token.is(Parser::Token::Type::Comma))
return false;
var_contents.skip_whitespace();
if (!expand_variables(element, property_name, dependencies, var_contents, dest))
return false;
}
}
return true;
}
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
bool StyleComputer::expand_unresolved_values(DOM::Element& element, StringView property_name, Parser::TokenStream<Parser::ComponentValue>& source, Vector<Parser::ComponentValue>& dest) const
{
// FIXME: Do this better!
// We build a copy of the tree of ComponentValues, with all var()s and attr()s replaced with their contents.
// This is a very naive solution, and we could do better if the CSS Parser could accept tokens one at a time.
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
while (source.has_next_token()) {
auto const& value = source.next_token();
if (value.is_function()) {
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
if (value.function().name().equals_ignoring_case("attr"sv)) {
LibWeb: Add basic support for the attr() CSS function CSS Values and Units Module Level 5 defines attr as: `attr(<q-name> <attr-type>?, <declaration-value>?)` This implementation does not contain support for the type argument, effectively supporting `attr(<q-name>, <declaration-value>?)`
2022-03-29 23:33:50 +02:00
// https://drafts.csswg.org/css-values-5/#attr-substitution
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
Parser::TokenStream attr_contents { value.function().values() };
attr_contents.skip_whitespace();
if (!attr_contents.has_next_token())
LibWeb: Add basic support for the attr() CSS function CSS Values and Units Module Level 5 defines attr as: `attr(<q-name> <attr-type>?, <declaration-value>?)` This implementation does not contain support for the type argument, effectively supporting `attr(<q-name>, <declaration-value>?)`
2022-03-29 23:33:50 +02:00
return false;
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
auto const& attr_name_token = attr_contents.next_token();
LibWeb: Move Token and Tokenizer into Parser namespace
2022-04-12 15:10:08 +01:00
if (!attr_name_token.is(Parser::Token::Type::Ident))
LibWeb: Add basic support for the attr() CSS function CSS Values and Units Module Level 5 defines attr as: `attr(<q-name> <attr-type>?, <declaration-value>?)` This implementation does not contain support for the type argument, effectively supporting `attr(<q-name>, <declaration-value>?)`
2022-03-29 23:33:50 +02:00
return false;
auto attr_name = attr_name_token.token().ident();
auto attr_value = element.get_attribute(attr_name);
// 1. If the attr() function has a substitution value, replace the attr() function by the substitution value.
if (!attr_value.is_null()) {
// FIXME: attr() should also accept an optional type argument, not just strings.
LibWeb: Move Token and Tokenizer into Parser namespace
2022-04-12 15:10:08 +01:00
dest.empend(Parser::Token::of_string(attr_value));
LibWeb: Add basic support for the attr() CSS function CSS Values and Units Module Level 5 defines attr as: `attr(<q-name> <attr-type>?, <declaration-value>?)` This implementation does not contain support for the type argument, effectively supporting `attr(<q-name>, <declaration-value>?)`
2022-03-29 23:33:50 +02:00
continue;
}
// 2. Otherwise, if the attr() function has a fallback value as its last argument, replace the attr() function by the fallback value.
// If there are any var() or attr() references in the fallback, substitute them as well.
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
attr_contents.skip_whitespace();
if (attr_contents.has_next_token()) {
auto const& comma_token = attr_contents.next_token();
if (!comma_token.is(Parser::Token::Type::Comma))
return false;
attr_contents.skip_whitespace();
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
if (!expand_unresolved_values(element, property_name, attr_contents, dest))
LibWeb: Add basic support for the attr() CSS function CSS Values and Units Module Level 5 defines attr as: `attr(<q-name> <attr-type>?, <declaration-value>?)` This implementation does not contain support for the type argument, effectively supporting `attr(<q-name>, <declaration-value>?)`
2022-03-29 23:33:50 +02:00
return false;
continue;
}
// 3. Otherwise, the property containing the attr() function is invalid at computed-value time.
return false;
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
}
LibWeb: Resolve unresolved CSS calc() values in StyleComputer When mixing calc() and var(), we're forced to delay resolving them until we're in StyleComputer. Previously we'd just skip over them. This patch handles calc() in the same pass as attr(). We reparse the calc() value after var() expansion, and then try to resolve it to a constant value if possible. If it's not possible, we leave the calc() where it is, and maybe layout can figure it out later. Note that I've only implemented resolution to integer and percentage in this commit. There are more things a calc() could resolve to, and we should implement those as well.
2022-11-02 20:26:11 +01:00
if (value.function().name().equals_ignoring_case("calc"sv)) {
auto const& calc_function = value.function();
if (auto calc_value = CSS::Parser::Parser::parse_calculated_value({}, Parser::ParsingContext { document() }, calc_function.values())) {
switch (calc_value->resolved_type()) {
case CalculatedStyleValue::ResolvedType::Integer: {
auto resolved_value = calc_value->resolve_integer();
dest.empend(Parser::Token::create_number(resolved_value.value()));
continue;
}
case CalculatedStyleValue::ResolvedType::Percentage: {
auto resolved_value = calc_value->resolve_percentage();
dest.empend(Parser::Token::create_percentage(resolved_value.value().value()));
continue;
}
default:
dbgln("FIXME: Unimplement calc() expansion in StyleComputer");
break;
}
}
}
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& source_function = value.function();
LibWeb: Move ComponentValue to CSS::Parser namespace
2022-04-12 12:13:10 +01:00
Vector<Parser::ComponentValue> function_values;
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
Parser::TokenStream source_function_contents { source_function.values() };
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
if (!expand_unresolved_values(element, property_name, source_function_contents, function_values))
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
return false;
LibWeb: Break friendship between CSS Function and Parser Again, this means deviating from the spec by creating a complete Function in one go instead of creating it empty and then poking at its internals.
2022-04-12 16:44:02 +01:00
NonnullRefPtr<Parser::Function> function = Parser::Function::create(source_function.name(), move(function_values));
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
dest.empend(function);
continue;
}
if (value.is_block()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& source_block = value.block();
LibWeb: Use TokenStreams when expanding unresolved CSS values This fixes a bug where any whitespace inside the `var()` or `attr()` functions would make the StyleComputer fail to resolve them.
2022-09-27 16:46:22 +01:00
Parser::TokenStream source_block_values { source_block.values() };
LibWeb: Move ComponentValue to CSS::Parser namespace
2022-04-12 12:13:10 +01:00
Vector<Parser::ComponentValue> block_values;
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
if (!expand_unresolved_values(element, property_name, source_block_values, block_values))
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
return false;
LibWeb: Break friendship between CSS Block and Parser This means deviating a little from the spec, so that we create a complete Block in one go instead of creating an empty one and then poking at its internals.
2022-04-12 16:05:44 +01:00
NonnullRefPtr<Parser::Block> block = Parser::Block::create(source_block.token(), move(block_values));
LibWeb: Move/rename StyleBlockRule to Parser::Block
2022-04-12 14:08:26 +01:00
dest.empend(move(block));
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
continue;
}
dest.empend(value.token());
}
return true;
}
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
RefPtr<StyleValue> StyleComputer::resolve_unresolved_style_value(DOM::Element& element, PropertyID property_id, UnresolvedStyleValue const& unresolved) const
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
{
LibWeb: Add basic support for the attr() CSS function CSS Values and Units Module Level 5 defines attr as: `attr(<q-name> <attr-type>?, <declaration-value>?)` This implementation does not contain support for the type argument, effectively supporting `attr(<q-name>, <declaration-value>?)`
2022-03-29 23:33:50 +02:00
// Unresolved always contains a var() or attr(), unless it is a custom property's value, in which case we shouldn't be trying
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
// to produce a different StyleValue from it.
LibWeb: Add basic support for the attr() CSS function CSS Values and Units Module Level 5 defines attr as: `attr(<q-name> <attr-type>?, <declaration-value>?)` This implementation does not contain support for the type argument, effectively supporting `attr(<q-name>, <declaration-value>?)`
2022-03-29 23:33:50 +02:00
VERIFY(unresolved.contains_var_or_attr());
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
Parser::TokenStream unresolved_values_without_variables_expanded { unresolved.values() };
Vector<Parser::ComponentValue> values_with_variables_expanded;
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
HashMap<DeprecatedFlyString, NonnullRefPtr<PropertyDependencyNode>> dependencies;
LibWeb: Do CSS var() expansion in a separate pass By expanding all the var() values first, we allow var() to occur anywhere, even as arguments to CSS functions.
2022-11-02 20:19:03 +01:00
if (!expand_variables(element, string_from_property_id(property_id), dependencies, unresolved_values_without_variables_expanded, values_with_variables_expanded))
return {};
Parser::TokenStream unresolved_values_with_variables_expanded { values_with_variables_expanded };
Vector<Parser::ComponentValue> expanded_values;
if (!expand_unresolved_values(element, string_from_property_id(property_id), unresolved_values_with_variables_expanded, expanded_values))
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
return {};
LibWeb: Move CSS Parser into new Web::CSS::Parser namespace The goal here is to move the parser-internal classes into this namespace so they can have more convenient names without causing collisions. The Parser itself won't collide, and would be more convenient to just remain `CSS::Parser`, but having a namespace and a class with the same name makes C++ unhappy.
2022-04-12 12:00:07 +01:00
if (auto parsed_value = Parser::Parser::parse_css_value({}, Parser::ParsingContext { document() }, property_id, expanded_values))
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
return parsed_value.release_nonnull();
return {};
}
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
void StyleComputer::cascade_declarations(StyleProperties& style, DOM::Element& element, Vector<MatchingRule> const& matching_rules, CascadeOrigin cascade_origin, Important important) const
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
{
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
for (auto const& match : matching_rules) {
for (auto const& property : verify_cast<PropertyOwningCSSStyleDeclaration>(match.rule->declaration()).properties()) {
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
if (important != property.important)
continue;
LibWeb: Resolve custom properties The way to get the custom properties is pretty weird and this code is as far from optimized as it gets but somehow it works :^)
2021-05-24 23:02:58 +02:00
auto property_value = property.value;
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
if (property.value->is_unresolved()) {
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
if (auto resolved = resolve_unresolved_style_value(element, property.property_id, property.value->as_unresolved()))
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 12:32:12 +00:00
property_value = resolved.release_nonnull();
}
LibWeb: CSS don't set resolve-failures (var/attr) Previously when resolving an attr or var-defined property with a 'not-set' value like this `property: var(--ValueNotSet)`, we left the property unchanged (as an unresolved) and added it to the computed-style of the element. We still don't change the property but rather we now also don't set unresolved properties in the computed-style. This is an intended behavior. The specification suggests that, on resolving an attr or var property (custom properties) we have an invalid property when neither the variable inside the var, nor the backup value could be resolved. An invalid property must be inherited or defaulted depending on it's type. We already do this with every 'untouched' (as in m_property_values contains no entry for it) value. So not setting the property results in an inherited (or initial) value by a later-called function. This also fixes another problem, where `text-decoration: var(--NotSet)` wouldn't be inherited because the computed-style of the parent element hasn't set `text-decoration` but rather all it's long-versions like `text-decoration-line` and so on.
2022-12-31 11:11:41 +01:00
if (!property_value->is_unresolved())
set_property_expanding_shorthands(style, property.property_id, property_value, m_document);
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
}
}
if (cascade_origin == CascadeOrigin::Author) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
if (auto const* inline_style = verify_cast<ElementInlineCSSStyleDeclaration>(element.inline_style())) {
for (auto const& property : inline_style->properties()) {
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
if (important != property.important)
LibWeb: Resolve 'inherit' property-value somewhat This doesn't capture the whole picture as shorthands are not considered in a careful way. A very dirty hack is included to not try to resolve 'font' as the amount of debug spam it generated ("No inital value found for...") was unhelpful.
2021-09-20 20:11:33 +02:00
continue;
LibWeb: Resolve style values from the element inline style This will set the background color in the project header on GitHub! :^)
2022-03-26 16:06:31 +01:00
auto property_value = property.value;
if (property.value->is_unresolved()) {
if (auto resolved = resolve_unresolved_style_value(element, property.property_id, property.value->as_unresolved()))
property_value = resolved.release_nonnull();
}
LibWeb: CSS don't set resolve-failures (var/attr) Previously when resolving an attr or var-defined property with a 'not-set' value like this `property: var(--ValueNotSet)`, we left the property unchanged (as an unresolved) and added it to the computed-style of the element. We still don't change the property but rather we now also don't set unresolved properties in the computed-style. This is an intended behavior. The specification suggests that, on resolving an attr or var property (custom properties) we have an invalid property when neither the variable inside the var, nor the backup value could be resolved. An invalid property must be inherited or defaulted depending on it's type. We already do this with every 'untouched' (as in m_property_values contains no entry for it) value. So not setting the property results in an inherited (or initial) value by a later-called function. This also fixes another problem, where `text-decoration: var(--NotSet)` wouldn't be inherited because the computed-style of the parent element hasn't set `text-decoration` but rather all it's long-versions like `text-decoration-line` and so on.
2022-12-31 11:11:41 +01:00
if (!property_value->is_unresolved())
set_property_expanding_shorthands(style, property.property_id, property_value, m_document);
LibWeb: Resolve 'inherit' property-value somewhat This doesn't capture the whole picture as shorthands are not considered in a careful way. A very dirty hack is included to not try to resolve 'font' as the amount of debug spam it generated ("No inital value found for...") was unhelpful.
2021-09-20 20:11:33 +02:00
}
LibHTML: Start building the style tree. Walk the DOM and construct a parallel style tree that points back to the DOM and has the relevant CSS property values hanging off of them. The values are picked based on naive selector matching. There's no cascade or specificity taken into account yet.
2019-06-28 21:17:34 +02:00
}
}
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
}
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
static ErrorOr<void> cascade_custom_properties(DOM::Element& element, Vector<MatchingRule> const& matching_rules)
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 17:04:31 +01:00
{
LibWeb: Reduce HashMap thrashing during custom property cascade Build the final custom property map right away instead of first making a temporary pointer-only map. We also precompute the final needed capacity for the map to avoid incremental rehashing.
2022-03-03 13:40:06 +01:00
size_t needed_capacity = 0;
for (auto const& matching_rule : matching_rules)
needed_capacity += verify_cast<PropertyOwningCSSStyleDeclaration>(matching_rule.rule->declaration()).custom_properties().size();
LibWeb: Set CSS custom properties from the element inline style
2022-03-26 16:10:30 +01:00
if (auto const* inline_style = verify_cast<PropertyOwningCSSStyleDeclaration>(element.inline_style()))
needed_capacity += inline_style->custom_properties().size();
LibWeb: Reduce HashMap thrashing during custom property cascade Build the final custom property map right away instead of first making a temporary pointer-only map. We also precompute the final needed capacity for the map to avoid incremental rehashing.
2022-03-03 13:40:06 +01:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
HashMap<DeprecatedFlyString, StyleProperty> custom_properties;
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
TRY(custom_properties.try_ensure_capacity(needed_capacity));
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 17:04:31 +01:00
for (auto const& matching_rule : matching_rules) {
LibWeb: Reduce HashMap thrashing during custom property cascade Build the final custom property map right away instead of first making a temporary pointer-only map. We also precompute the final needed capacity for the map to avoid incremental rehashing.
2022-03-03 13:40:06 +01:00
for (auto const& it : verify_cast<PropertyOwningCSSStyleDeclaration>(matching_rule.rule->declaration()).custom_properties())
LibWeb: Set CSS custom properties from the element inline style
2022-03-26 16:10:30 +01:00
custom_properties.set(it.key, it.value);
}
if (auto const* inline_style = verify_cast<PropertyOwningCSSStyleDeclaration>(element.inline_style())) {
for (auto const& it : inline_style->custom_properties())
LibWeb: Reduce HashMap thrashing during custom property cascade Build the final custom property map right away instead of first making a temporary pointer-only map. We also precompute the final needed capacity for the map to avoid incremental rehashing.
2022-03-03 13:40:06 +01:00
custom_properties.set(it.key, it.value);
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 17:04:31 +01:00
}
LibWeb: Reduce HashMap thrashing during custom property cascade Build the final custom property map right away instead of first making a temporary pointer-only map. We also precompute the final needed capacity for the map to avoid incremental rehashing.
2022-03-03 13:40:06 +01:00
element.set_custom_properties(move(custom_properties));
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
return {};
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 17:04:31 +01:00
}
LibWeb: Use W3C urls for CSS-CASCADE spec links
2021-10-15 19:46:52 +01:00
// https://www.w3.org/TR/css-cascade/#cascading
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
ErrorOr<void> StyleComputer::compute_cascaded_values(StyleProperties& style, DOM::Element& element, Optional<CSS::Selector::PseudoElement> pseudo_element) const
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
{
// First, we collect all the CSS rules whose selectors match `element`:
MatchingRuleSet matching_rule_set;
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
matching_rule_set.user_agent_rules = collect_matching_rules(element, CascadeOrigin::UserAgent, pseudo_element);
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
sort_matching_rules(matching_rule_set.user_agent_rules);
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
matching_rule_set.author_rules = collect_matching_rules(element, CascadeOrigin::Author, pseudo_element);
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
sort_matching_rules(matching_rule_set.author_rules);
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 17:04:31 +01:00
// Then we resolve all the CSS custom properties ("variables") for this element:
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
// FIXME: Look into how custom properties should interact with pseudo elements and support that properly.
if (!pseudo_element.has_value())
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
TRY(cascade_custom_properties(element, matching_rule_set.author_rules));
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 17:04:31 +01:00
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
// Then we apply the declarations from the matched rules in cascade order:
// Normal user agent declarations
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
cascade_declarations(style, element, matching_rule_set.user_agent_rules, CascadeOrigin::UserAgent, Important::No);
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
// FIXME: Normal user declarations
// Author presentational hints (NOTE: The spec doesn't say exactly how to prioritize these.)
element.apply_presentational_hints(style);
LibWeb: Apply non-CSS presentational hints before author styles According to css-cascade-4, we should apply presentational hints from content attributes *before* author styles.
2022-03-12 01:25:43 +01:00
// Normal author declarations
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
cascade_declarations(style, element, matching_rule_set.author_rules, CascadeOrigin::Author, Important::No);
LibWeb: Apply non-CSS presentational hints before author styles According to css-cascade-4, we should apply presentational hints from content attributes *before* author styles.
2022-03-12 01:25:43 +01:00
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
// FIXME: Animation declarations [css-animations-1]
// Important author declarations
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
cascade_declarations(style, element, matching_rule_set.author_rules, CascadeOrigin::Author, Important::Yes);
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
// FIXME: Important user declarations
// Important user agent declarations
LibWeb: Don't make deep copy of custom properties for every element Previously we were making a copy of the full set of custom properties that applied to a DOM element. This was very costly and dominated the profile when mousing around on GitHub. Note that this may break custom properties on pseudo elements a little bit, and that's something we'll have to look into.
2022-03-13 17:07:14 +01:00
cascade_declarations(style, element, matching_rule_set.user_agent_rules, CascadeOrigin::UserAgent, Important::Yes);
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
// FIXME: Transition declarations [css-transitions-1]
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
return {};
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
}
LibWeb: Inherit style across shadow tree boundaries This makes the text in <input> inherit style from the <input> element.
2022-11-05 17:08:16 +01:00
static DOM::Element const* element_to_inherit_style_from(DOM::Element const* element, Optional<CSS::Selector::PseudoElement> pseudo_element)
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
{
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
// Pseudo-elements treat their originating element as their parent.
DOM::Element const* parent_element = nullptr;
if (pseudo_element.has_value()) {
parent_element = element;
} else if (element) {
LibWeb: Inherit style across shadow tree boundaries This makes the text in <input> inherit style from the <input> element.
2022-11-05 17:08:16 +01:00
parent_element = element->parent_or_shadow_host_element();
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
}
return parent_element;
}
static NonnullRefPtr<StyleValue> get_inherit_value(CSS::PropertyID property_id, DOM::Element const* element, Optional<CSS::Selector::PseudoElement> pseudo_element)
{
LibWeb: Inherit style across shadow tree boundaries This makes the text in <input> inherit style from the <input> element.
2022-11-05 17:08:16 +01:00
auto* parent_element = element_to_inherit_style_from(element, pseudo_element);
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
LibWeb: Rename Element::specified_css_values() => computed_css_values() Let's make it very clear that these are *computed* values, and not at all the specified values. The specified values are currently discarded by the CSS cascade algorithm.
2022-03-15 19:41:35 +01:00
if (!parent_element || !parent_element->computed_css_values())
LibWeb: Make property_initial_value() return a NonnullRefPtr The finale! Users can now be sure that the value is valid, which makes things simpler.
2021-11-10 13:54:33 +00:00
return property_initial_value(property_id);
LibWeb: Make StyleProperties::property() always return a value By the time that property() gets called, we've already given every single property a value, so we can just return it. This simplifies a lot of places that were manually handling a lack of value unnecessarily.
2022-04-14 11:52:35 +01:00
return parent_element->computed_css_values()->property(property_id);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
};
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
void StyleComputer::compute_defaulted_property_value(StyleProperties& style, DOM::Element const* element, CSS::PropertyID property_id, Optional<CSS::Selector::PseudoElement> pseudo_element) const
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
{
// FIXME: If we don't know the correct initial value for a property, we fall back to InitialStyleValue.
LibWeb: Turn StyleProperties::m_property_values into an Array After style computation, every StyleProperties has a value for every PropertyID. Given this, it's simpler, faster and less memory-heavy to use an Array instead of a HashMap. :^)
2022-02-18 20:21:49 +01:00
auto& value_slot = style.m_property_values[to_underlying(property_id)];
if (!value_slot) {
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
if (is_inherited_property(property_id))
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
style.m_property_values[to_underlying(property_id)] = get_inherit_value(property_id, element, pseudo_element);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
else
LibWeb: Turn StyleProperties::m_property_values into an Array After style computation, every StyleProperties has a value for every PropertyID. Given this, it's simpler, faster and less memory-heavy to use an Array instead of a HashMap. :^)
2022-02-18 20:21:49 +01:00
style.m_property_values[to_underlying(property_id)] = property_initial_value(property_id);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
return;
}
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
LibWeb: Turn StyleProperties::m_property_values into an Array After style computation, every StyleProperties has a value for every PropertyID. Given this, it's simpler, faster and less memory-heavy to use an Array instead of a HashMap. :^)
2022-02-18 20:21:49 +01:00
if (value_slot->is_initial()) {
value_slot = property_initial_value(property_id);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
return;
}
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
LibWeb: Turn StyleProperties::m_property_values into an Array After style computation, every StyleProperties has a value for every PropertyID. Given this, it's simpler, faster and less memory-heavy to use an Array instead of a HashMap. :^)
2022-02-18 20:21:49 +01:00
if (value_slot->is_inherit()) {
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
value_slot = get_inherit_value(property_id, element, pseudo_element);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
return;
}
LibWeb: Support the CSS 'unset' value This works as 'inherit' for inherited properties and 'initial' for everything else.
2022-03-12 17:00:29 +01:00
// https://www.w3.org/TR/css-cascade-4/#inherit-initial
// If the cascaded value of a property is the unset keyword,
if (value_slot->is_unset()) {
if (is_inherited_property(property_id)) {
// then if it is an inherited property, this is treated as inherit,
value_slot = get_inherit_value(property_id, element, pseudo_element);
} else {
// and if it is not, this is treated as initial.
value_slot = property_initial_value(property_id);
}
}
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
LibWeb: Use W3C urls for CSS-CASCADE spec links
2021-10-15 19:46:52 +01:00
// https://www.w3.org/TR/css-cascade/#defaulting
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
void StyleComputer::compute_defaulted_values(StyleProperties& style, DOM::Element const* element, Optional<CSS::Selector::PseudoElement> pseudo_element) const
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
{
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
// Walk the list of all known CSS properties and:
// - Add them to `style` if they are missing.
// - Resolve `inherit` and `initial` as needed.
LibWeb: Don't add shorthand CSS properties to cascaded values We already expand shorthands in the cascade, so there's no need to preserve them in the output. This patch reorganizes the CSS::PropertyID enum values so that we can easily iterate over all shorthand or longhand properties.
2021-09-21 15:51:51 +02:00
for (auto i = to_underlying(CSS::first_longhand_property_id); i <= to_underlying(CSS::last_longhand_property_id); ++i) {
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
auto property_id = (CSS::PropertyID)i;
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
compute_defaulted_property_value(style, element, property_id, pseudo_element);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
}
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
LibWeb: Resolve Lengths to CSSPixels
2022-11-08 17:29:52 +00:00
CSSPixels StyleComputer::root_element_font_size() const
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
{
LibWeb: Make default CSS font settings match other browsers better Let's make 16px the default font size instead of 10px. This makes our layout results match those of other engines in many more cases. Also make the h1-h6 element styles use relative (em) font sizes, also matching other browsers.
2022-09-08 12:41:42 +02:00
constexpr float default_root_element_font_size = 16;
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
LibWeb: Give StyleComputer a helper for getting the current viewport
2022-03-19 18:08:52 +01:00
auto const* root_element = m_document.first_child_of_type<HTML::HTMLHtmlElement>();
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
if (!root_element)
return default_root_element_font_size;
auto const* computed_root_style = root_element->computed_css_values();
if (!computed_root_style)
return default_root_element_font_size;
LibWeb: Make StyleProperties::property() always return a value By the time that property() gets called, we've already given every single property a value, so we can just return it. This simplifies a lot of places that were manually handling a lack of value unnecessarily.
2022-04-14 11:52:35 +01:00
auto root_value = computed_root_style->property(CSS::PropertyID::FontSize);
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
LibWeb: Make StyleProperties::property() always return a value By the time that property() gets called, we've already given every single property a value, so we can just return it. This simplifies a lot of places that were manually handling a lack of value unnecessarily.
2022-04-14 11:52:35 +01:00
return root_value->to_length().to_px(viewport_rect(), computed_root_style->computed_font().pixel_metrics(), default_root_element_font_size, default_root_element_font_size);
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
}
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
void StyleComputer::compute_font(StyleProperties& style, DOM::Element const* element, Optional<CSS::Selector::PseudoElement> pseudo_element) const
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
{
// To compute the font, first ensure that we've defaulted the relevant CSS font properties.
// FIXME: This should be more sophisticated.
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
compute_defaulted_property_value(style, element, CSS::PropertyID::FontFamily, pseudo_element);
compute_defaulted_property_value(style, element, CSS::PropertyID::FontSize, pseudo_element);
compute_defaulted_property_value(style, element, CSS::PropertyID::FontStyle, pseudo_element);
compute_defaulted_property_value(style, element, CSS::PropertyID::FontWeight, pseudo_element);
LibWeb: Inherit style across shadow tree boundaries This makes the text in <input> inherit style from the <input> element.
2022-11-05 17:08:16 +01:00
auto* parent_element = element_to_inherit_style_from(element, pseudo_element);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
LibWeb: Make StyleProperties::property() always return a value By the time that property() gets called, we've already given every single property a value, so we can just return it. This simplifies a lot of places that were manually handling a lack of value unnecessarily.
2022-04-14 11:52:35 +01:00
auto font_size = style.property(CSS::PropertyID::FontSize);
auto font_style = style.property(CSS::PropertyID::FontStyle);
auto font_weight = style.property(CSS::PropertyID::FontWeight);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
int weight = Gfx::FontWeight::Regular;
if (font_weight->is_identifier()) {
switch (static_cast<IdentifierStyleValue const&>(*font_weight).id()) {
case CSS::ValueID::Normal:
weight = Gfx::FontWeight::Regular;
break;
case CSS::ValueID::Bold:
weight = Gfx::FontWeight::Bold;
break;
case CSS::ValueID::Lighter:
// FIXME: This should be relative to the parent.
weight = Gfx::FontWeight::Regular;
break;
case CSS::ValueID::Bolder:
// FIXME: This should be relative to the parent.
weight = Gfx::FontWeight::Bold;
break;
default:
break;
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02: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
} else if (font_weight->has_integer()) {
int font_weight_integer = font_weight->to_integer();
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
if (font_weight_integer <= Gfx::FontWeight::Regular)
weight = Gfx::FontWeight::Regular;
else if (font_weight_integer <= Gfx::FontWeight::Bold)
weight = Gfx::FontWeight::Bold;
else
weight = Gfx::FontWeight::Black;
LibWeb+Base: Enable calc() for font-weight property :^) Modified the test-page because FontDatabase looks for exact font-weight matches, so requesting weight 800 in a font that only has 700, causes it to return the default font instead. So, we ask for 700 here. The actual fix is to improve our font-matching but I am trying not to get distracted today. :^)
2022-01-27 15:54:38 +00:00
} else if (font_weight->is_calculated()) {
auto maybe_weight = font_weight->as_calculated().resolve_integer();
if (maybe_weight.has_value())
weight = maybe_weight.value();
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
bool bold = weight > Gfx::FontWeight::Regular;
LibWeb: Handle <absolute-size> values in the `font-size` CSS property
2022-11-30 16:17:57 +01:00
// FIXME: Should be based on "user's default font size"
LibWeb: Make default CSS font settings match other browsers better Let's make 16px the default font size instead of 10px. This makes our layout results match those of other engines in many more cases. Also make the h1-h6 element styles use relative (em) font sizes, also matching other browsers.
2022-09-08 12:41:42 +02:00
float font_size_in_px = 16;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
if (font_size->is_identifier()) {
LibWeb: Handle <absolute-size> values in the `font-size` CSS property
2022-11-30 16:17:57 +01:00
// https://w3c.github.io/csswg-drafts/css-fonts/#absolute-size-mapping
AK::HashMap<Web::CSS::ValueID, float> absolute_size_mapping = {
{ CSS::ValueID::XxSmall, 0.6 },
{ CSS::ValueID::XSmall, 0.75 },
{ CSS::ValueID::Small, 8.0 / 9.0 },
{ CSS::ValueID::Medium, 1.0 },
{ CSS::ValueID::Large, 1.2 },
{ CSS::ValueID::XLarge, 1.5 },
{ CSS::ValueID::XxLarge, 2.0 },
{ CSS::ValueID::XxxLarge, 3.0 },
LibWeb: Handle <relative-size> values in the `font-size` CSS property
2022-11-30 16:56:33 +01:00
{ CSS::ValueID::Smaller, 0.8 },
{ CSS::ValueID::Larger, 1.25 },
LibWeb: Handle <absolute-size> values in the `font-size` CSS property
2022-11-30 16:17:57 +01:00
};
LibWeb: Handle <relative-size> values in the `font-size` CSS property
2022-11-30 16:56:33 +01:00
LibWeb: Handle <absolute-size> values in the `font-size` CSS property
2022-11-30 16:17:57 +01:00
auto const identifier = static_cast<IdentifierStyleValue const&>(*font_size).id();
LibWeb: Handle <relative-size> values in the `font-size` CSS property
2022-11-30 16:56:33 +01:00
// https://w3c.github.io/csswg-drafts/css-fonts/#valdef-font-size-relative-size
// TODO: If the parent element has a keyword font size in the absolute size keyword mapping table,
// larger may compute the font size to the next entry in the table,
// and smaller may compute the font size to the previous entry in the table.
LibWeb: Handle <absolute-size> values in the `font-size` CSS property
2022-11-30 16:17:57 +01:00
if (identifier == CSS::ValueID::Smaller || identifier == CSS::ValueID::Larger) {
LibWeb: Handle <relative-size> values in the `font-size` CSS property
2022-11-30 16:56:33 +01:00
if (parent_element && parent_element->computed_css_values()) {
font_size_in_px = parent_element->computed_css_values()->computed_font().pixel_metrics().size;
}
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
LibWeb: Handle <relative-size> values in the `font-size` CSS property
2022-11-30 16:56:33 +01:00
auto const multiplier = absolute_size_mapping.get(identifier).value_or(1.0);
font_size_in_px *= multiplier;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
} else {
LibWeb: Resolve Lengths to CSSPixels
2022-11-08 17:29:52 +00:00
auto root_font_size = root_element_font_size();
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
LibGfx: Rename FontMetrics => FontPixelMetrics Let's make it clear in the type name that this contains pixel metrics. Also rename Font::metrics() => Font::pixel_metrics().
2022-03-28 12:03:44 +02:00
Gfx::FontPixelMetrics font_metrics;
LibWeb: Rename Element::specified_css_values() => computed_css_values() Let's make it very clear that these are *computed* values, and not at all the specified values. The specified values are currently discarded by the CSS cascade algorithm.
2022-03-15 19:41:35 +01:00
if (parent_element && parent_element->computed_css_values())
LibGfx: Rename FontMetrics => FontPixelMetrics Let's make it clear in the type name that this contains pixel metrics. Also rename Font::metrics() => Font::pixel_metrics().
2022-03-28 12:03:44 +02:00
font_metrics = parent_element->computed_css_values()->computed_font().pixel_metrics();
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
else
LibWeb: Get default fonts via Platform::FontPlugin Instead of asking Gfx::FontDatabase for the "default font" and the "default fixed-width font", we now proxy those requests out via the Platform::FontPlugin. This will allow Ladybird to use other default fonts as fallback.
2022-09-17 21:25:50 +02:00
font_metrics = Platform::FontPlugin::the().default_font().pixel_metrics();
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
LibWeb: Resolve Lengths to CSSPixels
2022-11-08 17:29:52 +00:00
auto parent_font_size = [&]() -> CSSPixels {
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
if (!parent_element || !parent_element->computed_css_values())
LibWeb: Pass font sizes in pt rather than px to Gfx::FontDatabase Our font database uses point sizes for fonts, and we were passing it px sizes. This caused all fonts to be 1.333x larger than they should be on the web. Of course it wasn't always noticeable with bitmap fonts, but noticeable everywhere with scalable fonts.
2022-03-23 14:10:35 +01:00
return font_size_in_px;
LibWeb: Make StyleProperties::property() always return a value By the time that property() gets called, we've already given every single property a value, so we can just return it. This simplifies a lot of places that were manually handling a lack of value unnecessarily.
2022-04-14 11:52:35 +01:00
auto value = parent_element->computed_css_values()->property(CSS::PropertyID::FontSize);
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
if (value->is_length()) {
auto length = static_cast<LengthStyleValue const&>(*value).to_length();
if (length.is_absolute() || length.is_relative())
LibWeb: Pass font sizes in pt rather than px to Gfx::FontDatabase Our font database uses point sizes for fonts, and we were passing it px sizes. This caused all fonts to be 1.333x larger than they should be on the web. Of course it wasn't always noticeable with bitmap fonts, but noticeable everywhere with scalable fonts.
2022-03-23 14:10:35 +01:00
return length.to_px(viewport_rect(), font_metrics, font_size_in_px, root_font_size);
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
}
LibWeb: Pass font sizes in pt rather than px to Gfx::FontDatabase Our font database uses point sizes for fonts, and we were passing it px sizes. This caused all fonts to be 1.333x larger than they should be on the web. Of course it wasn't always noticeable with bitmap fonts, but noticeable everywhere with scalable fonts.
2022-03-23 14:10:35 +01:00
return font_size_in_px;
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
};
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
Optional<Length> maybe_length;
LibWeb: Handle percentage font sizes
2022-01-18 17:01:15 +00:00
if (font_size->is_percentage()) {
// Percentages refer to parent element's font size
LibWeb: Make parent- and root-relative font-size work better Relative font-sizes like "2em" were previously resolved against the fallback value (10px) which led to incorrect layouts in many places. Fix this by resolving relative font-sizes against the absolutized font-size of the parent or root element as appropriate.
2022-03-16 12:30:06 +01:00
maybe_length = Length::make_px(font_size->as_percentage().percentage().as_fraction() * parent_font_size());
LibWeb: Handle percentage font sizes
2022-01-18 17:01:15 +00:00
} else if (font_size->is_length()) {
maybe_length = font_size->to_length();
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
} else if (font_size->is_calculated()) {
LibWeb: Replace Length::set_calculated_style() with ::make_calculated() There's no need to modify the Length's calculated-value after creating it, so let's make it immutable. :^)
2022-01-25 12:11:23 +00:00
maybe_length = Length::make_calculated(font_size->as_calculated());
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
if (maybe_length.has_value()) {
LibWeb: Ignore `font-size: calc(...)` for now This doesn't work correctly in the new world where fonts are resolved during the CSS cascade. Let's patch it out with a FIXME and get back to it once everything has fallen into place.
2021-09-24 15:47:42 +02:00
// FIXME: Support font-size: calc(...)
LibWeb+Base: Enable calc() for font-weight property :^) Modified the test-page because FontDatabase looks for exact font-weight matches, so requesting weight 800 in a font that only has 700, causes it to return the default font instead. So, we ask for 700 here. The actual fix is to improve our font-matching but I am trying not to get distracted today. :^)
2022-01-27 15:54:38 +00:00
// Theoretically we can do this now, but to resolve it we need a layout_node which we might not have. :^(
LibWeb: Ignore `font-size: calc(...)` for now This doesn't work correctly in the new world where fonts are resolved during the CSS cascade. Let's patch it out with a FIXME and get back to it once everything has fallen into place.
2021-09-24 15:47:42 +02:00
if (!maybe_length->is_calculated()) {
LibWeb: Resolve Lengths to CSSPixels
2022-11-08 17:29:52 +00:00
auto px = maybe_length.value().to_px(viewport_rect(), font_metrics, parent_font_size(), root_font_size).value();
LibWeb: Ignore `font-size: calc(...)` for now This doesn't work correctly in the new world where fonts are resolved during the CSS cascade. Let's patch it out with a FIXME and get back to it once everything has fallen into place.
2021-09-24 15:47:42 +02:00
if (px != 0)
LibWeb: Pass font sizes in pt rather than px to Gfx::FontDatabase Our font database uses point sizes for fonts, and we were passing it px sizes. This caused all fonts to be 1.333x larger than they should be on the web. Of course it wasn't always noticeable with bitmap fonts, but noticeable everywhere with scalable fonts.
2022-03-23 14:10:35 +01:00
font_size_in_px = px;
LibWeb: Ignore `font-size: calc(...)` for now This doesn't work correctly in the new world where fonts are resolved during the CSS cascade. Let's patch it out with a FIXME and get back to it once everything has fallen into place.
2021-09-24 15:47:42 +02:00
}
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
}
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
int slope = Gfx::name_to_slope("Normal"sv);
LibWeb+Base: Parse font-style CSS property
2022-02-19 21:21:20 +01:00
// FIXME: Implement oblique <angle>
if (font_style->is_identifier()) {
switch (static_cast<IdentifierStyleValue const&>(*font_style).id()) {
case CSS::ValueID::Italic:
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
slope = Gfx::name_to_slope("Italic"sv);
LibWeb+Base: Parse font-style CSS property
2022-02-19 21:21:20 +01:00
break;
case CSS::ValueID::Oblique:
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
slope = Gfx::name_to_slope("Oblique"sv);
LibWeb+Base: Parse font-style CSS property
2022-02-19 21:21:20 +01:00
break;
case CSS::ValueID::Normal:
default:
break;
}
}
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
// FIXME: Implement the full font-matching algorithm: https://www.w3.org/TR/css-fonts-4/#font-matching-algorithm
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
// Note: This is modified by the find_font() lambda
FontSelector font_selector;
bool monospace = false;
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
auto find_font = [&](DeprecatedString const& family) -> RefPtr<Gfx::Font> {
LibWeb: Don't round font sizes when looking them up We previously had a rounding error which sometimes led to asking LibGfx for fonts with slightly wrong sizes.
2022-03-26 23:55:11 +01:00
float font_size_in_pt = font_size_in_px * 0.75f;
LibWeb: Pass font sizes in pt rather than px to Gfx::FontDatabase Our font database uses point sizes for fonts, and we were passing it px sizes. This caused all fonts to be 1.333x larger than they should be on the web. Of course it wasn't always noticeable with bitmap fonts, but noticeable everywhere with scalable fonts.
2022-03-23 14:10:35 +01:00
font_selector = { family, font_size_in_pt, weight, slope };
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
if (auto it = m_loaded_fonts.find(family); it != m_loaded_fonts.end()) {
auto& loader = *it->value;
if (auto found_font = loader.font_with_point_size(font_size_in_pt))
return found_font;
}
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
if (auto found_font = FontCache::the().get(font_selector))
return found_font;
LibWeb: Pass font sizes in pt rather than px to Gfx::FontDatabase Our font database uses point sizes for fonts, and we were passing it px sizes. This caused all fonts to be 1.333x larger than they should be on the web. Of course it wasn't always noticeable with bitmap fonts, but noticeable everywhere with scalable fonts.
2022-03-23 14:10:35 +01:00
if (auto found_font = Gfx::FontDatabase::the().get(family, font_size_in_pt, weight, slope, Gfx::Font::AllowInexactSizeMatch::Yes))
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
return found_font;
return {};
};
auto find_generic_font = [&](ValueID font_id) -> RefPtr<Gfx::Font> {
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
Platform::GenericFont generic_font {};
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
switch (font_id) {
case ValueID::Monospace:
case ValueID::UiMonospace:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::Monospace;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
monospace = true;
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
break;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
case ValueID::Serif:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::Serif;
break;
LibWeb: Set default fantasy font to Comic Book > Fantasy fonts are primarily decorative or expressive fonts that > contain decorative or expressive representations of characters. https://drafts.csswg.org/css-fonts/#valdef-font-family-fantasy Seems like this font fits this description. :)
2022-03-05 17:58:07 +01:00
case ValueID::Fantasy:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::Fantasy;
break;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
case ValueID::SansSerif:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::SansSerif;
break;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
case ValueID::Cursive:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::Cursive;
break;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
case ValueID::UiSerif:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::UiSerif;
break;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
case ValueID::UiSansSerif:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::UiSansSerif;
break;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
case ValueID::UiRounded:
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
generic_font = Platform::GenericFont::UiRounded;
break;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
default:
return {};
}
LibWeb+WebContent: Add abstraction layer for generic font families Instead of hard-coding the names of system fonts to use for the CSS generic fonts (like "sans-serif", "monospace", etc.) we now call out to a Platform::FontPlugin and ask for the generic names.
2022-09-08 11:55:12 +02:00
return find_font(Platform::FontPlugin::the().generic_font_name(generic_font));
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
};
RefPtr<Gfx::Font> found_font;
LibWeb: Make StyleProperties::property() always return a value By the time that property() gets called, we've already given every single property a value, so we can just return it. This simplifies a lot of places that were manually handling a lack of value unnecessarily.
2022-04-14 11:52:35 +01:00
auto family_value = style.property(PropertyID::FontFamily);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
if (family_value->is_value_list()) {
LibWeb: Fix a bunch of trivial clang-tidy warnings in StyleComputer - Replace "auto" with "auto const" where appropriate. - Remove an unused struct. - Make sort_matching_rules() a file-local static function. - Remove some unnecessary includes.
2022-02-09 20:11:16 +01:00
auto const& family_list = static_cast<StyleValueList const&>(*family_value).values();
for (auto const& family : family_list) {
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
if (family.is_identifier()) {
found_font = find_generic_font(family.to_identifier());
} else if (family.is_string()) {
LibWeb+WebContent: Use new String class in CSS::StyleValue Converts uses of DeprecatedString to String in StyleValue, and patches surrounding files that depend on these functions.
2023-01-06 19:02:26 +01:00
found_font = find_font(family.to_string().release_value_but_fixme_should_propagate_errors().to_deprecated_string());
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
if (found_font)
break;
}
} else if (family_value->is_identifier()) {
found_font = find_generic_font(family_value->to_identifier());
} else if (family_value->is_string()) {
LibWeb+WebContent: Use new String class in CSS::StyleValue Converts uses of DeprecatedString to String in StyleValue, and patches surrounding files that depend on these functions.
2023-01-06 19:02:26 +01:00
found_font = find_font(family_value->to_string().release_value_but_fixme_should_propagate_errors().to_deprecated_string());
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
}
if (!found_font) {
found_font = StyleProperties::font_fallback(monospace, bold);
}
FontCache::the().set(font_selector, *found_font);
LibWeb: Pass font sizes in pt rather than px to Gfx::FontDatabase Our font database uses point sizes for fonts, and we were passing it px sizes. This caused all fonts to be 1.333x larger than they should be on the web. Of course it wasn't always noticeable with bitmap fonts, but noticeable everywhere with scalable fonts.
2022-03-23 14:10:35 +01:00
style.set_property(CSS::PropertyID::FontSize, LengthStyleValue::create(CSS::Length::make_px(font_size_in_px)));
LibWeb: Respect font-size specified by CSS in "em" length calculations "5em" means 5*font-size, but by forcing "em" to mean the presentation size of the bitmap font actually used, we broke a bunch of layouts that depended on a correct interpretation of "em". This means that "em" units will no longer be relative to the exact size of the bitmap font in use, but I think that's a compromise we'll have to make, since accurate layouts are more important. This yields a visual progression on both ACID2 and ACID3. :^)
2022-02-21 16:24:12 +01:00
style.set_property(CSS::PropertyID::FontWeight, NumericStyleValue::create_integer(weight));
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
style.set_computed_font(found_font.release_nonnull());
}
LibWeb: Stub getting the initial font instead of the root one Previously this queried the root layout-node's font, which was both wrong and could crash if the layout wasn't ready yet. Now, it's just wrong. But at least all the font-related wrongness is grouped together in StyleComputer. :^)
2022-03-11 12:53:32 +00:00
Gfx::Font const& StyleComputer::initial_font() const
{
// FIXME: This is not correct.
return StyleProperties::font_fallback(false, false);
}
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
void StyleComputer::absolutize_values(StyleProperties& style, DOM::Element const*, Optional<CSS::Selector::PseudoElement>) const
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
{
LibGfx: Rename FontMetrics => FontPixelMetrics Let's make it clear in the type name that this contains pixel metrics. Also rename Font::metrics() => Font::pixel_metrics().
2022-03-28 12:03:44 +02:00
auto font_metrics = style.computed_font().pixel_metrics();
LibWeb: Resolve Lengths to CSSPixels
2022-11-08 17:29:52 +00:00
auto root_font_size = root_element_font_size();
auto font_size = style.property(CSS::PropertyID::FontSize)->to_length().to_px(viewport_rect(), font_metrics, root_font_size, root_font_size);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +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
for (size_t i = 0; i < style.m_property_values.size(); ++i) {
auto& value_slot = style.m_property_values[i];
LibWeb: Turn StyleProperties::m_property_values into an Array After style computation, every StyleProperties has a value for every PropertyID. Given this, it's simpler, faster and less memory-heavy to use an Array instead of a HashMap. :^)
2022-02-18 20:21:49 +01:00
if (!value_slot)
continue;
LibWeb: Resolve Lengths to CSSPixels
2022-11-08 17:29:52 +00:00
value_slot = value_slot->absolutized(viewport_rect(), font_metrics, font_size.value(), root_font_size.value());
LibHTML: Implement basic support for inline style attributes You can now style elements with inline styles: <div style="color: #ff0000">This is red!</div> Pretty neat :^)
2019-09-30 20:25:33 +02:00
}
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
}
LibHTML: Implement basic support for inline style attributes You can now style elements with inline styles: <div style="color: #ff0000">This is red!</div> Pretty neat :^)
2019-09-30 20:25:33 +02:00
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
enum class BoxTypeTransformation {
None,
Blockify,
Inlinify,
};
LibWeb: Blockify children of parents with display:grid or display:flex
2022-02-28 11:34:15 +01:00
static BoxTypeTransformation required_box_type_transformation(StyleProperties const& style, DOM::Element const& element, Optional<CSS::Selector::PseudoElement> const&)
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
{
// Absolute positioning or floating an element blockifies the box’s display type. [CSS2]
if (style.position() == CSS::Position::Absolute || style.position() == CSS::Position::Fixed || style.float_() != CSS::Float::None)
return BoxTypeTransformation::Blockify;
// FIXME: Containment in a ruby container inlinifies the box’s display type, as described in [CSS-RUBY-1].
LibWeb: Blockify children of parents with display:grid or display:flex
2022-02-28 11:34:15 +01:00
// A parent with a grid or flex display value blockifies the box’s display type. [CSS-GRID-1] [CSS-FLEXBOX-1]
LibWeb: Rename Element::specified_css_values() => computed_css_values() Let's make it very clear that these are *computed* values, and not at all the specified values. The specified values are currently discarded by the CSS cascade algorithm.
2022-03-15 19:41:35 +01:00
if (element.parent_element() && element.parent_element()->computed_css_values()) {
auto const& parent_display = element.parent_element()->computed_css_values()->display();
LibWeb: Blockify children of parents with display:grid or display:flex
2022-02-28 11:34:15 +01:00
if (parent_display.is_grid_inside() || parent_display.is_flex_inside())
return BoxTypeTransformation::Blockify;
}
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
return BoxTypeTransformation::None;
}
LibWeb: Teach StyleComputer about "Automatic Box Type Transformation" CSS has rules about automatic blockification or inlinification of boxes in certain circumstances. This patch implements automatic blockification of absolutely positioned and floating elements. This makes the smile appear on ACID2. :^)
2022-01-24 14:41:48 +01:00
// https://drafts.csswg.org/css-display/#transformations
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
void StyleComputer::transform_box_type_if_needed(StyleProperties& style, DOM::Element const& element, Optional<CSS::Selector::PseudoElement> pseudo_element) const
LibWeb: Teach StyleComputer about "Automatic Box Type Transformation" CSS has rules about automatic blockification or inlinification of boxes in certain circumstances. This patch implements automatic blockification of absolutely positioned and floating elements. This makes the smile appear on ACID2. :^)
2022-01-24 14:41:48 +01:00
{
// 2.7. Automatic Box Type Transformations
// Some layout effects require blockification or inlinification of the box type,
// which sets the box’s computed outer display type to block or inline (respectively).
// (This has no effect on display types that generate no box at all, such as none or contents.)
// FIXME: If a block box (block flow) is inlinified, its inner display type is set to flow-root so that it remains a block container.
//
// FIXME: If an inline box (inline flow) is inlinified, it recursively inlinifies all of its in-flow children,
// so that no block-level descendants break up the inline formatting context in which it participates.
//
// FIXME: For legacy reasons, if an inline block box (inline flow-root) is blockified, it becomes a block box (losing its flow-root nature).
// For consistency, a run-in flow-root box also blockifies to a block box.
//
// FIXME: If a layout-internal box is blockified, its inner display type converts to flow so that it becomes a block container.
// Inlinification has no effect on layout-internal boxes. (However, placement in such an inline context will typically cause them
// to be wrapped in an appropriately-typed anonymous inline-level box.)
auto display = style.display();
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
if (display.is_none() || display.is_contents())
return;
LibWeb: Teach StyleComputer about "Automatic Box Type Transformation" CSS has rules about automatic blockification or inlinification of boxes in certain circumstances. This patch implements automatic blockification of absolutely positioned and floating elements. This makes the smile appear on ACID2. :^)
2022-01-24 14:41:48 +01:00
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
switch (required_box_type_transformation(style, element, pseudo_element)) {
case BoxTypeTransformation::None:
break;
case BoxTypeTransformation::Blockify:
LibWeb: Blockify `inline-flex` to `flex` Previously, `inline-flex` would blockify to `block` since blockification didn't take the inner display type into account. This is still not perfect, but it fixes a lot of situations where inline-level flex containers would be demoted to regular block containers.
2022-07-19 15:31:01 +02:00
if (!display.is_block_outside()) {
// FIXME: We only want to change the outer display type here, but we don't have a nice API
// to do that specifically. For now, we simply check for "inline-flex" and convert
// that to "flex".
if (display.is_flex_inside())
style.set_property(CSS::PropertyID::Display, IdentifierStyleValue::create(CSS::ValueID::Flex));
else
style.set_property(CSS::PropertyID::Display, IdentifierStyleValue::create(CSS::ValueID::Block));
}
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
break;
case BoxTypeTransformation::Inlinify:
LibWeb: Don't blockify or inlinify boxes with already-correct type If something is already a block on the outside, we don't want to overwrite its inside display type.
2022-02-28 11:35:37 +01:00
if (!display.is_inline_outside())
style.set_property(CSS::PropertyID::Display, IdentifierStyleValue::create(CSS::ValueID::Inline));
LibWeb: Split CSS box type transformations into a helper function Let's have one function that determines the type of transformation needed, and another to actually perform the transformation. This makes it much easier to read, and we don't have to duplicate the logic for doing the transformation.
2022-02-28 11:27:57 +01:00
break;
}
LibWeb: Teach StyleComputer about "Automatic Box Type Transformation" CSS has rules about automatic blockification or inlinification of boxes in certain circumstances. This patch implements automatic blockification of absolutely positioned and floating elements. This makes the smile appear on ACID2. :^)
2022-01-24 14:41:48 +01:00
}
LibWeb: Rename CSS::StyleResolver => StyleComputer Resolved style is a spec concept that refers to the weird mix of computed style and used style reflected by getComputedStyle(). The purpose of this class is to produce the *computed* style for a given element, so let's call it StyleComputer.
2021-09-24 13:49:57 +02:00
NonnullRefPtr<StyleProperties> StyleComputer::create_document_style() const
LibWeb: Give DOM::Document some default style properties Add StyleResolver::create_document_style() to help in creating an "empty" style with nothing but default values.
2021-09-23 19:48:41 +02:00
{
auto style = StyleProperties::create();
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
compute_font(style, nullptr, {});
compute_defaulted_values(style, nullptr, {});
absolutize_values(style, nullptr, {});
LibWeb: Give StyleComputer a helper for getting the current viewport
2022-03-19 18:08:52 +01:00
style->set_property(CSS::PropertyID::Width, CSS::LengthStyleValue::create(CSS::Length::make_px(viewport_rect().width())));
style->set_property(CSS::PropertyID::Height, CSS::LengthStyleValue::create(CSS::Length::make_px(viewport_rect().height())));
LibWeb: Make the initial containing block style have `display:block` We always create a Layout::InitialContainingBlock for the ICB, but in a future where we always honor the CSS::Display everywhere, we need to make sure everyone has the right display values.
2022-10-06 12:19:33 +02:00
style->set_property(CSS::PropertyID::Display, CSS::IdentifierStyleValue::create(CSS::ValueID::Block));
LibWeb: Give DOM::Document some default style properties Add StyleResolver::create_document_style() to help in creating an "empty" style with nothing but default values.
2021-09-23 19:48:41 +02:00
return style;
}
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
ErrorOr<NonnullRefPtr<StyleProperties>> StyleComputer::compute_style(DOM::Element& element, Optional<CSS::Selector::PseudoElement> pseudo_element) const
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
{
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
build_rule_cache_if_needed();
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
auto style = StyleProperties::create();
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
// 1. Perform the cascade. This produces the "specified style"
LibWeb: Use HashMap::try_ensure_capacity in StyleComputer
2022-12-06 03:08:20 -03:00
TRY(compute_cascaded_values(style, element, pseudo_element));
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
// 2. Compute the font, since that may be needed for font-relative CSS units
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
compute_font(style, &element, pseudo_element);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
// 3. Absolutize values, turning font/viewport relative lengths into absolute lengths
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
absolutize_values(style, &element, pseudo_element);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
// 4. Default the values, applying inheritance and 'initial' as needed
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
compute_defaulted_values(style, &element, pseudo_element);
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 13:13:51 +02:00
LibWeb: Teach StyleComputer about "Automatic Box Type Transformation" CSS has rules about automatic blockification or inlinification of boxes in certain circumstances. This patch implements automatic blockification of absolutely positioned and floating elements. This makes the smile appear on ACID2. :^)
2022-01-24 14:41:48 +01:00
// 5. Run automatic box type transformations
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
transform_box_type_if_needed(style, element, pseudo_element);
LibWeb: Teach StyleComputer about "Automatic Box Type Transformation" CSS has rules about automatic blockification or inlinification of boxes in certain circumstances. This patch implements automatic blockification of absolutely positioned and floating elements. This makes the smile appear on ACID2. :^)
2022-01-24 14:41:48 +01:00
LibHTML: Rename "style_properties" to "style" everywhere
2019-10-07 09:23:53 +02:00
return style;
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
}
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
PropertyDependencyNode::PropertyDependencyNode(DeprecatedString name)
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
: m_name(move(name))
{
}
void PropertyDependencyNode::add_child(NonnullRefPtr<PropertyDependencyNode> new_child)
{
for (auto const& child : m_children) {
if (child.m_name == new_child->m_name)
return;
}
// We detect self-reference already.
VERIFY(new_child->m_name != m_name);
m_children.append(move(new_child));
}
bool PropertyDependencyNode::has_cycles()
{
if (m_marked)
return true;
TemporaryChange change { m_marked, true };
for (auto& child : m_children) {
if (child.has_cycles())
return true;
}
return false;
}
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
void StyleComputer::build_rule_cache_if_needed() const
{
LibWeb: Use StyleComputer::invalidate_rule_cache() directly everywhere Get rid of the old, roundabout way of invalidating the rule cache by incrementing the StyleSheetList "generation". Instead, when something wants to invalidate the rule cache, just have it directly invalidate the rule cache. This makes it much easier to see what's happening anyway.
2022-03-14 20:31:57 +01:00
if (m_rule_cache)
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
return;
const_cast<StyleComputer&>(*this).build_rule_cache();
}
void StyleComputer::build_rule_cache()
{
// FIXME: Make a rule cache for UA style as well.
m_rule_cache = make<RuleCache>();
size_t num_class_rules = 0;
LibWeb: Add "ID" buckets to StyleComputer::RuleCache We can skip rules that require a specific ID when matching against any element that doesn't have that ID.
2022-02-10 18:50:58 +01:00
size_t num_id_rules = 0;
LibWeb: Add "tag name" buckets to StyleComputer::RuleCache We can skip rules that require a specific tag name when matching against any element with a different tag name. :^)
2022-02-10 18:59:19 +01:00
size_t num_tag_name_rules = 0;
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
size_t num_pseudo_element_rules = 0;
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
Vector<MatchingRule> matching_rules;
size_t style_sheet_index = 0;
for_each_stylesheet(CascadeOrigin::Author, [&](auto& sheet) {
size_t rule_index = 0;
LibWeb: Make StyleSheet and CSSStyleSheet GC-allocated
2022-08-07 13:14:54 +02:00
sheet.for_each_effective_style_rule([&](auto const& rule) {
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
size_t selector_index = 0;
for (CSS::Selector const& selector : rule.selectors()) {
LibWeb: Make CSSRule and all its subclasses GC-allocated
2022-08-07 15:46:44 +02:00
MatchingRule matching_rule { &rule, style_sheet_index, rule_index, selector_index, selector.specificity() };
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
bool added_to_bucket = false;
for (auto const& simple_selector : selector.compound_selectors().last().simple_selectors) {
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
if (simple_selector.type == CSS::Selector::SimpleSelector::Type::PseudoElement) {
LibWeb: Use a Variant for SimpleSelector's contents This reduces SimpleSelector's size from 112 bytes to 80 bytes. :^)
2022-03-21 15:43:59 +00:00
m_rule_cache->rules_by_pseudo_element.ensure(simple_selector.pseudo_element()).append(move(matching_rule));
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
++num_pseudo_element_rules;
LibWeb: Add "ID" buckets to StyleComputer::RuleCache We can skip rules that require a specific ID when matching against any element that doesn't have that ID.
2022-02-10 18:50:58 +01:00
added_to_bucket = true;
break;
}
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
}
if (!added_to_bucket) {
for (auto const& simple_selector : selector.compound_selectors().last().simple_selectors) {
if (simple_selector.type == CSS::Selector::SimpleSelector::Type::Id) {
LibWeb: Use a Variant for SimpleSelector's contents This reduces SimpleSelector's size from 112 bytes to 80 bytes. :^)
2022-03-21 15:43:59 +00:00
m_rule_cache->rules_by_id.ensure(simple_selector.name()).append(move(matching_rule));
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
++num_id_rules;
added_to_bucket = true;
break;
}
if (simple_selector.type == CSS::Selector::SimpleSelector::Type::Class) {
LibWeb: Use a Variant for SimpleSelector's contents This reduces SimpleSelector's size from 112 bytes to 80 bytes. :^)
2022-03-21 15:43:59 +00:00
m_rule_cache->rules_by_class.ensure(simple_selector.name()).append(move(matching_rule));
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
++num_class_rules;
added_to_bucket = true;
break;
}
if (simple_selector.type == CSS::Selector::SimpleSelector::Type::TagName) {
LibWeb: Use a Variant for SimpleSelector's contents This reduces SimpleSelector's size from 112 bytes to 80 bytes. :^)
2022-03-21 15:43:59 +00:00
m_rule_cache->rules_by_tag_name.ensure(simple_selector.name()).append(move(matching_rule));
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
++num_tag_name_rules;
added_to_bucket = true;
break;
}
LibWeb: Add "tag name" buckets to StyleComputer::RuleCache We can skip rules that require a specific tag name when matching against any element with a different tag name. :^)
2022-02-10 18:59:19 +01:00
}
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
}
if (!added_to_bucket)
m_rule_cache->other_rules.append(move(matching_rule));
++selector_index;
}
++rule_index;
});
++style_sheet_index;
});
if constexpr (LIBWEB_CSS_DEBUG) {
dbgln("Built rule cache!");
LibWeb: Add a rule-cache for PseudoElements This works a little differently from the other caches - ALL rules containing a pseudo-element are in this bucket. This lets us only look at this bucket when finding styles for a pseudo-element, and ignore it if we're not.
2022-02-25 17:50:06 +00:00
dbgln(" ID: {}", num_id_rules);
dbgln(" Class: {}", num_class_rules);
dbgln(" TagName: {}", num_tag_name_rules);
dbgln("PseudoElement: {}", num_pseudo_element_rules);
dbgln(" Other: {}", m_rule_cache->other_rules.size());
dbgln(" Total: {}", num_class_rules + num_id_rules + num_tag_name_rules + m_rule_cache->other_rules.size());
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
}
}
void StyleComputer::invalidate_rule_cache()
{
m_rule_cache = nullptr;
}
LibWeb: Use CSS Pixels for viewport rects
2022-11-09 12:32:20 +00:00
CSSPixelRect StyleComputer::viewport_rect() const
LibWeb: Give StyleComputer a helper for getting the current viewport
2022-03-19 18:08:52 +01:00
{
if (auto const* browsing_context = document().browsing_context())
LibWeb: Use CSS Pixels for viewport rects
2022-11-09 12:32:20 +00:00
return browsing_context->viewport_rect();
LibWeb: Give StyleComputer a helper for getting the current viewport
2022-03-19 18:08:52 +01:00
return {};
}
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
void StyleComputer::did_load_font([[maybe_unused]] DeprecatedFlyString const& family_name)
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
{
LibWeb: Invalidate layout whenever a CSS font is loaded It's not enough to invalidate only the style, we have to do a full layout invalidation since new fonts might mean new metrics, etc.
2022-09-14 21:24:31 +02:00
document().invalidate_layout();
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
}
LibWeb: Load fonts from style sheet once when sheet is added Previously, we were running the "load fonts if needed" machine at the start of every style computation. That was a lot of unnecessary work, especially on sites with lots of style rules, since we had to traverse every style sheet to see if any @font-face rules needed loading. With this patch, we now load fonts once per sheet, right after adding it to a document's style sheet list.
2022-04-08 21:27:35 +02:00
void StyleComputer::load_fonts_from_sheet(CSSStyleSheet const& sheet)
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
{
LibWeb: Load fonts from style sheet once when sheet is added Previously, we were running the "load fonts if needed" machine at the start of every style computation. That was a lot of unnecessary work, especially on sites with lots of style rules, since we had to traverse every style sheet to see if any @font-face rules needed loading. With this patch, we now load fonts once per sheet, right after adding it to a document's style sheet list.
2022-04-08 21:27:35 +02:00
for (auto const& rule : static_cast<CSSStyleSheet const&>(sheet).rules()) {
if (!is<CSSFontFaceRule>(rule))
continue;
auto const& font_face = static_cast<CSSFontFaceRule const&>(rule).font_face();
if (font_face.sources().is_empty())
continue;
if (m_loaded_fonts.contains(font_face.font_family()))
continue;
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
LibWeb: Be slightly better at @font-face rules with multiple sources This patch improves @font-face loading when there are multiple src values in two ways: - Invalid/empty URLs are ignored - Fonts with unsupported file extensions are ignored This makes us load and display the emblem font on modern Reddit, which is pretty neat! :^)
2022-09-14 21:46:34 +02:00
// NOTE: This is rather ad-hoc, we just look for the first valid
LibGfx: Rename TTF/TrueType to OpenType OpenType is the backwards-compatible successor to TrueType, and the format we're actually parsing in LibGfx. So let's call it that.
2022-12-19 12:26:27 +01:00
// source URL that's either a WOFF or OpenType file and try loading that.
LibWeb: Be slightly better at @font-face rules with multiple sources This patch improves @font-face loading when there are multiple src values in two ways: - Invalid/empty URLs are ignored - Fonts with unsupported file extensions are ignored This makes us load and display the emblem font on modern Reddit, which is pretty neat! :^)
2022-09-14 21:46:34 +02:00
// FIXME: Find out exactly which resources we need to load and how.
Optional<AK::URL> candidate_url;
for (auto& source : font_face.sources()) {
if (!source.url.is_valid())
continue;
AK+Everywhere: Replace "protocol" with "scheme" url helpers URL had properly named replacements for protocol(), set_protocol() and create_with_file_protocol() already. This patch removes these function and updates all call sites to use the functions named according to the specification. See https://url.spec.whatwg.org/#concept-url-scheme
2022-09-29 01:30:58 +02:00
if (source.url.scheme() != "data") {
LibWeb: Don't ignore data: URLs in @font-face src Since data: URLs don't have a path, we shouldn't be checking for a TTF or WOFF extension. Thanks Timon for pointing this out! :^)
2022-09-15 12:43:27 +02:00
auto path = source.url.path();
if (!path.ends_with(".woff"sv, AK::CaseSensitivity::CaseInsensitive)
&& !path.ends_with(".ttf"sv, AK::CaseSensitivity::CaseInsensitive)) {
continue;
}
LibWeb: Be slightly better at @font-face rules with multiple sources This patch improves @font-face loading when there are multiple src values in two ways: - Invalid/empty URLs are ignored - Fonts with unsupported file extensions are ignored This makes us load and display the emblem font on modern Reddit, which is pretty neat! :^)
2022-09-14 21:46:34 +02:00
}
candidate_url = source.url;
break;
}
if (!candidate_url.has_value())
continue;
LibWeb: Load fonts from style sheet once when sheet is added Previously, we were running the "load fonts if needed" machine at the start of every style computation. That was a lot of unnecessary work, especially on sites with lots of style rules, since we had to traverse every style sheet to see if any @font-face rules needed loading. With this patch, we now load fonts once per sheet, right after adding it to a document's style sheet list.
2022-04-08 21:27:35 +02:00
LoadRequest request;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
auto url = m_document.parse_url(candidate_url.value().to_deprecated_string());
LibWeb: Load fonts from style sheet once when sheet is added Previously, we were running the "load fonts if needed" machine at the start of every style computation. That was a lot of unnecessary work, especially on sites with lots of style rules, since we had to traverse every style sheet to see if any @font-face rules needed loading. With this patch, we now load fonts once per sheet, right after adding it to a document's style sheet list.
2022-04-08 21:27:35 +02:00
auto loader = make<FontLoader>(const_cast<StyleComputer&>(*this), font_face.font_family(), move(url));
const_cast<StyleComputer&>(*this).m_loaded_fonts.set(font_face.font_family(), move(loader));
}
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
}
LibWeb: Load fonts from style sheet once when sheet is added Previously, we were running the "load fonts if needed" machine at the start of every style computation. That was a lot of unnecessary work, especially on sites with lots of style rules, since we had to traverse every style sheet to see if any @font-face rules needed loading. With this patch, we now load fonts once per sheet, right after adding it to a document's style sheet list.
2022-04-08 21:27:35 +02:00
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
Reference in a new issue Copy permalink