W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

[whatwg] Javascript: URLs as element attributes

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 02 Dec 2010 09:32:43 +0100
Message-ID: <op.vm2vctj3sr6mfa@kirk>
On Wed, 01 Dec 2010 16:24:31 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 12/1/10 3:16 AM, Philip J?genstedt wrote:
>> Do you do that just for inlines, or also when navigating to javascript:
>> URLs? If it's both, then that's something we'd need to standardize,
>> unless all browsers already do the same.
>
> It's both in Gecko.  We really do try to keep the number of  
> special-cases to a minimum.  ;)

I'm looking forward to some standardization effort on this point.

> I agree that we probably need to standardize this, because I fully  
> expect web sites to depend on the ISO-8859-1 bit when all the charcodes  
> are < 255.
>
>> Indeed, so the question is just what the compat constraints are.
>
> Well, no.  There's the question of what's least confusing for authors  
> too; see my other mail about that in this thread.

This one?

On Tue, 30 Nov 2010 20:32:06 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> One other thing.... since this is a generic protocol, if we define  
> special-case behavior for it in some cases (e.g. <img>), that opens up  
> some cans of worms.  For example, what should url("javascript:") do in  
> CSS?  HTML5 seems like the wrong place to define that....

On this point I can only say that I think that javascript: in CSS should  
also not execute, and doesn't in Opera (before or after my changes).

>> Right, these aren't inlines, in Opera terminology at least. As far as I
>> can see the spec agrees on this, as frames/iframes have their own
>> browsing contexts.
>
> So do <object>s, sometimes, right?

Yes, but as far as I can tell from the algorithm [1], the browsing context  
isn't created until step 8, after the URL in data="" has been resolved and  
fetched. In other words, at the time the steps for handling javascript:  
[2] are run, there's no browsing context, and it will be treated as any  
other inline. This is a good thing IMO, as it would be quite confusing if  
the context in which the script executed depended on the expected type of  
the <object> content.

The spec change that I'm suggesting is to remove the case "If the Document  
object of the element, attribute, or style sheet from which the  
javascript: URL was reached has an associated browsing context", which  
would mean (among other things) that <object data="javscript:..."> would  
never execute. But again, let's wait a little bit longer and see if any  
compat issues arise.

[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-object-element
[2]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#javascript-protocol

-- 
Philip J?genstedt
Core Developer
Opera Software
Received on Thursday, 2 December 2010 00:32:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC