I would personally be happy with us just adding a non-normative Note to the end or that algorithm, saying something like

Note: In practice, rather than handcrafting an implementation of the above algorithm, most existing implementations use double-parsing functions from libraries such as double-conversion and fast_float.

…or whatever similar wording we might be able to get agreement on.

Also by the way, I realize I misspoke a bit about something: While it’s true that the Blink and Gecko and WebKit use double-conversion or fast_float — they don’t _just _ use those. Instead they have to do preprocessing to skip ASCII whitespace — not Unicode whitespace, and specifically not U+000B, and maybe to skip/ignore any leading plus sign.

fast_float uses a from_chars implementation rather than strtod — and from_chars on its own per-spec doesn’t skip/ignore leading whitespace. The docs say it also doesn’t skip/ignore a leading plus sign, but it seems to me that maybe the fast_float from_chars at least actually does.

And I’m not sure if the double parser in double-conversion skips leading plus signs and whitespace — but if it does skip whitespace, it would do it for Unicode whitespace, not the ASCII whitespace subset.

So anyway, to conform to the HTML algorithm, engines using any third-party libraries would need to do preprocessing on the strings — to skip/ignore the right kind of whitespace and (possibly) the plus sign.

Hi all. The HTML spec says, under §4.13.4, "The CustomElementRegistry interface", for the "Element definition" list of steps, specifically step 18:

Let upgrade candidates be all elements that are shadow-including descendants of document, whose namespace is the HTML namespace and whose local name is localName, in shadow-including tree order. Additionally, if extends is non-null, only include elements whose is value is equal to name.

This suggests that e.g. define("foo-bar", class FooBarElement extends HTMLElement { /* ... */ }) (autonomous custom element) will not "upgrade" elements like<span is="foo-bar"><!-- ... --></span> (span can be replaced with any other known HTML element for the sake of the example), correct? To explain how I have assumed this: thenamefor the element isfoo-bar, after all (established at the outset of the aforementioned list of steps), while localName is same asname (step 5) sinceextends is null, and so only<foo-bar><!-- ... --></foo-bar> element(s) in the document will be upgraded. Can someone tell me my reading of the spec is correct?