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

[whatwg] Inconsistent behavior for empty-string URLs

From: Nicholas Zakas <nzakas@yahoo-inc.com>
Date: Tue, 15 Dec 2009 17:37:33 -0800
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D462@SNV-EXVS09.ds.corp.yahoo.com>
Yes, that sounds right.

Commander Lock: "Damnit Morpheus, not everyone believes what you
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Tuesday, December 15, 2009 5:22 PM
To: Nicholas Zakas
Cc: Maciej Stachowiak; whatwg at lists.whatwg.org; Aryeh Gregor; Simon
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
> 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
> to be sent. Examples: <img>, <link>, <script>, <iframe>, etc. This
> 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:

<input type=image>

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
Received on Tuesday, 15 December 2009 17:37:33 UTC

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