Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/DOM/ElementFactory.cpp

726 lines
44 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
/*
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: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
* Copyright (c) 2020-2023, Luke Wilde <lukew@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+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
#include <LibWeb/DOM/Document.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/DOM/ElementFactory.h>
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
#include <LibWeb/HTML/CustomElements/CustomElementDefinition.h>
LibWeb: Return HTMLElement for valid custom element tag names
2023-03-23 04:28:25 -04:00
#include <LibWeb/HTML/CustomElements/CustomElementName.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLAnchorElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLAreaElement.h>
#include <LibWeb/HTML/HTMLAudioElement.h>
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
#include <LibWeb/HTML/HTMLBRElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLBaseElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLBodyElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLButtonElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLCanvasElement.h>
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
#include <LibWeb/HTML/HTMLDListElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLDataElement.h>
#include <LibWeb/HTML/HTMLDataListElement.h>
#include <LibWeb/HTML/HTMLDetailsElement.h>
#include <LibWeb/HTML/HTMLDialogElement.h>
LibWeb: Add almost all obsolete but required IDL attributes As according to https://html.spec.whatwg.org/multipage/obsolete.html Section 16.3 "Requirements for implementations" Not all of these attributes are included due to requiring a bit more functionality.
2020-11-12 04:16:41 +00:00
#include <LibWeb/HTML/HTMLDirectoryElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLDivElement.h>
#include <LibWeb/HTML/HTMLEmbedElement.h>
#include <LibWeb/HTML/HTMLFieldSetElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLFontElement.h>
#include <LibWeb/HTML/HTMLFormElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLFrameElement.h>
#include <LibWeb/HTML/HTMLFrameSetElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLHRElement.h>
#include <LibWeb/HTML/HTMLHeadElement.h>
#include <LibWeb/HTML/HTMLHeadingElement.h>
#include <LibWeb/HTML/HTMLHtmlElement.h>
#include <LibWeb/HTML/HTMLIFrameElement.h>
#include <LibWeb/HTML/HTMLImageElement.h>
#include <LibWeb/HTML/HTMLInputElement.h>
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
#include <LibWeb/HTML/HTMLLIElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLLabelElement.h>
#include <LibWeb/HTML/HTMLLegendElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLLinkElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLMapElement.h>
#include <LibWeb/HTML/HTMLMarqueeElement.h>
#include <LibWeb/HTML/HTMLMenuElement.h>
#include <LibWeb/HTML/HTMLMetaElement.h>
#include <LibWeb/HTML/HTMLMeterElement.h>
#include <LibWeb/HTML/HTMLModElement.h>
#include <LibWeb/HTML/HTMLOListElement.h>
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
#include <LibWeb/HTML/HTMLObjectElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLOptGroupElement.h>
#include <LibWeb/HTML/HTMLOptionElement.h>
#include <LibWeb/HTML/HTMLOutputElement.h>
#include <LibWeb/HTML/HTMLParagraphElement.h>
#include <LibWeb/HTML/HTMLParamElement.h>
#include <LibWeb/HTML/HTMLPictureElement.h>
#include <LibWeb/HTML/HTMLPreElement.h>
#include <LibWeb/HTML/HTMLProgressElement.h>
#include <LibWeb/HTML/HTMLQuoteElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLScriptElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLSelectElement.h>
#include <LibWeb/HTML/HTMLSlotElement.h>
#include <LibWeb/HTML/HTMLSourceElement.h>
#include <LibWeb/HTML/HTMLSpanElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLStyleElement.h>
LibWeb: Implement the <summary> element
2023-06-02 21:08:14 +02:00
#include <LibWeb/HTML/HTMLSummaryElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLTableCaptionElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLTableCellElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLTableColElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLTableElement.h>
#include <LibWeb/HTML/HTMLTableRowElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLTableSectionElement.h>
#include <LibWeb/HTML/HTMLTemplateElement.h>
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
#include <LibWeb/HTML/HTMLTextAreaElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLTimeElement.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLTitleElement.h>
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
#include <LibWeb/HTML/HTMLTrackElement.h>
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
#include <LibWeb/HTML/HTMLUListElement.h>
#include <LibWeb/HTML/HTMLUnknownElement.h>
#include <LibWeb/HTML/HTMLVideoElement.h>
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
#include <LibWeb/HTML/Scripting/ExceptionReporter.h>
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
#include <LibWeb/HTML/WindowOrWorkerGlobalScope.h>
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
#include <LibWeb/Infra/Strings.h>
LibWeb: Generate MathML Elements We will now generate MathML elements when parsing HTML.
2023-07-05 20:25:52 -05:00
#include <LibWeb/MathML/MathMLElement.h>
#include <LibWeb/MathML/TagNames.h>
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
#include <LibWeb/Namespace.h>
LibWeb: Add the bare minimum to render SVGAElement (`<a>`)
2024-06-23 17:05:47 +02:00
#include <LibWeb/SVG/SVGAElement.h>
LibWeb: Add SVG `<circle>` element and test case :^)
2022-02-11 16:14:58 +00:00
#include <LibWeb/SVG/SVGCircleElement.h>
LibWeb: Sketch out a very basic SVG <clipPath> element This element doesn't actually support anything at the moment, but it still massively speeds up painting performance on Wikipedia! :^) How? Because we no longer paint SVG <path> elements found inside <clipPath> elements. SVGClipPathElement::create_layout_node() returns nullptr which stops the layout tree builder from recursing further into the subtree, and so the <path> element never gets a layout or paint box. Mousing over Wikipedia now barely break 50% CPU usage on my machine :^)
2022-04-10 19:05:12 +02:00
#include <LibWeb/SVG/SVGClipPathElement.h>
LibWeb: Add SVGDefsElement * Similarly to clipPath, this doesn't need to get rendered, so return no LayoutNode.
2022-04-11 16:59:03 +02:00
#include <LibWeb/SVG/SVGDefsElement.h>
LibWeb: Implement <desc> SVG element
2024-04-15 18:43:01 +01:00
#include <LibWeb/SVG/SVGDescElement.h>
LibWeb: Add SVG `<ellipse>` element and test case :^)
2022-02-11 16:45:59 +00:00
#include <LibWeb/SVG/SVGEllipseElement.h>
LibWeb/SVG: Add FEBlendElement
2025-07-04 20:55:08 +02:00
#include <LibWeb/SVG/SVGFEBlendElement.h>
LibWeb: Implement `<feComposite>` SVG filter
2025-08-06 13:27:50 +01:00
#include <LibWeb/SVG/SVGFECompositeElement.h>
LibWeb/SVG: Add FEFloodElement
2025-07-06 21:48:55 +02:00
#include <LibWeb/SVG/SVGFEFloodElement.h>
LibWeb/SVG: Add FEGaussianBlurElement
2025-07-04 21:08:28 +02:00
#include <LibWeb/SVG/SVGFEGaussianBlurElement.h>
LibWeb: Implement `<feImage>` SVG filter
2025-08-06 22:52:29 +01:00
#include <LibWeb/SVG/SVGFEImageElement.h>
LibWeb: Implement `<feMerge>` SVG filter
2025-08-06 16:29:28 +02:00
#include <LibWeb/SVG/SVGFEMergeElement.h>
#include <LibWeb/SVG/SVGFEMergeNodeElement.h>
LibWeb: Implement `<feOffset>` SVG filter
2025-08-06 13:53:50 +02:00
#include <LibWeb/SVG/SVGFEOffsetElement.h>
LibWeb: Add SVGFilterElement
2025-02-21 13:22:48 +01:00
#include <LibWeb/SVG/SVGFilterElement.h>
LibWeb: Sketch out basic support for SVG <foreignObject> elements This patch adds basic DOM construction and IDL bindings for foreign objects in SVG trees.
2022-11-10 13:49:26 +01:00
#include <LibWeb/SVG/SVGForeignObjectElement.h>
LibWeb: Add a bare-bones SVG <g> element
2021-09-18 00:04:19 +02:00
#include <LibWeb/SVG/SVGGElement.h>
LibWeb/SVG: Implement `SVGImageElement` This element allows images to be embedded within SVGs.
2024-08-20 15:12:55 +01:00
#include <LibWeb/SVG/SVGImageElement.h>
LibWeb: Add SVG `<line>` element and test case :^)
2022-02-11 16:56:36 +00:00
#include <LibWeb/SVG/SVGLineElement.h>
LibWeb: Implement SVGLinearGradientElement (<linearGradient>) This represents the SVG <linearGradient>. The actual gradient is converted to a Gfx::PaintStyle for use in SVG fills... There is a little guesswork in the implementation, but it seems to match Chrome/Firefox. Note: Still not hooked up to actual painting in this commit.
2023-04-22 18:51:00 +01:00
#include <LibWeb/SVG/SVGLinearGradientElement.h>
LibWeb: Stub out SVGMaskElement Just enough that we stop creating layout nodes for mask elements, which was making some SVG content look very wrong. :^)
2023-08-10 09:55:15 +02:00
#include <LibWeb/SVG/SVGMaskElement.h>
LibWeb/SVG: Implement <metadata> element
2024-08-16 17:27:32 +01:00
#include <LibWeb/SVG/SVGMetadataElement.h>
LibWeb: Refactor SVG files into their own directory; follow spec layout
2020-07-23 09:44:42 -07:00
#include <LibWeb/SVG/SVGPathElement.h>
LibWeb: Add SVG `<polygon>` element and test case :^)
2022-02-11 17:36:05 +00:00
#include <LibWeb/SVG/SVGPolygonElement.h>
LibWeb: Add SVG `<polyline>` element and test case :^)
2022-02-11 17:28:24 +00:00
#include <LibWeb/SVG/SVGPolylineElement.h>
LibWeb: Add an initial implementation of SVG `<radialGradient>` This follows on from the SVG linear gradients. It supports the same features (xlink:href, gradientUnits, gradientTransform). With this commit I have now implemented all web gradients :^) (Though we are still missing a few parameters for SVG gradients, e.g. spreadMethod).
2023-05-02 23:11:58 +01:00
#include <LibWeb/SVG/SVGRadialGradientElement.h>
LibWeb: Add SVG `<rect>` element and test case :^)
2022-02-11 15:52:42 +00:00
#include <LibWeb/SVG/SVGRectElement.h>
LibWeb: Refactor SVG files into their own directory; follow spec layout
2020-07-23 09:44:42 -07:00
#include <LibWeb/SVG/SVGSVGElement.h>
LibWeb: Add IDL definition for SVGScriptElement It does not currently handle any of the actual scripting, but this should at least allow us to create an instance of the element. The test being added here isn't actually testing much, but before the previous commit we used to crash parsing the page due to a TODO().
2023-09-23 08:56:49 +12:00
#include <LibWeb/SVG/SVGScriptElement.h>
LibWeb: Implement SVGStopElement (<stop>) This is used to specify the color/position of color stops for SVG gradients.
2023-04-20 18:51:00 +01:00
#include <LibWeb/SVG/SVGStopElement.h>
LibWeb: Implement the `<style>` SVG element The `<style>` element is allowed to be in the SVG namespace, so we now support this element. It has the same behaviour as the HTML namespace `<style>` element as described in the spec. "The semantics and processing of a ‘style’ and its attributes must be the same as is defined for the HTML ‘style’ element."
2023-06-08 17:48:33 +01:00
#include <LibWeb/SVG/SVGStyleElement.h>
LibWeb: Implement the `<symbol>` SVG element
2023-05-31 00:50:12 +01:00
#include <LibWeb/SVG/SVGSymbolElement.h>
LibWeb: Add support for SVG <tspan> elements
2023-07-22 19:34:51 +01:00
#include <LibWeb/SVG/SVGTSpanElement.h>
LibWeb: Split SVGTextContentElement into spec defined subclasses As part of this move properties/methods to the correct subclass (position related properties go under SVGTextPositioningElement). SVG text element hierarchy: SVGTextContentElement ^- SVGTextPositioningElement ^- SVGTextElement ^- SVGTSpanElement ^- SVGTextPathElement (TODO) ^- SVGTRefElement (TODO)
2023-07-22 19:24:55 +01:00
#include <LibWeb/SVG/SVGTextElement.h>
LibWeb: Add initial support for SVG `<textPath>` This patch adds basic support for the SVG `<textPath>`, so it supports placing text along a path, but none of the extra attributes for controlling the layout of the text. This is enough to correctly display the MDN example.
2023-12-17 18:35:21 +00:00
#include <LibWeb/SVG/SVGTextPathElement.h>
LibWeb: Implement the SVG title element
2023-06-08 11:46:44 -04:00
#include <LibWeb/SVG/SVGTitleElement.h>
LibWeb: Implement the `<use>` SVG element The SVG <use> element is used to be able to reuse other SVG graphics without having to re-write the svg element. We now support this feature! :^)
2023-05-30 21:23:52 +01:00
#include <LibWeb/SVG/SVGUseElement.h>
LibWeb: Implement `SVGViewElement` This identifies a particular region of an SVG image, which can then be linked to by an SVG fragment identifier.
2025-07-12 14:26:50 +01:00
#include <LibWeb/SVG/SVGViewElement.h>
LibWeb: Refactor SVG files into their own directory; follow spec layout
2020-07-23 09:44:42 -07:00
#include <LibWeb/SVG/TagNames.h>
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
#include <LibWeb/WebIDL/AbstractOperations.h>
LibHTML: Move Element construction to a separate file We now have create_element(document, tag_name) in ElementFactory. This will be useful for constructing new elements outside of parsing.
2019-10-12 13:02:38 +02:00
LibWeb: Move DOM classes into the Web::DOM namespace LibWeb keeps growing and the Web namespace is filling up fast. Let's put DOM stuff into Web::DOM, just like we already started doing with SVG stuff in Web::SVG.
2020-07-26 19:37:56 +02:00
namespace Web::DOM {
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
ErrorOr<FixedArray<FlyString>> valid_local_names_for_given_html_element_interface(StringView html_element_interface_name)
LibHTML: Move Element construction to a separate file We now have create_element(document, tag_name) in ElementFactory. This will be useful for constructing new elements outside of parsing.
2019-10-12 13:02:38 +02:00
{
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLAnchorElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::a });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLAreaElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::area });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLAudioElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::audio });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLBaseElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::base });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLBodyElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::body });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLBRElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::br });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLButtonElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::button });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLCanvasElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::canvas });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLDataElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::data });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLDataListElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::datalist });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLDetailsElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::details });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLDialogElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::dialog });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLDirectoryElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::dir });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLDivElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::div });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLDListElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::dl });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLEmbedElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::embed });
LibWeb: Fix various local names for custom elements This fixes the typo in `HTMLFieldSetElement` and adds valid local names for `<meta>`, `<ol>` and `<optgroup>`.
2024-11-26 13:12:50 +01:00
if (html_element_interface_name == "HTMLFieldSetElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::fieldset });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLFontElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::font });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLFormElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::form });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLFrameElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::frame });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLFrameSetElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::frameset });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLHeadElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::head });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLHeadingElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::h1, HTML::TagNames::h2, HTML::TagNames::h3, HTML::TagNames::h4, HTML::TagNames::h5, HTML::TagNames::h6 });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLHRElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::hr });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLHtmlElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::html });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLIFrameElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::iframe });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLImageElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::img });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLInputElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::input });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLLabelElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::label });
LibWeb: Add missing elements to valid local name map Previously, attempting to create a custom element that extended any of these elements would fail.
2025-02-02 14:44:17 +00:00
if (html_element_interface_name == "HTMLLegendElement"sv)
return FixedArray<FlyString>::create({ HTML::TagNames::legend });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLLIElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::li });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLLinkElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::link });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLMapElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::map });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLMarqueeElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::marquee });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLMenuElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::menu });
LibWeb: Fix various local names for custom elements This fixes the typo in `HTMLFieldSetElement` and adds valid local names for `<meta>`, `<ol>` and `<optgroup>`.
2024-11-26 13:12:50 +01:00
if (html_element_interface_name == "HTMLMetaElement"sv)
return FixedArray<FlyString>::create({ HTML::TagNames::meta });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLMeterElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::meter });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLModElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::ins, HTML::TagNames::del });
LibWeb: Fix various local names for custom elements This fixes the typo in `HTMLFieldSetElement` and adds valid local names for `<meta>`, `<ol>` and `<optgroup>`.
2024-11-26 13:12:50 +01:00
if (html_element_interface_name == "HTMLOListElement"sv)
return FixedArray<FlyString>::create({ HTML::TagNames::ol });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLObjectElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::object });
LibWeb: Fix various local names for custom elements This fixes the typo in `HTMLFieldSetElement` and adds valid local names for `<meta>`, `<ol>` and `<optgroup>`.
2024-11-26 13:12:50 +01:00
if (html_element_interface_name == "HTMLOptGroupElement"sv)
return FixedArray<FlyString>::create({ HTML::TagNames::optgroup });
LibWeb: Add missing elements to valid local name map Previously, attempting to create a custom element that extended any of these elements would fail.
2025-02-02 14:44:17 +00:00
if (html_element_interface_name == "HTMLOptionElement"sv)
return FixedArray<FlyString>::create({ HTML::TagNames::option });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLOutputElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::output });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLParagraphElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::p });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLParamElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::param });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLPictureElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::picture });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLPreElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::pre, HTML::TagNames::listing, HTML::TagNames::xmp });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLProgressElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::progress });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLQuoteElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::blockquote, HTML::TagNames::q });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLScriptElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::script });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLSelectElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::select });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLSlotElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::slot });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLSourceElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::source });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLSpanElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::span });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLStyleElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::style });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTableCaptionElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::caption });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTableCellElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::td, HTML::TagNames::th });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTableColElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::colgroup, HTML::TagNames::col });
LibWeb: Add missing elements to valid local name map Previously, attempting to create a custom element that extended any of these elements would fail.
2025-02-02 14:44:17 +00:00
if (html_element_interface_name == "HTMLTableRowElement"sv)
return FixedArray<FlyString>::create({ HTML::TagNames::tr });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTableElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::table });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTableSectionElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::tbody, HTML::TagNames::thead, HTML::TagNames::tfoot });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTemplateElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::template_ });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTextAreaElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::textarea });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTimeElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::time });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTitleElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::title });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLTrackElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::track });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLUListElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::ul });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLVideoElement"sv)
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({ HTML::TagNames::video });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (html_element_interface_name == "HTMLElement"sv)
LibWeb: Add the search element
2024-11-19 20:03:15 +01:00
return FixedArray<FlyString>::create({ HTML::TagNames::article, HTML::TagNames::search, HTML::TagNames::section, HTML::TagNames::nav, HTML::TagNames::aside, HTML::TagNames::hgroup, HTML::TagNames::header, HTML::TagNames::footer, HTML::TagNames::address, HTML::TagNames::dt, HTML::TagNames::dd, HTML::TagNames::figure, HTML::TagNames::figcaption, HTML::TagNames::main, HTML::TagNames::em, HTML::TagNames::strong, HTML::TagNames::small, HTML::TagNames::s, HTML::TagNames::cite, HTML::TagNames::dfn, HTML::TagNames::abbr, HTML::TagNames::ruby, HTML::TagNames::rt, HTML::TagNames::rp, HTML::TagNames::code, HTML::TagNames::var, HTML::TagNames::samp, HTML::TagNames::kbd, HTML::TagNames::sub, HTML::TagNames::sup, HTML::TagNames::i, HTML::TagNames::b, HTML::TagNames::u, HTML::TagNames::mark, HTML::TagNames::bdi, HTML::TagNames::bdo, HTML::TagNames::wbr, HTML::TagNames::summary, HTML::TagNames::noscript, HTML::TagNames::acronym, HTML::TagNames::basefont, HTML::TagNames::big, HTML::TagNames::center, HTML::TagNames::nobr, HTML::TagNames::noembed, HTML::TagNames::noframes, HTML::TagNames::plaintext, HTML::TagNames::rb, HTML::TagNames::rtc, HTML::TagNames::strike, HTML::TagNames::tt });
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
return FixedArray<FlyString>::create({});
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
}
LibWeb: Use the prefix passed to Document.createElementNS() 1% progression on ACID3. :^)
2022-02-25 21:29:12 +01:00
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// https://html.spec.whatwg.org/multipage/dom.html#elements-in-the-dom%3Aelement-interface
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
bool is_unknown_html_element(FlyString const& tag_name)
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
{
// NOTE: This is intentionally case-sensitive.
LibWeb: Use the prefix passed to Document.createElementNS() 1% progression on ACID3. :^)
2022-02-25 21:29:12 +01:00
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 1. If name is applet, bgsound, blink, isindex, keygen, multicol, nextid, or spacer, then return HTMLUnknownElement.
if (tag_name.is_one_of(HTML::TagNames::applet, HTML::TagNames::bgsound, HTML::TagNames::blink, HTML::TagNames::isindex, HTML::TagNames::keygen, HTML::TagNames::multicol, HTML::TagNames::nextid, HTML::TagNames::spacer))
return true;
LibWeb: Support (and validate) prefixes in Document.createElementNS() 1% progression on ACID3. :^)
2022-03-02 10:55:16 +01:00
Everywhere: Run clang-format The following command was used to clang-format these files: clang-format-19 -i $(find . \ -not \( -path "./\.*" -prune \) \ -not \( -path "./Build/*" -prune \) \ -not \( -path "./Toolchain/*" -prune \) \ -type f -name "*.cpp" -o -name "*.mm" -o -name "*.h")
2024-12-27 18:47:33 -05:00
// 2. If name is acronym, basefont, big, center, nobr, noembed, noframes, plaintext, rb, rtc, strike, or tt, then return HTMLElement.
// 3. If name is listing or xmp, then return HTMLPreElement.
// 4. Otherwise, if this specification defines an interface appropriate for the element type corresponding to the local name name, then return that interface.
// 5. If other applicable specifications define an appropriate interface for name, then return the interface they define.
LibWeb: Remove the initialize_strings methods We added these methods to propagate OOM errors at process startup, but we longer fret about these tiny OOM failures. Requiring that these init methods be called prohibits using these strings in processes that have not set up a MainThreadVM. So let's just remove them and initialize the strings in a sane manner. In doing so, this also standardizes how we initialize strings whose C++ variable name differs from their string value. Instead of special-casing these strings, we just include their string value in the x-macro list.
2025-01-11 14:07:41 -05:00
#define __ENUMERATE_HTML_TAG(name, tag) \
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (tag_name == HTML::TagNames::name) \
return false;
ENUMERATE_HTML_TAGS
#undef __ENUMERATE_HTML_TAG
// 6. If name is a valid custom element name, then return HTMLElement.
if (HTML::is_valid_custom_element_name(tag_name))
return false;
// 7. Return HTMLUnknownElement.
return true;
}
Meta: Disallow links to single-page HTML spec
2025-02-04 13:01:46 +01:00
// https://html.spec.whatwg.org/multipage/dom.html#elements-in-the-dom%3Aelement-interface
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-15 04:01:23 +13:00
static GC::Ref<Element> create_html_element(JS::Realm& realm, Document& document, QualifiedName qualified_name)
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
{
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
FlyString tag_name = qualified_name.local_name();
LibWeb: Support (and validate) prefixes in Document.createElementNS() 1% progression on ACID3. :^)
2022-03-02 10:55:16 +01:00
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::a)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLAnchorElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::area)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLAreaElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::audio)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLAudioElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::base)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLBaseElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::body)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLBodyElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::br)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLBRElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::button)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLButtonElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::canvas)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLCanvasElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::data)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLDataElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::datalist)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLDataListElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::details)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLDetailsElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::dialog)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLDialogElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::dir)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLDirectoryElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::div)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLDivElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::dl)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLDListElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::embed)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLEmbedElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::fieldset)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLFieldSetElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::font)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLFontElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::form)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLFormElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::frame)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLFrameElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::frameset)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLFrameSetElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::head)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLHeadElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(HTML::TagNames::h1, HTML::TagNames::h2, HTML::TagNames::h3, HTML::TagNames::h4, HTML::TagNames::h5, HTML::TagNames::h6))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLHeadingElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::hr)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLHRElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::html)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLHtmlElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::iframe)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLIFrameElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::img)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLImageElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::input)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLInputElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::label)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLLabelElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::legend)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLLegendElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::li)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLLIElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::link)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLLinkElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::map)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLMapElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::marquee)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLMarqueeElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::menu)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLMenuElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::meta)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLMetaElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::meter)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLMeterElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(HTML::TagNames::ins, HTML::TagNames::del))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLModElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::object)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLObjectElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::ol)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLOListElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::optgroup)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLOptGroupElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::option)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLOptionElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::output)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLOutputElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::p)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLParagraphElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::param)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLParamElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::picture)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLPictureElement>(document, move(qualified_name));
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
// NOTE: The obsolete elements "listing" and "xmp" are explicitly mapped to HTMLPreElement in the specification.
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(HTML::TagNames::pre, HTML::TagNames::listing, HTML::TagNames::xmp))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLPreElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::progress)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLProgressElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(HTML::TagNames::blockquote, HTML::TagNames::q))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLQuoteElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::script)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLScriptElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::select)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLSelectElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::slot)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLSlotElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::source)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLSourceElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::span)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLSpanElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::style)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLStyleElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::summary)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLSummaryElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::caption)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTableCaptionElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(Web::HTML::TagNames::td, Web::HTML::TagNames::th))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTableCellElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(HTML::TagNames::colgroup, HTML::TagNames::col))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTableColElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::table)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTableElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::tr)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTableRowElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(HTML::TagNames::tbody, HTML::TagNames::thead, HTML::TagNames::tfoot))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTableSectionElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::template_)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTemplateElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::textarea)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTextAreaElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::time)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTimeElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::title)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTitleElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::track)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLTrackElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::ul)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLUListElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name == HTML::TagNames::video)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLVideoElement>(document, move(qualified_name));
LibWeb: Make `document.createElementNS()` case-sensitive Previously, when creating a HTML element with `document.createElementNS()` we would convert the given local name to lowercase before deciding which element type to return. We now no longer perform this lower case conversion, so if an uppercase local name is provided, an element of type `HTMLUnknownElement` will be returned. This aligns our implementation with the specification.
2024-07-24 23:55:15 +01:00
if (tag_name.is_one_of(
LibWeb: Add the search element
2024-11-19 20:03:15 +01:00
HTML::TagNames::article, HTML::TagNames::search, HTML::TagNames::section, HTML::TagNames::nav, HTML::TagNames::aside, HTML::TagNames::hgroup, HTML::TagNames::header, HTML::TagNames::footer, HTML::TagNames::address, HTML::TagNames::dt, HTML::TagNames::dd, HTML::TagNames::figure, HTML::TagNames::figcaption, HTML::TagNames::main, HTML::TagNames::em, HTML::TagNames::strong, HTML::TagNames::small, HTML::TagNames::s, HTML::TagNames::cite, HTML::TagNames::dfn, HTML::TagNames::abbr, HTML::TagNames::ruby, HTML::TagNames::rt, HTML::TagNames::rp, HTML::TagNames::code, HTML::TagNames::var, HTML::TagNames::samp, HTML::TagNames::kbd, HTML::TagNames::sub, HTML::TagNames::sup, HTML::TagNames::i, HTML::TagNames::b, HTML::TagNames::u, HTML::TagNames::mark, HTML::TagNames::bdi, HTML::TagNames::bdo, HTML::TagNames::wbr, HTML::TagNames::noscript,
Meta+LibHTTP through LibWeb: Make clang-format-10 clean
2020-09-18 09:49:51 +02:00
// Obsolete
HTML::TagNames::acronym, HTML::TagNames::basefont, HTML::TagNames::big, HTML::TagNames::center, HTML::TagNames::nobr, HTML::TagNames::noembed, HTML::TagNames::noframes, HTML::TagNames::plaintext, HTML::TagNames::rb, HTML::TagNames::rtc, HTML::TagNames::strike, HTML::TagNames::tt))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (HTML::is_valid_custom_element_name(qualified_name.local_name()))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<HTML::HTMLUnknownElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
}
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-15 04:01:23 +13:00
static GC::Ref<SVG::SVGElement> create_svg_element(JS::Realm& realm, Document& document, QualifiedName qualified_name)
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
{
LibWeb: Port SVG::TagNames from DeprecatedFlyString
2023-10-08 14:17:34 +13:00
auto const& local_name = qualified_name.local_name();
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::svg)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGSVGElement>(document, move(qualified_name));
LibWeb: Sketch out a very basic SVG <clipPath> element This element doesn't actually support anything at the moment, but it still massively speeds up painting performance on Wikipedia! :^) How? Because we no longer paint SVG <path> elements found inside <clipPath> elements. SVGClipPathElement::create_layout_node() returns nullptr which stops the layout tree builder from recursing further into the subtree, and so the <path> element never gets a layout or paint box. Mousing over Wikipedia now barely break 50% CPU usage on my machine :^)
2022-04-10 19:05:12 +02:00
// FIXME: Support SVG's mixedCase tag names properly.
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name.equals_ignoring_ascii_case(SVG::TagNames::clipPath))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGClipPathElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::circle)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGCircleElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name.equals_ignoring_ascii_case(SVG::TagNames::defs))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGDefsElement>(document, move(qualified_name));
LibWeb: Implement <desc> SVG element
2024-04-15 18:43:01 +01:00
if (local_name == SVG::TagNames::desc)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGDescElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::ellipse)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGEllipseElement>(document, move(qualified_name));
LibWeb/SVG: Add FEBlendElement
2025-07-04 20:55:08 +02:00
if (local_name == SVG::TagNames::feBlend)
return realm.create<SVG::SVGFEBlendElement>(document, move(qualified_name));
LibWeb: Implement `<feComposite>` SVG filter
2025-08-06 13:27:50 +01:00
if (local_name == SVG::TagNames::feComposite)
return realm.create<SVG::SVGFECompositeElement>(document, move(qualified_name));
LibWeb/SVG: Add FEFloodElement
2025-07-06 21:48:55 +02:00
if (local_name == SVG::TagNames::feFlood)
return realm.create<SVG::SVGFEFloodElement>(document, move(qualified_name));
LibWeb/SVG: Add FEGaussianBlurElement
2025-07-04 21:08:28 +02:00
if (local_name == SVG::TagNames::feGaussianBlur)
return realm.create<SVG::SVGFEGaussianBlurElement>(document, move(qualified_name));
LibWeb: Implement `<feImage>` SVG filter
2025-08-06 22:52:29 +01:00
if (local_name == SVG::TagNames::feImage)
return realm.create<SVG::SVGFEImageElement>(document, move(qualified_name));
LibWeb: Implement `<feMerge>` SVG filter
2025-08-06 16:29:28 +02:00
if (local_name == SVG::TagNames::feMerge)
return realm.create<SVG::SVGFEMergeElement>(document, move(qualified_name));
if (local_name == SVG::TagNames::feMergeNode)
return realm.create<SVG::SVGFEMergeNodeElement>(document, move(qualified_name));
LibWeb: Implement `<feOffset>` SVG filter
2025-08-06 13:53:50 +02:00
if (local_name == SVG::TagNames::feOffset)
return realm.create<SVG::SVGFEOffsetElement>(document, move(qualified_name));
LibWeb: Add SVGFilterElement
2025-02-21 13:22:48 +01:00
if (local_name == SVG::TagNames::filter)
return realm.create<SVG::SVGFilterElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name.equals_ignoring_ascii_case(SVG::TagNames::foreignObject))
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGForeignObjectElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::line)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGLineElement>(document, move(qualified_name));
LibWeb: Implement SVGLinearGradientElement (<linearGradient>) This represents the SVG <linearGradient>. The actual gradient is converted to a Gfx::PaintStyle for use in SVG fills... There is a little guesswork in the implementation, but it seems to match Chrome/Firefox. Note: Still not hooked up to actual painting in this commit.
2023-04-22 18:51:00 +01:00
if (local_name == SVG::TagNames::linearGradient)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGLinearGradientElement>(document, move(qualified_name));
LibWeb: Stub out SVGMaskElement Just enough that we stop creating layout nodes for mask elements, which was making some SVG content look very wrong. :^)
2023-08-10 09:55:15 +02:00
if (local_name == SVG::TagNames::mask)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGMaskElement>(document, move(qualified_name));
LibWeb/SVG: Implement <metadata> element
2024-08-16 17:27:32 +01:00
if (local_name == SVG::TagNames::metadata)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGMetadataElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::path)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGPathElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::polygon)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGPolygonElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::polyline)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGPolylineElement>(document, move(qualified_name));
LibWeb: Add an initial implementation of SVG `<radialGradient>` This follows on from the SVG linear gradients. It supports the same features (xlink:href, gradientUnits, gradientTransform). With this commit I have now implemented all web gradients :^) (Though we are still missing a few parameters for SVG gradients, e.g. spreadMethod).
2023-05-02 23:11:58 +01:00
if (local_name == SVG::TagNames::radialGradient)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGRadialGradientElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::rect)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGRectElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::g)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGGElement>(document, move(qualified_name));
LibWeb: Implement SVGStopElement (<stop>) This is used to specify the color/position of color stops for SVG gradients.
2023-04-20 18:51:00 +01:00
if (local_name == SVG::TagNames::stop)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGStopElement>(document, move(qualified_name));
LibWeb: Implement the `<style>` SVG element The `<style>` element is allowed to be in the SVG namespace, so we now support this element. It has the same behaviour as the HTML namespace `<style>` element as described in the spec. "The semantics and processing of a ‘style’ and its attributes must be the same as is defined for the HTML ‘style’ element."
2023-06-08 17:48:33 +01:00
if (local_name == SVG::TagNames::style)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGStyleElement>(document, move(qualified_name));
LibWeb: Implement the `<symbol>` SVG element
2023-05-31 00:50:12 +01:00
if (local_name == SVG::TagNames::symbol)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGSymbolElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (local_name == SVG::TagNames::text)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGTextElement>(document, move(qualified_name));
LibWeb: Add initial support for SVG `<textPath>` This patch adds basic support for the SVG `<textPath>`, so it supports placing text along a path, but none of the extra attributes for controlling the layout of the text. This is enough to correctly display the MDN example.
2023-12-17 18:35:21 +00:00
if (local_name == SVG::TagNames::textPath)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGTextPathElement>(document, move(qualified_name));
LibWeb: Implement the SVG title element
2023-06-08 11:46:44 -04:00
if (local_name == SVG::TagNames::title)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGTitleElement>(document, move(qualified_name));
LibWeb: Add support for SVG <tspan> elements
2023-07-22 19:34:51 +01:00
if (local_name == SVG::TagNames::tspan)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGTSpanElement>(document, move(qualified_name));
LibWeb: Implement the `<use>` SVG element The SVG <use> element is used to be able to reuse other SVG graphics without having to re-write the svg element. We now support this feature! :^)
2023-05-30 21:23:52 +01:00
if (local_name == SVG::TagNames::use)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGUseElement>(document, move(qualified_name));
LibWeb: Add IDL definition for SVGScriptElement It does not currently handle any of the actual scripting, but this should at least allow us to create an instance of the element. The test being added here isn't actually testing much, but before the previous commit we used to crash parsing the page due to a TODO().
2023-09-23 08:56:49 +12:00
if (local_name == SVG::TagNames::script)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGScriptElement>(document, move(qualified_name));
LibWeb: Implement `SVGViewElement` This identifies a particular region of an SVG image, which can then be linked to by an SVG fragment identifier.
2025-07-12 14:26:50 +01:00
if (local_name == SVG::TagNames::view)
return realm.create<SVG::SVGViewElement>(document, move(qualified_name));
LibWeb: Add the bare minimum to render SVGAElement (`<a>`)
2024-06-23 17:05:47 +02:00
if (local_name == SVG::TagNames::a)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGAElement>(document, move(qualified_name));
LibWeb/SVG: Implement `SVGImageElement` This element allows images to be embedded within SVGs.
2024-08-20 15:12:55 +01:00
if (local_name == SVG::TagNames::image)
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGImageElement>(document, move(qualified_name));
LibWeb: Add HTML elements to factories, add missing tags and attributes This is mostly to get the grunt work of the way. This is split up into multiple commits to hopefully make it more manageable to review. Note that these are not full implementations, and the bindings mostly get the low hanging fruit. Also implements some attributes that I kept out because they had dashes in them. Therefore, this closes #2905.
2020-08-09 17:10:41 +01:00
LibWeb: Use right interface for custom SVG and MathML elements The DOM spec gets overridden by both the SVG2 and MathML core specs in that unknown elements should not inherit DOM::Element, but SVG::SVGElement and MathML::MathMLElement respectively.
2024-10-31 10:35:07 +01:00
// https://svgwg.org/svg2-draft/types.html#ElementsInTheSVGDOM
// Elements in the SVG namespace whose local name does not match an element defined in any
// specification supported by the software must nonetheless implement the SVGElement interface.
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<SVG::SVGElement>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
}
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-15 04:01:23 +13:00
static GC::Ref<MathML::MathMLElement> create_mathml_element(JS::Realm& realm, Document& document, QualifiedName qualified_name)
LibWeb: Generate MathML Elements We will now generate MathML elements when parsing HTML.
2023-07-05 20:25:52 -05:00
{
LibWeb: Use right interface for custom SVG and MathML elements The DOM spec gets overridden by both the SVG2 and MathML core specs in that unknown elements should not inherit DOM::Element, but SVG::SVGElement and MathML::MathMLElement respectively.
2024-10-31 10:35:07 +01:00
// https://w3c.github.io/mathml-core/#dom-and-javascript
// All the nodes representing MathML elements in the DOM must implement, and expose to scripts,
// the following MathMLElement interface.
LibWeb: Generate MathML Elements We will now generate MathML elements when parsing HTML.
2023-07-05 20:25:52 -05:00
LibWeb: Use right interface for custom SVG and MathML elements The DOM spec gets overridden by both the SVG2 and MathML core specs in that unknown elements should not inherit DOM::Element, but SVG::SVGElement and MathML::MathMLElement respectively.
2024-10-31 10:35:07 +01:00
// https://w3c.github.io/mathml-core/#mathml-elements-and-attributes
// The term MathML element refers to any element in the MathML namespace.
LibWeb: Generate MathML Elements We will now generate MathML elements when parsing HTML.
2023-07-05 20:25:52 -05:00
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<MathML::MathMLElement>(document, move(qualified_name));
LibWeb: Generate MathML Elements We will now generate MathML elements when parsing HTML.
2023-07-05 20:25:52 -05:00
}
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// https://dom.spec.whatwg.org/#concept-create-element
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-15 04:01:23 +13:00
WebIDL::ExceptionOr<GC::Ref<Element>> create_element(Document& document, FlyString local_name, Optional<FlyString> namespace_, Optional<FlyString> prefix, Optional<String> is_value, bool synchronous_custom_elements_flag)
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
{
auto& realm = document.realm();
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 1. Let result be null.
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// NOTE: We collapse this into just returning an element where necessary.
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 2. Let definition be the result of looking up a custom element definition given document, namespace, localName, and is.
LibWeb: Pass DOM namespace strings as FlyString in more places
2023-11-04 10:19:21 +01:00
auto definition = document.lookup_custom_element_definition(namespace_, local_name, is_value);
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 3. If definition is non-null, and definition’s name is not equal to its local name (i.e., definition represents a customized built-in element), then:
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (definition && definition->name() != definition->local_name()) {
// 1. Let interface be the element interface for localName and the HTML namespace.
// 2. Set result to a new element that implements interface, with no attributes, namespace set to the HTML namespace,
// namespace prefix set to prefix, local name set to localName, custom element state set to "undefined", custom element definition set to null,
// is value set to is, and node document set to document.
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
auto element = create_html_element(realm, document, QualifiedName { local_name, prefix, Namespace::HTML });
LibWeb: Set `is` value when creating a customized built-in element
2025-02-02 14:45:26 +00:00
element->set_is_value(is_value);
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 3. If the synchronous custom elements flag is set, then run this step while catching any exceptions:
if (synchronous_custom_elements_flag) {
// 1. Upgrade element using definition.
auto upgrade_result = element->upgrade_element(*definition);
// If this step threw an exception, then:
if (upgrade_result.is_throw_completion()) {
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 1. Report exception for definition’s constructor’s corresponding JavaScript object’s associated realm’s global object.
auto& window_or_worker = as<HTML::WindowOrWorkerGlobalScopeMixin>(HTML::relevant_global_object(definition->constructor().callback));
window_or_worker.report_an_exception(upgrade_result.error_value());
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 2. Set result’s custom element state to "failed".
element->set_custom_element_state(CustomElementState::Failed);
}
}
// 4. Otherwise, enqueue a custom element upgrade reaction given result and definition.
else {
element->enqueue_a_custom_element_upgrade_reaction(*definition);
}
return element;
LibWeb: Return HTMLElement for valid custom element tag names
2023-03-23 04:28:25 -04:00
}
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 4. Otherwise, if definition is non-null, then:
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (definition) {
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 1. If synchronousCustomElements is true, then run these steps while catching any exceptions:
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
if (synchronous_custom_elements_flag) {
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-15 04:01:23 +13:00
auto synchronously_upgrade_custom_element = [&]() -> JS::ThrowCompletionOr<GC::Ref<HTML::HTMLElement>> {
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 1. Let C be definition’s constructor.
auto& constructor = definition->constructor();
// 2. Set result to the result of constructing C, with no arguments.
LibWeb: Do not create a RootVector to invoke IDL callbacks These callbacks are evaluated synchronously via JS::Call. We do not need to construct an expensive RootVector container just to immediately invoke the callbacks. Stylistically, this also helps indicate where the actual arguments start at the call sites, by wrapping the arguments in braces.
2025-04-15 20:56:03 -04:00
auto result = TRY(WebIDL::construct(constructor, {}));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
LibWeb: Verify element namespace in DOM::create_element()
2025-01-09 21:36:40 +01:00
// NOTE: IDL does not currently convert the object for us, so we will have to do it here.
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
if (!result.is_object() || !is<HTML::HTMLElement>(result.as_object()))
LibWeb: Don't crash when upgrading custom element with a bad constructor Previously, a crash would occur when attempting to throw an error in this case because the method used to create the exception tried to get the current realm from the execution context stack, which is empty. The realm is now passed explicitly when constructing the error, avoiding the crash.
2025-01-12 17:17:21 +00:00
return JS::throw_completion(JS::TypeError::create(realm, "Custom element constructor must return an object that implements HTMLElement"_string));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
GC::Ref<HTML::HTMLElement> element = as<HTML::HTMLElement>(result.as_object());
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
LibWeb: Verify element namespace in DOM::create_element()
2025-01-09 21:36:40 +01:00
// FIXME: 3. Assert: result’s custom element state and custom element definition are initialized.
// 4. Assert: result’s namespace is the HTML namespace.
// Spec Note: IDL enforces that result is an HTMLElement object, which all use the HTML namespace.
VERIFY(element->namespace_uri() == Namespace::HTML);
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 5. If result’s attribute list is not empty, then throw a "NotSupportedError" DOMException.
if (element->has_attributes())
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
return JS::throw_completion(WebIDL::NotSupportedError::create(realm, "Synchronously created custom element cannot have attributes"_utf16));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 6. If result has children, then throw a "NotSupportedError" DOMException.
if (element->has_children())
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
return JS::throw_completion(WebIDL::NotSupportedError::create(realm, "Synchronously created custom element cannot have children"_utf16));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 7. If result’s parent is not null, then throw a "NotSupportedError" DOMException.
if (element->parent())
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
return JS::throw_completion(WebIDL::NotSupportedError::create(realm, "Synchronously created custom element cannot have a parent"_utf16));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 8. If result’s node document is not document, then throw a "NotSupportedError" DOMException.
if (&element->document() != &document)
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
return JS::throw_completion(WebIDL::NotSupportedError::create(realm, "Synchronously created custom element must be in the same document that element creation was invoked in"_utf16));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 9. If result’s local name is not equal to localName, then throw a "NotSupportedError" DOMException.
if (element->local_name() != local_name)
LibJS+LibWeb: Port interned bytecode strings to UTF-16 This was almost a no-op, except we intern JS exception messages. So the bulk of this patch is porting exception messages to UTF-16.
2025-08-07 19:31:52 -04:00
return JS::throw_completion(WebIDL::NotSupportedError::create(realm, "Synchronously created custom element must have the same local name that element creation was invoked with"_utf16));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 10. Set result’s namespace prefix to prefix.
LibWeb: Use FlyString for create_element() prefix strings
2023-11-04 09:22:31 +01:00
element->set_prefix(prefix);
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 11. Set result’s is value to null.
element->set_is_value(Optional<String> {});
return element;
};
auto result = synchronously_upgrade_custom_element();
// If any of these steps threw an exception, then:
if (result.is_throw_completion()) {
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 1. Report exception for definition’s constructor’s corresponding JavaScript object’s associated realm’s global object.
auto& window_or_worker = as<HTML::WindowOrWorkerGlobalScopeMixin>(HTML::relevant_global_object(definition->constructor().callback));
window_or_worker.report_an_exception(result.error_value());
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 2. Set result to a new element that implements the HTMLUnknownElement interface, with no attributes, namespace set to the HTML namespace, namespace prefix set to prefix,
// local name set to localName, custom element state set to "failed", custom element definition set to null, is value set to null, and node document set to document.
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-15 04:01:23 +13:00
GC::Ref<Element> element = realm.create<HTML::HTMLUnknownElement>(document, QualifiedName { local_name, prefix, Namespace::HTML });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
element->set_custom_element_state(CustomElementState::Failed);
return element;
}
return result.release_value();
}
// 2. Otherwise:
// 1. Set result to a new element that implements the HTMLElement interface, with no attributes, namespace set to the HTML namespace, namespace prefix set to prefix,
// local name set to localName, custom element state set to "undefined", custom element definition set to null, is value set to null, and node document set to document.
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
auto element = realm.create<HTML::HTMLElement>(document, QualifiedName { local_name, prefix, Namespace::HTML });
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
element->set_custom_element_state(CustomElementState::Undefined);
// 2. Enqueue a custom element upgrade reaction given result and definition.
element->enqueue_a_custom_element_upgrade_reaction(*definition);
return element;
}
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 5. Otherwise:
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// 1. Let interface be the element interface for localName and namespace.
// 2. Set result to a new element that implements interface, with no attributes, namespace set to namespace, namespace prefix set to prefix,
// local name set to localName, custom element state set to "uncustomized", custom element definition set to null, is value set to is,
// and node document set to document.
LibWeb: Port Element::local_name and TagNames from Deprecated String Which pretty much needs to be done together due to the amount of places where they are compared together. This also involves porting over StackOfOpenElements over to FlyString from DeprecatedFly string to prevent a gazillion calls to `.to_deprecated_fly_string` calls in HTMLParser.
2023-10-01 20:07:44 +13:00
auto qualified_name = QualifiedName { local_name, prefix, namespace_ };
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
LibWeb: Make Web::Namespace::Foo strings be FlyString This required dealing with a *lot* of fallout, but it's all basically just switching from DeprecatedFlyString to either FlyString or Optional<FlyString> in a hundred places to accommodate the change.
2023-11-04 18:42:04 +01:00
if (namespace_ == Namespace::HTML) {
LibJS: Make Heap::allocate<T>() infallible Stop worrying about tiny OOMs. Work towards #20449. While going through these, I also changed the function signature in many places where returning ThrowCompletionOr<T> is no longer necessary.
2023-08-13 13:05:26 +02:00
auto element = create_html_element(realm, document, move(qualified_name));
LibWeb/DOM: Stop moving `is_value` in `create_element()` Clangd points out that 1) `set_is_value()` takes a reference so moving isn't useful, and 2) we're reading `is_value` in step 3 after moving it.
2025-02-13 12:55:12 +00:00
element->set_is_value(is_value);
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
element->set_custom_element_state(CustomElementState::Uncustomized);
// 3. If namespace is the HTML namespace, and either localName is a valid custom element name or is is non-null,
// then set result’s custom element state to "undefined".
if (HTML::is_valid_custom_element_name(local_name) || is_value.has_value())
element->set_custom_element_state(CustomElementState::Undefined);
return element;
}
LibWeb: Make Web::Namespace::Foo strings be FlyString This required dealing with a *lot* of fallout, but it's all basically just switching from DeprecatedFlyString to either FlyString or Optional<FlyString> in a hundred places to accommodate the change.
2023-11-04 18:42:04 +01:00
if (namespace_ == Namespace::SVG) {
LibJS: Make Heap::allocate<T>() infallible Stop worrying about tiny OOMs. Work towards #20449. While going through these, I also changed the function signature in many places where returning ThrowCompletionOr<T> is no longer necessary.
2023-08-13 13:05:26 +02:00
auto element = create_svg_element(realm, document, qualified_name);
LibWeb/DOM: Stop moving `is_value` in `create_element()` Clangd points out that 1) `set_is_value()` takes a reference so moving isn't useful, and 2) we're reading `is_value` in step 3 after moving it.
2025-02-13 12:55:12 +00:00
element->set_is_value(is_value);
LibWeb: Use right interface for custom SVG and MathML elements The DOM spec gets overridden by both the SVG2 and MathML core specs in that unknown elements should not inherit DOM::Element, but SVG::SVGElement and MathML::MathMLElement respectively.
2024-10-31 10:35:07 +01:00
element->set_custom_element_state(CustomElementState::Uncustomized);
return element;
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
}
LibWeb: Make Web::Namespace::Foo strings be FlyString This required dealing with a *lot* of fallout, but it's all basically just switching from DeprecatedFlyString to either FlyString or Optional<FlyString> in a hundred places to accommodate the change.
2023-11-04 18:42:04 +01:00
if (namespace_ == Namespace::MathML) {
LibJS: Make Heap::allocate<T>() infallible Stop worrying about tiny OOMs. Work towards #20449. While going through these, I also changed the function signature in many places where returning ThrowCompletionOr<T> is no longer necessary.
2023-08-13 13:05:26 +02:00
auto element = create_mathml_element(realm, document, qualified_name);
LibWeb/DOM: Stop moving `is_value` in `create_element()` Clangd points out that 1) `set_is_value()` takes a reference so moving isn't useful, and 2) we're reading `is_value` in step 3 after moving it.
2025-02-13 12:55:12 +00:00
element->set_is_value(is_value);
LibWeb: Use right interface for custom SVG and MathML elements The DOM spec gets overridden by both the SVG2 and MathML core specs in that unknown elements should not inherit DOM::Element, but SVG::SVGElement and MathML::MathMLElement respectively.
2024-10-31 10:35:07 +01:00
element->set_custom_element_state(CustomElementState::Uncustomized);
return element;
LibWeb: Generate MathML Elements We will now generate MathML elements when parsing HTML.
2023-07-05 20:25:52 -05:00
}
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
// 6. Return result.
// NOTE: See step 1.
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
// https://dom.spec.whatwg.org/#concept-element-interface
// The element interface for any name and namespace is Element, unless stated otherwise.
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
auto element = realm.create<DOM::Element>(document, move(qualified_name));
LibWeb: Introduce CustomElementRegistry and creating custom elements The main missing feature here is form associated custom elements.
2023-03-29 23:46:18 +01:00
element->set_is_value(move(is_value));
element->set_custom_element_state(CustomElementState::Uncustomized);
return element;
LibHTML: Move Element construction to a separate file We now have create_element(document, tag_name) in ElementFactory. This will be useful for constructing new elements outside of parsing.
2019-10-12 13:02:38 +02:00
}
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
Reference in a new issue Copy permalink