[Suggestion] Add constants for SVG, and MathML namespaces

[Jamesernator]

Not sure if HTML or DOM spec is better for this, but I've put it here as SVG/MathML integration is primarily specced in HTML.

Currently when dealing with SVG and MathML in the DOM one needs to use .createElementNS, however it's often a bit of a pain to remember the exact url for these namespaces, and what often winds up happening is a bunch of these constants wind up floating around everywhere.

As both of these namespaces have behaviour within browsers, it would be nice to expose them as constants so that they can be referred to in a more uniform way.

Given that both elements and attributes can have namespaces, I'd imagine putting these constants on Node e.g.:

const rect = document.createElementNS(Node.SVG_NS, "rect");
const attr = document.createAttributeNS(Node.SVG_NS, "x");

const msub = document.createElementNS(Node.MATH_NS, "msub");
const mathVariant = document.createAttributeNS(Node.MATH_NS, "mathvariant");

Open Question: Also add constant for HTML namespace for consistency? (Any others?)

[annevk]

See whatwg/dom#311. At this point I would rather pursue new creation APIs that simplify this somewhat. There's also no precedence for using constants for strings that I know of, the strings themselves are the constant.

[domenic]

Indeed, exposing the constants seems like a really indirect way of accomplishing the use case here (remember step 1).

[Jamesernator]

Indeed, exposing the constants seems like a really indirect way of accomplishing the use case here (remember step 1).

This is fair, the main use case I was thinking was "I need a way to more easily get these namespace strings" (hence constants really being the solution). But yes better creation APIs would make more sense as the use case is wider in particular I would say the problem is: "mathml/svg elements are currently more cumbersome to construct in comparison to html ones".

In this regard it might be covered more by this issue on DOM. That issue doesn't cover mathml/svg specifically, but I'd imagine whatever solution could be adapted to have entrypoints for MathML/SVG as well.

[annevk]

Indeed, let's dupe it into that for now.