Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-18 09:50:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/DOM/ElementFactory.cpp

803 lines
49 KiB
C++
Raw Permalink 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>
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
* Copyright (c) 2025, Sam Atkins <sam@ladybird.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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
#include <LibWeb/HTML/CustomElements/CustomElementRegistry.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>
LibWeb: Add HTMLSelectedContentElement for customizable select Introduce the HTMLSelectedContentElement and integrate it into <select>, <option> and HTMLParser. See whatwg/html#10548. There are two bugs with WPT tests which causes the third subtest in selectedcontent.html and selectedcontent-mutations.html fail. See whatwg/html#11882, web-platform-tests/wpt#55849.
2025-12-07 16:37:54 -08:00
#include <LibWeb/HTML/HTMLSelectedContentElement.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/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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
#include <LibWeb/HTML/Scripting/Agent.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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
#include <LibWeb/HTML/Scripting/SimilarOriginWindowAgent.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>
LibWeb: Add MathML Element presentational hints
2025-09-20 22:54:45 +02:00
#include <LibWeb/MathML/MathMLMiElement.h>
#include <LibWeb/MathML/MathMLMspaceElement.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/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 SVGFEColorMatrixElement and feColorMatrix
2025-09-22 02:47:28 +04:00
#include <LibWeb/SVG/SVGFEColorMatrixElement.h>
LibWeb: Add SVGFEComponentTransferElement
2025-11-05 10:32:56 +01:00
#include <LibWeb/SVG/SVGFEComponentTransferElement.h>
LibWeb: Implement `<feComposite>` SVG filter
2025-08-06 13:27:50 +01:00
#include <LibWeb/SVG/SVGFECompositeElement.h>
LibWeb/SVG: Implement the feDisplacementMap filter
2026-02-25 23:29:50 +00:00
#include <LibWeb/SVG/SVGFEDisplacementMapElement.h>
LibWeb/SVG: Implement SVGFEDropShadowElement IDL interface
2026-01-06 23:40:22 +01:00
#include <LibWeb/SVG/SVGFEDropShadowElement.h>
LibWeb/SVG: Add FEFloodElement
2025-07-06 21:48:55 +02:00
#include <LibWeb/SVG/SVGFEFloodElement.h>
LibWeb: Add SVGFEFunc{A,B,G,R}Element
2025-11-05 17:05:26 +01:00
#include <LibWeb/SVG/SVGFEFuncAElement.h>
#include <LibWeb/SVG/SVGFEFuncBElement.h>
#include <LibWeb/SVG/SVGFEFuncGElement.h>
#include <LibWeb/SVG/SVGFEFuncRElement.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+LibGfx: Implement `SVGFEMorphologyElement` This filter primitive is used to erode or dilate an image.
2025-11-15 12:30:15 +00:00
#include <LibWeb/SVG/SVGFEMorphologyElement.h>
LibWeb: Implement `<feOffset>` SVG filter
2025-08-06 13:53:50 +02:00
#include <LibWeb/SVG/SVGFEOffsetElement.h>
LibWeb/SVG: Implement the feTurbulence filter
2026-02-10 15:08:11 +00:00
#include <LibWeb/SVG/SVGFETurbulenceElement.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: Implement `SVGPatternElement`
2026-02-17 16:24:44 +00:00
#include <LibWeb/SVG/SVGPatternElement.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: Add HTMLSelectedContentElement for customizable select Introduce the HTMLSelectedContentElement and integrate it into <select>, <option> and HTMLParser. See whatwg/html#10548. There are two bugs with WPT tests which causes the third subtest in selectedcontent.html and selectedcontent-mutations.html fail. See whatwg/html#11882, web-platform-tests/wpt#55849.
2025-12-07 16:37:54 -08:00
if (html_element_interface_name == "HTMLSelectedContentElement"sv)
return FixedArray<FlyString>::create({ HTML::TagNames::selectedcontent });
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
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
static GC::Ref<Element> create_html_element(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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
auto& realm = document.realm();
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: Add HTMLSelectedContentElement for customizable select Introduce the HTMLSelectedContentElement and integrate it into <select>, <option> and HTMLParser. See whatwg/html#10548. There are two bugs with WPT tests which causes the third subtest in selectedcontent.html and selectedcontent-mutations.html fail. See whatwg/html#11882, web-platform-tests/wpt#55849.
2025-12-07 16:37:54 -08:00
if (tag_name == HTML::TagNames::selectedcontent)
return realm.create<HTML::HTMLSelectedContentElement>(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
}
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
static GC::Ref<SVG::SVGElement> create_svg_element(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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
auto& realm = document.realm();
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: Add SVGFEComponentTransferElement
2025-11-05 10:32:56 +01:00
if (local_name == SVG::TagNames::feColorMatrix)
return realm.create<SVG::SVGFEColorMatrixElement>(document, move(qualified_name));
if (local_name == SVG::TagNames::feComponentTransfer)
return realm.create<SVG::SVGFEComponentTransferElement>(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: Implement the feDisplacementMap filter
2026-02-25 23:29:50 +00:00
if (local_name == SVG::TagNames::feDisplacementMap)
return realm.create<SVG::SVGFEDisplacementMapElement>(document, move(qualified_name));
LibWeb/SVG: Implement SVGFEDropShadowElement IDL interface
2026-01-06 23:40:22 +01:00
if (local_name == SVG::TagNames::feDropShadow)
return realm.create<SVG::SVGFEDropShadowElement>(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: Add SVGFEFunc{A,B,G,R}Element
2025-11-05 17:05:26 +01:00
if (local_name == SVG::TagNames::feFuncA)
return realm.create<SVG::SVGFEFuncAElement>(document, move(qualified_name));
if (local_name == SVG::TagNames::feFuncB)
return realm.create<SVG::SVGFEFuncBElement>(document, move(qualified_name));
if (local_name == SVG::TagNames::feFuncG)
return realm.create<SVG::SVGFEFuncGElement>(document, move(qualified_name));
if (local_name == SVG::TagNames::feFuncR)
return realm.create<SVG::SVGFEFuncRElement>(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+LibGfx: Implement `SVGFEMorphologyElement` This filter primitive is used to erode or dilate an image.
2025-11-15 12:30:15 +00:00
if (local_name == SVG::TagNames::feMorphology)
return realm.create<SVG::SVGFEMorphologyElement>(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/SVG: Implement the feTurbulence filter
2026-02-10 15:08:11 +00:00
if (local_name == SVG::TagNames::feTurbulence)
return realm.create<SVG::SVGFETurbulenceElement>(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: Implement `SVGPatternElement`
2026-02-17 16:24:44 +00:00
if (local_name == SVG::TagNames::pattern)
return realm.create<SVG::SVGPatternElement>(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
}
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
static GC::Ref<MathML::MathMLElement> create_mathml_element(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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
auto& realm = document.realm();
LibWeb: Add MathML Element presentational hints
2025-09-20 22:54:45 +02:00
auto const& local_name = qualified_name.local_name();
if (local_name == MathML::TagNames::mi)
return realm.create<MathML::MathMLMiElement>(document, move(qualified_name));
if (local_name == MathML::TagNames::mspace)
return realm.create<MathML::MathMLMspaceElement>(document, move(qualified_name));
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// https://dom.spec.whatwg.org/#create-an-element-internal
template<typename Interface>
GC::Ref<Element> create_element_internal(Document& document, Interface interface, FlyString local_name, Optional<FlyString> namespace_, Optional<FlyString> prefix, CustomElementState custom_element_state, Optional<String> is_value, GC::Ptr<HTML::CustomElementRegistry> registry)
{
// 1. Let element be a new element that implements interface, with namespace set to namespace, namespace prefix set
// to prefix, local name set to localName, custom element registry set to registry, custom element state set to
// state, custom element definition set to null, is value set to is, and node document set to document.
auto qualified_name = QualifiedName { local_name, prefix, namespace_ };
auto element = interface(document, qualified_name);
element->set_custom_element_registry(registry);
element->set_custom_element_state(custom_element_state);
element->set_is_value(move(is_value));
// NB: Document is set in the call to `interface()` above. Custom element definition is null by default.
// 2. Assert: element’s attribute list is empty.
VERIFY(!element->has_attributes());
// 3. Return element.
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
// https://dom.spec.whatwg.org/#concept-create-element
LibWeb: Implement scoped custom element registries
2026-02-27 17:05:47 +00: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, Variant<GC::Ptr<HTML::CustomElementRegistry>, Default> initial_registry)
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
GC::Ptr<Element> result;
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 2. If registry is "default", then set registry to the result of looking up a custom element registry given
// document.
LibWeb: Implement scoped custom element registries
2026-02-27 17:05:47 +00:00
GC::Ptr<HTML::CustomElementRegistry> registry = initial_registry.visit(
[&document](Default const&) {
return HTML::look_up_a_custom_element_registry(document);
},
[](GC::Ptr<HTML::CustomElementRegistry> pointer) {
return pointer;
});
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 3. Let definition be the result of looking up a custom element definition given registry, namespace, localName,
// and is.
auto definition = HTML::look_up_a_custom_element_definition(registry, 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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 4. 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):
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.
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 2. Set result to the result of creating an element internal given document, interface, localName, the HTML
// namespace, prefix, "undefined", is, and registry.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
result = create_element_internal(document, create_html_element, local_name, Namespace::HTML, prefix, CustomElementState::Undefined, is_value, registry);
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 3. If synchronousCustomElements is true, then run this step 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) {
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 1. Upgrade result using definition.
auto upgrade_result = result->upgrade_element(*definition);
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// If this step threw an exception exception:
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 (upgrade_result.is_throw_completion()) {
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 1. Report exception for definition’s constructor’s corresponding JavaScript object’s associated
// realm’s global object.
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
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".
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
result->set_custom_element_state(CustomElementState::Failed);
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
}
}
// 4. Otherwise, enqueue a custom element upgrade reaction given result and definition.
else {
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
result->enqueue_a_custom_element_upgrade_reaction(*definition);
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: 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: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 5. Otherwise, if definition is non-null, then:
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
else if (definition) {
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 1. If synchronousCustomElements is true:
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) {
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 1. Let C be definition’s constructor.
auto& constructor = definition->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: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 2. Set the surrounding agent’s active custom element constructor map[C] to registry.
LibWeb: Implement scoped custom element registries
2026-02-27 17:05:47 +00:00
auto& active_custom_element_constructor_map = HTML::relevant_similar_origin_window_agent(document).active_custom_element_constructor_map;
active_custom_element_constructor_map.set(static_cast<JS::FunctionObject&>(*constructor.callback), registry);
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 3. Run these steps while catching any exceptions:
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
auto synchronously_upgrade_custom_element = [&]() -> JS::ThrowCompletionOr<void> {
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 1. Set result to the result of constructing C, with no arguments.
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.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
result = TRY(WebIDL::construct(constructor, {})).as_if<HTML::HTMLElement>();
if (!result)
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
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// FIXME: 2. Assert: result’s custom element state and custom element definition are initialized.
LibWeb: Verify element namespace in DOM::create_element()
2025-01-09 21:36:40 +01:00
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 3. Assert: result’s namespace is the HTML namespace.
// Note: IDL enforces that result is an HTMLElement object, which all use the HTML namespace.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
VERIFY(result->namespace_uri() == Namespace::HTML);
LibWeb: Verify element namespace in DOM::create_element()
2025-01-09 21:36:40 +01:00
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 4. If result’s attribute list is not empty, then throw a "NotSupportedError" DOMException.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
if (result->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
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 5. If result has children, then throw a "NotSupportedError" DOMException.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
if (result->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
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 6. If result’s parent is not null, then throw a "NotSupportedError" DOMException.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
if (result->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
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 7. If result’s node document is not document, then throw a "NotSupportedError" DOMException.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
if (&result->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
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 8. If result’s local name is not equal to localName, then throw a "NotSupportedError" DOMException.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
if (result->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
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 9. Set result’s namespace prefix to prefix.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
result->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
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 10. Set result’s is value to null.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
result->set_is_value(Optional<String> {});
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 11. Set result’s custom element registry to registry.
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
result->set_custom_element_registry(registry);
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
return {};
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 any of these steps threw an exception, then:
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
if (auto maybe_error = synchronously_upgrade_custom_element(); maybe_error.is_throw_completion()) {
// 1. Report exception for definition’s constructor’s corresponding JavaScript object’s associated
// realm’s global object.
LibWeb: Update `create_element()` to follow the latest specification
2025-02-02 14:47:12 +00:00
auto& window_or_worker = as<HTML::WindowOrWorkerGlobalScopeMixin>(HTML::relevant_global_object(definition->constructor().callback));
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
window_or_worker.report_an_exception(maybe_error.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
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 2. Set result to the result of creating an element internal given document, HTMLUnknownElement,
// localName, the HTML namespace, prefix, "failed", null, and registry.
result = create_element_internal(document, [](auto& document, auto qualified_name) { return document.realm().template create<HTML::HTMLUnknownElement>(document, qualified_name); }, local_name, Namespace::HTML, prefix, CustomElementState::Failed, {}, registry);
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: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
// 4. Remove the surrounding agent’s active custom element constructor map[C].
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// Note: Under normal circumstances it will already have been removed at this point.
LibWeb: Implement scoped custom element registries
2026-02-27 17:05:47 +00:00
active_custom_element_constructor_map.remove(static_cast<JS::FunctionObject&>(*constructor.callback));
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. Otherwise:
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
else {
// 1. Set result to the result of creating an element internal given document, HTMLElement, localName, the HTML
// namespace, prefix, "undefined", null, and registry.
result = create_element_internal(document, [](auto& document, auto qualified_name) { return document.realm().template create<HTML::HTMLElement>(document, qualified_name); }, local_name, Namespace::HTML, prefix, CustomElementState::Undefined, {}, registry);
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 2. Enqueue a custom element upgrade reaction given result and definition.
result->enqueue_a_custom_element_upgrade_reaction(*definition);
}
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 6. Otherwise:
else {
// 1. Let interface be the element interface for localName and namespace.
// 2. Set result to the result of creating an element internal given document, interface, localName, namespace,
// prefix, "uncustomized", is, and registry.
if (namespace_ == Namespace::HTML) {
result = create_element_internal(document, create_html_element, local_name, namespace_, prefix, CustomElementState::Uncustomized, is_value, registry);
// 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())
result->set_custom_element_state(CustomElementState::Undefined);
}
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
else if (namespace_ == Namespace::SVG) {
result = create_element_internal(document, create_svg_element, local_name, namespace_, prefix, CustomElementState::Uncustomized, is_value, registry);
}
LibWeb: Bring create_element more in line with the spec
2026-03-05 17:54:30 +01:00
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
else if (namespace_ == Namespace::MathML) {
result = create_element_internal(document, create_mathml_element, local_name, namespace_, prefix, CustomElementState::Uncustomized, is_value, registry);
}
LibWeb: Generate MathML Elements We will now generate MathML elements when parsing HTML.
2023-07-05 20:25:52 -05:00
LibWeb/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
else {
// https://dom.spec.whatwg.org/#concept-element-interface
// The element interface for any name and namespace is Element, unless stated otherwise.
result = create_element_internal(document, [](auto& document, auto qualified_name) { return document.realm().template create<DOM::Element>(document, qualified_name); }, local_name, namespace_, prefix, CustomElementState::Uncustomized, is_value, registry);
}
}
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/DOM: Bring create_element() closer to spec I believe the test regressions were previous false positives, that now fail because we partially implement things instead of not implementing them at all.
2026-02-26 14:13:47 +00:00
// 7. Return result.
return GC::Ref { *result };
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