Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 23:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/HTML/HTMLObjectElement.h

102 lines
3.4 KiB
C
Raw Normal View History

LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02: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
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
*/
#pragma once
#include <LibCore/Forward.h>
#include <LibGfx/Forward.h>
LibWeb: Make FormAssociatedElement inherit from HTMLElement The new event target implementation requires us to downcast an EventTarget to a FormAssociatedElement to check if the current Element EventTarget has a form owner to setup a with scope for the form owner. This also makes all form associated elements inherit from FormAssociatedElement where it was previously missing. https://html.spec.whatwg.org/#form-associated-element
2021-10-14 16:18:49 +01:00
#include <LibWeb/HTML/FormAssociatedElement.h>
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
#include <LibWeb/HTML/HTMLElement.h>
LibWeb: Rename BrowsingContextContainer => NavigableContainer The "browsing context container" concept in the HTML spec has been replaced with "navigable container". Renaming this is the first step of many towards implementing the new world. Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
2022-12-12 12:20:02 +01:00
#include <LibWeb/HTML/NavigableContainer.h>
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader We achieve this by adding a new Layout::ImageProvider class and having both HTMLImageElement and HTMLObjectElement inherit from it. The HTML spec is vague on how object image loading should work, which is why this first pass is focusing on image elements.
2023-05-12 07:17:01 +02:00
#include <LibWeb/Layout/ImageProvider.h>
LibWeb: Piggyback on HTML::ImageRequest in HTMLObjectElement Like the piggybacking in CSS, this is also totally ad-hoc, since there's no spec to follow. The code here is weird and definitely sub-optimal as we do a second load if it turns out the loaded resource is an image, but given that object elements are rarely used nowadays, I doubt we'll even notice. That said, we should of course improve this code as we move forward.
2023-06-11 16:02:37 +02:00
#include <LibWeb/Loader/Resource.h>
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
LibWeb: Move HTML classes into the Web::HTML namespace
2020-07-28 18:20:36 +02:00
namespace Web::HTML {
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 08:24:11 -04:00
class HTMLObjectElement final
LibWeb: Rename BrowsingContextContainer => NavigableContainer The "browsing context container" concept in the HTML spec has been replaced with "navigable container". Renaming this is the first step of many towards implementing the new world. Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
2022-12-12 12:20:02 +01:00
: public NavigableContainer
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
, public FormAssociatedElement
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader We achieve this by adding a new Layout::ImageProvider class and having both HTMLImageElement and HTMLObjectElement inherit from it. The HTML spec is vague on how object image loading should work, which is why this first pass is focusing on image elements.
2023-05-12 07:17:01 +02:00
, public ResourceClient
, public Layout::ImageProvider {
LibWeb: Rename BrowsingContextContainer => NavigableContainer The "browsing context container" concept in the HTML spec has been replaced with "navigable container". Renaming this is the first step of many towards implementing the new world. Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
2022-12-12 12:20:02 +01:00
WEB_PLATFORM_OBJECT(HTMLObjectElement, NavigableContainer)
LibWeb: Put most LibWeb GC objects in type-specific heap blocks With this change, we now have ~1200 CellAllocators across both LibJS and LibWeb in a normal WebContent instance. This gives us a minimum heap size of 4.7 MiB in the scenario where we only have one cell allocated per type. Of course, in practice there will be many more of each type, so the effective overhead is quite a bit smaller than that in practice. I left a few types unconverted to this mechanism because I got tired of doing this. :^)
2023-11-19 19:47:52 +01:00
JS_DECLARE_ALLOCATOR(HTMLObjectElement);
LibWeb: Rename BrowsingContextContainer => NavigableContainer The "browsing context container" concept in the HTML spec has been replaced with "navigable container". Renaming this is the first step of many towards implementing the new world. Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
2022-12-12 12:20:02 +01:00
FORM_ASSOCIATED_ELEMENT(NavigableContainer, HTMLObjectElement)
LibWeb: Begin supporting non-image HTMLObjectElement data representation We currently only supported loading image data from an HTMLObjectElement node. This adds (some) support for non-image data. A big FIXME is to actually paint that data. We will need to make FrameBox and NestedBrowsingContextPaintable work with HTMLObjectElement for this (they currently only work with HTMLIFrameElement).
2022-03-23 20:15:56 -04:00
enum class Representation {
Unknown,
Image,
NestedBrowsingContext,
Children,
};
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
public:
virtual ~HTMLObjectElement() override;
LibWeb: Reset form association when the element's form attribute changes
2024-02-03 09:33:33 -05:00
virtual void form_associated_element_attribute_changed(FlyString const& name, Optional<String> const& value) override;
LibWeb: Destroy associated navigable when <object> is removed from DOM
2024-04-17 13:56:55 +02:00
virtual void form_associated_element_was_removed(DOM::Node*) override;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
LibWeb: Port HTMLObjectElement interface from DeprecatedString to String
2023-09-03 15:39:01 +12:00
String data() const;
void set_data(String const& data) { MUST(set_attribute(HTML::AttributeNames::data, data)); }
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 08:24:11 -04:00
LibWeb: Remove DOM element deprecated_get_attribute()
2024-01-16 19:04:45 +01:00
String type() const { return get_attribute_value(HTML::AttributeNames::type); }
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
LibWeb: Add form associated element categories
2022-03-01 21:03:30 +00:00
// ^FormAssociatedElement
// https://html.spec.whatwg.org/multipage/forms.html#category-listed
virtual bool is_listed() const override { return true; }
LibWeb: Make HTML::SharedImageRequest GC allocated This allows to partially solve the problem of cyclic dependency between HTMLImageElement and SharedImageRequest that prevents all image elements from being deallocated.
2023-08-18 14:11:55 +02:00
virtual void visit_edges(Cell::Visitor&) override;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
private:
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 13:42:07 +02:00
HTMLObjectElement(DOM::Document&, DOM::QualifiedName);
LibWeb: Add fast_is<T> for form, embed, image, and object elements These are used by Window::supported_property_names(), which can get very hot.
2023-12-24 14:41:33 +01:00
virtual bool is_html_object_element() const override { return true; }
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 08:41:28 +02:00
virtual void initialize(JS::Realm&) override;
LibWeb: Move setting of Web object prototypes to initialize() This needs to happen before prototype/constructor intitialization can be made lazy. Otherwise, GC could run during the C++ constructor and try to collect the object currently being created.
2023-01-10 06:28:20 -05:00
LibWeb: Map embedded content element attributes to dimension properties
2024-10-01 17:26:01 +01:00
virtual void apply_presentational_hints(CSS::StyleProperties&) const override;
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
virtual JS::GCPtr<Layout::Node> create_layout_node(NonnullRefPtr<CSS::StyleProperties>) override;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
LibWeb: Implement falling back early to an object's child representation
2022-03-24 11:14:19 -04:00
bool has_ancestor_media_element_or_object_element_not_showing_fallback_content() const;
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 08:24:11 -04:00
void queue_element_task_to_run_object_representation_steps();
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
void run_object_representation_handler_steps(Optional<ByteString> resource_type);
LibWeb: Conditionally update an object's children when its state changes We should only update the object children of an object when the parent's representation changes to/from falling back to its children.
2022-03-24 11:09:45 -04:00
void run_object_representation_completed_steps(Representation);
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 08:24:11 -04:00
void run_object_representation_fallback_steps();
LibWeb: Piggyback on HTML::ImageRequest in HTMLObjectElement Like the piggybacking in CSS, this is also totally ad-hoc, since there's no spec to follow. The code here is weird and definitely sub-optimal as we do a second load if it turns out the loaded resource is an image, but given that object elements are rarely used nowadays, I doubt we'll even notice. That said, we should of course improve this code as we move forward.
2023-06-11 16:02:37 +02:00
void load_image();
LibWeb: Conditionally update an object's children when its state changes We should only update the object children of an object when the parent's representation changes to/from falling back to its children.
2022-03-24 11:09:45 -04:00
void update_layout_and_child_objects(Representation);
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 08:24:11 -04:00
// ^ResourceClient
virtual void resource_did_load() override;
virtual void resource_did_fail() override;
LibWeb: Implement HTMLOrSVGElement.tabIndex
2022-11-05 03:58:14 +00:00
// ^DOM::Element
virtual i32 default_tab_index_value() const override;
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader We achieve this by adding a new Layout::ImageProvider class and having both HTMLImageElement and HTMLObjectElement inherit from it. The HTML spec is vague on how object image loading should work, which is why this first pass is focusing on image elements.
2023-05-12 07:17:01 +02:00
// ^Layout::ImageProvider
LibWeb: Generalize ImageBox and ImagePaintable for any ImageProvider They currently assume the DOM node is an HTMLImageElement with respect to handling the alt attribute. The HTMLInputElement will require the same behavior.
2024-02-18 20:10:37 -05:00
virtual bool is_image_available() const override;
LibWeb: Make ImageBox ask ImageProvider for intrinsic size and ratio This paves the way for ImageProvider to have something vector-based underneath. :^)
2023-05-20 16:27:31 +02:00
virtual Optional<CSSPixels> intrinsic_width() const override;
virtual Optional<CSSPixels> intrinsic_height() const override;
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
virtual Optional<CSSPixelFraction> intrinsic_aspect_ratio() const override;
LibGfx+LibWeb: Add ImmutableBitmap for images bitmap caching in painter Before this change, we used Gfx::Bitmap to represent both decoded images that are not going to be mutated and bitmaps corresponding to canvases that could be mutated. This change introduces a wrapper for bitmaps that are not going to be mutated, so the painter could do caching: texture caching in the case of GPU painter and potentially scaled bitmap caching in the case of CPU painter.
2023-11-24 14:45:45 +01:00
virtual RefPtr<Gfx::ImmutableBitmap> current_image_bitmap(Gfx::IntSize = {}) const override;
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader We achieve this by adding a new Layout::ImageProvider class and having both HTMLImageElement and HTMLObjectElement inherit from it. The HTML spec is vague on how object image loading should work, which is why this first pass is focusing on image elements.
2023-05-12 07:17:01 +02:00
virtual void set_visible_in_viewport(bool) override;
LibWeb: Visit ImageProvider from Layout::ImageBox Adds missing visit of HTMLElement that serves as image provider of image layout node.
2024-02-26 17:36:48 +01:00
virtual JS::NonnullGCPtr<DOM::Element const> to_html_element() const override { return *this; }
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader We achieve this by adding a new Layout::ImageProvider class and having both HTMLImageElement and HTMLObjectElement inherit from it. The HTML spec is vague on how object image loading should work, which is why this first pass is focusing on image elements.
2023-05-12 07:17:01 +02:00
LibWeb: Begin supporting non-image HTMLObjectElement data representation We currently only supported loading image data from an HTMLObjectElement node. This adds (some) support for non-image data. A big FIXME is to actually paint that data. We will need to make FrameBox and NestedBrowsingContextPaintable work with HTMLObjectElement for this (they currently only work with HTMLIFrameElement).
2022-03-23 20:15:56 -04:00
Representation m_representation { Representation::Unknown };
LibWeb: Piggyback on HTML::ImageRequest in HTMLObjectElement Like the piggybacking in CSS, this is also totally ad-hoc, since there's no spec to follow. The code here is weird and definitely sub-optimal as we do a second load if it turns out the loaded resource is an image, but given that object elements are rarely used nowadays, I doubt we'll even notice. That said, we should of course improve this code as we move forward.
2023-06-11 16:02:37 +02:00
LibWeb: Make HTML::DecodedImageData to be GC-allocated This change fixes GC-leak caused by following mutual dependency: - SVGDecodedImageData owns JS::Handle for Page. - SVGDecodedImageData is owned by visited objects. by making everything inherited from HTML::DecodedImageData and ListOfAvailableImages to be GC-allocated. Generally, if visited object has a handle, very likely we leak everything visited from object in a handle.
2023-12-12 20:07:19 +01:00
JS::GCPtr<DecodedImageData> image_data() const;
LibWeb: Piggyback on HTML::ImageRequest in HTMLObjectElement Like the piggybacking in CSS, this is also totally ad-hoc, since there's no spec to follow. The code here is weird and definitely sub-optimal as we do a second load if it turns out the loaded resource is an image, but given that object elements are rarely used nowadays, I doubt we'll even notice. That said, we should of course improve this code as we move forward.
2023-06-11 16:02:37 +02:00
LibWeb: Rename SharedImageRequest to SharedResourceRequest For the SVG <use> element, we want to support loading HTML documents that have a SVG element inside of it pointed to by the URL fragment. In this situation we would need to fetch and parse the entire document in SharedImageRequest (so that we can still cache the SVGs). Rename SharedImageRequest to SharedResourceRequest to make the class a little more generic for future usecases.
2024-08-03 15:27:08 +12:00
JS::GCPtr<SharedResourceRequest> m_resource_request;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 22:24:49 +02:00
};
}
LibWeb: Add fast_is<T> for form, embed, image, and object elements These are used by Window::supported_property_names(), which can get very hot.
2023-12-24 14:41:33 +01:00
namespace Web::DOM {
template<>
inline bool Node::fast_is<HTML::HTMLObjectElement>() const { return is_html_object_element(); }
}
Reference in a new issue Copy permalink