Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, 09 Mar 2010 01:40:31 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Dec 2009, Simon Pieters wrote: I've now looked at a selection of random URLs. Conclusion: None of these seem to need a request to be made. img should fire an error event. iframe and frame should use about:blank. Did you miss the part about the error event for img src? I don't see anything in the spec that says error should be fired for that case. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, 2010-03-11 at 17:53 +0100, Simon Pieters wrote: On Tue, 09 Mar 2010 01:40:31 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Dec 2009, Simon Pieters wrote: I've now looked at a selection of random URLs. Conclusion: None of these seem to need a request to be made. img should fire an error event. iframe and frame should use about:blank. Did you miss the part about the error event for img src? I don't see anything in the spec that says error should be fired for that case. I would assume that the error is the same as that of a broken URL. A valid image file cannot be found (as the URL is zero-length) so it cannot display it. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, 11 Mar 2010, Simon Pieters wrote: On Tue, 09 Mar 2010 01:40:31 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 18 Dec 2009, Simon Pieters wrote: I've now looked at a selection of random URLs. Conclusion: None of these seem to need a request to be made. img should fire an error event. iframe and frame should use about:blank. Did you miss the part about the error event for img src? I don't see anything in the spec that says error should be fired for that case. Oops, the edits in that section were incomplete. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inconsistent behavior for empty-string URLs
Hi guys, Sorry to pester, but I want to make sure this comes to resolution before it's forgotten. Any other feedback? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, January 07, 2010 1:09 PM To: Nicholas Zakas Cc: Simon Pieters; Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, Jan 7, 2010 at 1:03 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: I'm going to take a lack of response to this question as a no. :) Given the disparate browser implementations for dealing with empty string URLs, it seems unlikely that anyone is relying upon the current behaviors, so I'd like to suggest this change be added to HTML5: For any img, link, script, iframe, audio, video, audio, object, embed, input, html manifest, or frame tag that will result in an automatic download of an external resource must ignore any empty string URL and not download the external resource. This is true even when a base href is applied to the page. Does that sound right? Sounds good to me. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, 12 Jan 2010, Nicholas Zakas wrote: Sorry to pester, but I want to make sure this comes to resolution before it's forgotten. Any other feedback? Don't worry, all e-mail sent to this list ends up in a pile that I eventually go through and reply to. You can see all the e-mail pending review here: http://www.whatwg.org/issues/ (This thread is under processing-model currently, though that can vary over time as I rearrange the buckets to fit the prevalent topics.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inconsistent behavior for empty-string URLs
Cool, thanks. I just wanted to make sure the relevant folks from Mozilla, Opera, and WebKit were all in agreement and that I hadn't missed anyone. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Tuesday, January 12, 2010 2:21 PM To: Nicholas Zakas Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Tue, 12 Jan 2010, Nicholas Zakas wrote: Sorry to pester, but I want to make sure this comes to resolution before it's forgotten. Any other feedback? Don't worry, all e-mail sent to this list ends up in a pile that I eventually go through and reply to. You can see all the e-mail pending review here: http://www.whatwg.org/issues/ (This thread is under processing-model currently, though that can vary over time as I rearrange the buckets to fit the prevalent topics.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inconsistent behavior for empty-string URLs
I'm going to take a lack of response to this question as a no. :) Given the disparate browser implementations for dealing with empty string URLs, it seems unlikely that anyone is relying upon the current behaviors, so I'd like to suggest this change be added to HTML5: For any img, link, script, iframe, audio, video, audio, object, embed, input, html manifest, or frame tag that will result in an automatic download of an external resource must ignore any empty string URL and not download the external resource. This is true even when a base href is applied to the page. Does that sound right? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Tuesday, January 05, 2010 12:21 PM To: Simon Pieters; Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs Given all of this info, does anyone believe there's further investigation necessary before making a recommendation for this change? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Simon Pieters Sent: Tuesday, December 22, 2009 2:30 AM To: Nicholas Zakas; Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Mon, 21 Dec 2009 20:03:01 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Here are the results of testing various tags with empty URLs across different browsers. The table below indicates how many requests are sent when the given tag is encountered on the page (curiously, Firefox 3 sometimes sends two extra requests). Even though the link tags don't show it in the table, they all had href=. IE7 IE8 FF3 FF3.5 SF4 Ch3 Op10 img src= 1 1 1 0 1 1 0 link rel=stylesheet 0 0 1 1 1 1 0 link rel=icon 0 0 2 1 1 1 0 link rel=shortcut icon0 0 2 1 1 1 0 link rel=prefetch 0 0 2 0 0 0 0 script src= 0 0 1 1 1 1 0 iframe src= 0 0 0 0 0 0 0 input type=image src= 1 1 1 0 1 1 0 object data= 0 0 1 1 0 0 0 embed src=0 0 0 0 0 0 0 html manifest=0 0 0 0 1 0 0 For the most part, no two browsers act the same. Safari and Chrome are the closest (not surprising). Apply a base URL via base in all cases didn't change the results, except in IE, where it prevented the extra image request from being made. Thanks. IIRC, IE doesn't make a request when using minimized attribute syntax, i.e. img src (because it drops the attribute during parsing). -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, Jan 7, 2010 at 1:03 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: I'm going to take a lack of response to this question as a no. :) Given the disparate browser implementations for dealing with empty string URLs, it seems unlikely that anyone is relying upon the current behaviors, so I'd like to suggest this change be added to HTML5: For any img, link, script, iframe, audio, video, audio, object, embed, input, html manifest, or frame tag that will result in an automatic download of an external resource must ignore any empty string URL and not download the external resource. This is true even when a base href is applied to the page. Does that sound right? Sounds good to me. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
Given all of this info, does anyone believe there's further investigation necessary before making a recommendation for this change? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Simon Pieters Sent: Tuesday, December 22, 2009 2:30 AM To: Nicholas Zakas; Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Mon, 21 Dec 2009 20:03:01 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Here are the results of testing various tags with empty URLs across different browsers. The table below indicates how many requests are sent when the given tag is encountered on the page (curiously, Firefox 3 sometimes sends two extra requests). Even though the link tags don't show it in the table, they all had href=. IE7 IE8 FF3 FF3.5 SF4 Ch3 Op10 img src= 1 1 1 0 1 1 0 link rel=stylesheet 0 0 1 1 1 1 0 link rel=icon 0 0 2 1 1 1 0 link rel=shortcut icon0 0 2 1 1 1 0 link rel=prefetch 0 0 2 0 0 0 0 script src= 0 0 1 1 1 1 0 iframe src= 0 0 0 0 0 0 0 input type=image src= 1 1 1 0 1 1 0 object data= 0 0 1 1 0 0 0 embed src=0 0 0 0 0 0 0 html manifest=0 0 0 0 1 0 0 For the most part, no two browsers act the same. Safari and Chrome are the closest (not surprising). Apply a base URL via base in all cases didn't change the results, except in IE, where it prevented the extra image request from being made. Thanks. IIRC, IE doesn't make a request when using minimized attribute syntax, i.e. img src (because it drops the attribute during parsing). -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Mon, 21 Dec 2009 20:03:01 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Here are the results of testing various tags with empty URLs across different browsers. The table below indicates how many requests are sent when the given tag is encountered on the page (curiously, Firefox 3 sometimes sends two extra requests). Even though the link tags don't show it in the table, they all had href=. IE7 IE8 FF3 FF3.5 SF4 Ch3 Op10 img src=1 1 1 0 1 1 0 link rel=stylesheet 0 0 1 1 1 1 0 link rel=icon 0 0 2 1 1 1 0 link rel=shortcut icon 0 0 2 1 1 1 0 link rel=prefetch 0 0 2 0 0 0 0 script src= 0 0 1 1 1 1 0 iframe src= 0 0 0 0 0 0 0 input type=image src= 1 1 1 0 1 1 0 object data=0 0 1 1 0 0 0 embed src= 0 0 0 0 0 0 0 html manifest= 0 0 0 0 1 0 0 For the most part, no two browsers act the same. Safari and Chrome are the closest (not surprising). Apply a base URL via base in all cases didn't change the results, except in IE, where it prevented the extra image request from being made. Thanks. IIRC, IE doesn't make a request when using minimized attribute syntax, i.e. img src (because it drops the attribute during parsing). -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
Here are the results of testing various tags with empty URLs across different browsers. The table below indicates how many requests are sent when the given tag is encountered on the page (curiously, Firefox 3 sometimes sends two extra requests). Even though the link tags don't show it in the table, they all had href=. IE7 IE8 FF3 FF3.5 SF4 Ch3 Op10 img src=1 1 1 0 1 1 0 link rel=stylesheet 0 0 1 1 1 1 0 link rel=icon 0 0 2 1 1 1 0 link rel=shortcut icon 0 0 2 1 1 1 0 link rel=prefetch 0 0 2 0 0 0 0 script src= 0 0 1 1 1 1 0 iframe src= 0 0 0 0 0 0 0 input type=image src= 1 1 1 0 1 1 0 object data=0 0 1 1 0 0 0 embed src= 0 0 0 0 0 0 0 html manifest= 0 0 0 0 1 0 0 For the most part, no two browsers act the same. Safari and Chrome are the closest (not surprising). Apply a base URL via base in all cases didn't change the results, except in IE, where it prevented the extra image request from being made. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Simon Pieters Sent: Friday, December 18, 2009 2:25 AM To: Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Nicholas Zakas; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Fri, 18 Dec 2009 01:51:44 +0100, Simon Pieters sim...@opera.com wrote: On Thu, 17 Dec 2009 22:58:03 +0100, Simon Pieters sim...@opera.com wrote: I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, (and still haven't, just made the data slightly more digestible) I've now looked at a selection of random URLs. Conclusion: None of these seem to need a request to be made. img should fire an error event. iframe and frame should use about:blank. but it would probably be good to do so before changing things, so we have an idea what the compat impact is. http://simon.html5.org/dump/empty-url-attributes.xml img src, 3221 occurrences Some pages use these as spacers. http://10-0-1-1.category.datapicks.com/.html has: img alt=! Advanced Applet Suite onerror=this.src='http://www.datapicks.com/icon.gif'; src= align=left border=0 vspace=3 hspace=5 width=32 height=32 ...which suggests that we need to fire an error event (the page works as intended in Chrome and but has broken image boxes in Opera and Firefox). Similarly http://dailysofts.com/program/366/5247/MacDrive_6_for_Windows.html has: img alt=Stamp It onerror=this.src='/icon.gif'; src= align=left border=0 height=32 width=32 http://album.cando360.com/photo/personal_2453.html has: img src= id=GlobalUserLogined_MyHeaderImg / ...which seems like something that is filled in when the user is logged in, maybe with script. Similarly http://managedhealthcareexecutive.modernmedicine.com/mhe/article/article Detail.jsp?id=367917sk=date=%0A%09%09%09pageID=2 has: img id=randomImage src= alt=Word Verification Image Loading, please wait.../ script src, 248 occurrences These seem to be mostly not-filled-in boiletplate. iframe src, 1862 occurrences These seem to just want to get an about:blank iframe for various reasons. video src, 0 occurrences video poster, 0 occurrences audio src, 0 occurrences object data, 0 occurrences embed src, 74 occurrences These seem to be not-filled-in object/embed plugin boilerplates. Not sure if they need to invoke the plugin (from type or other) or not. source src, 0 occurrences input src, 55 occurrences Not sure what to make of these. Some are not type=image, some seem to be invisible submit buttons... command icon, 0 occurrences html manifest, 0 occurrences applet code, 0 occurrences frame src, 53 occurrences Mostly a blank main frame getting filled in with script or by clicking a link in another frame. body background, 1665 occurrences Pages with no background image... http://simon.html5.org/dump/empty-url-link-attributes.xml link rel=icon, 243 occurrences Not-filled-in boilerplate. link rel=prefetch, 0 occurrences link rel=stylesheet, 115 occurrences Not-filled-in boilerplate. -- Simon Pieters
Re: [whatwg] Inconsistent behavior for empty-string URLs
Apologies, the formatting didn't come out how I had hoped. :) Here's another attempt: IE7 IE8 FF3 FF3.5 img src=1 1 1 0 link rel=stylesheet 0 0 1 1 link rel=icon 0 0 2 1 link rel=shortcut icon 0 0 2 1 link rel=prefetch 0 0 2 0 script src= 0 0 1 1 iframe src= 0 0 0 0 input type=image src= 1 1 1 0 object data=0 0 1 1 embed src= 0 0 0 0 html manifest= 0 0 0 0 SF4 Ch3 Op10 img src=1 1 0 link rel=stylesheet 1 1 0 link rel=icon 1 1 0 link rel=shortcut icon 1 1 0 link rel=prefetch 0 0 0 script src= 1 1 0 iframe src= 0 0 0 input type=image src= 1 1 0 object data=0 0 0 embed src= 0 0 0 html manifest= 1 0 0 -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Monday, December 21, 2009 11:03 AM To: Simon Pieters; Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs Here are the results of testing various tags with empty URLs across different browsers. The table below indicates how many requests are sent when the given tag is encountered on the page (curiously, Firefox 3 sometimes sends two extra requests). Even though the link tags don't show it in the table, they all had href=. IE7 IE8 FF3 FF3.5 SF4 Ch3 Op10 img src=1 1 1 0 1 1 0 link rel=stylesheet 0 0 1 1 1 1 0 link rel=icon 0 0 2 1 1 1 0 link rel=shortcut icon 0 0 2 1 1 1 0 link rel=prefetch 0 0 2 0 0 0 0 script src= 0 0 1 1 1 1 0 iframe src= 0 0 0 0 0 0 0 input type=image src= 1 1 1 0 1 1 0 object data=0 0 1 1 0 0 0 embed src= 0 0 0 0 0 0 0 html manifest= 0 0 0 0 1 0 0 For the most part, no two browsers act the same. Safari and Chrome are the closest (not surprising). Apply a base URL via base in all cases didn't change the results, except in IE, where it prevented the extra image request from being made. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Simon Pieters Sent: Friday, December 18, 2009 2:25 AM To: Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Nicholas Zakas; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Fri, 18 Dec 2009 01:51:44 +0100, Simon Pieters sim...@opera.com wrote: On Thu, 17 Dec 2009 22:58:03 +0100, Simon Pieters sim...@opera.com wrote: I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, (and still haven't, just made the data slightly more digestible) I've now looked at a selection of random URLs. Conclusion: None of these seem to need a request to be made. img should fire an error event. iframe and frame should use about:blank. but it would probably be good to do so before changing things, so we have an idea what the compat impact is. http://simon.html5.org/dump/empty-url-attributes.xml img src, 3221 occurrences Some pages use these as spacers. http://10-0-1-1.category.datapicks.com/.html has: img alt=! Advanced Applet Suite onerror=this.src='http://www.datapicks.com/icon.gif'; src= align=left border=0 vspace=3 hspace=5
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Fri, 18 Dec 2009 01:51:44 +0100, Simon Pieters sim...@opera.com wrote: On Thu, 17 Dec 2009 22:58:03 +0100, Simon Pieters sim...@opera.com wrote: I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, (and still haven't, just made the data slightly more digestible) I've now looked at a selection of random URLs. Conclusion: None of these seem to need a request to be made. img should fire an error event. iframe and frame should use about:blank. but it would probably be good to do so before changing things, so we have an idea what the compat impact is. http://simon.html5.org/dump/empty-url-attributes.xml img src, 3221 occurrences Some pages use these as spacers. http://10-0-1-1.category.datapicks.com/.html has: img alt=! Advanced Applet Suite onerror=this.src='http://www.datapicks.com/icon.gif'; src= align=left border=0 vspace=3 hspace=5 width=32 height=32 ...which suggests that we need to fire an error event (the page works as intended in Chrome and but has broken image boxes in Opera and Firefox). Similarly http://dailysofts.com/program/366/5247/MacDrive_6_for_Windows.html has: img alt=Stamp It onerror=this.src='/icon.gif'; src= align=left border=0 height=32 width=32 http://album.cando360.com/photo/personal_2453.html has: img src= id=GlobalUserLogined_MyHeaderImg / ...which seems like something that is filled in when the user is logged in, maybe with script. Similarly http://managedhealthcareexecutive.modernmedicine.com/mhe/article/articleDetail.jsp?id=367917sk=date=%0A%09%09%09pageID=2 has: img id=randomImage src= alt=Word Verification Image Loading, please wait.../ script src, 248 occurrences These seem to be mostly not-filled-in boiletplate. iframe src, 1862 occurrences These seem to just want to get an about:blank iframe for various reasons. video src, 0 occurrences video poster, 0 occurrences audio src, 0 occurrences object data, 0 occurrences embed src, 74 occurrences These seem to be not-filled-in object/embed plugin boilerplates. Not sure if they need to invoke the plugin (from type or other) or not. source src, 0 occurrences input src, 55 occurrences Not sure what to make of these. Some are not type=image, some seem to be invisible submit buttons... command icon, 0 occurrences html manifest, 0 occurrences applet code, 0 occurrences frame src, 53 occurrences Mostly a blank main frame getting filled in with script or by clicking a link in another frame. body background, 1665 occurrences Pages with no background image... http://simon.html5.org/dump/empty-url-link-attributes.xml link rel=icon, 243 occurrences Not-filled-in boilerplate. link rel=prefetch, 0 occurrences link rel=stylesheet, 115 occurrences Not-filled-in boilerplate. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Wed, 16 Dec 2009 17:21:01 +0100, Jonas Sicking jo...@sicking.cc wrote: 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 Sounds good. script iframe video Including poster? Yes. Good catch. 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? I don't really feel strongly about applet given that it's deprecated. But sounds good. I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, but it would probably be good to do so before changing things, so we have an idea what the compat impact is. It would also be good to document what browsers do today for all of these. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
Simon, Here's a list for the first four I mentioned: img src= IE 8 and earlier: makes a request FF 3 and earlier: makes a request FF 3.5: does not make a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request link href= IE 8 and earlier: does not make a request FF 3.5 and earlier: makes a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request script src= IE 8 and earlier: does not make a request FF 3.5 and earlier: makes a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request iframe src= IE 8 and earlier: does not make a request FF 3.5 and earlier: does not make a request Safari 4 and earlier: does not make a request Chrome 3 and earlier: does not make a request Opera 10 and earlier: does not make a request -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 17, 2009 1:58 PM To: Jonas Sicking Cc: Nicholas Zakas; Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Wed, 16 Dec 2009 17:21:01 +0100, Jonas Sicking jo...@sicking.cc wrote: 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 Sounds good. script iframe video Including poster? Yes. Good catch. 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? I don't really feel strongly about applet given that it's deprecated. But sounds good. I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, but it would probably be good to do so before changing things, so we have an idea what the compat impact is. It would also be good to document what browsers do today for all of these. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, 17 Dec 2009 23:20:38 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Simon, Here's a list for the first four I mentioned: Nice. Could you test the others as well, and maybe make a table on the whatwg wiki or something? :-) Is the result different if the base URL is different from the document's URL? Is the result different if the value is #? img src= IE 8 and earlier: makes a request FF 3 and earlier: makes a request FF 3.5: does not make a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request link href= Is this for rel=stylesheet? Have you tested rel=icon and rel=prefetch (I think IE needs shortcut icon and not all browsers support prefetch)? IE 8 and earlier: does not make a request FF 3.5 and earlier: makes a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request script src= IE 8 and earlier: does not make a request FF 3.5 and earlier: makes a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request iframe src= IE 8 and earlier: does not make a request FF 3.5 and earlier: does not make a request Safari 4 and earlier: does not make a request Chrome 3 and earlier: does not make a request Opera 10 and earlier: does not make a request -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 17, 2009 1:58 PM To: Jonas Sicking Cc: Nicholas Zakas; Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Wed, 16 Dec 2009 17:21:01 +0100, Jonas Sicking jo...@sicking.cc wrote: 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 Sounds good. script iframe video Including poster? Yes. Good catch. 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? I don't really feel strongly about applet given that it's deprecated. But sounds good. I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, but it would probably be good to do so before changing things, so we have an idea what the compat impact is. It would also be good to document what browsers do today for all of these. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, 17 Dec 2009 22:58:03 +0100, Simon Pieters sim...@opera.com wrote: I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, (and still haven't, just made the data slightly more digestible) but it would probably be good to do so before changing things, so we have an idea what the compat impact is. http://simon.html5.org/dump/empty-url-attributes.xml img src, 3221 occurrences script src, 248 occurrences iframe src, 1862 occurrences video src, 0 occurrences video poster, 0 occurrences audio src, 0 occurrences object data, 0 occurrences embed src, 74 occurrences source src, 0 occurrences input src, 55 occurrences command icon, 0 occurrences html manifest, 0 occurrences applet code, 0 occurrences frame src, 53 occurrences body background, 1665 occurrences http://simon.html5.org/dump/empty-url-link-attributes.xml link rel=icon, 243 occurrences link rel=prefetch, 0 occurrences link rel=stylesheet, 115 occurrences -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
Yup, I'll take a look this weekend. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Simon Pieters Sent: Thursday, December 17, 2009 2:44 PM To: Nicholas Zakas; Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, 17 Dec 2009 23:20:38 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Simon, Here's a list for the first four I mentioned: Nice. Could you test the others as well, and maybe make a table on the whatwg wiki or something? :-) Is the result different if the base URL is different from the document's URL? Is the result different if the value is #? img src= IE 8 and earlier: makes a request FF 3 and earlier: makes a request FF 3.5: does not make a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request link href= Is this for rel=stylesheet? Have you tested rel=icon and rel=prefetch (I think IE needs shortcut icon and not all browsers support prefetch)? IE 8 and earlier: does not make a request FF 3.5 and earlier: makes a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request script src= IE 8 and earlier: does not make a request FF 3.5 and earlier: makes a request Safari 4 and earlier: makes a request Chrome 3 and earlier: makes a request Opera 10 and earlier: does not make a request iframe src= IE 8 and earlier: does not make a request FF 3.5 and earlier: does not make a request Safari 4 and earlier: does not make a request Chrome 3 and earlier: does not make a request Opera 10 and earlier: does not make a request -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 17, 2009 1:58 PM To: Jonas Sicking Cc: Nicholas Zakas; Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Wed, 16 Dec 2009 17:21:01 +0100, Jonas Sicking jo...@sicking.cc wrote: 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 Sounds good. script iframe video Including poster? Yes. Good catch. 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? I don't really feel strongly about applet given that it's deprecated. But sounds good. I asked Philip to provide some data about pages using empty attributes for these: Philip` zcorpan: http://philip.html5.org/data/empty-url-attributes.txt Philip` zcorpan: http://philip.html5.org/data/empty-url-link-attributes.txt I have not looked at these yet, but it would probably be good to do so before changing things, so we have an idea what the compat impact is. It would also be good to document what browsers do today for all of these. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Wed, 16 Dec 2009 02:21:33 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@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 links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links 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
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Wed, Dec 16, 2009 at 2:59 AM, Simon Pieters sim...@opera.com wrote: On Wed, 16 Dec 2009 02:21:33 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@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 links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links 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 Sounds good. script iframe video Including poster? Yes. Good catch. 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? I don't really feel strongly about applet given that it's deprecated. But sounds good. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
Looks like a good list to me. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, December 16, 2009 8:21 AM To: Simon Pieters Cc: Nicholas Zakas; Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Wed, Dec 16, 2009 at 2:59 AM, Simon Pieters sim...@opera.com wrote: On Wed, 16 Dec 2009 02:21:33 +0100, Jonas Sicking jo...@sicking.cc wrote: On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@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 links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links 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 Sounds good. script iframe video Including poster? Yes. Good catch. 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? I don't really feel strongly about applet given that it's deprecated. But sounds good. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Mon, 14 Dec 2009 20:08:40 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: It seems that thusfar, Jonas from Mozilla is open to this change. Is there anyone from Opera or WebKit that would like to chime in either in favor or opposition? It appears that Opera already does this (though I haven't tested SVG or CSS). I think it's ok, but I'd like it specced. :-) -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Dec 14, 2009, at 11:08 AM, Nicholas Zakas wrote: It seems that thusfar, Jonas from Mozilla is open to this change. Is there anyone from Opera or WebKit that would like to chime in either in favor or opposition? I'd love to issue fewer useless loads, if sites don't actually rely on it. Does anyone have data on what, if any, compatibility impact this has? I can't imagine loading the base URL to be terribly useful in most cases, but perhaps there are wacky sites that do indeed rely on it. Regards, Maciej Thanks. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Friday, December 11, 2009 10:15 AM To: Simon Pieters; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs I agree, automatic downloads are the real issue. a href= is fine because a user must initiate the action (and thus generate a real pageview). I'd think that the behavior should be the same in CSS and SVG for resources that are automatically downloaded. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 10, 2009 10:57 AM To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. I think it shouldn't apply to markup that doesn't download things automatically; in particular a href= should work. What about URLs in CSS and SVG? -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
If this change is made, what is the correct (explicit) way to refer to the current URL? . ? In terms of web compat, I do recall a web picture gallery package that returned a html information page with a self reference to show the actual image. -- James 2009/12/15 Maciej Stachowiak m...@apple.com On Dec 14, 2009, at 11:08 AM, Nicholas Zakas wrote: It seems that thusfar, Jonas from Mozilla is open to this change. Is there anyone from Opera or WebKit that would like to chime in either in favor or opposition? I'd love to issue fewer useless loads, if sites don't actually rely on it. Does anyone have data on what, if any, compatibility impact this has? I can't imagine loading the base URL to be terribly useful in most cases, but perhaps there are wacky sites that do indeed rely on it. Regards, Maciej Thanks. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Friday, December 11, 2009 10:15 AM To: Simon Pieters; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs I agree, automatic downloads are the real issue. a href= is fine because a user must initiate the action (and thus generate a real pageview). I'd think that the behavior should be the same in CSS and SVG for resources that are automatically downloaded. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 10, 2009 10:57 AM To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. I think it shouldn't apply to markup that doesn't download things automatically; in particular a href= should work. What about URLs in CSS and SVG? -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 6:16 AM, James May wha...@fowlsmurf.net wrote: If this change is made, what is the correct (explicit) way to refer to the current URL? . ? No, that will return the file in the current directory named .. This might be the current directory itself. You would have to say foo.html or such. This shouldn't be a big deal, given how crazy you'd have to be to use the same URL for an HTML file and an image (or whatever). In terms of web compat, I do recall a web picture gallery package that returned a html information page with a self reference to show the actual image. How did that work? It used a script that sniffed referers or something crazy like that?
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 6:55 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, Dec 15, 2009 at 6:16 AM, James May wha...@fowlsmurf.net wrote: If this change is made, what is the correct (explicit) way to refer to the current URL? . ? No, that will return the file in the current directory named .. This might be the current directory itself. You would have to say foo.html or such. This shouldn't be a big deal, given how crazy you'd have to be to use the same URL for an HTML file and an image (or whatever). I think # should work as well. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 1:44 AM, Maciej Stachowiak m...@apple.com wrote:
Does anyone have data on what, if any, compatibility impact this has? I
can't imagine loading the base URL to be terribly useful in most cases, but
perhaps there are wacky sites that do indeed rely on it.
Given that opera has this somewhat deployed, would be interesting to
hear if they have had any compatibility issues.
The one place where I've seen this used is inside XSLT stylesheets,
where i've seen something like:
xsl:value-of select=document('')/foo/bar
to read data out of the stylesheet document.
/ Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 12:33 PM, Jonas Sicking jo...@sicking.cc wrote: I think # should work as well. Good point.
Re: [whatwg] Inconsistent behavior for empty-string URLs
Is it necessary to apply this within XSLT and CSS as well? Or is it
possible to have this be an HTML-only feature? I'd be happy with the
latter.
-Nicholas
__
Commander Lock: Damnit Morpheus, not everyone believes what you
believe!
Morpheus: My beliefs do not require them to.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, December 15, 2009 9:37 AM
To: Maciej Stachowiak
Cc: Nicholas Zakas; whatwg@lists.whatwg.org; Aryeh Gregor; Simon Pieters
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 1:44 AM, Maciej Stachowiak m...@apple.com
wrote:
Does anyone have data on what, if any, compatibility impact this has?
I
can't imagine loading the base URL to be terribly useful in most
cases, but
perhaps there are wacky sites that do indeed rely on it.
Given that opera has this somewhat deployed, would be interesting to
hear if they have had any compatibility issues.
The one place where I've seen this used is inside XSLT stylesheets,
where i've seen something like:
xsl:value-of select=document('')/foo/bar
to read data out of the stylesheet document.
/ Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 11:14 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Is it necessary to apply this within XSLT and CSS as well? Or is it possible to have this be an HTML-only feature? I'd be happy with the latter. Nothing is required. But we do need a concrete proposal that everyone agrees on. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
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. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, December 15, 2009 11:47 AM To: Nicholas Zakas Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon Pieters Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Tue, Dec 15, 2009 at 11:14 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Is it necessary to apply this within XSLT and CSS as well? Or is it possible to have this be an HTML-only feature? I'd be happy with the latter. Nothing is required. But we do need a concrete proposal that everyone agrees on. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@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 links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. So the specific list would then be: img link script iframe video audio object embed source 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
Re: [whatwg] Inconsistent behavior for empty-string URLs
Yes, that sounds right. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, December 15, 2009 5:22 PM To: Nicholas Zakas Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon Pieters Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@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 links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. So the specific list would then be: img link script iframe video audio object embed source 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
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 8:21 PM, Jonas Sicking jo...@sicking.cc wrote: For example not all links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. I'd say the rule should be that if the type is text/html or unknown, should work. If it's known to be some other type, like text/css, then it should fail. Alternatively, it should work for everything that doesn't actually fetch a resource automatically. After all, the rationale for this whole change is that as a source for images and such 1) makes no sense and is almost certainly an authoring mistake, and 2) causes extra HTTP requests -- but neither is true for all links. For instance, link rel=first href= makes perfect sense and causes no extra requests, so I don't think it should be prohibited.
Re: [whatwg] Inconsistent behavior for empty-string URLs
Shouldn't this proposal take into account the CSS3 content property? (
http://www.w3.org/TR/css3-content/)
E.g., figure[alt] { content: attr(href, url), attr(alt); }
This was discussed not too long ago, starting in this thread:
Adding a src attribute to all elements (
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/023955.html
)
-Mike
On Tue, Dec 15, 2009 at 8:37 PM, Nicholas Zakas nza...@yahoo-inc.comwrote:
Yes, that sounds right.
-Nicholas
__
Commander Lock: Damnit Morpheus, not everyone believes what you
believe!
Morpheus: My beliefs do not require them to.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, December 15, 2009 5:22 PM
To: Nicholas Zakas
Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon
Pieters
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@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 links are automatically downloaded, such as
link rel=prev. However I suspect that we'll want all links to
behave the same.
So the specific list would then be:
img
link
script
iframe
video
audio
object
embed
source
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
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 5:51 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, Dec 15, 2009 at 8:21 PM, Jonas Sicking jo...@sicking.cc wrote: For example not all links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. I'd say the rule should be that if the type is text/html or unknown, should work. Interesting. I don't think we want to base it on the type attribute, since that should generally be possible to leave out. But I can certainly see a use for link rel=sitemap href=. So maybe just apply the don't-download rule rel=stylesheet (and rel=stylesheet alternate etc). / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
I agree, automatic downloads are the real issue. a href= is fine because a user must initiate the action (and thus generate a real pageview). I'd think that the behavior should be the same in CSS and SVG for resources that are automatically downloaded. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 10, 2009 10:57 AM To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. I think it shouldn't apply to markup that doesn't download things automatically; in particular a href= should work. What about URLs in CSS and SVG? -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Wed, 09 Dec 2009 21:14:00 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Can the self-reference img exception become the rule and apply to all of these tags the same way? If we'd also apply it to APIs that would be annoying actually. We have a bunch of Web Workers tests that rely on this working fine. What is wrong with having this work as is? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Inconsistent behavior for empty-string URLs
Sweet, so how can we get this done? :) -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, December 09, 2009 2:56 PM To: Nicholas Zakas Cc: Simon Pieters; Aryeh Gregor; whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Wed, Dec 9, 2009 at 12:14 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Just curious if anyone knows why img src= is the exception in the spec, rather than having the same behavior for all elements that download resources on page load? As far as I can tell, the spec would currently allow self-referencing downloads for the following elements: * iframe * embed * object * video * audio * source As stated. If the other browser vendors are ok with it, I'm ok with making the empty string mean don't load in all these cases. I.e. treat an empty src/href attribute the same way as an absence of the attribute (except for script which still wouldn't treat it as an inline script). / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. It's the automatic download that makes this problematic, as it silently doubles the number of requests to the server, which as I've said in previous emails, is a huge problem for high-volume sites. Opera already doesn't make a request in all of these cases, so I'm guessing that Web Workers is an exception? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Thursday, December 10, 2009 1:56 AM To: Nicholas Zakas; Simon Pieters; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Wed, 09 Dec 2009 21:14:00 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Can the self-reference img exception become the rule and apply to all of these tags the same way? If we'd also apply it to APIs that would be annoying actually. We have a bunch of Web Workers tests that rely on this working fine. What is wrong with having this work as is? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, Dec 10, 2009 at 10:22 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Sweet, so how can we get this done? :) Just gotta convince the other browser vendors that this is a good idea ;) / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. I think it shouldn't apply to markup that doesn't download things automatically; in particular a href= should work. What about URLs in CSS and SVG? -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: It's the automatic download that makes this problematic, as it silently doubles the number of requests to the server, which as I've said in previous emails, is a huge problem for high-volume sites. Opera already doesn't make a request in all of these cases, so I'm guessing that Web Workers is an exception? It only doubles the load if you have crappy markup (or server setup, depending on your goals). Not sure why we are not loading the resource. That'd be a bug per the current specification. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Inconsistent behavior for empty-string URLs
Just curious if anyone knows why img src= is the exception in the spec, rather than having the same behavior for all elements that download resources on page load? As far as I can tell, the spec would currently allow self-referencing downloads for the following elements: * iframe * embed * object * video * audio * source Can the self-reference img exception become the rule and apply to all of these tags the same way? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Tuesday, December 08, 2009 9:43 AM To: Simon Pieters; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs The change seems reasonable to me. It just seems that the same change should be made in all cases that cause similar issues, making it the rule of the spec instead of an exception for this one case. Does that make sense? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Tuesday, December 08, 2009 1:27 AM To: Aryeh Gregor; Nicholas Zakas Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor simetrical+...@gmail.com wrote: I don't know why img src= has a special exception. It would be possible to look through the svn log to see if there was a helpful commit message, or maybe someone will remember. I seem to remember someone from Mozilla mentioned that they recently changed the behavior for img, so Hixie changed the spec for img. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Wed, Dec 9, 2009 at 12:14 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Just curious if anyone knows why img src= is the exception in the spec, rather than having the same behavior for all elements that download resources on page load? As far as I can tell, the spec would currently allow self-referencing downloads for the following elements: * iframe * embed * object * video * audio * source As stated. If the other browser vendors are ok with it, I'm ok with making the empty string mean don't load in all these cases. I.e. treat an empty src/href attribute the same way as an absence of the attribute (except for script which still wouldn't treat it as an inline script). / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor simetrical+...@gmail.com wrote: I don't know why img src= has a special exception. It would be possible to look through the svn log to see if there was a helpful commit message, or maybe someone will remember. I seem to remember someone from Mozilla mentioned that they recently changed the behavior for img, so Hixie changed the spec for img. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 8, 2009 at 1:26 AM, Simon Pieters sim...@opera.com wrote: On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor simetrical+...@gmail.com wrote: I don't know why img src= has a special exception. It would be possible to look through the svn log to see if there was a helpful commit message, or maybe someone will remember. I seem to remember someone from Mozilla mentioned that they recently changed the behavior for img, so Hixie changed the spec for img. It turns out that img src= is decently common on the web, and in all cases we saw did *not* intend its literal interpretation (i.e. display an image using the current baseuri). So it was deemed as a worth while performance improvement to add code to suppress the network fetch. For further details see: https://bugzilla.mozilla.org/show_bug.cgi?id=444931 / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
I'd agree with that, I've yet been able to find an example of someone intentionally including an empty-string URL in one of these tags. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Sent: Monday, December 07, 2009 9:53 PM To: Nicholas Zakas Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Mon, Dec 7, 2009 at 10:51 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Hi, In a recent investigation into capacity issues, I found that there are several instances where the browser will make a second to the page based on resolving empty-string URLs in the several tags. I tested four instances: img src=, link href=, script src=, and iframe src=. Across major browsers today, the behavior is vastly different: * Internet Explorer 8 - Make a request for: img src= - Does not make a request for: link href=, script src=, iframe src= * Firefox 3 - Make a request for: img src=, link href=, script src= - Does not make a request for: iframe src=. * Firefox 3.5 - Make a request for: link href=, script src= - Does not make a request for: img src=, iframe src= * Safari 4 - Make a request for:img src=, link href=, script src= - Does not make a request for: iframe src= * Chrome 3 (same as Safari) - Make a request for:img src=, link href=, script src= - Does not make a request for: iframe src= * Opera 10 - Make a request for: (none) - Does not make a request for: img src=, link href=, script src=, iframe src= Presently, HTML5 does provide guidance on the correct behavior for img src= in section 4.8.2, indicating that Firefox 3.5's and Opera 10's behavior in this regard is correct: If the base URI of the element is the same as the document's address, then the src attribute's value must not be the empty string. This seems like it should also apply to the other elements that download resources automatically. All browsers seem to be in agreement over the behavior of iframe src= despite a lack of guidance in any HTML spec, and I'd assume that they will soon all be in agreement over img src=, per the HTML5 spec. It would be nice to formalize this behavior so that we can get all browsers to act in consistently in these confusing cases. My opinion is that Opera is the only browser currently doing this in a reasonable manner, in that it makes a lot of sense to me that an empty-string URL for an element that automatically downloads a resource should be considered invalid and ignored. My hypothesis is that these patterns are most frequently indications of errors rather than an intentional use of this little-known behavior, and as a result, sending another request is an unexpected and unwelcome result. For high-volume web sites, a single mistaken inclusion of one of these patterns immediately doubles page views, which can introduce capacity issues (which I've needed to investigate at least twice in the past three years). I'm interested in what others' opinions on this may be, as this seems like an important area in which to gain consistency. Given that the concern is sites that accidentally leave a attribute empty, wouldn't you want to prevent a request from going out even if the base-uri is set? I.e. wouldn't you want to prevent a request from going out for the current document: foo.html: headbase src=bar.html bodyimg src= It seems to me equally unlikely that someone would do that intentionally expecting a request to be sent to bar.html? / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
The change seems reasonable to me. It just seems that the same change should be made in all cases that cause similar issues, making it the rule of the spec instead of an exception for this one case. Does that make sense? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Tuesday, December 08, 2009 1:27 AM To: Aryeh Gregor; Nicholas Zakas Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor simetrical+...@gmail.com wrote: I don't know why img src= has a special exception. It would be possible to look through the svn log to see if there was a helpful commit message, or maybe someone will remember. I seem to remember someone from Mozilla mentioned that they recently changed the behavior for img, so Hixie changed the spec for img. -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Mon, Dec 7, 2009 at 1:51 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Presently, HTML5 does provide guidance on the correct behavior for img src=”” in section 4.8.2, indicating that Firefox 3.5’s and Opera 10’s behavior in this regard is correct: “If the base URI of the element is the same as the document’s address, then the src attribute’s value must not be the empty string.” That says that if it's the empty string, the document is invalid. It doesn't say what the UA has to do. The relevant part is: [[ Unless . . . the element's src attribute has a value that is an ignored self-reference, then, when an img is created with a src attribute, and whenever the src attribute is set subsequently, the user agent must resolve the value of that attribute, relative to the element, and if that is successful must then fetch that resource. . . . The src attribute's value is an ignored self-reference if its value is the empty string, and the base URI of the element is the same as the document's address. ]] This implies user agents don't need to resolve the src or fetch the element if the src is empty (unless the base URI is non-default). I don't think they're prohibited from doing so, since there's no detectable difference to their user-visible output -- likewise they might fetch resources speculatively even if not explicitly required to. It's kind of pointless, though. The other cases seem to make no specific exception for an empty URL, so as far as I can tell, the UA must fetch them as usual -- although of course it might have a valid copy in the cache. This is clearly not a good idea for iframe, since otherwise iframe src= is an instant infinite loop on a typical page. The same goes for a URL that consists only of a fragment. In fact, a quick test in the browsers I had handy (Firefox 3.5 and Opera 9.22) suggests that there are more elaborate protections against recursion here. Try saving these two files in the same directory with the names test1.html and test2.html, and viewing test1.html in a web browser: !doctype html p1/p iframe src=test2.html !doctype html p2/p iframe src=test1.html Neither browser I tested with has an infinite loop here, although they terminate at different steps: Firefox displays each page only once (visible text is 1 2), while Opera displays test1.html twice (1 2 1). Is this covered by the spec anywhere? I'm not sure it makes a difference whether script src=/script or link rel=stylesheet href= does anything special. It seems simpler to just leave them as-is, so they fetch the resource again (or retrieve it from cache if possible) and then probably throw it out as invalid (since it's HTML and not CSS/JS/etc.). I’m interested in what others’ opinions on this may be, as this seems like an important area in which to gain consistency. Why? It seems like fairly unlikely markup. Consistency is good, but I wouldn't call this point important.
Re: [whatwg] Inconsistent behavior for empty-string URLs
Thanks for the references, this helps my understanding a lot. The reason I think this is important is because the just fetch the resource again behavior is inherently destructive and unexpected. When one of these appears on a page, page views double. This isn't a problem if it's your personal blog, but for high-volume web sites such as Yahoo!, Google, and Facebook, a 100% increase in traffic causes a lot of problems. From conversations with engineers at other companies, it seems that we've all fallen victim to this behavior at one time or another. I think one would argue that img src= is unlikely markup as well, yet the spec currently provides guidance around this case. Wouldn't it make sense to be consistent across tags that act in a similar fashion? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: simetri...@gmail.com [mailto:simetri...@gmail.com] On Behalf Of Aryeh Gregor Sent: Monday, December 07, 2009 11:44 AM To: Nicholas Zakas Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Mon, Dec 7, 2009 at 1:51 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Presently, HTML5 does provide guidance on the correct behavior for img src= in section 4.8.2, indicating that Firefox 3.5's and Opera 10's behavior in this regard is correct: If the base URI of the element is the same as the document's address, then the src attribute's value must not be the empty string. That says that if it's the empty string, the document is invalid. It doesn't say what the UA has to do. The relevant part is: [[ Unless . . . the element's src attribute has a value that is an ignored self-reference, then, when an img is created with a src attribute, and whenever the src attribute is set subsequently, the user agent must resolve the value of that attribute, relative to the element, and if that is successful must then fetch that resource. . . . The src attribute's value is an ignored self-reference if its value is the empty string, and the base URI of the element is the same as the document's address. ]] This implies user agents don't need to resolve the src or fetch the element if the src is empty (unless the base URI is non-default). I don't think they're prohibited from doing so, since there's no detectable difference to their user-visible output -- likewise they might fetch resources speculatively even if not explicitly required to. It's kind of pointless, though. The other cases seem to make no specific exception for an empty URL, so as far as I can tell, the UA must fetch them as usual -- although of course it might have a valid copy in the cache. This is clearly not a good idea for iframe, since otherwise iframe src= is an instant infinite loop on a typical page. The same goes for a URL that consists only of a fragment. In fact, a quick test in the browsers I had handy (Firefox 3.5 and Opera 9.22) suggests that there are more elaborate protections against recursion here. Try saving these two files in the same directory with the names test1.html and test2.html, and viewing test1.html in a web browser: !doctype html p1/p iframe src=test2.html !doctype html p2/p iframe src=test1.html Neither browser I tested with has an infinite loop here, although they terminate at different steps: Firefox displays each page only once (visible text is 1 2), while Opera displays test1.html twice (1 2 1). Is this covered by the spec anywhere? I'm not sure it makes a difference whether script src=/script or link rel=stylesheet href= does anything special. It seems simpler to just leave them as-is, so they fetch the resource again (or retrieve it from cache if possible) and then probably throw it out as invalid (since it's HTML and not CSS/JS/etc.). I'm interested in what others' opinions on this may be, as this seems like an important area in which to gain consistency. Why? It seems like fairly unlikely markup. Consistency is good, but I wouldn't call this point important.
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Mon, Dec 7, 2009 at 10:51 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Hi, In a recent investigation into capacity issues, I found that there are several instances where the browser will make a second to the page based on resolving empty-string URLs in the several tags. I tested four instances: img src=””, link href=””, script src=””, and iframe src=””. Across major browsers today, the behavior is vastly different: * Internet Explorer 8 - Make a request for: img src=”” - Does not make a request for: link href=””, script src=””, iframe src=”” * Firefox 3 - Make a request for: img src=””, link href=””, script src=”” - Does not make a request for: iframe src=””. * Firefox 3.5 - Make a request for: link href=””, script src=”” - Does not make a request for: img src=””, iframe src=”” * Safari 4 - Make a request for:img src=””, link href=””, script src=”” - Does not make a request for: iframe src=”” * Chrome 3 (same as Safari) - Make a request for:img src=””, link href=””, script src=”” - Does not make a request for: iframe src=”” * Opera 10 - Make a request for: (none) - Does not make a request for: img src=””, link href=””, script src=””, iframe src=”” Presently, HTML5 does provide guidance on the correct behavior for img src=”” in section 4.8.2, indicating that Firefox 3.5’s and Opera 10’s behavior in this regard is correct: “If the base URI of the element is the same as the document’s address, then the src attribute’s value must not be the empty string.” This seems like it should also apply to the other elements that download resources automatically. All browsers seem to be in agreement over the behavior of iframe src=”” despite a lack of guidance in any HTML spec, and I’d assume that they will soon all be in agreement over img src=””, per the HTML5 spec. It would be nice to formalize this behavior so that we can get all browsers to act in consistently in these confusing cases. My opinion is that Opera is the only browser currently doing this in a reasonable manner, in that it makes a lot of sense to me that an empty-string URL for an element that automatically downloads a resource should be considered invalid and ignored. My hypothesis is that these patterns are most frequently indications of errors rather than an intentional use of this little-known behavior, and as a result, sending another request is an unexpected and unwelcome result. For high-volume web sites, a single mistaken inclusion of one of these patterns immediately doubles page views, which can introduce capacity issues (which I’ve needed to investigate at least twice in the past three years). I’m interested in what others’ opinions on this may be, as this seems like an important area in which to gain consistency. Given that the concern is sites that accidentally leave a attribute empty, wouldn't you want to prevent a request from going out even if the base-uri is set? I.e. wouldn't you want to prevent a request from going out for the current document: foo.html: headbase src=bar.html bodyimg src= It seems to me equally unlikely that someone would do that intentionally expecting a request to be sent to bar.html? / Jonas
