Make element and attribute names behave like the HTML parser #449

domenic · 2017-04-26T16:33:37Z

@dominiccooney has started gathering data on this in Blink, so I wanted to help the process along by preparing a spec PR. We should not merge this yet.

The biggest open question, which we could use some help on, is what to do with the -NS variants, createElementNS and createAttributeNS/setAttributeNS.

One idea I thought of is that "validate and extract" should delegate to the HTML validate-and-canonicalize algorithms if the namespace passed in is the HTML namespace.

Another idea is that we should just leave them alone. But I think the same frameworks that are asking for this change for HTML elements probably also want it for SVG elements. (I'm surprised SVG elements care what namespace their attributes are in...)

Note to self: we need to remember to also update the restrictions on valid custom element names, since they were designed to be the union of restrictions from the HTML parser + the DOM APIs.

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 7:33 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 CSS Spec Preprocessor - CSS Spec Preprocessor is the web service used to build Bikeshed specs.

🔗 Related URL

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 [no address given] to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.4.10 (Debian) Server at api.csswg.org Port 443</address>
</body></html>

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

annevk · 2017-04-26T17:00:19Z

The biggest open question, which we could use some help on, is what to do with the -NS variants, createElementNS and createAttributeNS/setAttributeNS.

Those are the variants you would actually use internally, as you don't want to use setAttribute() which is rather odd when it comes to namespaces.

(I'm surprised SVG elements care what namespace their attributes are in...)

HTML elements care too. Say more.

domenic · 2017-04-26T17:05:12Z

Those are the variants you would actually use internally, as you don't want to use setAttribute() which is rather odd when it comes to namespaces.

What do you mean "internally"? Looking at e.g. Ember or React it seems like everyone branches on whether they're supplied a namespace by their caller (presumably only for SVG cases) and uses setAttribute instead. Anecdotally, I've never used setAttributeNS myself.

HTML elements care too. Say more.

I would have thought that after all the trouble we went through to try to simplify Attrs, at least one of the changes that might have stuck was making their namespace APIs have no effect on the processing models that consult those attributes. I guess not.

annevk · 2017-04-26T17:11:56Z

I mean browsers. Browsers definitely care about the namespace of an attribute. And the problem with setAttribute() is that it doesn't care, so you might be accidentally overwriting a value of a namespaced attribute, while you were just trying to set a (new) non-namespaced attribute. (This is only a problem for frameworks of course, and only for those that care about usually theoretical scenarios.)

domenic · 2017-04-26T17:16:20Z

I'm still a little unclear on what you mean by "care". They store it, so it can be reflected in other DOM APIs, sure. But e.g. if I set the src="" attribute on a script element using setAttribute("src", "...") (which sets a null namespace, instead of the HTML namespace) it seems like browsers still load the script file.

Basically my confusion is about whether anyone ever cares about setting the namespace of an attribute "correctly", such as when trying to set two attributes with the same name but different namespace. It seems like the fact frameworks provide methods that take a namespace means some people care. I am not sure why, given my above example of browsers not caring about the namespace for <script src>, although I suspect it has something to do with SVG.

annevk · 2017-04-26T17:20:41Z

Why do you think it should be the HTML namespace? (Hint: if you use the HTML namespace for the "src" attribute, it won't load.)

domenic · 2017-04-26T17:25:16Z

Ah, very interesting. Browsing https://developer.mozilla.org/en-US/docs/Web/SVG/Namespaces_Crash_Course, it appears that people use namespaces for xlink:href mostly.

This makes me lean toward not caring about the -NS methods for attributes at all as people should mostly only have to use them for xlink:href, which is going away. They can just use the null namespace for all attributes most of the time, which means only using createAttribute/setAttribute.

I guess that still leaves createElementNS though, and we maybe should make the attribute-NS methods consistent with that. So, what should our answer be for createElementNS?

annevk · 2017-04-26T17:29:22Z

Given that createElement() depends on context for creating HTML elements (and cannot create SVG elements) it seems unsuitable as well. So I think we definitely want to make createElementNS() work, if anything.

dominiccooney · 2017-04-27T01:20:07Z

My $0.02, I think you do want createElementNS to use the HTML rules for local names in the HTML namespace. Why? It would be good if there's one line of code authors can reliably use to duplicate an element. I think that line has to be:

document.createElementNS(
    element.namespaceURI,
    `${element.prefix}:${element.localName}`,
    magic(element));

(OK three lines. And a function, "magic", which somehow detects autonomous built-in elements and produces a dictionary with 'is' for them.)

Maybe validate and extract step 5 should specify that it splits on the first colon. Since :foo would not be a valid local name any more, validate and extract may want to map the empty string prefix to null so that the checks in step 6 work.

If you make the local name checks consistent with createElement's then that line of code should be sufficient for duplicating an element, whether it is HTML, SVG or vanilla.

domenic · 2017-05-11T00:01:39Z

I've updated this with a revision that takes into account the -NS methods too.

dominiccooney · 2017-08-09T02:52:33Z

I have posted some data from Chromium here: https://bugs.chromium.org/p/chromium/issues/detail?id=648179&desc=2#c19

domenic · 2017-08-15T20:53:39Z

OK, so we finally have data!

DOM valid, HTML parser invalid: 0.047 % page loads
DOM invalid, HTML parser valid: 0.000003 % page loads

Unfortunately, it looks like simply aligning with the HTML parser is not going to be possible. @dominiccooney mentioned it might be possible to change the parser to allow more, but in general that's pretty high-cost and risky. Unless there's some unexpected enthusiasm for that, I'd rather set it aside.

What do people think of just expanding the valid-in-DOM category? Then we will still have two categories, but at least valid-in-DOM will be a superset of valid-in-HTML. I could work on updating this PR to illustrate that concretely, if people would like.

annevk · 2017-08-16T07:17:25Z

I always thought that was the plan. With the syntax being less expressive. Matching the HTML exactly would never have worked due to casing depending on context and such.

strongholdmedia · 2017-08-16T18:55:22Z

What do people think of just expanding the valid-in-DOM category?
I personally think that you should say WHICH DOM.
There is almost as much cowboyism recently with custom rules and "solutions" lately (as in angular, etc), that makes me think the "creators" either forgot quirks mode and browser wars, or just entered the game after it was over (is it even, btw?)

snuggs · 2018-12-18T02:57:10Z

dom.bs

+
+ <li><p>If <var>qualifiedName</var> contains a "<code>:</code>" (U+003E), then split
+ <var>qualifiedName</var> on that first occurrence of "<code>:</code>" and set <var>prefix</var> to
+ the part before and <var>localName</var> to the part after.


@domenic before and after seem a bit vague. Perhaps suffix with ... _prefix to the part before and localName to the part after the : respectively.

Just a thought. Sounded incomplete when reading out loud.

domenic added do not merge needs tests labels Apr 26, 2017

domenic force-pushed the relax-name-validation branch from 73602fa to d607808 Compare April 26, 2017 16:38

domenic mentioned this pull request Apr 26, 2017

Seeking feedback on changes to the DOM APIs for element/attribute name validation glimmerjs/glimmer-vm#473

Open

domenic added 2 commits May 10, 2017 19:26

Make element and attribute names behave like the HTML parser

30ffc26

Update the NS methods too

d91bdac

domenic force-pushed the relax-name-validation branch from d607808 to d91bdac Compare May 11, 2017 00:01

zcorpan mentioned this pull request Aug 16, 2017

Make custom attribute rules consistent with custom element name rules whatwg/html#2271

Open

domenic mentioned this pull request Nov 11, 2017

[templates] Allow removal of boolean attributes WICG/webcomponents#705

Open

annevk assigned domenic Mar 30, 2018

annevk added do not merge yet and removed do not merge labels May 28, 2018

domenic mentioned this pull request Jun 4, 2018

Inconsistency in getAttribute and setAttribute regarding invalid attribute names whatwg/html#3733

Closed

snuggs reviewed Dec 18, 2018

View reviewed changes

annevk mentioned this pull request Jan 7, 2019

Attribute DOM representation and parsing is inconsistent whatwg/html#4275

Closed

domenic mentioned this pull request Jun 26, 2019

A way for createAttribute() to bypass XML Name validation in HTML documents #769

Open

domenic mentioned this pull request Mar 17, 2020

Valid/Invalid characters in document.createElement() #849

Open

Base automatically changed from master to main January 15, 2021 07:32

domenic closed this Oct 25, 2021

annevk deleted the relax-name-validation branch October 25, 2021 16:00

domenic mentioned this pull request Jun 8, 2022

Allow more characters in element/attribute names and prefixes #1079

Open

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make element and attribute names behave like the HTML parser #449

Make element and attribute names behave like the HTML parser #449

domenic commented Apr 26, 2017 •

edited by pr-preview bot

Loading

annevk commented Apr 26, 2017

domenic commented Apr 26, 2017 •

edited

Loading

annevk commented Apr 26, 2017 •

edited

Loading

domenic commented Apr 26, 2017

annevk commented Apr 26, 2017

domenic commented Apr 26, 2017

annevk commented Apr 26, 2017

dominiccooney commented Apr 27, 2017

domenic commented May 11, 2017

dominiccooney commented Aug 9, 2017

domenic commented Aug 15, 2017

annevk commented Aug 16, 2017

strongholdmedia commented Aug 16, 2017

snuggs Dec 18, 2018

Make element and attribute names behave like the HTML parser #449

Make element and attribute names behave like the HTML parser #449

Conversation

domenic commented Apr 26, 2017 • edited by pr-preview bot Loading

💥 Error: 500 Internal Server Error 💥

annevk commented Apr 26, 2017

domenic commented Apr 26, 2017 • edited Loading

annevk commented Apr 26, 2017 • edited Loading

domenic commented Apr 26, 2017

annevk commented Apr 26, 2017

domenic commented Apr 26, 2017

annevk commented Apr 26, 2017

dominiccooney commented Apr 27, 2017

domenic commented May 11, 2017

dominiccooney commented Aug 9, 2017

domenic commented Aug 15, 2017

annevk commented Aug 16, 2017

strongholdmedia commented Aug 16, 2017

snuggs Dec 18, 2018

Choose a reason for hiding this comment

domenic commented Apr 26, 2017 •

edited by pr-preview bot

Loading

domenic commented Apr 26, 2017 •

edited

Loading

annevk commented Apr 26, 2017 •

edited

Loading