dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/CSS/CSSFontFaceRule.h

44 lines
1.2 KiB
C
Raw Normal View History

LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
/*
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 08:05:49 -03:00
* Copyright (c) 2022-2025, Sam Atkins <sam@ladybird.org>
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 08:05:49 -03:00
#include <LibWeb/CSS/CSSFontFaceDescriptors.h>
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
#include <LibWeb/CSS/CSSRule.h>
LibWeb: Rename CSS::FontFace to CSS::ParsedFontFace This implementation detail of CSSFontFaceRule is hogging the name of a Web API from CSS Font Loading Module Level 3.
2024-05-07 12:18:37 -03:00
#include <LibWeb/CSS/ParsedFontFace.h>
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
namespace Web::CSS {
class CSSFontFaceRule final : public CSSRule {
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated This is a monster patch that turns all EventTargets into GC-allocated PlatformObjects. Their C++ wrapper classes are removed, and the LibJS garbage collector is now responsible for their lifetimes. There's a fair amount of hacks and band-aids in this patch, and we'll have a lot of cleanup to do after this.
2022-08-28 08:42:07 -03:00
WEB_PLATFORM_OBJECT(CSSFontFaceRule, CSSRule);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
GC_DECLARE_ALLOCATOR(CSSFontFaceRule);
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
public:
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 08:05:49 -03:00
[[nodiscard]] static GC::Ref<CSSFontFaceRule> create(JS::Realm&, GC::Ref<CSSFontFaceDescriptors>);
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
virtual ~CSSFontFaceRule() override = default;
LibWeb/CSS: Only attempt to load valid `@font-face` fonts These must have a `font-family` and `src` set to be included in font-matching. Otherwise they should be ignored, but still exist in the CSSOM.
2025-04-03 08:15:11 -03:00
bool is_valid() const;
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 08:05:49 -03:00
ParsedFontFace font_face() const;
LibWeb: Dump CSSDescriptors in a generic way This replaces the need for bespoke (and verbose) dumping for each at-rule that has descriptors.
2025-05-08 10:37:25 -03:00
GC::Ref<CSSStyleDeclaration> style() { return m_style; }
GC::Ref<CSSFontFaceDescriptors const> descriptors() const { return m_style; }
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
private:
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 08:05:49 -03:00
CSSFontFaceRule(JS::Realm&, GC::Ref<CSSFontFaceDescriptors>);
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated This is a monster patch that turns all EventTargets into GC-allocated PlatformObjects. Their C++ wrapper classes are removed, and the LibJS garbage collector is now responsible for their lifetimes. There's a fair amount of hacks and band-aids in this patch, and we'll have a lot of cleanup to do after this.
2022-08-28 08:42:07 -03:00
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 03:41:28 -03:00
virtual void initialize(JS::Realm&) override;
LibWeb: Port CSSRule::serialized from DeprecatedString to String
2023-11-20 07:16:39 -03:00
virtual String serialized() const override;
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 08:05:49 -03:00
virtual void visit_edges(Visitor&) override;
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
LibWeb/CSS: Parse `@font-face` descriptors as style values CSSFontFaceRule now stores its values as a CSSFontFaceDescriptors, with a ParsedFontFace produced on request. This is exposed via the `style` attribute, so we pass a lot of tests that try to read values from that. We have one test regression, which we passed by mistake before: The test wanted to ensure we don't allow `@font-face` nested inside other rules. We passed it just because we discarded any `@font-face` without a `font-family`. What we're supposed to do is 1) keep at-rules with missing required descriptors and just not use them, and 2) reject certain ones when nested. We may want to cache the ParsedFontFace in the future, but I didn't here because 1) it's called rarely, and 2) that would mean knowing to invalidate it when the CSSFontFaceDescriptors changes, which isn't obvious to me right now.
2025-04-03 08:05:49 -03:00
GC::Ref<CSSFontFaceDescriptors> m_style;
LibWeb: Implement initial CSSFontFaceRule and FontFace classes For now, this is the bare minimum that's needed: font-family and src.
2022-03-28 16:30:26 -03:00
};
template<>
inline bool CSSRule::fast_is<CSSFontFaceRule>() const { return type() == CSSRule::Type::FontFace; }
}
Reference in a new issue Copy permalink