Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-30 12:50:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/CSS/Parser/ParsingContext.cpp

77 lines
1.8 KiB
C++
Raw Normal View History

LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2018-2022, Andreas Kling <andreas@ladybird.org>
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
* Copyright (c) 2020-2021, the SerenityOS developers.
* Copyright (c) 2021-2023, Sam Atkins <atkinssj@serenityos.org>
* Copyright (c) 2021, Tobias Christiansen <tobyase@serenityos.org>
* Copyright (c) 2022, MacDue <macdue@dueutil.tech>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibWeb/CSS/Parser/Parser.h>
#include <LibWeb/DOM/Document.h>
namespace Web::CSS::Parser {
LibWeb/CSS: Make ParsingContext's Realm optional We only need a Realm to allocate CSSOM objects on the GC heap. Style values are not such objects, and over time, we'll be changing the parser to only produce non-CSSOM objects.
2024-12-05 10:41:19 +00:00
ParsingContext::ParsingContext(Mode mode)
: m_mode(mode)
{
}
LibWeb: Add SVG-presentation-attribute-parsing mode to CSS parser When parsing these, <number> is allowed anywhere that would usually allow a <length>, <length-percentage>, or <angle>. The spec is not clear on exactly how this should work (see https://github.com/w3c/svgwg/issues/792 ) so I'm using some artistic license until things are clearer: - If we expected a <length>, treat the <number> as pixels. - If we expected an <angle>, treat the <number> as degrees. - Only allow direct <number> tokens, not calc() or other functions. From what I can tell this is what the spec *intended* but I may be very wrong. In any case, telling the ParsingContext whether we're parsing one of these attributes is a cleaner approach and more correct than temporarily enabling quirks mode, which we did previously.
2023-09-25 15:26:33 +01:00
ParsingContext::ParsingContext(JS::Realm& realm, Mode mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
: m_realm(realm)
LibWeb: Add SVG-presentation-attribute-parsing mode to CSS parser When parsing these, <number> is allowed anywhere that would usually allow a <length>, <length-percentage>, or <angle>. The spec is not clear on exactly how this should work (see https://github.com/w3c/svgwg/issues/792 ) so I'm using some artistic license until things are clearer: - If we expected a <length>, treat the <number> as pixels. - If we expected an <angle>, treat the <number> as degrees. - Only allow direct <number> tokens, not calc() or other functions. From what I can tell this is what the spec *intended* but I may be very wrong. In any case, telling the ParsingContext whether we're parsing one of these attributes is a cleaner approach and more correct than temporarily enabling quirks mode, which we did previously.
2023-09-25 15:26:33 +01:00
, m_mode(mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
{
}
LibWeb: Add CSS ParsingContext constructor with a realm and URL This is useful for when we want to parse paths relative to the current ESO's api base url when there isn't a document, such as in a Worker context.
2024-05-15 14:56:14 -06:00
ParsingContext::ParsingContext(JS::Realm& realm, URL::URL url, Mode mode)
: m_realm(realm)
, m_url(move(url))
, m_mode(mode)
{
}
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
ParsingContext::ParsingContext(DOM::Document const& document, URL::URL url, Mode mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
: m_realm(const_cast<JS::Realm&>(document.realm()))
, m_document(&document)
, m_url(move(url))
LibWeb: Add SVG-presentation-attribute-parsing mode to CSS parser When parsing these, <number> is allowed anywhere that would usually allow a <length>, <length-percentage>, or <angle>. The spec is not clear on exactly how this should work (see https://github.com/w3c/svgwg/issues/792 ) so I'm using some artistic license until things are clearer: - If we expected a <length>, treat the <number> as pixels. - If we expected an <angle>, treat the <number> as degrees. - Only allow direct <number> tokens, not calc() or other functions. From what I can tell this is what the spec *intended* but I may be very wrong. In any case, telling the ParsingContext whether we're parsing one of these attributes is a cleaner approach and more correct than temporarily enabling quirks mode, which we did previously.
2023-09-25 15:26:33 +01:00
, m_mode(mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
{
}
LibWeb: Add SVG-presentation-attribute-parsing mode to CSS parser When parsing these, <number> is allowed anywhere that would usually allow a <length>, <length-percentage>, or <angle>. The spec is not clear on exactly how this should work (see https://github.com/w3c/svgwg/issues/792 ) so I'm using some artistic license until things are clearer: - If we expected a <length>, treat the <number> as pixels. - If we expected an <angle>, treat the <number> as degrees. - Only allow direct <number> tokens, not calc() or other functions. From what I can tell this is what the spec *intended* but I may be very wrong. In any case, telling the ParsingContext whether we're parsing one of these attributes is a cleaner approach and more correct than temporarily enabling quirks mode, which we did previously.
2023-09-25 15:26:33 +01:00
ParsingContext::ParsingContext(DOM::Document const& document, Mode mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
: m_realm(const_cast<JS::Realm&>(document.realm()))
, m_document(&document)
, m_url(document.url())
LibWeb: Add SVG-presentation-attribute-parsing mode to CSS parser When parsing these, <number> is allowed anywhere that would usually allow a <length>, <length-percentage>, or <angle>. The spec is not clear on exactly how this should work (see https://github.com/w3c/svgwg/issues/792 ) so I'm using some artistic license until things are clearer: - If we expected a <length>, treat the <number> as pixels. - If we expected an <angle>, treat the <number> as degrees. - Only allow direct <number> tokens, not calc() or other functions. From what I can tell this is what the spec *intended* but I may be very wrong. In any case, telling the ParsingContext whether we're parsing one of these attributes is a cleaner approach and more correct than temporarily enabling quirks mode, which we did previously.
2023-09-25 15:26:33 +01:00
, m_mode(mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
{
}
LibWeb: Add SVG-presentation-attribute-parsing mode to CSS parser When parsing these, <number> is allowed anywhere that would usually allow a <length>, <length-percentage>, or <angle>. The spec is not clear on exactly how this should work (see https://github.com/w3c/svgwg/issues/792 ) so I'm using some artistic license until things are clearer: - If we expected a <length>, treat the <number> as pixels. - If we expected an <angle>, treat the <number> as degrees. - Only allow direct <number> tokens, not calc() or other functions. From what I can tell this is what the spec *intended* but I may be very wrong. In any case, telling the ParsingContext whether we're parsing one of these attributes is a cleaner approach and more correct than temporarily enabling quirks mode, which we did previously.
2023-09-25 15:26:33 +01:00
ParsingContext::ParsingContext(DOM::ParentNode& parent_node, Mode mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
: m_realm(parent_node.realm())
, m_document(&parent_node.document())
, m_url(parent_node.document().url())
LibWeb: Add SVG-presentation-attribute-parsing mode to CSS parser When parsing these, <number> is allowed anywhere that would usually allow a <length>, <length-percentage>, or <angle>. The spec is not clear on exactly how this should work (see https://github.com/w3c/svgwg/issues/792 ) so I'm using some artistic license until things are clearer: - If we expected a <length>, treat the <number> as pixels. - If we expected an <angle>, treat the <number> as degrees. - Only allow direct <number> tokens, not calc() or other functions. From what I can tell this is what the spec *intended* but I may be very wrong. In any case, telling the ParsingContext whether we're parsing one of these attributes is a cleaner approach and more correct than temporarily enabling quirks mode, which we did previously.
2023-09-25 15:26:33 +01:00
, m_mode(mode)
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
{
}
bool ParsingContext::in_quirks_mode() const
{
return m_document ? m_document->in_quirks_mode() : false;
}
// https://www.w3.org/TR/css-values-4/#relative-urls
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
URL::URL ParsingContext::complete_url(StringView relative_url) const
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
{
return m_url.complete_url(relative_url);
}
HTML::Window const* ParsingContext::window() const
{
LibWeb: Ignore window-forwarded document.body.onfoo in detached DOM Normally, assigning to e.g document.body.onload will forward to window.onload. However, in a detached DOM tree, there is no associated window, so we have nowhere to forward to, making this a no-op. The bulk of this change is making Document::window() return a nullable pointer, as documents created by DOMParser or DOMImplementation do not have an associated window object, and so must be able to return null from here.
2024-03-10 08:41:18 +01:00
if (!m_document)
return nullptr;
return m_document->window();
LibWeb+LibJS: Move some code around to make CSS/Parser parse faster This makes it possible to include fewer full definitions of things, which makes the file about 30% faster to compile.
2023-07-09 11:40:17 +03:30
}
}
Reference in a new issue Copy permalink