Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support to tag-hyphenated elements #1988

Closed
wants to merge 2 commits into from
Closed

Add support to tag-hyphenated elements #1988

wants to merge 2 commits into from

Conversation

LeonardoBraga
Copy link
Contributor

Fixes #1987

@@ -627,6 +627,7 @@ test("jQuery('html')", function() {

ok( jQuery("<div></div>")[0], "Create a div with closing tag." );
ok( jQuery("<table></table>")[0], "Create a table with closing tag." );
ok( jQuery("<tr-d></tr-d>")[0], "Create a dash-delimited tag." );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mean to be pedantic, but that's not "delimited". Suggest: "hyphenated".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a problem! I changed as suggested. Please let me know if anything requires adjustments.

@LeonardoBraga LeonardoBraga changed the title Core: Add support to dash-delimited elements Core: Add support to tag-hyphenated elements Jan 4, 2015
@@ -1620,6 +1620,8 @@ function testHtml( valueObj ) {
tmp = " " + tmp.slice( 1 );
equal( div.html(valueObj( tmp )).html().replace( />/g, "&gt;" ), tmp, "Escaped html, leading space" );

equal( jQuery("<tr-d></tr-d><tr-d></tr-d>").length, 2, "Create tag-hyphenated elements." );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would want more assertions for this, so it would be more thorough, like check for nodeName and for other elements like this. No need to do this for core module though.

And i would prefer if those assertions would be in different test.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And maybe a case with two (or more) hyphens, just in case. It's obvious current implementation will work in the same way but it's better to be future-proof.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 the more tests the better, especially if this involves regexps

@markelog
Copy link
Member

markelog commented Jan 4, 2015

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.

@LeonardoBraga
Copy link
Contributor Author

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?

@markelog
Copy link
Member

markelog commented Jan 4, 2015

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

@LeonardoBraga
Copy link
Contributor Author

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


var j = jQuery("<tr-d></tr-d>");
ok( j[0], "Create a tag-hyphenated elements" );
equal( j[0].nodeName, "TR-D", "Tag-hyphenated element has expected node name" );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use jQuery.nodeName here

@markelog
Copy link
Member

markelog commented Jan 4, 2015

@markelog
Copy link
Member

markelog commented Jan 4, 2015

Should I provide a PR for that branch too?

That would be preferable

@dmethvin dmethvin added this to the 3.0.0 milestone Jan 5, 2015
@gibson042
Copy link
Member

@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.

@dmethvin
Copy link
Member

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).

@LeonardoBraga
Copy link
Contributor Author

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.

@gibson042
Copy link
Member

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.

@markelog
Copy link
Member

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

@markelog markelog closed this in 85ffc6d Jan 13, 2015
@markelog markelog changed the title Core: Add support to tag-hyphenated elements Add support to tag-hyphenated elements Jan 13, 2015
@markelog
Copy link
Member

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.

@dmethvin
Copy link
Member

😈

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

@markelog
Copy link
Member

we can just skip it for IE8.

Will do that.

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

@LeonardoBraga
Copy link
Contributor Author

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?

@markelog
Copy link
Member

See the 87bb713

@mgol
Copy link
Member

mgol commented Jan 14, 2015

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.

@markelog
Copy link
Member

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.

@dmethvin
Copy link
Member

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.
capture

@gibson042
Copy link
Member

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.

@markelog
Copy link
Member

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.

@mbest
Copy link

mbest commented Sep 24, 2015

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.

@mgol
Copy link
Member

mgol commented Mar 6, 2016

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

@mgol mgol modified the milestones: 1.12.0/2.2.0, 3.0.0 Mar 6, 2016
@mgol
Copy link
Member

mgol commented Mar 7, 2016

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

@mgol mgol removed this from the 1.12.0/2.2.0 milestone Mar 7, 2016
gibson042 added a commit to gibson042/jquery that referenced this pull request Jul 11, 2018
gibson042 added a commit to gibson042/jquery that referenced this pull request Jul 11, 2018
gibson042 added a commit to gibson042/jquery that referenced this pull request Jul 11, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jan 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Core: Issue while creating dash-delimited nodes
7 participants