Permalink
Show file tree
Hide file tree
16 comments
on commit
sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Adjust jQuery('html') detection to only match when html starts with '…
…<' (counting space characters). Fixes #11290
- Loading branch information
Showing
2 changed files
with
3 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
239fc86
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.
How does this effect round-tripping?
239fc86
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.
http://jsfiddle.net/RphY2/
239fc86
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 is intentionally more strict and would be a change in behavior for that situation. However, the coming introduction of parseHTML will take care of explicitly generating html.
239fc86
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.
I get it's a change in behavior. Right now on edge, it's causing a syntax error. Please see my fiddle.
239fc86
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's a syntax error because the string prefixed with "hi ..." is no longer considered to be HTML, which is what the patch is trying to do.
For that particular case you're not really round-tripping the HTML since the outer div is gone and
$()
has always lost leading/trailing text.If this seems to abrupt, and I can agree that it might be, I suggest that we leave
$(html)
untouched (or at least less aggressively neutered, for example allow leading alphanumerics) and only introduce$.parseHTML
in 1.8 with the strong warning that people MUST switch over by 1.9 if they want to process random HTML.239fc86
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.
I'd be alright with that. I guess the question is are there enough cases where this would break to warrant not adding now?
239fc86
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.
Well if there are, I'm foreseeing a situation like we had in 1.6 with attroperties. If we warn about it now and provide
$.parseHTML
simultaneously, nobody can say they were not told.239fc86
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.
Honestly, my concern is that this is too drastic of a change - especially for those that have large systems, plugins etc. /2cents
239fc86
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.
@rwldrn: agreed, I'm working on parseHTML right now. Dave is a little low on time.
239fc86
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.
So to be clear, this change and the previous mod to this regex are being reverted?
239fc86
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.
Yeah, we're not changing
$()
behavior in 1.8; instead we'll evangelize and get feedback over the next 6 months and really lock it down in 1.9 if all goes well. The key is to haveparseHTML
ready so people have a way to explicitly say they are expecting HTML and whether they want it to run scripts.Sound reasonable, everyone?
239fc86
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.
+1
239fc86
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.
+1
239fc86
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.
+1
239fc86
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.
For the record: Reverted in c20e031.
By the way, this didn't affect .html(), right? I mean setting
$foo.html('hello <p></p>');
is completely valid imho. Passing it to$()
seems a different case. Although I can imagine both being a potential problem.239fc86
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.
No, it doesn't affect that.