Hi dmethvin, thanks for your fast response :-)
I think that you fundamentally don't understand the issue. I agree with both 1) and 2) but the implementation is fundamentally flawed ..
please re-read http://blog.jquery.com/2012/06/22/jquery-1-8-beta-1-see-whats-coming-and-going/ ( maybe you wrote this section I'm not sure :-) under XSS PROTECTION .. is specifically says that this is a safe feature to use for taking any untrusted source :
"Developers have sometimes forgotten this, passing strings to jQuery that come from untrusted sources such as the URL or user input." and it continues in a similar fashion..
this directly implies its use is as an html parser of html from any source ..
( this does not align with "We're just trying to ensure that the developer is clear on what they are asking jQuery to do" as you state )
if the blog statement is the case, then the fundamental implementation is totally flawed, you can't go creating dom elements from untrusted sources, even if those elements are not ( yet ) inserted .. the dom will do all kinds of prefetchings and other side-effecting actions .
i agree that jquery can't prevent all possible xss's written with it, but it can avoid including functions that do it by default, especially when documented to the country .. so on this basis i am not happy that the ticket has been closed within hours of being opened ...
there are obviously a few good solutions :
1) the documentation is updated to state that this is simply a way to include html with out the ambiguity of $() possibly being seen as a selector and also striping script tags
2) it's reimplemented to generate jquery lookalike dom nodes that you can do the normal .attr and .text etc.. on but are not in fact real dom nodes, until inserted
( or maybe 3) there are multiple options in the call that let you specify what tag types are allowed disallowed or filtered, and for them what attributes are allowed or disallowed before the dom nodes are made and returned )