[whatwg] Inconsistent behavior for empty-string URLs

Wed Dec 16 02:59:33 PST 2009

On Wed, 16 Dec 2009 02:21:33 +0100, Jonas Sicking <jonas at sicking.cc> wrote:

> On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas <nzakas at yahoo-inc.com>  
> wrote:
>> Here's what I would propose:
>>
>> 1. Empty string attributes for HTML elements specifying resources to
>> automatically download are considered invalid and don't cause a request
>> to be sent. Examples: <img>, <link>, <script>, <iframe>, etc. This would
>> not apply to <a href=""> because it is a user-initiated request.
>>
>> 2. This also applies to manipulation of HTML elements through the DOM,
>> so (new Image()).src="" would not result in a request being sent.
>>
>> 3. This does not apply to JavaScript APIs that are unrelated to HTML
>> elements, such as Web Workers, XMLHttpRequest, etc.
>
> I'd prefer to explicitly enumerate the elements we're talking about,
> rather than giving rules which risk being interpreted differently by
> different people.
> For example not all <link>s are automatically downloaded, such as
> <link rel=prev>. However I suspect that we'll want all <link>s to
> behave the same.
>
> So the specific list would then be:
>
> <img>
> <link>

I think only icon, prefetch and stylesheet links.

The following element defines two links, one of which would be ignored:

    <link rel="icon index" href>

> <script>
> <iframe>
> <video>

Including poster?

> <audio>
> <object>
> <embed>
> <source>
> <input type=image>

<command icon>?
<html manifest>?
<applet code>? (Maybe not, since it's more of a parameter to the Java  
plugin.)
<frame src>?

It seems the spec already ignores empty string for the background=""  
attribute.

> All of these would never attempt to fetch a resource if the src/href
> attribute is empty (even if the current baseuri is different from the
> document uri). However it would not act as if the attribute was not
> set (important for <script>).
>
> Does that sound right?
>
> / Jonas
>

-- 
Simon Pieters
Opera Software