Issue 687721  has been merged into this issue.

Monica will take a look at this.

I played with the repro a bit, here:

https://jsbin.com/guqasuqaro/1/edit?html,console,output

It looks to me this is a problem with case handling of 🙀 and 🐱. I note that omg-🐱 element in markup seems to work fine; and defining omg-🙀 works with omg-🙀 markup.

This might be generally related to  Issue 685012 .

I'd start with digging into HTML and DOM specs to work out exactly where the HTML parser flips the case of elements it is creating (maybe domenic can point to it?) and doing some debugging around HTMLConstructionSite::createElement to see what local names these elements have.

FWIW custom elements doesn't do lowercasing, it just requires the names are "valid" and compares them literally. I note that customElements.define treats omg-🙀 and omg-🐱 as valid. I think that is correct.

So there's a couple of likely outcomes here. They're not mutually exclusive!

1. The Blink HTML parser isn't doing case handling of 🙀 correctly, and should.
2. Custom elements, the HTML parser, and createElement all have different ideas about which names are valid which leads to this. Fix the specs and implementations. See Issue 648179.
3. Something else is wrong.

> I'd start with digging into HTML and DOM specs to work out exactly where the HTML parser flips the case of elements it is creating (maybe domenic can point to it?)

https://html.spec.whatwg.org/#tag-name-state

> ASCII upper alpha: Append the lowercase version of the current input character (add 0x0020 to the character's code point) to the current tag token's tag name.

Thanks for the pointer domenic.

I tried this again in 58.0.3029.81 (Official Build) (64-bit) and I think this is WAI now. The original jsbin doesn't do what you might expect, but that's because omg-cat (parsed) and omg-kitten (registered) are different names.

A remaining sadness is document.createElement('omg-🙀') and document.createElement('omg-🐱') don't work because of the DOM name validation rules; that is Issue 648179.

It's a bit of a gotcha but authors should look up custom element definitions with customElements.get(e.localName) and not use e.tagName because tagName is ASCII-uppercased.

I agree this is working as intended. I'm not sure what I was thinking back in February, but at least now it looks like the test in the OP just has a typo, using two different cat emojis when it should only be using one. When it uses one cat emoji, everything works fine.