-
Notifications
You must be signed in to change notification settings - Fork 20.6k
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
2.0: Squeeze support module #1165
Conversation
a = div.getElementsByTagName("a")[ 0 ]; | ||
if ( !a ) { | ||
input = div.getElementsByTagName("input")[ 0 ]; | ||
if ( !input ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get more out of this? What environments does jQuery 2.0 support where getElementsByTagName
isn't available? Could be nice to remove this altogether :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some, like this one, in that case, div
will be an xml-node, without innerHTML
property, so result of getElementsByTagName
call will be an empty collection and jQuery.support
will be almost empty.
Or if some code would include jQuery into naked nodejs enviroment, or would use spiderMonkey interpretator without DOM implementation with jQuery included.
jQuery would be broken anyway, but it would not throw exceptions right away, but those are very weird use-cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, they are weird edge cases... Maybe we'll just keep it intact to avoid unnecessary breakage :)
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only have two places left in support.js where we are using innerHTML to make elements. One is to create this input, and the other is actually to clear a div that is pulled in via a closure. Maybe it makes sense to remove these? That still doesn't fix the XML issues though, I doubt they would survive a complete trip through this code.
We landed something different as part as gh-1182. |
Rebase? |
@Orkel if you want to try a rebase that would be great. |
Sorry for late response Rebase? Done, plus some additional reduction |
fragment.appendChild( input ); | ||
|
||
// WebKit doesn't clone checked state correctly in fragments | ||
// old WebKit doesn't clone checked state correctly in fragments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be a // Support: WebKit<version
style comment... do you know when it was fixed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It definitely is not fixed in WebKit 534, word "old" is as close as i can get to version number, without testing all other builds of WebKit.
Small additional for #1110 PR.