Could break this pull on two commits? One for core, other for manipulation, i think it would be best way to do this. You can squash other commits, don't need them.

Also please verify these changes would work in compat branch.

I'm implementing the requested changes and will update this PR soon, however I noticed that rsingleTag does not contain :, while rtagName does. Shouldn't we add : to rsingleTag in order to keep consistency?

@LeonardoBraga i guess you missed my comment - #1988 (comment)

@markelog Applied and tested the changes locally on compat and they seem to be fine. Should I provide a PR for that branch too?

In #1988 (comment), i meant all of them, like here - https://github.com/jquery/jquery/blob/66e1b6b8d49812239b5712d65922ff94c60f7b02/test/unit/manipulation.js#L264-268, just to be safe

Should I provide a PR for that branch too?

That would be preferable

@gkalpak makes a valid point... in fact, HTML tag names must start with an ASCII letter, but can then include almost anything. Let's update all three regular expressions accordingly, so that the capture consists of a case-insensitive a–z and any number of non-whitespace non-slash non-greater-than non-NULL characters.

Wow, so ASCII letters are just lowercased and pretty much any other non-space character is allowed. That's mighty liberal. So it does sound like we need to adjust our regex-en (or whatever the plural of regex is).

I'll update this PR to also address the concerns regarding valid tag names.

Regarding the previous state, it's not clear to me how we stand on:

1. Should I add : to all regexes (trusting Wikipedia on the plural here) to keep consistency or leave them as they are? This might mean a few extra bytes, but it's a "price" worth paying for consistency, IMO.
2. Should I extend all the tests cases that I added for - to also test : or this is not necessary?

Thank you - I'm glad this exposed some other cases that needed attention as well. I'll try to wrap up this quickly.

I stand by my previous position, because ":" is special.

We want no ":" in rsingleTag so elements with the character in their name are created by the namespace-aware innerHTML instead of the namespace-ignorant document.createElement: https://rawgit.com/gibson042/fdedc0a26c25ffbfc014/raw/9a5487e7aad4282641a498bf95ccd9299a747c16/rdf.xhtml

We want a ":" in rtagName and rxhtmlTag so the former correctly identifies the first open tag and the latter doesn't mangle input: http://jsfiddle.net/5y6p8777/

Where the statements now refer to acceptance of the character, rather than its literal appearance in the regex.

I think we should merge this as is, this PR solves real problem that users faced, "almost anything" is nice to have and could be solved in another PR

This, and i can't believe we forgot about it, doesn't work in IE8, remember why we have the shim?

Right, now i do too. My first thought was to revert, now i think we should blacklist those hyphenated tests for the old one. Since if user uses custom elements he definitely doesn't use it with IE8.

😈

I don't think we need to revert, we can just skip it for IE8.

we can just skip it for IE8.

Will do that.

@LeonardoBraga note that you would have to do the same thing for #2005

you would have to do the same thing

Do you mean to blacklist the tests I'll write for IE8? If so, is there a place where this is already done in the code so I can follow the same pattern?

See the 87bb713

This, and i can't believe we forgot about it, doesn't work in IE8, remember why we have the shim?

Isn't it enough to document.createElement it to make IE8 recognize it? The developer might be doing that and using custom tags on IE8 so maybe we should test this scenario.

Isn't it enough to document.createElement it to make IE8 recognize it?

Yes.

The developer might be doing that and using custom tags on IE8 so maybe we should test this scenario.

Even though this is unlikely use-case, we still can't do that, oldIE will identify only those elements that created in the scope of the document it first added to, which is in our case, is internal documentFragment element, which is not exposed.

I thought for sure IE8 would die on special chars but at least that part works. I don't think we want to guarantee this madness works consistently in IE8 anyway.

I don't think we want to guarantee this madness works consistently in IE8 anyway.

Agreed. As long as our code is solid, it's OK for some edge cases to fail on IE8.

I thought for sure IE8 would die on special chars but at least that part works.

If wouldn't do something crazy like find those elems in user string and create them on our documentFragment it wouldn't work for the same reason hyphenated elements fall through the cracks.

Why is this only being fixed in version 3.0.0? For anyone using jQuery for template-like support across multiple browsers, this change is essential for full support of custom elements. I think it should be back ported to 1.x and 2.x. This shouldn't be hard since it's a small, non-breaking change.

This has been backported to 1.12.0 & 2.2.0 so I changed the milestone (it used to say 3.0.0).

I moved the milestone from this PR to the issue #1987.