ladybird/Libraries/LibWeb/CSS/Descriptor.h

/*
 * Copyright (c) 2025, Sam Atkins <sam@ladybird.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#pragma once

#include <AK/NonnullRefPtr.h>
#include <LibWeb/CSS/DescriptorNameAndID.h>
#include <LibWeb/Forward.h>

namespace Web::CSS {

struct Descriptor {
    ~Descriptor();

    DescriptorNameAndID descriptor_name_and_id;
    NonnullRefPtr<StyleValue const> value;
};

}
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way. 2025-04-02 13:05:48 -03:00			`/*`
			`* Copyright (c) 2025, Sam Atkins <sam@ladybird.org>`
			`*`
			`* SPDX-License-Identifier: BSD-2-Clause`
			`*/`

			`#pragma once`

			`#include <AK/NonnullRefPtr.h>`
LibWeb: Support custom descriptors Some at-rules (i.e. `@function`) require us to support custom descriptors (e.g. `--foo`). We do this by adding `DescriptorID::Custom` and using a new `DescriptorNameAndID` class in a bunch of places where we previously just used `DescriptorID` 2026-03-04 08:03:57 -03:00			`#include <LibWeb/CSS/DescriptorNameAndID.h>`
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way. 2025-04-02 13:05:48 -03:00			`#include <LibWeb/Forward.h>`

			`namespace Web::CSS {`

			`struct Descriptor {`
			`~Descriptor();`

LibWeb: Support custom descriptors Some at-rules (i.e. `@function`) require us to support custom descriptors (e.g. `--foo`). We do this by adding `DescriptorID::Custom` and using a new `DescriptorNameAndID` class in a bunch of places where we previously just used `DescriptorID` 2026-03-04 08:03:57 -03:00			`DescriptorNameAndID descriptor_name_and_id;`
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it not being there has bothered me for a long time. 😅 2025-08-08 06:11:51 -03:00			`NonnullRefPtr<StyleValue const> value;`
LibWeb: Parse descriptors as style values, using the JSON data The goal here is to do something a bit smarter with the parsing here than we do for properties. Instead of the JSON saying "here are the values, and here are the keywords, and we can have up to 3", here we place the syntax in the JSON directly (though currently broken up as one string per option) and then we attempt to parse each one in sequence. It's something we'll need eventually for `@property` among other things. ...However, in this first pass, I've gone with the simplest option of hard-coding the types instead of figuring them out properly. So there's a PositivePercentage type and a UnicodeRangeTokens type, instead of properly implementing the grammar for those in a generic way. 2025-04-02 13:05:48 -03:00			`};`

			`}`