Re: [whatwg] Script preloading

[Nicholas Zakas]

When Kyle and I originally started pushing for a way to preload JavaScript
many moons ago, the intent was very simple: to allow the downloading of
JavaScript and execution of JavaScript to be separate. The idea being that
you should be able to preload scripts that you'll need later without
incurring the cost of parsing and execution at that point in time. There
are many examples of people doing this, the most famous being the Gmail
mobile approach of loading JavaScript in comments and then pulling that
code out and eval()ing it.

I still feel very strongly that this pattern is a necessary evolution of
how we should be able to load scripts into web pages. I just want a flag
that says don't execute this now and a method to say okay, execute this
now. Allowing that flag to be set both in HTML and JavaScript is ideal.

The question of dependency management is, in my mind, a separate issue and
one that doesn't belong in this layer of the web platform. HTML isn't the
right spot for a dependency tree to be defined for scripts (or anything
else). To me, that is a problem to be solved within the ECMAScript world
much the way CSS has @import available from within CSS code.

I think the use cases other than the initial one (preload/execute later)
are best relegated to script loaders and are very tied to a current way of
thinking about loading JavaScript. I'd rather provide a simple, low-level
piece of functionality that make the job of script loaders easier by
providing a reliable API and then let the dependency management use cases
be addressed outside of HTML.

Other random thoughts:

* whenneeded is a very strange name for that attribute. It doesn't really
tell me anything, as opposed to preload, noexecute, or future. How do
I know when it will be needed?

* I like execute() as the way to run the script in question.


-N





On Thu, Aug 29, 2013 at 5:58 AM, Brian Kardell bkard...@gmail.com wrote:

 On Aug 29, 2013 1:21 AM, Jonas Sicking jo...@sicking.cc wrote:
 
  Hi Ryosuke,
 
  Based on the feedback here, it doesn't sound like you are a huge fan
  of the original proposal in this thread.
 
  At this point, has any implementation come out in support of the
  proposal in this thread as a preferred solution over
  noexecute/execute()?
 
  The strongest support I've seen in this thread, though I very well
  could have missed some, is it's better than status quo.
 
  Is that the case?
 
  / Jonas
 
  On Wed, Aug 28, 2013 at 7:43 PM, Ryosuke Niwa rn...@apple.com wrote:
   On Jul 13, 2013, at 5:55 AM, Andy Davies dajdav...@gmail.com wrote:
  
   On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote:
  
   On browser preloading:
  
   There seems to an inherent conflict between 'indiscriminate'
 Pre-parsers/
   PreloadScanner and responsive design for mobile. Responsive designs
   mostly implies that everything needed for a full screen desktop is
   provided in markup to all devices.
  
  
   The pre-loader is a tradeoff, it's aiming to increase network
 utilisation
   by speculatively downloading resources it can discover.
  
   Some of the resources downloaded may be not be used but with good
 design
   and mobile first approaches hopefully this number can be minimised.
  
   Even if some unused resources get downloaded how much it matter?
  
   It matters a lot when you only have GSM wireless connection, and barely
 loading anything at all.
  
   By starting the downloads earlier, connections will be opened sooner,
 and
   the TCP congestion window to grow sooner. Of course this has to be
 balanced
   against visitors who might be paying to download those unused bytes,
 and
   whether the unused resources are blocking something on the critical
 path
   from being downloaded (believe some preloaders can re-prioritise
 resources
   if they need them before the preloader has downloaded them)
  
   Exactly.  I'd to make sure whatever API we come up gives enough
 flexibility for the UAs to decide whether a given resource needs to be
 loaded immediatley.
  
  
  
   On Jul 12, 2013, at 11:56 AM, Kyle Simpson get...@gmail.com wrote:
  
   My scope (as it always has been) put simply: I want (for all the
 reasons here and before) to have a silver bullet in script loading, which
 lets me load any number of scripts in parallel, and to the extent that is
 reasonable, be fully in control of what order they run in, if at all,
 responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might
 have existed at the time of initial request. I want such a facility because
 I want to continue to have LABjs be a best-in-class fully-capable script
 loader that sets the standard for best-practice on-demand script loading.
  
  
   Because of the different network conditions and constraints various
 devices have, I'm wary of any solution that gives the full control over
 when each script is loaded.  While I'm sure large corporations with lots of
 resources will get this right, I don't want to provide a preloading API
 

Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access

[Nicholas Zakas]

I brought this up a while ago as well:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028868.html

Echoing Ilya: this is actually a very important feature because generally you 
don't want long-lived connections (HTTP streaming) and short-lived connections 
(web page requests) going through the same hosts.

-Nicholas
 
__
Commander Lock: Dammit 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 ilya goberman
Sent: Wednesday, June 01, 2011 11:24 AM
To: whatwg@lists.whatwg.org
Subject: [whatwg] Enhancement request: change EventSource to allow cross-domain 
access


Can EventSource be enhanced to support cross-domain requests via 
Access-Control-Allow-Origin header, just like it is already done for XHR? See 
http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests.

I filed a request with WebKit bugzilla and they suggested to send it to you: 
https://bugs.webkit.org/show_bug.cgi?id=61862

The rationale and use cases are exactly the same as for XHR: it can be useful 
to access different domains.
Is support for EventSource cross domains planned at all? It is supposedly one 
of the most requested features, but I do not know how it is tracked.
Thanks

  

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I already explained that in my previous email. Parsing and compilation on a 
background thread removes some of the problem but not all of it. Ultimately, 
even if the script is just a function waiting to be called, the browser still 
executes it in a blocking fashion after parsing and compilation. It's the 
execution that is troublesome part because it interferes with the UI. The fact 
that the script isn't doing much is helpful, but once again, there will be a 
non-zero interrupt that can affect user experience.

-N

-Original Message-
From: Kornel Lesiński [mailto:kor...@geekhood.net] 
Sent: Tuesday, May 24, 2011 2:33 PM
To: whatwg@lists.whatwg.org
Cc: Nicholas Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Tue, 24 May 2011 17:34:45 +0100, Nicholas Zakas nza...@yahoo-inc.com  
wrote:

 Your assertion that loading a file that simply defines a function will  
 solve the problem is a bit too simplistic for most web applications.

Could you describe the case where wrapping script in a function would not  
solve the problem in UAs that parse scripts asynchronously?

-- 
regards, Kornel Lesiński

Re: [whatwg] window.cipher HTML crypto API draft spec

[Nicholas Zakas]

I'm excited to see this get some steam behind it, though I'd echo what some 
others have said about this being very targeted at the address book use case. 
The use case I'm more interested in is a bit simpler: I want to encrypt data 
before saving to localStorage. The key may be one that exists solely on the 
server.

IMHO, this is an important use case and potentially more common. I'd really 
like for any encryption API to enable this use case easily, and I'm having a 
hard time figuring if it's possible with this API. Can you share your thoughts 
on this (maybe some pseudo-code)?
 
-Nicholas

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of David Dahl
Sent: Tuesday, May 24, 2011 7:48 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

- Original Message -
From: Henri Sivonen hsivo...@iki.fi
To: David Dahl dd...@mozilla.com
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 2:25:53 AM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 It seems unfortunate that crypto is only available when a JavaScript
  program explicitly drives encryption. This means that in order to use
  crypto, the Web app has to be written in such a way that all its
  resource handling is programmed in JavaScript instead of using
  traditional browser-handled resource retrievals.

I imagine using resource retrieval would be the way to handle larger binary 
data decryption, and would be an amazing counterpart to this API - it also 
seems like a much bigger project to undertake. The emphasis on DOMCrypt is 
mainly on giving content developers a way to write privacy-enhanced web apps.

 Consider for example a DropBox-style service that has a browser-based UI
  but that has a design where content is encrypted on the client-side so
  that the service provider is unable to decrypt the data. In this case,
  it would make sense to be able to implement a file download by having a
  plain a href to an excrypted file and have the browser automatically
  decrypt it. Likewise, a service that allows the transmission of
  encrypted images should be implementable by having img src point
  directly to an encrypted file.

I think someone was asking about that kind of functionality during my 
presentation at Mozilla. Again, this would be a pretty advanced complement to 
this API - I would love to see something like that spec'd and implemented as 
well.

 I suggest adding a Content-Encoding type that tells the HTTP stack that
  the payload of a HTTP response is encrypted and needs to be decrypted
  using a key previously initialized using the JS API.

cool. I'll look into that.

- -

 On the other hand, it seems that letting Web apps generate per-user key
  pairs and letting Web apps discover if the user possesses the private
  key that decrypts a particular message is a privacy problem. Someone who
  wishes to surveil Web users could use private keys as supercookies,
  since the generated private key is most probably going to be unique to
  user.

Currently, my implementation requires the enduser to open a file from the file 
system in order to view the contents of the private key. It is only accessible 
to privileged code - content has no access to it whatsoever.

 OTOH, wiping keys along with cookies could lead to accidents.
 Is there a plan on how this will integrate into various private data
  deletion UIs in such a way that users have the option to delete keys but
  understand the implications and don't delete them accidentally?

Not yet. There no doubt will have to be a UI that helps users understand the 
ramifications of deleting keys, etc.

 Are all the methods that take a success callback meant to pop up a
  geolocation-style asynchronous authorization UI until the user
  perma-authorizes a site to use crypto?

It is not implemented yet, but yes, that would be the plan.
- -

 Is the plan to use Firefox Sync to sync the user's private keys across
  multiple browser instances so that the user doesn't need to manually
  transfer keys in the usual case?

I do think so, however, there are those who would caution against the private 
key ever going over the wire. I think with Sync, it would be safe.

- -

 Currently, it is unfortunate that choosing to use a webmail client
  effectively prevents a person from using encrypted email. To allow
  people to use end-to-end encrypted email with webmail apps, it would be
  useful to support OpenPGP as an encryption format. (Obviously, a
  malicious webmail app could capture the decrypted messages on the
  browser and send them back to the server, but when the webmail app
  itself doesn't contain code like that, putting the decryption in the
  browser rather than putting it on the server would still probably be
  more subpoena-resistant and resistant against casual snooping by bored
  administrators.)

I think with an API like this we might see a 

Re: [whatwg] window.cipher HTML crypto API draft spec

[Nicholas Zakas]

Why do you assume I want to access the data from localStorage only while 
offline? This use case is for an online data cache.

If I wanted to access the data offline as well, I’d probably still encrypt it 
so that it’s not in plain text on disk.

-Nicholas


From: Ian Fette (イアンフェッティ) [mailto:ife...@google.com]
Sent: Tuesday, May 24, 2011 10:16 AM
To: Nicholas Zakas
Cc: David Dahl; Henri Sivonen; whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

Well, presumably you would be using LocalStorage because you want to use the 
data offline. So, if you're offline, you need the decryption key to be 
available offline, which means either the user has a separate device with the 
key (e.g. a CAC card, not really practical for average users) or the key / 
whatever is needed to decrypt is stored somewhere on the device, at which point 
what's the point of encrypting it?
On Tue, May 24, 2011 at 10:04 AM, Nicholas Zakas 
nza...@yahoo-inc.commailto:nza...@yahoo-inc.com wrote:
I'm excited to see this get some steam behind it, though I'd echo what some 
others have said about this being very targeted at the address book use case. 
The use case I'm more interested in is a bit simpler: I want to encrypt data 
before saving to localStorage. The key may be one that exists solely on the 
server.

IMHO, this is an important use case and potentially more common. I'd really 
like for any encryption API to enable this use case easily, and I'm having a 
hard time figuring if it's possible with this API. Can you share your thoughts 
on this (maybe some pseudo-code)?

-Nicholas

-Original Message-
From: whatwg-boun...@lists.whatwg.orgmailto:whatwg-boun...@lists.whatwg.org 
[mailto:whatwg-boun...@lists.whatwg.orgmailto:whatwg-boun...@lists.whatwg.org]
 On Behalf Of David Dahl
Sent: Tuesday, May 24, 2011 7:48 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.orgmailto:whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

- Original Message -
From: Henri Sivonen hsivo...@iki.fimailto:hsivo...@iki.fi
To: David Dahl dd...@mozilla.commailto:dd...@mozilla.com
Cc: whatwg@lists.whatwg.orgmailto:whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 2:25:53 AM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 It seems unfortunate that crypto is only available when a JavaScript
 program explicitly drives encryption. This means that in order to use
 crypto, the Web app has to be written in such a way that all its
 resource handling is programmed in JavaScript instead of using
 traditional browser-handled resource retrievals.

I imagine using resource retrieval would be the way to handle larger binary 
data decryption, and would be an amazing counterpart to this API - it also 
seems like a much bigger project to undertake. The emphasis on DOMCrypt is 
mainly on giving content developers a way to write privacy-enhanced web apps.

 Consider for example a DropBox-style service that has a browser-based UI
 but that has a design where content is encrypted on the client-side so
 that the service provider is unable to decrypt the data. In this case,
 it would make sense to be able to implement a file download by having a
 plain a href to an excrypted file and have the browser automatically
 decrypt it. Likewise, a service that allows the transmission of
 encrypted images should be implementable by having img src point
 directly to an encrypted file.

I think someone was asking about that kind of functionality during my 
presentation at Mozilla. Again, this would be a pretty advanced complement to 
this API - I would love to see something like that spec'd and implemented as 
well.

 I suggest adding a Content-Encoding type that tells the HTTP stack that
 the payload of a HTTP response is encrypted and needs to be decrypted
 using a key previously initialized using the JS API.

cool. I'll look into that.

- -

 On the other hand, it seems that letting Web apps generate per-user key
 pairs and letting Web apps discover if the user possesses the private
 key that decrypts a particular message is a privacy problem. Someone who
 wishes to surveil Web users could use private keys as supercookies,
 since the generated private key is most probably going to be unique to
 user.

Currently, my implementation requires the enduser to open a file from the file 
system in order to view the contents of the private key. It is only accessible 
to privileged code - content has no access to it whatsoever.

 OTOH, wiping keys along with cookies could lead to accidents.
 Is there a plan on how this will integrate into various private data
 deletion UIs in such a way that users have the option to delete keys but
 understand the implications and don't delete them accidentally?

Not yet. There no doubt will have to be a UI that helps users understand the 
ramifications of deleting keys, etc.

 Are all the methods that take a success callback meant to pop

Re: [whatwg] window.cipher HTML crypto API draft spec

[Nicholas Zakas]

Very cool, thanks!

Followup question: is aKey in your example a string or a data structure? The 
reason I ask is because I'd love to generate the key on the server and then 
pass it back to the client for use. When I previously did some thinking about 
this, I was thinking of the key as a base64-encoded value, so just curious what 
you're using.

Thanks again,
Nicholas

-Original Message-
From: David Dahl [mailto:dd...@mozilla.com] 
Sent: Tuesday, May 24, 2011 10:28 AM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Henri Sivonen
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

Nicholas:

Sure thing. The symmetric API would look something like this: 

cipher.sym.generateKey(function callback(aKey){})
cipher.sym.encrypt(plainText, key, function callback(cipherText){})
cipher.sym.decrypt(cipherText, key, function callback(plainText){})

--- sample code ---
function createKey() {
  cipher.sym.generateKey(function (aKey){
XHR.post(/save-key/, {key: aKey}, function (result){
  if (result)
alert(Success: Your key was saved.);
});
  });
}

function saveRecord(aRecord, aKey) {
  cipher.sym.encrypt(aRecord, aKey, function (aCipherText) {
localStorage.setItem(foo, aCipherText);
  });
}

function readRecord(aID, aKey) {
  var cipherRecord = localStorage.getItem(aID);
  cipher.sym.decrypt(cipherRecord, aKey, function (plainText){
alert(plainText);
  });
}

The web app would have your browser create a key, send it to the server via 
xhr, etc, then you can use encrypt() and decrypt() to secure your localStorage 
data.

I will add the symmetric API bits to the spec. The implementation is nearly 
already done as all of the public key encryption already uses symmetric crypto 
behind the scenes. I will also add this to my implementation for 
experimentation.

Regards,

David

- Original Message -
From: Nicholas Zakas nza...@yahoo-inc.com
To: David Dahl dd...@mozilla.com, Henri Sivonen hsivo...@iki.fi
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 12:04:42 PM
Subject: RE: [whatwg] window.cipher HTML crypto API draft spec

I'm excited to see this get some steam behind it, though I'd echo what some 
others have said about this being very targeted at the address book use case. 
The use case I'm more interested in is a bit simpler: I want to encrypt data 
before saving to localStorage. The key may be one that exists solely on the 
server.

IMHO, this is an important use case and potentially more common. I'd really 
like for any encryption API to enable this use case easily, and I'm having a 
hard time figuring if it's possible with this API. Can you share your thoughts 
on this (maybe some pseudo-code)?
 
-Nicholas

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of David Dahl
Sent: Tuesday, May 24, 2011 7:48 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

- Original Message -
From: Henri Sivonen hsivo...@iki.fi
To: David Dahl dd...@mozilla.com
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 2:25:53 AM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 It seems unfortunate that crypto is only available when a JavaScript
  program explicitly drives encryption. This means that in order to use
  crypto, the Web app has to be written in such a way that all its
  resource handling is programmed in JavaScript instead of using
  traditional browser-handled resource retrievals.

I imagine using resource retrieval would be the way to handle larger binary 
data decryption, and would be an amazing counterpart to this API - it also 
seems like a much bigger project to undertake. The emphasis on DOMCrypt is 
mainly on giving content developers a way to write privacy-enhanced web apps.

 Consider for example a DropBox-style service that has a browser-based UI
  but that has a design where content is encrypted on the client-side so
  that the service provider is unable to decrypt the data. In this case,
  it would make sense to be able to implement a file download by having a
  plain a href to an excrypted file and have the browser automatically
  decrypt it. Likewise, a service that allows the transmission of
  encrypted images should be implementable by having img src point
  directly to an encrypted file.

I think someone was asking about that kind of functionality during my 
presentation at Mozilla. Again, this would be a pretty advanced complement to 
this API - I would love to see something like that spec'd and implemented as 
well.

 I suggest adding a Content-Encoding type that tells the HTTP stack that
  the payload of a HTTP response is encrypted and needs to be decrypted
  using a key previously initialized using the JS API.

cool. I'll look into that.

- -

 On the other hand, it seems that letting Web apps generate per-user key
  pairs and letting Web apps discover if the user possesses the private

[whatwg] Clarification on applicationCache events

[Nicholas Zakas]

The spec currently states this about the obsolete and error events on 
window.applicationCache (5.6.1.1):


 *   Obsolete - The manifest was found to have become a 404 or 410 page, so the 
application cache is being deleted.
 *   Error - The manifest was a 404 or 410 page, so the attempt to cache the 
application has been aborted.

Later on (5.6.4), the spec states about 404 or 410 manifest files:


 *   For each cache host associated with an application cache in cache group, 
create a task to fire a simple event named obsolete that is cancelable at the 
ApplicationCache singleton of the cache host, and append it to task list. The 
default action of these events must be, if the user agent shows caching 
progress, the display of some sort of user interface indicating to the user 
that the application is no longer available for offline use.
 *   For each entry in cache group's list of pending master entries, create a 
task to fire a simple event that is cancelable named error (not obsolete!) at 
the ApplicationCache singleton of the cache host the Document for this entry, 
if there still is one, and append it to task list. The default action of this 
event must be, if the user agent shows caching progress, the display of some 
sort of user interface indicating to the user that the user agent failed to 
save the application for offline use.

This seems to indicate that the obsolete event is always fired and the error 
event may optionally fire afterward. If that's correct, then I think the table 
in section 5.6.1.1 needs some updating to better reflect the expected behavior.

-N

Re: [whatwg] Why is @scoped required for style as flow content?

[Nicholas Zakas]

 The part of the spec that defines what browsers are supposed to do 
already reflects current browser behavior.

Can you point me to that? 

And if the spec already specifies the current browser behavior, why does the 
definition of style require the scoped attribute in flow content? This seems 
very different than the improperly nested tags scenario you mention, where the 
parser needs to perform some error recovery. 

It just doesn't seem like requiring scoped at any point adds much value. It 
makes sense as an optional attribute, but I can't think of a reason why it 
should ever be required.

-Nicholas
 
__
Commander Lock: Dammit 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 Boris Zbarsky
Sent: Thursday, March 24, 2011 6:38 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Why is @scoped required for style as flow content?

On 3/24/11 9:29 PM, Nicholas Zakas wrote:
 div
  style.foo { color: red; }/style
 /div

 works just fine in browsers today
  and the style information is applied to the entire document.

And it continues to work when they implement the proposed spec, yes.

 This is considered invalid HTML5 (tested using html5.validator.nu) because 
 the scoped attribute is missing.

Right.

 Fixing the issue results in:

 div
  style scoped.foo { color: red; }/div
 /div

The correct fix for this issue is to put this style in the head, 
isn't it?  Why would would you fix it by adding @scoped?

 It seems like the scoped attribute should be optional whenstyle  is used as 
 flow content

What are the use cases for wanting this?

 while also ensuring that the spec reflects current browser behavior.

The part of the spec that defines what browsers are supposed to do 
already reflects current browser behavior.

There's a difference between specifying what browsers should do and 
deciding what markup is valid.  For example, if we consider this markup:


   biBold and italic/b just italic/i

then the spec defines that browsers should render it so that it is 
self-describing (which they do).  But the markup is nevertheless invalid.

 Pleasant side effect is that everyone withstyle  as flow content will have 
 on less validation error to worry about.

That would be one reason to allow style as flow content: so that 
legacy pages that use it thus don't need to change anything.

However such pages don't care about validating anyway, since in HTML4 
style is _only_ valid as a child of head.  So why are we worrying 
about making it easier for them to validate?

Are there any other reasons to allow style as flow content?  That is, 
are there good use cases for it?

-Boris

[whatwg] Why is @scoped required for style as flow content?

[Nicholas Zakas]

HTML5 currently requires the scoped attribute for style elements when placed 
in an area where flow content is expected. This strikes me as strange since 
it's not backwards compatible with HTML 4 nor indicative of how browsers deal 
with style elements as flow content today. Put quite simply, this:

div
style.foo { color: red; }/style
/div

works just fine in browsers today, and the style information is applied to the 
entire document. This is considered invalid HTML5 (tested using 
html5.validator.nu) because the scoped attribute is missing. Fixing the issue 
results in:

div
style scoped.foo { color: red; }/div
/div

However, this is not equivalent to the previous code because the styles are now 
confined to the subtree of the enclosing div element.

It seems like the scoped attribute should be optional when style is used as 
flow content and disallowed when used in meta content. That way, you're adding 
the new functionality of limiting styles to a subtree while also ensuring that 
the spec reflects current browser behavior. Pleasant side effect is that 
everyone with style as flow content will have on less validation error to 
worry about.

Thoughts?

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Okay, so it sounds like everyone is really much more in favor of an approach 
that doesn't require execute() to run the code that was preloaded. That seems 
to narrow the field back down to the two proposals outlined on Kyle's wiki. The 
question really is, even with that preference, are either of these 
implementable within current browser script loading systems? More precisely, is 
the preference strong enough to rationalize making changes so that one of these 
can be implemented?

-Nicholas
 
__
Commander Lock: Dammit 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 Boris Zbarsky
Sent: Thursday, March 03, 2011 8:28 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On 3/3/11 5:20 AM, Henri Sivonen wrote:
 Are there the known to be pages that users frequently encounter that create 
 and set src on a large number of script nodes without inserting them?

Not known to me, no.  I've seen pages that create lots of scripts (one 
per each dynamic action they want to do), of course.

 Or is this a theoretical concern about accidental resource exhaustion?

More this, yes.

 Is the expectation that IE is safe because the accident happens on a sniffed 
 branch that IE doesn't get?

No, IE is safe because it coalesces the script loads in weird ways as 
discussed earlier in this thread.

 (I still quite like the idea of starting fetch upon setting .src and making 
 insertion trigger evaluation. The idea of adding an execute() method scares 
 me. Mainly because having an execute() method is so radically different from 
 how things have worked so far and having insertion execute degrades 
 gracefully(ish) in existing browsers.)

I admit the graceful degradation argument is pretty tempting

-Boris

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

After chatting a bit with Boris, it seems important for implementation that a 
script node is already in the DOM before download begins. Given that, it 
seems like this proposal is closest to being implementable:

https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=enauthkey=CJ6z2ZgO

One of the suggested alterations was to replace execute() with simply setting 
preload back to false. The reason I like execute() better is that it provides 
the opportunity for feedback in the form of a return value (false if code was 
not executed, and true if code was executed).

I'd like to know if anyone has further suggestions for how to improve this 
proposal.

-Nicholas
 
__
Commander Lock: Dammit 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: Wednesday, February 23, 2011 2:44 PM
To: Boris Zbarsky; Jorge
Cc: whatwg@lists.whatwg.org; Glenn Maynard
Subject: Re: [whatwg] Proposal for separating script downloads and execution

Sorry, I've been traveling and out of the loop for a bit. Just catching up on 
the thread.

One thing I want to throw out there: the proposals I put together were intended 
to start a discussion, not to end it. If there are parts that could be changed 
to make implementation easier, then let's make those changes. In my experience, 
things don't move until someone makes a concrete proposal that people can poke 
holes in. :)

It seems like the conversation has turned back to my original proposal, or at 
the very least, version 2: 
https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=enauthkey=CJ6z2ZgO

So to answer some of the questions brought up:

1) If execute() is called before the script is fully loaded, it should throw a 
ReferenceError. Part of the rationale for having readyState was so you could 
determine if the script was ready for execute() to be called. That purpose can 
also be served via onload and onerror.

2) Any attempt to set the text property on a dynamic script element already 
marked with preload is ignored. If the preload property is set to true after 
the text property is set to a value, then the preload property is ignored and 
remains false.

3) If cloneNode() is called on a script marked as preload, then the cloned 
script node cannot be executed. Any call to execute() will return false and do 
nothing.

I'm much more a fan of v2.1, as I think it decreases the surface area of 
changes and eliminates some of these edge cases. It also allows vendors to 
determine what the default behavior should be while allowing developers to 
accurately feature detect that decision.

So question is: what are the changes that can be made to one of these proposals 
that would make people feel comfortable implementing?

-Nicholas
 
__
Commander Lock: Dammit 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 Boris Zbarsky
Sent: Wednesday, February 23, 2011 6:18 AM
To: Jorge
Cc: whatwg@lists.whatwg.org; Glenn Maynard
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On 2/23/11 4:16 AM, Jorge wrote:
 Wouldn't this :

 HTMLScriptElement.prototype.execute= function execute () {
// ...
return (1, eval)( this.innerText ); // global eval
 }

 do it ?

No.  First of all, the script can be an external script, so innerText 
doesn't do the right thing.

 (only that it should be privileged: able to bypass the usual s.o.p. 
 restrictions wrt .innerText...)

That's the thing.  The privileged bit involves things that make it very 
difficult to transport exceptions across it correctly, especially if the 
caller of execute() is not in the same window as the script itself.  At 
least in Gecko.

-Boris

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Sorry, I've been traveling and out of the loop for a bit. Just catching up on 
the thread.

One thing I want to throw out there: the proposals I put together were intended 
to start a discussion, not to end it. If there are parts that could be changed 
to make implementation easier, then let's make those changes. In my experience, 
things don't move until someone makes a concrete proposal that people can poke 
holes in. :)

It seems like the conversation has turned back to my original proposal, or at 
the very least, version 2: 
https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=enauthkey=CJ6z2ZgO

So to answer some of the questions brought up:

1) If execute() is called before the script is fully loaded, it should throw a 
ReferenceError. Part of the rationale for having readyState was so you could 
determine if the script was ready for execute() to be called. That purpose can 
also be served via onload and onerror.

2) Any attempt to set the text property on a dynamic script element already 
marked with preload is ignored. If the preload property is set to true after 
the text property is set to a value, then the preload property is ignored and 
remains false.

3) If cloneNode() is called on a script marked as preload, then the cloned 
script node cannot be executed. Any call to execute() will return false and do 
nothing.

I'm much more a fan of v2.1, as I think it decreases the surface area of 
changes and eliminates some of these edge cases. It also allows vendors to 
determine what the default behavior should be while allowing developers to 
accurately feature detect that decision.

So question is: what are the changes that can be made to one of these proposals 
that would make people feel comfortable implementing?

-Nicholas
 
__
Commander Lock: Dammit 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 Boris Zbarsky
Sent: Wednesday, February 23, 2011 6:18 AM
To: Jorge
Cc: whatwg@lists.whatwg.org; Glenn Maynard
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On 2/23/11 4:16 AM, Jorge wrote:
 Wouldn't this :

 HTMLScriptElement.prototype.execute= function execute () {
// ...
return (1, eval)( this.innerText ); // global eval
 }

 do it ?

No.  First of all, the script can be an external script, so innerText 
doesn't do the right thing.

 (only that it should be privileged: able to bypass the usual s.o.p. 
 restrictions wrt .innerText...)

That's the thing.  The privileged bit involves things that make it very 
difficult to transport exceptions across it correctly, especially if the 
caller of execute() is not in the same window as the script itself.  At 
least in Gecko.

-Boris

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

With regards to #1, I do think it could be user-agent defined if agreement 
can't be reached on the correct default behavior (so in IE preload would 
default to true while in FF it would default to false). That seems like a 
reasonable first step.

CCing Boris to see if the implementation would be too horrible to consider.

-N


From: serverher...@gmail.com [mailto:serverher...@gmail.com] On Behalf Of Will 
Alexander
Sent: Wednesday, February 16, 2011 9:29 AM
To: Nicholas Zakas
Cc: Glenn Maynard; Will Alexander; whatwg@lists.whatwg.org; Kyle Simpson; Steve 
Souders
Subject: Re: RE: [whatwg] Proposal for separating script downloads and execution


On Feb 15, 2011 6:34 PM, Nicholas Zakas 
nza...@yahoo-inc.commailto:nza...@yahoo-inc.com wrote:

 1) Should the default behavior for dynamic script nodes be to start 
 downloading the file upon the setting of src and only execute when added to 
 the document (IE's behavior) or not?

Could the default behavior be defined by the user-agent and the value of this 
property reflect that?  So in IE the def value would be true, but false in 
other browsers.

 2) Can the proposals on the table be used to better detect the correct 
 behavior from #1?

 3) Are the proposals close to being feasible with, perhaps, some changes? Or 
 are they completely outlandish and have no possibility of reaching 
 implementation?

In this bug report Boris Zbarsky expresses concern that prefetching without 
creating memory leaks is difficult.

https://bugzilla.mozilla.org/show_bug.cgi?id=621553

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

As much as I love you guys, please make sure that only one of my email 
addresses is being used. I've had to remove my personal email address from this 
thread at least twice and it keeps magically reappearing. :)

I do believe that preloading of style sheets is a very different use case than 
preloading of JavaScript. I would also argue that the current rel=prefetch 
functionality probably works for most of the CSS preloading use cases (where 
you're likely fetching CSS for the next page you're going to navigate to, 
rather than for the current page).

That being said, I think we're going a bit off-track now. Both Kyle's and my 
proposals are based on already-existing functionality that we know doesn't 
break the web (code hacks aside). We'd both like to formalize that behavior in 
some way so that we can make better use of it. We should really be discussing 
whether any of the proposals are worth pursuing to any degree.

Some of the key questions in my mind are:

1) Should the default behavior for dynamic script nodes be to start downloading 
the file upon the setting of src and only execute when added to the document 
(IE's behavior) or not?
2) Can the proposals on the table be used to better detect the correct behavior 
from #1?
3) Are the proposals close to being feasible with, perhaps, some changes? Or 
are they completely outlandish and have no possibility of reaching 
implementation?

-N


-Original Message-
From: Kyle Simpson [mailto:get...@gmail.com] 
Sent: Tuesday, February 15, 2011 3:29 PM
To: Will Alexander
Cc: Glenn Maynard; Nicholas Zakas; whatwg@lists.whatwg.org; Nicholas C. Zakas; 
Steve Souders
Subject: Re: [whatwg] Proposal for separating script downloads and execution

 Although I'm not aware of anyone wrapping a 250KB style-sheet in
 comments, the pre-loading interface could seemingly be applied to any
 number of elements.  Nicholas' original e-mail referenced a blog post
 by Stoyan Stefanov which details a way to pre-fetch both scripts and
 stylesheets.

It's true that many developers have created various tricks for dynamically 
loading stylesheets. Since the link element doesn't fire an event when the 
stylesheet finishes loading, they've resorted to a number of hacks, usually 
related to polling some DOM element's calculated style to see if the 
stylesheet has been applied yet.

However, I haven't seen nearly as many people who are wanting to preload 
stylesheets (that is, load them but not have them applied). That doesn't 
mean it's not a valid use-case (it very well might be), but I don't see 
there's nearly as much evidence of people doing that as there is for the 
current use-case under discussion (preloading scripts). I do see that 
there's a pretty common use-case where they want to be able to load a script 
element, and be notified with a normative event when the stylesheet 
finishes, so they can execute some further JavaScript logic. But that's 
quite different from saying that they need to preload stylesheets.

If you're suggesting that we broaden the scope of this discussion to also 
include the use-cases for preloading of stylesheets, then I think that is 
not a good idea. I understand the desire to solve preloading in a 
*consistent* way (I will address that further in a moment) that would work 
for other resource types, but this discussion thread is already quite 
over-weighted with discussions just about scripts. Introducing stylesheets 
into the mix may very well cause the discussion to cross the tipping point 
into unmanageable.

Besides, if we're talking about adding stylesheets into the list of 
resources that should support preloading, why not open the conversation up 
to all types of media: images, video, audio, favicons, etc. I don't see why 
if we're going to broaden the scope of the discussion, we wouldn't just talk 
about all of those different containers' preloading mechanisms.

For the sake of discussion though, let's examine stylesheet preloading 
briefly: there's no reason that stylesheet preloading couldn't work exactly 
as I'm describing (my proposal) for script preloading. In fact, if we're 
looking at the broader context of resource preloading, there's even more 
precedent for doing it this way, when we consider that this is how Image 
preloading has worked for ages. Images are preloaded when the element's 
`src` is set, but are obviously not rendered until added to the DOM. If 
we're going for consistency, I'd say this is even more evidence for my 
proposal.


 Requiring authors opt-into the behavior seems best at least in the
 short term and readyState does not provide this mechanism.

I haven't seen any arguments which suggest that requiring an author to 
opt-in to preloading is necessary to avoid problems. Authors don't/can't opt 
into it in IE, nor does the spec currently give authors any way to opt in or 
out of the behavior, if the browser implements the current spec suggestion. 
Is there any evidence of any compat issues if a resource

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Earlier feedback on this list was that people didn't want to define readyState 
or onreadystatechange for script elements, which is why I changed my proposal 
the way that I did. Unless people's opinions have changed on that, I'm not sure 
why we're still talking about a readyState-based approach (and if it has 
changed, why not talk about my original proposal as well?). I also removed 
execute() for the same reason, the general feedback seemed to be that it 
introduced complexity even though I thought it was a bit more explicit.

You may be correct in that people may never want to set preload to false. 
You'll note that I put in my proposal that an alternate approach would be for 
preload to be set to true by default. This would allow even easier feature 
detection:

if (script.preload){
//do the preload way
}

So if browsers want that to be the default, this would act as a flag indicating 
that the new functionality is available.

I think changing the behavior of dynamic script elements to match IE's isn't a 
bad idea, but we need at least two additional things:

1) A definitive way to determine that this behavior is present (earlier in this 
thread, people seemed to agree that an explicit feature detect was important)
2) An event that allows us to know when the script is downloaded and ready for 
execution

In any case, I don't believe readyState/onreadystatechange fulfills both of 
those.


-N


From: Glenn Maynard [mailto:gl...@zewt.org]
Sent: Monday, February 14, 2011 1:37 AM
To: Kyle Simpson
Cc: Nicholas Zakas; whatwg@lists.whatwg.org; Nicholas C. Zakas; Will Alexander; 
Steve Souders
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Sun, Feb 13, 2011 at 11:09 PM, Kyle Simpson 
get...@gmail.commailto:get...@gmail.com wrote:
You seem to suggest this is a bad thing. I actually think it's a good thing 
that we're keeping script execution as much as possible in the existing 
architecture. There's lots of different reasons why the queues and behavior are 
set up the way they are, and I can say that I never intended this new add a 
script to DOM to execute suggestion was meant to imply some entirely different 
the browser must execute this now or else kind of model. That's a much more 
complicated road to go down, and one which I think we'll likely derail either 
of the two main proposals.

I was responding to Nicholas's change, since based on his example code I'm 
pretty sure he expected it to be synchronous.
Basically, the suggestion is that `preload` is how a web author can force the 
browser from its hinted you may preload to you must preload. I think this 
has the potential for confusion. It's like saying If I set a script element to 
`async`, it will definitely be asynchronous, but if I don't set it to `async`, 
then it may or may not be asynchronous, I'm just not sure. The same confusion 
would be true of defer, disabled, and a whole host of other 
attributes/properties on HTML elements that come to mind.

I don't think it's confusing, but I also don't know why anyone would want to 
set preload to false.

Between the readyState proposal and the current preload proposal (with no 
execute method), I prefer readyState.  The execute method was the critical 
difference between the two proposals; removing it essentially changed his 
proposal into a minor variation of yours.

--
Glenn Maynard

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

We've gone back and forth around implementation specifics, and now I'd like to 
get a general feeling on direction. It seems that enough people understand why 
a solution like this is important, both on the desktop and for mobile, so what 
are the next steps?

Are there changes I can make to my proposal that would make it easier to 
implement and therefore more likely to have someone take a stab at implementing?

Is there a concrete alternate proposal that's worth building out instead?

As I've said before, I believe this is an important feature in whatever 
incarnation may arise. If my solution isn't the right one, that's fine, but 
let's try to figure out what the right one is.

Thanks.

-N

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of timeless
Sent: Thursday, February 10, 2011 11:34 PM
To: Boris Zbarsky
Cc: whatwg@lists.whatwg.org; Bjoern Hoehrmann
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Fri, Feb 11, 2011 at 5:51 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 I don't think so.  If there is any parse or compilation or whatever you want
 to call it error, the script is never executed, so window.x is never
 defined.

oops, right, but i don't know that that complicates things much. you
just store a list of variables to pollute window with when /script
should be applied or the error to send to window.onerror at /script
time.

 Also, I would fully expect it to be a web compat requirement that
 window.onerror not be triggered until the script would be evaluated.  If you
 parse/compile/whatever before that and hit an error, you'd need to save that
 and report it at the right time.

sure, but that's one error to store with a pending script it's
cheaper than most other things. any attempt to speculatively compile
or compile on a thread will have to support queuing the window
assignments / onerror dispatch.

 Which means the that parse/compile/whatever process is currently not
 observable directly.  And that's a good thing!

agreed

 in theory, i believe a js engine could choose to discard all work it
 has done to validate syntax for x+y beyond saving those coordinates,
 and then either do the proper ast / bytecode / machine code generation
 lazily (or schedule to do it on a thread).

 Sure; a js engine could also not do any syntax validation at all, until it
 needs to run the script...

my operative assumption is that the scripts we're dealing with have
lots of functions which are declared but which will not be used in a
given page instance, which means that there /could/ be a win in not
performing a complete compile, both in time and space. obviously any
changes to the engines increases complexity which is a loss of sorts.

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Once again, the problem with changing how src works is that there's no way to 
feature detect this change. It's completely opaque to developers and therefore 
not helpful in solving the problem.

Again, the reason I used readyState was for tracking the script's state. My doc 
states that if execute() is called on any script whose readyState is earlier 
than loaded, then it throws an error; if it's called when readyState is 
loaded, then the code is executed and the state is changed to complete; if 
it's called when readyState is complete, nothing happens and the method 
returns false.

As I said before, I'm not married to all bits of this proposal. If there's some 
other way to achieve the same functionality, I'm all for it. The main goals are 
listed in the doc, and I'm happy to support any proposal that achieves all of 
them.

-N


-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Will Alexander
Sent: Friday, February 11, 2011 12:58 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Feb 11, 2011 10:41 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:

 We've gone back and forth around implementation specifics, and now I'd like 
 to get a general feeling on direction. It seems that enough people understand 
 why a solution like this is important, both on the desktop and for mobile, so 
 what are the next steps?

Early on it seemed there was general consensus that changing the
existing MAY fetch-upon-src-assignment to MUST or SHOULD.  Since that
is only tangential to this proposal, provides immediate benefit to
existing code, and can satisfy use cases that do not require strictly
synchronous execution.

I'm hopeful the change would generate activity around these bug reports.

https://bugs.webkit.org/show_bug.cgi?id=51650
https://bugzilla.mozilla.org/show_bug.cgi?id=621553

If I am wrong in my assessment of the consensus, does it make sense to
consider that change outside of this proposal?

 Are there changes I can make to my proposal that would make it easier to 
 implement and therefore more likely to have someone take a stab at 
 implementing?

I may have missed it, but what would execute() do if the url has not
been loaded?   Would it be similar to a synchronous XHR request, lead
to ASAP execution, or throw error?

 Is there a concrete alternate proposal that's worth building out instead?

If execute() must be synchronous, then readystate is not applicable.
Otherwise, while it should be considered, it would probably take
longer to describe and has no corresponding markup semantics.

Glenn's point about noexecute  being a natural extension of defer and
async is a good one, however neither of those required changing onload
semantics or introducing a new event type.  Readystate on the other
hand is already a well-known concept. Moreover, if history is any
indication, we'll continue using it to implement deferred exec for
awhile.

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Thanks Kyle, those comments were helpful. I've simplified and refined my 
proposal based on them and the others in this thread:
https://docs.google.com/document/d/1wLdTU3xPMKhBP0anS774Y4ZT2UQDqVhnQl3VnSceDJM/edit?hl=enauthkey=CJ6z2ZgO

Summary of changes:
* Changed noexecute to preload
* No HTML markup usage
* No change to load event
* Introduction of preload event
* Removed mention of readyState

I'd appreciate hearing feedback on this revision from everyone.

-N

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Kyle Simpson
Sent: Friday, February 11, 2011 3:42 PM
To: whatwg@lists.whatwg.org
Cc: Will Alexander; Nicholas C. Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution

 We've gone back and forth around implementation specifics, and now I'd 
 like to get a general feeling on direction. It seems that enough people 
 understand why a solution like this is important, both on the desktop and 
 for mobile, so what are the next steps?

 Are there changes I can make to my proposal that would make it easier to 
 implement and therefore more likely to have someone take a stab at 
 implementing?

Nicholas, if you're sticking with your original proposal of the `noexecute` 
on script elements, then a mechanism should be specified by which the event 
can be detected for when the script finishes loading. As stated earlier, 
`onload` isn't sufficient, since it doesn't fire until after a script has 
finished (including execution). Are you proposing instead a new event, like 
onloadingcomplete or something of that nature?

Otherwise, the next most obvious candidate for an event, using existing 
precedent, would be the `readyState=loaded`, coupled with that event being 
fired by `onreadystatechange`, as happens currently in IE (similar to XHR).

Once we have some event mechanism to detect when the script finishes 
loading, then your original proposal breaks down to:

1. Add a `noexecute` property on dynamic script elements, default it to 
false, let it be settable to true.
2. Add an `execute()` function.

For the `noexecute`, We need clearer definition on if this proposal is that 
it's only a property on dynamic script elements, or is it also a boolean 
attribute in markup script elements? If the proposal includes the markup 
attribute, we need clearer definition around the semantics of how that would 
be used. As stated, script src=... noexecute onload=this.execute() 
doesn't work (chicken-and-the-egg), so in place of that, what is a concrete 
example of how the `noexecute` boolean attribute in markup would be used and 
useful?

The `execute()` function needs further specification as to what happens if 
execute() is called too early, or on a script that already executed, or on a 
script that wasn't `noexecute`, as Will pointed out.


 Is there a concrete alternate proposal that's worth building out instead?

Aside from the event system questions, which is required for either 
proposal, the concrete alternate proposal (from me) is simply:

1. Change the suggestion behavior of preloading before DOM-append to 
required behavior, modeled as it is implemented in IE.


As to whether this one is more worth building out than your original 
proposal, my support arguments are:

1. entirely uses existing precedent, both in wording in the spec and in IE's 
implementation.
2. requires less new additions (no extra function call), which means less 
complexity to work through semantics on (see above questions about 
`execute()` semantics)


I haven't heard on this thread any serious discussion of other workable 
proposals besides those two. Correct me if I'm wrong.


 Early on it seemed there was general consensus that changing the existing
 MAY fetch-upon-src-assignment to MUST or SHOULD.

I'm not sure there's been consensus on this yet, but there's definitely been 
some strong support by several people. I'd say the two proposals are about 
even (maybe slightly in favor of `readyState`) in terms of vocalized support 
thus far.


 Since that is only
 tangential to this proposal, provides immediate benefit to existing code,
 and can satisfy use cases that do not require feature-detection or 
 strictly
 synchronous execution.

I'm not sure what you mean by do not require feature-detection. I think 
it's clear that both proposals need feature-detection to be useful. In both 
cases, we're creating opt-in behavior, and you only want to opt-in to that 
behavior (and, by extension, *not* use some other method/fallback) if the 
behavior you want exists.

If I created several script elements, but don't attach them to the DOM, and 
I assume (without feature-testing) that they are being fetched, then without 
this feature they'll never load. So I'd definitely need to feature-test 
before making that assumption.

Conversely, with `noexecute`, I'd definitely want to feature-test that 
`noexecute` was going to in fact suppress execution, 

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

The reason for using readyState/onreadystatechange was to build on 
kind-of-existing functionality rather that introducing something new. When 
thinking through the problems, I was easily able to map this onto my main goals:

1) Determine if a script is downloaded successfully or not.
2) Determine if a script has already been executed.

I'm not suggesting this is the only possible implementation, just that it was 
something familiar to developers already, and building on top of it may make 
understanding the new functionality a bit easier.

And from earlier in the thread: I'd also be fine if this were a scripting-only 
feature and wasn't used in markup. That was always a secondary use case in my 
mind.

Glenn - thanks for steering the conversation back towards interfaces.

-N

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Glenn Maynard
Sent: Wednesday, February 09, 2011 7:43 PM
To: Kyle Simpson
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson get...@gmail.com wrote:

 The original proposal is in fact more focused on the markup-driven use-case
 than on the script-driven use-case. The original proposer, Nicholas, agreed
 in an earlier message that he's really more concerned with script-driven
 functionality than markup driven functionality. And I completely agree with
 that assertion.

 In fact, I'd go so far as to say that the use-case for separating script
 loading from its parsing/execution phase (and thus being able to
 control/trigger when that phase occurs, later) is 99% driven by the
 script-loaders use-case. Script loaders by and large do not use markup
 semantics to accomplish their tasks (because most of them do not use
 document.write(script); to load scripts)

 So, if we consider the spirit of the original proposal, we should examine
 it in the proper context (the vast majority use-case), which is script
 elements being created from script logic rather than markup.

 Given that proper context, the proposal becomes something like:

 1. Give a dynamic script element a noExecute property (a boolean
 property, defaults to false, can be set to true)
 2. Give a dynamic script element an execute() function which executes a
 script that has been deferred by the noExecute property.


This is precisely what I described.  (Obviously, the noexecute flag would
be exposed both as a DOM attribute and a script property.)

The problem with *that* phrasing of the proposal (compared to the
 readyState preoloading I'm advocating) is:

 1. It asks for two new unprecedented additions to the script element
 specification. The other proposal asks to take the existing spec wording and
 change it from a may to a must (from suggestion to requirement).


It would take more than that.  It wouldn't make sense to put a must
requirement for must begin loading data when the src attribute is set, even
if the script element has not been added to the document inside a list of
steps that only happens when the script has been added to the document.

It would also require adding readyState to the script element spec; it's
currently only defined for document and media.  It would require specifying
onreadystatechange, which is only currently defined for document (and not
media, I believe).  The error event would need to be updated to reflect
the fact that it can fire when the script element isn't in the DOM tree if
the fetch fails; I think IE's behavior of firing that event in this case is
currently off-spec.

I'm not against this approach fundamentally; I'm just pointing out that it's
not a one-word s/may/must/ change.  I do believe noexecute is cleaner and
more powerful: it allows executing a fetched script synchronously, which
would make using this transparently behind a black-box script API easier.
With readyState, if you call a function and it needs an interface that isn't
yet loaded, it needs to trigger execution (by adding the script to the
document) and return with try again later, which is restrictive.  I'd also
expect most of the engine work needed to support noexecute is already
implemented for defer (a question for implementors, of course).

In any case, I'm not too worried about either approach; my main goal was
getting back to discussing interfaces, since it seemed like most of the
debate was tangental--the main relevant point seems to be guaranteeing
browsers retain the freedom to parse scripts at whatever point they want
(during load, after load, during idle time, or upon execution), which I
think everyone is strongly agreed on.

-- 
Glenn Maynard

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I had chatted with a few folks about using rel=prefetch, but there seems to be 
a lot of issues that would have to be resolved to get the behavior I'm after. 
Prefetching in this way is very passive, currently implemented as happening 
during user idle time, which is unpredictable (not to mention the issues Glen 
mentioned below). 

I think Glen summed this up correct by saying that prefetching is a hint, and 
when you want to load a script you want it to happen. This isn't to say that 
you wouldn't want to prefetch a script, but I see that as more of a way to help 
the next page you'll navigate to by priming the cache vs. helping the currently 
loaded page. 

In any event, it seems that rel=prefetch would have to change a lot vs. the 
changes to the script element to allow the same behavior.

-N

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Glenn Maynard
Sent: Wednesday, February 09, 2011 6:15 AM
To: timeless
Cc: Alexandre Morgaut; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

 On Wed, Feb 9, 2011 at 12:08 PM, Alexandre Morgaut
 alexandre.morg...@4d.com wrote:
  Another approach:
  The link tag is meant to support a prefetch value for the rel
attribute
  asking to preemptively cache the resource:
   - http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-prefetch
   - http://davidwalsh.name/html5-prefetch
  We can then write:
  link rel=prefetch type=text/javascript src=myscript.js
  let the link HTML Element have an execute() method when the type
attribute
  is one off a User-Agent supported Scripting Media Types:

Executing scripts out of a link seems very strange.

Prefetching can also be disabled by the user, heuristically disabled by the
browser or download at a lower priority.  There's no way to know in advance
whether that will happen--not just due to lack of an API to ask, but because
the browser can't always tell in advance.  Prefetching is a hint, where
script preloading shouldn't be; loaders must be able to know whether they
can load-without-executing or not.

--
Glenn Maynard

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

 What we're suggesting is that we be able to directly
 control execution, and in so doing, make an indirect hint to the browser
 that it should also strongly consider deferring the parsing.

That sounds fine to me.

Sorry for the confusion, that's exactly what I had in mind with the proposal 
initially by saying, User agents may background parse or compile the script in 
preparation for execution but must not execute the code until instructed to do 
so. It should definitely be up to the browser to determine the optimal way to 
proceed.

-N

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I had thought a bit about a new rel for links, but always got caught up on 
the execute() method and how inappropriate it was for any other content types. 
It seemed weird to be able to call such a method on link to execute a script 
when script's sole job is to execute scripts. If link then becomes capable 
of executing scripts, do we need script? 

If you can't get agreement to add a method on link, then we're back to 
possibly having a double-download situation, where you include the script via 
link and then need to create a dynamic script node to point to the same URL.

In the end it seemed that keeping script as the sole executor of scripts 
would be more likely agreed upon than augmenting link to do the same. It 
still seems like there would be more changes necessary for a link approach 
than a script approach, and I'm not sure it addresses backwards compatibility 
any better.

Once again, I expect the common case to be the script loader case, where 
script elements are created using JavaScript. In that case, there is zero 
impact on backwards compatibility when feature testing is used. The only 
backwards compatibility issue is when you use noexecute in markup, but a 
similar issue would occur using link in that case.

-N


-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Diego Perini
Sent: Wednesday, February 09, 2011 1:35 PM
To: Alexandre Morgaut
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Wed, Feb 9, 2011 at 6:57 PM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:

 On Feb 9, 2011, at 4:40 PM, Nicholas Zakas wrote:

 I had chatted with a few folks about using rel=prefetch, but there seems to 
 be a lot of issues that would have to be resolved to get the behavior I'm 
 after. Prefetching in this way is very passive, currently implemented as 
 happening during user idle time, which is unpredictable (not to mention the 
 issues Glen mentioned below).

 I think you guys are perfectly right as prefetch is not meant to say that 
 the interface will need the resource ASAP


 I think Glen summed this up correct by saying that prefetching is a hint, and 
 when you want to load a script you want it to happen. This isn't to say that 
 you wouldn't want to prefetch a script, but I see that as more of a way to 
 help the next page you'll navigate to by priming the cache vs. helping the 
 currently loaded page.

 Good point

 In any event, it seems that rel=prefetch would have to change a lot vs. the 
 changes to the script element to allow the same behavior.

 Surely, if starting from the specific prefetch behavior


 I still think that using a more declarative way to define required HTTP 
 resources would be a gain and may work in your case

 The link type list is rich:
 - 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes

 Adding a required relationShip could be more appropriate way

 link id=someScript rel=required type=text/javascript src=someData.js
 link id=someData rel=required type=application/json 
 src=someData.json
 link id=aTemplate rel=required type=text/html src=myTemplate.html

 This would still need:
 - a content property on HTML link elements (which may be also useful to 
 access raw CSS definition)

 Binding an execute(), run() or eval() method on link elements may be more 
 discussable but it doesn't hurt me that much
 This way, pre-parsing Script resources would be still possible


Completely agree, your proposal seems better, probably easier to
implement and seem less prone to backward compatibility issues to me.

I believe it would be better to leave out the script tag and try to
obtain the same benefits by defining the correct rel on link
elements.

Having script access to the content of the HTTP resource is what is
really missing and seems to me would cover most of the presented
needs.

Maybe not completely related to script loading, but bubbling all
load events up to the document like Opera does would also help
authors in determining the correct timings (when to execute/use the
resource once it is fully loaded).

--
Diego

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

The goal of this proposal is exactly what you're saying: to separate download 
from parse/execution. 

I don't think it's a common case that people would use these features via 
markup; I do think it's a common case for people to use these features via 
JavaScript to aid in dynamic script loading. However, I couldn't see a reason 
to not also allow it via markup if developers so desire (keeps consistency with 
other features).

-N

-Original Message-
From: Henri Sivonen [mailto:hsivo...@iki.fi] 
Sent: Tuesday, February 08, 2011 10:45 AM
To: Jonas Sicking
Cc: Nicholas Zakas; wha...@whatwg.org; Steve Souders; Tony Gentilcore
Subject: Re: [whatwg] Proposal for separating script downloads and execution

Jonas Sicking wrote:
 On Tue, Feb 8, 2011 at 1:28 AM, Henri Sivonen hsivo...@iki.fi wrote:
  On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
 
  On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com
  wrote:
  ? One reason I like the noexecute proposal more than relying on
 
  readyState is that noexecute can be used in markup. I.e. you can
  do
  things like:
 
  html
  head
  script src=a.js noexecute onload=...
  script src=b.js noexecute onload=...
  script src=c.js noexecute onload=...
  /head
 
  I think this would be a bad solution, because existing browsers
  wouldn't honor noexecute, so the solution wouldn't degrade
  gracefully.
 
 Actually, that depends entirely on what you're putting in the 'onload'
 handler. If you're simply waiting for all three scripts to download
 and at that point execute all three of them, for example to enable
 some feature in the page, then it would degrade just fine in older
 browsers. It would just load more slowly.
 
 I don't suspect this is an edge case either, in fact, it's the
 original use case we're trying to address here.

I thought the case being addressed here is fetching scripts early but not 
compiling or evaluating them until the app knows the functionality provided the 
script is going to be needed. The degradation story depends on the side effects 
of evaluating the script.

Aside: It seems like what the mobile Gmail developers are trying to do and what 
the browser developers are thinking *they* can outsmart the other by doing 
tricks. On one hand, browser developers want to compile scripts as early as 
possible before the script is ready to be evaluated. On the other hand, the 
mobile Gmail developers seem to believe that compiling scripts is too expensive

  Adopting the readyState / early .src assignment mechanism has these
  benefits over the proposed alternative:
   * Already (reportedly; I didn't test) work in IE. Always a plus
   over making up some new stuff.
 
 That is only the case if there is a readystatechange event. Is that
 so? Put it this way, can people solve the use case originally brought
 up here in IE9 today, without modifications?

Testing this shows that IE9 doesn't fire a progress event for the transition 
that is of interest for the use case. That is, when the script transitions to 
loaded, there's no event. Once the script has been evaluated, there is a 
(rather useless) progress event for the transition to complete. The 
interesting transition to loaded can only be observed by polling. Sigh. :-(

Demo: http://hsivonen.iki.fi/test/moz/script-readystate.html

   * Authors already have to deal with IE, so the question of opting
   in doesn't arise.
 
 I'm don't understand this.

The behavior of .src setting starts fetch already happens in IE. Even if 
authors don't like it now, they have to deal with it. There's neither opt-in 
nor opt-out. (Unless, of course, they are dealing by using browser-sniffed code 
paths.)

   * Sites already have to work when scripts haven't been fetched yet
   and when the scripts are already in the HTTP cache. Thus, starting
   the fetch earlier than before shouldn't cause breakage since the
   worst case is that the observable behavior becomes similar to the
   script already being in cache by the time the node is attached to
   the tree.
 
 There is the risk that you'll tie up a lot of network connections that
 won't be used if the scripts never end up inserted into the DOM.
 This doesn't cause site breakage, but performance is also important.

Is there any reason to believe that sites set .src on scripts they don't intend 
to have fetched?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Web Workers don't adequately solve this problem because:

1) There is no DOM. If the script being loaded and execute requires interaction 
with the DOM, it will just error out.

2) Assuming that #1 doesn't get in your way because you're not interacting with 
the DOM, you still have the potential for a double-download if caching headers 
are not set correctly.

#2 is a common problem with existing solutions as well, and one that I wanted 
to address with my proposal.

-N

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of John Tamplin
Sent: Tuesday, February 08, 2011 11:57 AM
To: Anne van Kesteren
Cc: Steve Souders; Jonas Sicking; wha...@whatwg.org; Henri Sivonen; Nicholas 
Zakas; Tony Gentilcore
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Tue, Feb 8, 2011 at 11:35 AM, Anne van Kesteren ann...@opera.com wrote:

 They have a way to download and execute scripts. So if the UI thread has a
 minimal script that takes care of creation of workers and creates a tunnel
 for DOM modifications you could theoretically be all set. (I have not
 followed this entire thread though, so apologies if I missed something.)


Is every developer having to write their own proxy to do DOM manipulations
on behalf of a Web Worker really the model you want to push here?  I know
everything looks like a nail when what you have is a hammer, but surely we
can do better than that.  I suspect the hack of downloading a commented
script and then evaluating it when needed is both easier to implement and
faster overall than such a solution, especially if the commented source is
stored in app cache.

Note that in the blog they mention that on an iPhone 2.2 parse time was 2.6
seconds for 200k of JS, compared to 240ms to just download it in a comment
-- the mobile network isn't the issue, it is the JS parser in mobile
browsers.

-- 
John A. Tamplin
Software Engineer (GWT), Google

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Knowing whether or not a script will run synchronously is key to the user 
experience. As soon as the script starts to run, the UI is frozen, so being 
able to determine when that script will run is incredibly important. 

In any event, it seems like no one disagrees that the end goal would be useful. 
How can we continue with a productive conversation to get to a resolution?

-N



-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Will Alexander
Sent: Thursday, February 03, 2011 11:58 PM
To: Jonas Sicking
Cc: whatwg@lists.whatwg.org; Kyle Simpson
Subject: Re: [whatwg] Proposal for separating script downloads and execution

 Doesn't link rel=prefetch mostly address the use-case of
 load-but-don't-execute in markup? The reason script-inserted script elements
 need this capability is more advanced than any use-case for why you'd do so
 in markup. In other words, I can't imagine that a script loader would rely
 on adding script tags through markup (like with document.write() I guess?)
 rather than just using dynamic script elements.
 Technically, the preloading event mechanism isn't strictly
 necessary, but it's quite useful for several things you can't do without it,
 and so I really don't think it's worth adjusting the spec without also
 adding that part in.

 I'm not quite sure I follow you here.

I would humbly submit that being able to query the status of a script,
while useful, is not necessary.
Fetching the src immediately upon assignment is entirely sufficient.
The readyState, while nice to have,
is not germane to the goals of this proposal. When would the executor
need to know ahead of
time that the script will run synchronously?


 What I was thinking was that we
 say that implementations MUST (in the rfc 2119 sense) start loading
 the script immediately.


The proposal's stated reason for not making this mandatory seems
sensible.  While there may be a high degree
of probability, there is no guarantee the script will actually be
used.   It would seem to me that it makes more sense to leave this
decision up to the browser, allowing it to adapt its pre-fetching
behavior (perhaps based on available bandwidth) if it chooses.
Perhaps SHOULD conveys a more appropriate level of requirement?


 Sure, but we'd also want to fire some event once the script has been
 fully downloaded so that the page doesn't have to use a timer and poll
 to figure out when the download is done.

IE will set the readyState property to loading but only when the
script has a document ancestor,
otherwise the value is uninitialized   If the value were always set
to loading to indicate pre-fetching is being
performed would that provide an appropriate level of feature
detection?  (IE currently will set the readyState to loaded once
the download has finished in either case)

Will

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I don't think readyState as Kyle describes is an appropriate candidate 
mechanism because it's not an actual indicator that the functionality exists. 
The only thing you can really be sure of if readyState is uninitialized is 
that the script element supports readyState. The fact the only browser 
supporting this presently is the same one that supports the desired behavior is 
a happy coincidence. There's nothing about the presence of readyState in 
general or the particular value that gives any explicit indication that adding 
the script node will result in a particular download/execute behavior. You may 
as well test another well-known IE property like (typeof ActiveXObject == 
object).

The thing I like about my proposal (with of course, the obvious bias that it is 
my proposal), is that it's easy and unconfusing to determine if the browser 
supports delayed execution by testing for the presence of script.execute. 

Even if my solution isn't the best one, I do believe the best one needs to 
follow this model of explicit feature detection.



-Nicholas
 
__
Commander Lock: Dammit 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 Steve Souders
Sent: Thursday, February 03, 2011 2:31 PM
To: wha...@whatwg.org
Cc: Nicholas Zakas; Jonas Sicking; Tony Gentilcore
Subject: Re: [whatwg] Proposal for separating script downloads and execution

This behavior is important to the next generation of web apps, 
especially for mobile.
 - download the bytes of JS now
 - execute later when specified (eg, when the user initiates a feature)

I've talked to several development teams that have already deployed this 
functionality but it is complex to build  maintain, and often does not 
work across even the most popular browsers. We need to lower the bar to 
developers and raise the standardization of behavior across web clients.

I'd like to see this move forward.

-Steve


On 2/1/2011 9:53 AM, Nicholas Zakas wrote:

 *Problem Statement:*

 Loading JavaScript onto a page poses several performance issues. With 
 a regular script tag, the UA waits for download and then waits for 
 execution. The defer attribute helps by not blocking on download and 
 deferring execution until later but preserves execution order; the 
 async attribute helps by not blocking on download but does block on 
 execution (the timing of which cannot be controlled) and does not 
 preserve order.

 Each of the existing solutions shifts around when download and 
 execution happens by giving developers control over when the download 
 occurs but only minimally when execution happens. As a result, 
 developers have created ever more ingenius/fragile solutions to allow 
 the separation of script downloads and execution. Examples:

 1. Preloading JS without execution 
 (http://www.phpied.com/preload-cssjavascript-without-execution/) by 
 Stoyan Stefanov, which describes how to download JavaScript without 
 execution it, as a cache-warming technique.

 2. ControlJS (http://stevesouders.com/controljs/) by Steve Souders, 
 which extends Stoyan's model to allow on-demand execution of scripts.

 3. Gmail putting JavaScript in comments and then parsing later 
 (http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html)
  
 to enable download without execution and then execution on-demand.

 The ability to separate download and execution is a trend that has not 
 only emerged, but continues to be explored. There are problems with 
 the previous solutions, the biggest of which (in the case of #1 and 
 #2) is the reliance on the browser caching behavior which may, in some 
 instances, lead to a double download of the same script. It would be 
 preferable for a standardized approach to achieve these goals.

 *Overview of Proposal:*

 Add a new attribute to the script called noexecute (for lack of a 
 better term) that instructs the browser to download the script but do 
 not execute it. Developers must manually execute the code by calling 
 an execute() method on the script node. Simple example:

 var script = document.createElement(script);

 script.noexecute = true;

 script.src = foo.js;

 document.head.appendChild(script);

 //later

 script.execute();

 *Proposal Details:*

 Because there are a lot of nuanced changes to script as a result of 
 this proposal, I've written up a full description here:

 https://docs.google.com/document/d/1s8_iRr1TcwcDtShgfuGThapwZtVXItymw5zc16D0Pz8/edit?hl=enauthkey=CNbDlo8J
  
 https://docs.google.com/document/d/1s8_iRr1TcwcDtShgfuGThapwZtVXItymw5zc16D0Pz8/edit?hl=enauthkey=CNbDlo8J

 I'd love some feedback on whether or not this a) makes sense and b) is 
 feasible.

 -Nicholas

 __

 Commander Lock: Dammit Morpheus, not everyone believes what you

[whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

Problem Statement:

Loading JavaScript onto a page poses several performance issues. With a regular 
script tag, the UA waits for download and then waits for execution. The defer 
attribute helps by not blocking on download and deferring execution until later 
but preserves execution order; the async attribute helps by not blocking on 
download but does block on execution (the timing of which cannot be controlled) 
and does not preserve order.

Each of the existing solutions shifts around when download and execution 
happens by giving developers control over when the download occurs but only 
minimally when execution happens. As a result, developers have created ever 
more ingenius/fragile solutions to allow the separation of script downloads and 
execution. Examples:

1. Preloading JS without execution 
(http://www.phpied.com/preload-cssjavascript-without-execution/) by Stoyan 
Stefanov, which describes how to download JavaScript without execution it, as a 
cache-warming technique.
2. ControlJS (http://stevesouders.com/controljs/) by Steve Souders, which 
extends Stoyan's model to allow on-demand execution of scripts.
3. Gmail putting JavaScript in comments and then parsing later 
(http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html)
 to enable download without execution and then execution on-demand.

The ability to separate download and execution is a trend that has not only 
emerged, but continues to be explored. There are problems with the previous 
solutions, the biggest of which (in the case of #1 and #2) is the reliance on 
the browser caching behavior which may, in some instances, lead to a double 
download of the same script. It would be preferable for a standardized approach 
to achieve these goals.

Overview of Proposal:

Add a new attribute to the script called noexecute (for lack of a better 
term) that instructs the browser to download the script but do not execute it. 
Developers must manually execute the code by calling an execute() method on the 
script node. Simple example:

var script = document.createElement(script);
script.noexecute = true;
script.src = foo.js;
document.head.appendChild(script);

//later
script.execute();

Proposal Details:
Because there are a lot of nuanced changes to script as a result of this 
proposal, I've written up a full description here:
https://docs.google.com/document/d/1s8_iRr1TcwcDtShgfuGThapwZtVXItymw5zc16D0Pz8/edit?hl=enauthkey=CNbDlo8J

I'd love some feedback on whether or not this a) makes sense and b) is feasible.

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I almost completely agree with you. The major issue I have with the way the 
spec is written is that there is no way to feature detect this capability. I'd 
like this behavior (which I agree, is useful), to be more explicit so we can 
easily make use where available.

-Nicholas
 
__
Commander Lock: Dammit 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 Kyle Simpson
Sent: Tuesday, February 01, 2011 10:25 AM
To: whatwg@lists.whatwg.org
Cc: Nicholas Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution

? The ability to separate download and execution is a trend that has not 
only emerged, but continues to be explored. There are problems with the 
previous solutions, the biggest of which (in the case of #1 and #2) is the 
reliance on the browser caching behavior which may, in some instances, lead 
to a double download of the same script. It would be preferable for a 
standardized approach to achieve these goals.

Absolutely agree with Nicholas that this is a necessary (but I think more 
advanced) use-case in script loading. It's *especially* useful for the 
mobile web, where CPU utilization (the parsing/execution of scripts) must be 
carefully managed. For instance, you might want to take advantage of loading 
a bunch of code all at once, while the mobile radio receiver is still on in 
the initial loading, but then choose to execute them piece by piece as the 
user needs it.

Of course, in the desktop world, it's useful as well, as script loaders can 
use this technique to load multiple files in parallel, but execute them in a 
desired order (for dependency-sake). FYI: for *that* particular use-case, a 
solution has already been discussed, and, as I understand it, Ian has agreed 
to add it to the spec. I'm referring to the async=false functionality 
proposal that's been discussed in various forums for the past few months, 
and is now in implementation in FF4 and coming soon to Webkit.



 Add a new attribute to the script called noexecute (for lack of a better 
 term) that instructs the browser to download the script but do not execute 
 it. Developers must manually execute the code by calling an execute() 
 method on the script node.

I'm not particularly in favor of this proposal, mostly because the spec 
already has a mechanism listed in it (and indeed it's been implemented in IE 
since v4) for doing exactly this.

http://dev.w3.org/html5/spec/Overview.html#running-a-script

In step 12:
For performance reasons, user agents may start fetching the script as soon 
as the attribute is set, instead, in the hope that the element will be 
inserted into the document. Either way, once the element is inserted into 
the document, the load must have started. If the UA performs such 
prefetching, but the element is never inserted in the document, or the src 
attribute is dynamically changed, then the user agent will not execute the 
script, and the fetching process will have been effectively wasted.

In other words, you can begin downloading one or more scripts (but not 
executing them) by simply creating a script element dynamically and setting 
its `src` property. The script will not be executed (even if it finishes 
downloading) until the script element is added to the DOM. In this way, you 
can easily create several script elements (but not append them to the DOM), 
and then when you want to execute them, you simply append them to the DOM in 
the order you prefer.

IE goes one step further, which I think is useful, which is to give a 
`readyState` (and `onreadystatechange` event handling) to the script 
element, which notifies the code of the state of this preloading. Why this 
is useful is that you may choose to wait until all scripts have finished 
loading before starting to execute them. Being notified of when they finish 
loading (but not executing) can be a very useful addition to this technique.

The wording in the spec lists this idea as may. I suggest that the 
discussion Nicholas has proposed should shift to discussing if the spec 
should:

1) change may to shall or will to move it from being a suggestion to 
being a directly specified thing (that way the other browsers besides IE 
have incentive to eventually include it)

2) consider also specifying (rudimentary/basic wording of course) a 
mechanism similar to or compatible with IE's existing `readyState` event 
emissions for the script tag, such that the progress of the preloading 
(script.src set but script not yet DOM appended) can be monitored if 
need-be.

The primary reason I'm in favor of this approach over the one Nicholas 
suggests is because it's already in the spec as a suggestion (less work to 
get it to fully specified) and because one browser has already implemented 
and proven the approach, a foundation

[whatwg] Small consistency issue with HTML5 nav element examples

[Nicholas Zakas]

In section 4.4.5 (the aside element), an example is given that shows nav 
being used within footer.

Section 4.4.3 (the nav element), explains that this would be an inappropriate 
use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element):

Not all groups of links on a page need to be in a nav element - only sections 
that consist of major navigation blocks are appropriate for the nav element. In 
particular, it is common for footers to have a short list of links to various 
pages of a site, such as the terms of service, the home page, and a copyright 
page. The footer element alone is sufficient for such cases, without a nav 
element.

Minor inconsistency, but felt it was worth pointing out to avoid confusion.

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

Re: [whatwg] Small consistency issue with HTML5 nav element examples

[Nicholas Zakas]

Ah, I misinterpreted. With this in mind, I'm a bit unclear as to when nav 
should be used. If it's intended for primary navigation but secondary 
navigation can also be marked up with it, does that mean it's best to use nav 
whenever you have more than one link grouped together?

Thanks.

-Nicholas
 
__
Commander Lock: Dammit 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: Friday, January 14, 2011 3:58 PM
To: Nicholas Zakas
Cc: wha...@whatwg.org
Subject: Re: [whatwg] Small consistency issue with HTML5 nav element examples

On Fri, 14 Jan 2011, Nicholas Zakas wrote:

 In section 4.4.5 (the aside element), an example is given that shows 
 nav being used within footer.
 
 Section 4.4.3 (the nav element), explains that this would be an 
 inappropriate use of nav 
 (http://dev.w3.org/html5/spec/Overview.html#the-nav-element):
 
 Not all groups of links on a page need to be in a nav element - only 
 sections that consist of major navigation blocks are appropriate for the 
 nav element. In particular, it is common for footers to have a short 
 list of links to various pages of a site, such as the terms of service, 
 the home page, and a copyright page. The footer element alone is 
 sufficient for such cases, without a nav element.

It doesn't say it's inappropriate, such that it's not necessary. It's 
still fine to use it there. I'll try to clarify that.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Clarification request on Server-Sent Events Last-Event-ID

[Nicholas Zakas]

Just a quick question about the Last-Event-ID header. The spec currently says:

If the event source's last event ID string is not the empty string, then a 
Last-Event-ID HTTP header must be included with the request, whose value is 
the value of the event source's last event ID string, encoded as UTF-8.

Consider the following scenario: a connection is established and one of the 
events has an id of foo, so the last event ID of the event source is now 
foo. The connection drops and on reconnect, the header Last-Event-ID: foo is 
sent per the spec. The next stream of events coming through do not have any 
IDs. The connection is dropped again.

The question is whether or not Last-Event-ID: foo should be sent a second time? 
Technically, it is the last event ID of the event source, and the spec never 
mentions resetting the last event ID outside of an empty id field in the 
stream.

Thanks.

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

[whatwg] Server-Sent Events and CORS

[Nicholas Zakas]

In the latest draft of Server-Sent Events, the EventSource object upholds the 
same origin policy for event stream resources. Although CORS is mentioned in 
the references section, it's not mentioned in the body of the spec, so I was 
wondering if this has been brought up before?

The reason I bring this up now is that it seems cross-origin requests are far 
more important for hanging GET requests than for normal XHR. Consider a large 
scale web application that uses Apache for serving pages. You clearly do not 
want Apache handling high-duration requests on top of normal page serving, as 
the former could prevent the latter if there are enough simultaneous 
connections. In practice, you'd want a separate box or series of boxes to 
handle just the hanging GETs, possibly running Jetty or NodeJS, so that the 
hanging GET requests don't affect the performance of the page serving.

IMHO, CORS really needs to be included as part of any implementation so that 
this can be used at scale. Otherwise, developers would be forced to use an 
iframe/postMessage() mechanism to work around the same origin policy. Are there 
any plans to formally include CORS in the spec?

Thanks.

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

Re: [whatwg] Question regarding event: in server-sent events

[Nicholas Zakas]

Just for my own understanding, what you're saying is:

1) Any event name in the stream must be a valid event name in that it must not 
have spaces, special characters, etc. (The wording in the spec made me think 
that it must be an event name that is listed in the DOM Events spec, such as 
click.)

2) When you define an custom event name, this still fires the message event 
with event.type set to the custom event name.

Are those correct?

-Nicholas
 
__
Commander Lock: Dammit 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: Friday, October 15, 2010 11:42 AM
To: wha...@whatwg.org; Nicholas Zakas
Subject: Re: [whatwg] Question regarding event: in server-sent events

On Fri, 15 Oct 2010 20:34:14 +0200, Nicholas Zakas nza...@yahoo-inc.com  
wrote:
 In reading through the spec, it looks like this is legal in the event  
 stream:

 event: foo
 data: bar

 And then processed as:

 If the event name buffer is not the empty string but is also not a  
 valid event type name, as defined by the DOM Events specification, set  
 the data  buffer and the event name buffer to the empty string and  
 abort these steps.

 If I'm reading this correctly, an event name of foo would fail this  
 step in the process and not cause a message event to be fired. However,  
 if the event name were for example click, then this would be okay and  
 the following step would be taken:

foo is a valid event type name. This would only fail when  
Event.initEvent(event name buffer, ...) fails. It seems per the current  
draft of DOM Events that will be never so maybe this ought to be reworded  
some. But then DOM Events is not done yet so...


 3)   Assuming I've understood the current spec correctly, what is  
 the use case for named events?

To make dispatching to different parts of the code easier. Without having  
to create some kind of logic that parses the data first.


-- 
Anne van Kesteren
http://annevankesteren.nl/

[whatwg] Question regarding event: in server-sent events

[Nicholas Zakas]

In reading through the spec, it looks like this is legal in the event stream:

event: foo
data: bar

And then processed as:

 If the event name buffer is not the empty string but is also not a valid 
 event type name, as defined by the DOM Events specification, set the data  
 buffer and the event name buffer to the empty string and abort these steps.

If I'm reading this correctly, an event name of foo would fail this step in 
the process and not cause a message event to be fired. However, if the event 
name were for example click, then this would be okay and the following step 
would be taken:

If the event name buffer has a value other than the empty string, change the 
type of the newly created event to equal the value of the event name  buffer.

A few questions about this:

1)   Does this mean that a click event would be fired on the EventSource 
object, such as that onclick would be called? Or does this still fire the 
message event but event.type is now click?
2)   Why the limitation of events only in the DOM Events spec? It seems 
that most of those events are irrelevant in the context of a non-UI part of the 
page.
3)   Assuming I've understood the current spec correctly, what is the use 
case for named events?

Thanks,
Nicholas

Re: [whatwg] script features

[Nicholas Zakas]

Really like the idea, though I think the naming of Opera's events 
(beforescript, afterscript) fit in better with other events on the page 
(i.e. beforeunload).

-Nicholas
 
__
Commander Lock: Dammit 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 Giorgio Maone
Sent: Monday, August 16, 2010 11:12 PM
To: Jonas Sicking
Cc: WHAT Working Group
Subject: Re: [whatwg] script features

  They would be great additions, thanks.

 2. scriptwillexecute/scriptdidexecute events
Notice that Opera has a richer set of eventsof this kind (exsposed to 
privileged User Scripts, though, AFAIK), allowing for much more control over 
the executing scripts, no matter if from script elements, event handlers or 
URLs:
http://www.opera.com/docs/userjs/specs/#evlistener

Cheers
-- G

Jonas Sicking wrote, On 17/08/2010 6.15:
 Hi All,

 I'd like to propose a couple of simple features to makescript
 elements more useful:

 1. document.currentScript

 This property returns the currently executingscript, if any.
 Returns null if noscript  is currently executing. In the case of
 several nested executingscripts, it returns the innermost one. This
 is useful for being able to pass parameters to the script by setting
 data- attributes on the script element.

 I think jQuery already does things that requires knowing which
 script  element linked to jQuery, and it approximates this property
 by getting the last element in
 document.getElementsByTagName(script), which won't work reliably.
 Especially with features likescript async.

 2. scriptwillexecute/scriptdidexecute events

 These events fire right before and right after ascript  is executed.
 This allows a page to override the context a specific script is
 seeing. For example installing compatibility shims for older browsers.
 Another possible use for this is to make ads execute asynchronously.
 Currently this is problematic because a lot of ads use document.write
 and so the content will be lost (or worse) if an async attribute is
 added to thescript  element used to load the ad. Using these events
 a page can override document.write while a specific script is
 executing and insert the written content into the DOM.

 (I've written an implementation for firefox for these features here:
 https://bugzilla.mozilla.org/show_bug.cgi?id=587931)

 / Jonas

Re: [whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

So given no strenuous objections, can we make expiration for Web Storage real? 
:)

-Nicholas
 
__
Commander Lock: Dammit 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, August 04, 2010 10:26 AM
To: Jeremy Orlow
Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow jor...@chromium.org wrote:
 On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com
 wrote:
  Yes, for IndexDB I think having a per-storage area expiration date
  completely makes sense. Do you expect that IndexedDB will become a 
  successor
  to sessionStorage/localStorage?

 No.  I think LocalStorage will stick around since it's just so simple to use
 and a lot of people just need to store a tiny bit of data here or
 there--much like cookies.  IndexedDB will be used for structured data, so I
 don't see many people using it for things they one used (abused) cookies
 for.


 My belief is that the simple key-value store paradigm would still end up
 being the default client-side data storage utility, and would therefore
 benefit from having a per-key expiration time to mimic cookie usage.

 I suspect it will be much easier to add to IndexedDB than to
 localStorage/sessionStorage. I don't expect the latter to go away,
 though generally it seems like people are disliking localStorage
 enough that it's hard to get any changes made to it.

 Jonas, are you against the expiration feature proposal for LocalStorage?
  Because no one else has voiced the typical we should just leave
 LocalStorage alone concerns.  So if you're not, I think we can assume that
 such types (me included) aren't going to raise such a concern.
 I'm actually much less enthusiastic about expiration for IndexedDB as I
 don't see very compelling use cases.

I'm definitely for expiration of localStorage values. Though I think
it also makes sense to do for IndexedDB. Especially if it can be done
on a per-objectStore basis as that makes it very low overhead.

/ Jonas

Re: [whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

Is it easier in terms of implementation issues or general consensus?

-Nicholas
 
__
Commander Lock: Dammit 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: Monday, August 02, 2010 5:51 PM
To: Nicholas Zakas
Cc: Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 Yes, for IndexDB I think having a per-storage area expiration date completely 
 makes sense. Do you expect that IndexedDB will become a successor to 
 sessionStorage/localStorage? My belief is that the simple key-value store 
 paradigm would still end up being the default client-side data storage 
 utility, and would therefore benefit from having a per-key expiration time to 
 mimic cookie usage.

I suspect it will be much easier to add to IndexedDB than to
localStorage/sessionStorage. I don't expect the latter to go away,
though generally it seems like people are disliking localStorage
enough that it's hard to get any changes made to it.

/ Jonas

Re: [whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

If a site could create multiple Storage areas, then I would agree that per-item 
expiration wouldn't be necessary and we could get along fine with per-storage 
expiration. However, that's not the case, and the expiration use case is 
clearly already present.

Having every developer that wants to expire data write his or her own code 
seems extremely wasteful to me. Why ask people to reinvent the same 
functionality over and over again? Whether or not cookies are a good model to 
follow, the expiration functionality is what makes auth sequences using them 
feasible. 

I'd defer to those who know on implementation details, but this doesn't seem 
like a very hard problem to solve in a performant way.

-Nicholas
 
__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

-Original Message-
From: Scott Hess [mailto:sh...@google.com] 
Sent: Friday, July 30, 2010 5:05 PM
To: Nicholas Zakas
Cc: Jeremy Orlow; Alexandre Morgaut; whatwg@lists.whatwg.org; Jonas Sicking
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 And I totally agree, this is not a strong security feature, and that's not
 the intent. The intent is just to give an extra measure of control of the
 lifetime of the data to bring Web Storage closer to being a replacement for
 a wider range of functionality that currently uses cookies.

I don't think this really follows.  Cookies were invented quite awhile
ago, and may not be a good model for development.  A reasonably small
dataset allows the client to expire cookies aggressively.  With large
local storage, doing per-item expiration is not a good idea - you do
not want your UA groveling through a gig of data you are not otherwise
using to expire a couple dozen items.  Per-database expiration might
make sense, because the expiration information could be stored in a
central location as a hint to the UA (if the site isn't going to use
the data after two weeks, might as well delete it).  Sites could
segment their expiration needs by using multiple data stores.

That said, idle storage is eventually going to be reclaimed anyhow, so
you could just ignore the problem.  Current storage proposals are much
richer than cookies, so the developer could just store dates alongside
their other data and make the decisions directly, no need for the
system to help.  Since the JavaScript accessing the data is executing
right next to the data, you don't have the latency issues
client/server communication introduces.  So long as expiration is a
SHOULD, its not clear to me that this idiom is powerful enough to
deserve footprint in the spec.

-scott

Re: [whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

Yes, for IndexDB I think having a per-storage area expiration date completely 
makes sense. Do you expect that IndexedDB will become a successor to 
sessionStorage/localStorage? My belief is that the simple key-value store 
paradigm would still end up being the default client-side data storage utility, 
and would therefore benefit from having a per-key expiration time to mimic 
cookie usage.

To be clear, I think there should be expiration for all forms of client-side 
data storage, and adding it to one doesn't seem like a reason to not add it to 
all.

-Nicholas
 
__
Commander Lock: Dammit 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, August 02, 2010 2:10 PM
To: Nicholas Zakas
Cc: Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 If a site could create multiple Storage areas, then I would agree that 
 per-item expiration wouldn't be necessary and we could get along fine with 
 per-storage expiration. However, that's not the case, and the expiration use 
 case is clearly already present.

If we add this to IndexedDB then there are certainly multiple storage
areas. You can have any number of objectStores inside any number of
databases.

 Having every developer that wants to expire data write his or her own code 
 seems extremely wasteful to me. Why ask people to reinvent the same 
 functionality over and over again? Whether or not cookies are a good model to 
 follow, the expiration functionality is what makes auth sequences using them 
 feasible.

 I'd defer to those who know on implementation details, but this doesn't seem 
 like a very hard problem to solve in a performant way.

If we add expiration to IndexedDB on an objectStore level, then the
page author doesn't need to do anything beyond setting an expiration
date, right?

/ Jonas

Re: [whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

To answer a few of the questions brought up in this thread all in one bang:

1)   TTL vs. Date - I originally was going to propose a date, but the more 
I dug in and around uses cases for cookies, the more frequently I found people 
setting dates based on a TTL (i.e., I want this to expire in one year, so I add 
one year to the current date and set that as the expiration). It seemed that 
the TTL case was more common, and you could easily set an actual date via (new 
Date(January 1, 2011) - new Date()) if that's what you really want.
2)   Expiration for the entire data store vs. individual keys - Funny 
enough, my original proposal was for the entire data store, but then I went 
back and looked at cookies again to try to find the analogy. It seemed to me 
that, in the current localStorage, each key is analogous to a single cookie. 
Since each single cookie has an expiration, it seemed like letting each key 
have a separate TTL would provide parity.
3)   MAY vs. SHOULD - I could be convinced either way. The important thing, 
in my mind, is that the browser makes its best attempt to remove the data when 
specified.

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Jeremy Orlow
Sent: Friday, July 30, 2010 8:22 AM
To: Jonas Sicking
Cc: whatwg@lists.whatwg.org; Nicholas Zakas
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Fri, Jul 30, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote:
It might be worth integrating this into IndexedDB as it seems like
people are more reluctant to add additional features to localStorage
for various reasons.

I have expressed this opinion quite vocally in the past, but given that 
expiration is an ability of cookies, cookies suffer from the same race 
conditions localStorage does [1], and giving people fewer reasons to depend on 
cookies is definitely good for the web (in terms of bandwidth and latency), I 
actually think we should go ahead with something like this.

The main thing is that it'd need to be specced as a MAY condition.  I.e. the 
browser MAY delete the content once it expires.  After all, if the user never 
turns on the computer, there's no possible way for the UA to delete the data.  
It'd then be up to the UAs to decide how agressive they'd like to be about 
deleting it.

I'd suggest moving forward looking at expiration for WebStorage first and then 
evaluate it for IndexedDB later on (since there's still a lot of more important 
stuff in the air with that spec right now).

One key question is if expiration needs to happen on a per-value
basis. Or if per-storage-area (per objectStore) is enough?

Good point.  Several of the use cases I can think of seems as though they might 
be solvable with just a global setting.  Unless there's a couple use cases 
where this seems fairly compelling, maybe we should concentrate on such a 
solution.

On Fri, Jul 30, 2010 at 9:07 AM, Alexandre Morgaut 
alexandre.morg...@4d.commailto:alexandre.morg...@4d.com wrote:
To update this expires or TTL attribute of this item, I would consider

Storage::setExpiration(in DOMString key, in TTL or expiration Date)

(or Storage::setTTL() if you guys don't agree on the Date option)

This might make sense, but I'm also not sure it's worth the additional API 
surface area.  Plus I kind of like the idea of making it difficult for people 
to detect whether the browser even supports expiration since we don't people to 
ever assume they can count on it.  (Since once again, what if the user doesn't 
turn on their computer or the UA doesn't delete expired data unless it's 
running?)

J

[1] Yes, I know it's specced to be non-racy, but no one implements it that way.

Re: [whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

I'm also not keen on UA sniffing for the determination of features, which is 
why I mentioned using localStorage.setItem.length to determine if the TTL 
parameter is valid for the browser.

IMO, it's fine not to delete the data while the page is loaded, but I would 
like to ensure that the data isn't able to be read if the expiration time is 
reached during the page lifecycle.

And I totally agree, this is not a strong security feature, and that's not the 
intent. The intent is just to give an extra measure of control of the lifetime 
of the data to bring Web Storage closer to being a replacement for a wider 
range of functionality that currently uses cookies.

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Jeremy Orlow
Sent: Friday, July 30, 2010 11:18 AM
To: Alexandre Morgaut
Cc: whatwg@lists.whatwg.org; Nicholas Zakas; Jonas Sicking
Subject: Re: [whatwg] Proposal for Web Storage expiration

On Fri, Jul 30, 2010 at 7:09 PM, Alexandre Morgaut 
alexandre.morg...@4d.commailto:alexandre.morg...@4d.com wrote:


Storage::setExpiration(in DOMString key, in TTL or expiration Date)

(or Storage::setTTL() if you guys don't agree on the Date option)

This might make sense, but I'm also not sure it's worth the additional API 
surface area.  Plus I kind of like the idea of making it difficult for people 
to detect whether the browser even supports expiration since we don't people to 
ever assume they can count on it.  (Since once again, what if the user doesn't 
turn on their computer or the UA doesn't delete expired data unless it's 
running?)

Well, as Nicholas said, the important thing is that the User-Agent makes its 
best to remove the items ASAP once they expired.

Sure some of these items could remain on disk while they expired until the UA 
start again.
This is absolutely not a strong security feature.
The user still should be able to remove manually the storages content, or 
disable access to the storage objects,  from the User-Agent menus/preferences.

I'm not confortable into hiding User-Agent capabilities from the API.
Smart people like John Resig recommend to check the available API instead of 
looking after the User-Agent name and version to detect them, and I kind of 
like this approach.

My point was that a programmer really shouldn't do anything differently whether 
or not the API is available.  But you're probably right that it'd only push 
such an author towards user-agent sniffing which is of course worse.

I just had another thought.  Although I strongly feel that the spec shouldn't 
guarantee when the data is deleted (and should probably have some non-normative 
text explaining why) we could (if we wanted to) guarantee that data won't be 
available to the page after that time.  (Of course subject to run to completion 
constraints--if the user calls localStorage.length, we can't delete the item 
until they leave the scripting context.  Also there's a question of whether 
we'd fire StorageEvents while something's timed out.  Maybe we should just 
expire stuff when navigating to a page and not while the page is running?)

J

[whatwg] Proposal for Web Storage expiration

[Nicholas Zakas]

Background:

The Web Storage specification provides two ways for web applications to store 
key-value data in the browser, effectively replacing cookies for cases when the 
server doesn't need the information. For a lot of web application needs, 
sessionStorage and localStorage (or some combination of the two) can be used to 
effectively reduce the number of cookies used. Cookies do have one advantage 
over these APIs: the ability to specify an expiration period after which the 
data is removed.

Right now, if a web application developers wish to have expiration of key-value 
pairs, he/she must manually implement such expiration on their own. An example 
of an API that already does this is XAuth (xauth.org).

Proposal:

Adding the ability to optionally define an expiration date for each key-value 
pair would bring sessionStorage/localStorage closer the capabilities of cookies 
today and provide useful control over the length of time that certain data can 
live in the browser. This becomes especially important if any 
authentication-related data is to be stored in Web Storage.

Proposed Interface Change:

The easiest way to include such a change would be to augment the 
Storage::setItem() method with a third optional argument. So change from:

setter creator void setItem(in DOMString key, in any data);

To:

setter creator void setItem(in DOMString key, in any data, [Optional] in 
unsigned long ttl);

The third argument is a TTL specifying how long, in milliseconds, the data 
should be stored in sessionStorage/localStorage. Some proposed implementation 
details:
* A TTL of 0 is considered invalid and ignored, as is any value less than 0. If 
you want to immediately remove a key, it should be done via removeItem().
* The TTL for a key may be changed each time setItem() is called, with the new 
TTL overwriting the old one.
* If a TTL was previously set, and then a new TTL is not provided on a 
subsequent call to setItem(), then the original TTL remains.
* If a TTL was previously set, and another call is made to setItem() that 
contains an invalid TTL (= 0), then the original TTL remains.
* To remove a previously set TTL, you must call removeItem() to completely 
remove the key and then re-add using setItem().
* Adding a third argument means the length property of setItem will be 3, so 
developers can check for support of this feature using 
(localStorage.setItem.length  2).
* The TTL is valid for both sessionStorage and localStorage, but more important 
for localStorage.

Thoughts?

-Nicholas

__
Commander Lock: Dammit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

[whatwg] Clarification request for charset/characterSet/defaultCharset

[Nicholas Zakas]

Hi all,

 

I was just reading through the spec and am having trouble understanding
the details of document.charset, document.characterSet, and
document.defaultCharset. It seems to me that document.characterSet is
simply a read-only equivalent of document.charset (I'm guessing these
are both here due to already-existing implementations), which is a
little confusing but not terribly so. I'm more interested in
document.defaultCharset and how it relates to the others. Some
questions:

 

1) Should document.charset/document.characterSet always start out
equivalent to document.defaultCharset?

2) What is the canonical source of truth for document.defaultCharset (is
this a system setting, a browser setting, or a document setting)?

3) If document.charset is set to a new value, is there any change
reflected in document.defaultCharset? What about vice-versa?

 

Thanks.

 

-Nicholas

 

__

Commander Lock: Dammit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.

 

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

I believe what I'm proposing is an incremental change to the
already-existing data storage API and not and doesn't drastically
increase the API surface area. Where the encryption key comes from I
think is an interesting question, which is why I didn't address that. I
think there will be (can be) a variety of places from where a key can
originate. I don't think it's necessarily important that a key
originated from a server be passed securely to the client. A lot of web
applications pass tokens back to the client for security purposes right
now. As long as there is a relationship between the signed-in user and
the key, you're generally covered.   

 

In any event, I think everyone has agreed that a JS crypto API would be
a good thing, yet no one has stepped forth with a proposal to move the
discussion forward. So here:

 

[Supplemental, NoInterfaceObject]
interface WindowCrypto {
const unsigned short AES_128 = 1;
const unsigned short AES_192 = 2;
const unsigned short AES_256 = 3;
 
DOMString encrypt(in DOMString valueToEncrypt, in unsigned short
cipher, in DOMString key);
DOMString decrypt(in DOMString valueToDecrypt, in unsigned short
cipher, in DOMString key);
}
Windows implements WindowCrypto

 

Thoughts?

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.



From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow
Sent: Thursday, April 08, 2010 7:49 AM
To: Paul Kinlan
Cc: whatwg@lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Jonas Sicking;
Eric Uhrhane
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

This is getting fairly tiresome.  If you're interested in continuing
this thread, please actually read the replies thus far and directly
respond to the points rather than re-stating what's already been
rebutted.

 

 

On Thu, Apr 8, 2010 at 3:17 PM, Paul Kinlan paulkin...@google.com
wrote:

Hi,

 

I have a specific use-case where encryption is required, and currently
the only solution is to find a JS library that can encrypt the data on
the way in or way out of storage.

 

The main cases I have:

1.  Storage needs to be encrypted on disk, device etc.
2.  Data needs to be in decrypted form for the shortest amount of
time possible while in use in an application.

These are not use cases.  Can you please describe some specific examples
applications and their requirements for encrypted data?  To be honest,
I'm pretty certain you're not going to come up with any that aren't
solved by what you can do today with JS, made better with a JS crypto
API, and made easier on the developer by integrating crypto into the
storage APIs.  (Though as I explain below, the last part is pretty much
a non-goal.)

 

My gut, general feeling is that encryption of information to and
from storage is moot, because introspection of a running app is so
unbelievably easy.  However, on disk storage *must* be encrypted and
sandboxed.  i.e, data needs to be only available to the domain running
the code, and it cannot be peaked at by examining the disk.

 

I have only followed this thread a little while, and as dev who
uses JS a lot, explicitly having to encrypt data is bad and a pain and
open to mistakes.

 

Then someone should make a library to do this.  Expanding the surface
areas of APIs should not be taken lightly.  As I've explained, we only
expand API surface areas when something is impossible to accomplish or
when there are performance reasons.  And then we still try to keep
things minimal.  Dirk explained well why a generic JS crypto library
would solve more use cases than adding crypto to a particular storage
API.  I really don't know why we're still discussing this.

 

I don't want to be handling encryption of my data, I don't do
anything special to communicate over https, and I look at storage the
same way.

 

What's been proposed so far will NOT work as seamlessly as HTTPS.

 

If you want it to happen magically, then the UA should encrypt all data
transparently to the user or web developer.  I actually think this is
ideal, but the problem is that it's not clear where the key should come
from.  After all, if you store it on disk, then you're still at the
mercy of the file system/OS keeping you secure.  If you store it
remotely (as has been mentioned in this thread) then we need to come up
with an API to pass that key in or we need to somehow add the key to
HTTPS connections.

 

Maybe what we should really be doing is looking at adding a HTML
attribute, HTTP header, or something like that that gives the browser a
private key to be used to encrypt _everything_ associated with the web
page.  Including history, any storage APIs, etc.  I suppose the file API
would need some way to opt-out (per what Jonas pointed out

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

I tried to articulate some of my thoughts as to why a generate purpose
crypto isn't enough to be useful and why trying to tack onto local
storage could get messy:

http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side
-data-storage/

 

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.



From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow
Sent: Thursday, April 08, 2010 3:14 AM
To: Jonas Sicking
Cc: whatwg@lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Eric Uhrhane
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking jo...@sicking.cc wrote:

On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow jor...@chromium.org
wrote:
 I don't think this is enough of a
 problem to kill the feature though.

 I think this is a good feature to try and integrate into existing APIs
if
 it's possible to do so cleanly.  I don't think it's worth creating yet
 another persistent storage API over, though.

...

 For
 localStorage, we could add a origin-wide setting or add an optional
param to
 setItem.

Well, it seems harsh to require that *all* data on a domain is either
security sensitive, and thus need expiration, or not security
sensitive and thus need none. I think it makes a lot of sense to be
able to let the page have several storage areas, some which expire and
some which don't.

Think mail.google.com where storing my emails would count as sensitive
and should have expiration, but storing my drafts might be worth doing
longer to prevent dataloss.

 

Local storage is not a good API for more complex applications like
gmail.  That's why I suggested integrating into IndexedDB and
WebSQLDatabase (which is what I meant when I said databases).  Note
that I also suggested that it could be an optional parameter to setItem
which would make it a per-item setting and still be backwards compatible
with LocalStorage.  (Like I said, creating another LocalStorage-like API
just for this feature is really not an option.)

 

I just thought of an alternative approach to this whole
situation
though. We could add crypto and expiration functionality to
IndexDB. I
know the crypto stuff has come up before and there was some
hesitation
though. (Though I guess the same thing could be said for
crypto+localStorage)

 

Nikunj has already said no more major features for v1 of IndexedDB.  I
think we might be able to sneak in an expiration parameter, but
encryption 1) is not practical for v1 and  2) we're really jumping the
gun on this encryption thing.  One person proposed it.  We haven't seen
any evidence this is a widely sought after feature.  If _anything_ the
right way to go is to make encryption fast and allow developers and
authors of libraries to layer the two.  If there's compelling demand,
THEN we should talk about adding it to individual APIs.

 

 It seems as though expiration policies could be added to the
creation of
 databases and the new FileWriter/FileSystem APIs pretty
easily.

I don't understand the usecase of expiring files. Isn't the
whole
point of saving to the file system so that the user gets better
access
to it and so that things like iPhoto can index any stored
images?


 But stillwe need some use cases.  :-)

I'm all for use cases. Though Nicholas did say that he'd want
encryption and expiration on essentially all privacy sensitive
information stored. Which I think I can understand.

 

As stated, a more general purpose crypto API should be enough to satisfy
this use case and others (like someone wanting to encrypt it client side
before sending it to the server).  That is the direction these
discussions should be headed, not taking one particular persistent
storage API and finding a way to tack encryption onto it.

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

I've actually already seen a very common repeated pattern as it comes to 
client-side data storage:

 

1. Hey let's try using localStorage to improve our user experience.

2. Sounds great, but the data can't be stored in plain text if its user data.

3. That's okay, we'll just use the XYZ JavaScript encryption library.

4. And then use it on every read and every write?

5. Ugh, you're right, nevermind.

 

I've had, or participated in, this conversation multiple times. I also know, 
from speaking with others about this proposal, that this conversation isn't 
uncommon.

 

Again I'll say I'm all for adding crypto into JavaScript. I think in addition 
to that, there should be affordances for what will likely be common usage 
patterns. To me, any and all mechanisms for client-side storage should have 
some basic crypto built-in, so why not start here?

 

In regards to data expiration, part of ensuring the security of data is knowing 
how long it will be stored on disk. If I let someone borrow my computer to 
check their email, and the email client happens to save some data onto the 
client, then that person's data will now be on my disk for who knows how long. 
That represents a data security issue. By allowing an expiration date to be 
tied to the data, you can have reasonable assurance that the data isn't just 
going to be sitting around waiting for someone to try and use it. 

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you believe!

Morpheus: My beliefs do not require them to.



From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Jeremy Orlow
Sent: Tuesday, April 06, 2010 6:55 AM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Dirk Pranke
Subject: Re: [whatwg] Proposal for secure key-value data stores

 

Sorry for misunderstanding your original suggestion.

On Wed, Mar 31, 2010 at 1:13 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:

I certainly can't argue against a focus on JS crypto. :) What I'd like to do is 
eliminate what I believe will be a repeated pattern for developers in the 
future. It would be really nice if, in addition to having access to crypto 
functions, there was an area where I could stick data that would get encrypted 
automatically (and of course, where I could be sure the data would be 
eliminated after a set amount of time).

 

It seems to me that Dirk is right that crypto in the browser is a more general 
problem and that a general crypto API would be much more valuable than creating 
new APIs with similar/duplicate functionality + crypto.  Optimizing for 
repeated patterns probably should wait until we see what patterns are 
actually common.  :-)

 

My proposal is less about encryption and more about providing better 
control over how data is stored and for how long.

 

Can you provide some concrete use cases for expiration of content?  They'd 
probably have to be pretty dramatic to warrant creating yet another storage 
mechanism.

 

Maybe this can somehow be integrated into IndexedDB?  There's very little 
chance of it being a v1 feature, but maybe we could make sure it's possible to 
add in future versions.

 


-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 Dirk Pranke
Sent: Tuesday, March 30, 2010 3:09 PM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for secure key-value data stores

On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas nza...@yahoo-inc.com 
wrote:
 Yes, that's precisely what I'm talking about. It seems to me that 
this will end up being a pretty common pattern (encrypting/decrypting data 
stored locally).

 The idea behind letting the key to be defined by the developer is to 
allow any usage that developers deem appropriate for the situation. For 
example, one might want to only use a server-generated key to access the data, 
in which case this data won't be available offline but will be used to 
supplement the online behavior. Another might determine the key based on some 
information in a cookie, which is less secure but does allow offline access 
while also ensuring that if the cookie changes or is deleted, the data remains 
secure.

 The idea behind the expiration date is to allow developers to be sure 
the data won't stay around on disk indefinitely. Think about the Internet café 
use case where people are repeatedly logging in and out - we don't want 
everyone's data living on that computer for however many years it's in use.

 One

[whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

Hi everyone,

 

In attempting to use localStorage at work, we ran into some major
security issues. Primary among those are the guidelines we have in place
regarding personalized user data. The short story is that personalized
data cannot be stored on disk unless it's encrypted using a
company-validated encryption mechanism and key. So if we actually wanted
to use localStorage, we'd be forced to encrypt each value as it was
being written and then decrypt each value being read. Because of this
tediousness, we opted not to use it. 

 

Another major issue also relates to the persistence of the data in
localStorage. Whereas cookies allow you to specify a time at which the
data will be removed, localStorage is there more or less forever.

 

It seems like any company that takes the security of its data seriously
would run into the same issues, and rather than forcing every company to
implement their own version of the same approach, a common native
approach would be incredibly useful.

 

With these problems in mind, and talking with a few other interested
parties, I came up with a draft proposal for a client-side data storage
mechanism that automatically handles encryption, decryption, and data
expiration. I'd love to hear what people think:

 

http://www.nczonline.net/blog/securestore-proposal/

 

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.

 

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

Yes, that's precisely what I'm talking about. It seems to me that this will end 
up being a pretty common pattern (encrypting/decrypting data stored locally).

The idea behind letting the key to be defined by the developer is to allow any 
usage that developers deem appropriate for the situation. For example, one 
might want to only use a server-generated key to access the data, in which case 
this data won't be available offline but will be used to supplement the online 
behavior. Another might determine the key based on some information in a 
cookie, which is less secure but does allow offline access while also ensuring 
that if the cookie changes or is deleted, the data remains secure.

The idea behind the expiration date is to allow developers to be sure the data 
won't stay around on disk indefinitely. Think about the Internet café use case 
where people are repeatedly logging in and out - we don't want everyone's data 
living on that computer for however many years it's in use.

One way or another, I think JavaScript crypto is going to be important in the 
next few years. 


-Nicholas
 
__
Commander Lock: Damnit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

-Original Message-
From: dpra...@google.com [mailto:dpra...@google.com] On Behalf Of Dirk Pranke
Sent: Tuesday, March 30, 2010 1:24 PM
To: Jeremy Orlow
Cc: Nicholas Zakas; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for secure key-value data stores

Nicholas is almost certainly discussing the case where the service
provider requires any data stored on a customer's computer to be
encrypted, not the provider's own computers. (e.g., this could be a
Yahoo! policy that data stored on Yahoo! users' computers must be
encrypted).

Hence they cannot enforce anything like use FileVault.

If the data is being encrypted and decrypted with a key provided by
the service (and not stored persistently), then the fact that the data
is accessible offline is moot. Although if the key can be retrieved
using the cookies that were available in the clear on the computer,
this is a weaker (but not completely shot down) point.

Perhaps an easy example of this would be to use LocalStorage for
password sync and password management for a web app (like LastPass).
We can implement the required crypto in JavaScript, but should we have
to?

-- Dirk

On Tue, Mar 30, 2010 at 12:19 PM, Jeremy Orlow jor...@chromium.org wrote:
 Most companies that have such policies enforce them with software that
 encrypts your home directory (or entire hard drive).  Since most (all?)
 browsers store such data within a users home directory, that should be
 sufficient for the specific case you're mentioning.  (Well, except
 for expiration.)  Note that home directory encryption is easy and free on
 some Linux distros and Mac OS.  (I don't know either way about Windows.)
 To be honest, if someone can get at _any_ of your browser data (LocalStorage
 included) you have a pretty major problem.  So tacking something onto other
 storage APIs doesn't really make that much sense.  If someone can get at
 even just your cookies, they can probably do a lot of damage.
 What are the use cases around expiration of data?
 Lastly, we really should not be creating new APIs that are synchronous that
 involve multiple top level windows (like LocalStorage and this API you're
 proposing).  It makes it very difficult to achieve isolation and parallelism
 between multiple sites.
 J
 On Tue, Mar 30, 2010 at 7:55 PM, Nicholas Zakas nza...@yahoo-inc.com
 wrote:

 Hi everyone,



 In attempting to use localStorage at work, we ran into some major security
 issues. Primary among those are the guidelines we have in place regarding
 personalized user data. The short story is that personalized data cannot be
 stored on disk unless it's encrypted using a company-validated encryption
 mechanism and key. So if we actually wanted to use localStorage, we'd be
 forced to encrypt each value as it was being written and then decrypt each
 value being read. Because of this tediousness, we opted not to use it.



 Another major issue also relates to the persistence of the data in
 localStorage. Whereas cookies allow you to specify a time at which the data
 will be removed, localStorage is there more or less forever.



 It seems like any company that takes the security of its data seriously
 would run into the same issues, and rather than forcing every company to
 implement their own version of the same approach, a common native approach
 would be incredibly useful.



 With these problems in mind, and talking with a few other interested
 parties, I came up with a draft proposal for a client-side data storage
 mechanism that automatically handles encryption, decryption, and data
 expiration. I'd love to hear what people think:



 http://www.nczonline.net/blog/securestore-proposal/





 -Nicholas

Re: [whatwg] Proposal for secure key-value data stores

[Nicholas Zakas]

I certainly can't argue against a focus on JS crypto. :) What I'd like to do is 
eliminate what I believe will be a repeated pattern for developers in the 
future. It would be really nice if, in addition to having access to crypto 
functions, there was an area where I could stick data that would get encrypted 
automatically (and of course, where I could be sure the data would be 
eliminated after a set amount of time).

My proposal is less about encryption and more about providing better control 
over how data is stored and for how long.

-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 Dirk Pranke
Sent: Tuesday, March 30, 2010 3:09 PM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Jeremy Orlow
Subject: Re: [whatwg] Proposal for secure key-value data stores

On Tue, Mar 30, 2010 at 2:06 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 Yes, that's precisely what I'm talking about. It seems to me that this will 
 end up being a pretty common pattern (encrypting/decrypting data stored 
 locally).

 The idea behind letting the key to be defined by the developer is to allow 
 any usage that developers deem appropriate for the situation. For example, 
 one might want to only use a server-generated key to access the data, in 
 which case this data won't be available offline but will be used to 
 supplement the online behavior. Another might determine the key based on some 
 information in a cookie, which is less secure but does allow offline access 
 while also ensuring that if the cookie changes or is deleted, the data 
 remains secure.

 The idea behind the expiration date is to allow developers to be sure the 
 data won't stay around on disk indefinitely. Think about the Internet café 
 use case where people are repeatedly logging in and out - we don't want 
 everyone's data living on that computer for however many years it's in use.

 One way or another, I think JavaScript crypto is going to be important in the 
 next few years.

Perhaps we should instead focus on a set of JS Crypto APIs, since that
is largely orthogonal to the storage APIs?

-- Dirk

Re: [whatwg] HTML Cookie API

[Nicholas Zakas]

I like the idea of creating an easier way to deal with cookies (which is why I 
wrote the YUI Cookie utility way back when). The thing that seems to be missing 
in your proposed API is what I consider to be the most common use case: 
retrieving the value of a single cookie. There's not many times when I need to 
get every single cookie that's available on the page, but there are plenty of 
times when I want to check the value of a single cookie. Using your API, 
getting the value of a single cookie with a known name becomes:

document.getCookies(function(cookies) {
  for (var i=0; i  cookies.length; ++i){
  if(cookies[i].name == my_cookie_name){
  doSomething(cookies[i]);
  }
  }
});

That seems like a lot of work just to retrieve a single cookie value. 

I'm also less-than-thrilled with this being asynchronous, as I think the use 
cases for cookies are vastly differently than those for databases and web 
storage. The world is already parsing cookies synchronously right now, it 
doesn't seem like asynchronicity buys much benefit, it just introduces an 
additional level of indirection.

-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 Adam Barth
Sent: Wednesday, February 24, 2010 8:47 AM
To: Darin Fisher
Cc: whatwg
Subject: Re: [whatwg] HTML Cookie API

Done.

On Wed, Feb 24, 2010 at 12:29 AM, Darin Fisher da...@chromium.org wrote:
 An explicit deleteCookie method might also be nice.
 -Darin

 On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth w...@adambarth.com wrote:

 The document.cookie API is kind of terrible.  Web developers shouldn't
 have to parse a cookie-string or prepare a properly formated
 set-cookie-string.  Here's a proposal for an HTML cookie API that
 isn't as terrible:


 https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMghl=en

 I'd like to propose we include this API in a future version of HTML.
 As always, feedback welcome.

 Adam

Re: [whatwg] HTML Cookie API

[Nicholas Zakas]

I think there's always going to be a disconnect between browser
developers and web developers, since we're both living in very different
worlds.

 

Like I said, I'm all for making cookie access more rational (as if one
could argue that it has been at all rational to this point). Right now,
though, I can't see a benefit to switching from any of the current
synchronous approaches to an asynchronous one, as it doesn't give me
enough added benefit. The asynchronous approach may be the most
performant and potentially the easiest to implement, but if it's out
there and everyone is still using document.cookie, is there really a net
gain?

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.



From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
Orlow
Sent: Wednesday, February 24, 2010 12:20 PM
To: David Flanagan
Cc: Peter Kasting; whatwg; Nicholas Zakas; Darin Fisher; Adam Barth
Subject: Re: [whatwg] HTML Cookie API

 

On Wed, Feb 24, 2010 at 9:07 PM, David Flanagan
da...@davidflanagan.com wrote:

Jeremy Orlow wrote:


Also note that the spec currently has the notion of a storage
mutex which should be taken whenever a script tries to access a cookie
(or local storage) and is held until the script finishes.  The network
stack is also supposed to take this lock whenever getting or setting a
cookie.  No one has implemented the storage mutex or stated any
intention of doing so because this is basically impossible today.  But,
if there were an asynchronous API that most people were using, it
actually could be possible that we'd want to implement such a mutex
since cookies would then obey run to completion semantics without having
serious lock contention.

 

Well if no one is going to implement the storage mutex, then I
probably need to retract my last message

 

But yeah.  Definitely any API that touches information
spanning tabs (and probably even APIs spanning origins within those
tabs) really should be designed in an async manor from now on.
Otherwise we're just digging the whole deeper in terms of forcing
ourselves into a single threaded world.

J

 

I worry that this comes down to web developers who want simple
APIs vs browser implementors who say we can't have them (at least not if
we also want speed.)

Concurrency issues are not my strong suit, but shouldn't it be
possible to have safe, synchronous read-only access to cookies (caching
volatile values like cookies within each thread and then clearing that
cache when the thread returns to the event loop).  Can't the requirement
for a mutex or an asynchronous API be limited to setCookie()?

 

From a technical standpoint, this is very doable.  And, done right, I
think I could be in favor of it.

 

But I believe the counter argument is that any relaxation of run to
completion semantics is going to confuse developers and probably result
in them writing racy code without realizing it.  Many developers won't
understand when it's safe to use the cached value vs needing to use the
asynchronous interface.  And if the less safe one is easier to use

 

I agree that asynchronous interfaces have disadvantages, but as far as I
can tell many of them are costs that you pay once (learning them and
getting use to them) or once per app (if you handle one asynchronous
call or need to use setTimeout, then probably using another won't
require too much restructuring of your code).  Maybe I'm just a browser
developer who's completely out of touch with reality though.  :-)

Re: [whatwg] HTML Cookie API

[Nicholas Zakas]

Even though there can be multiple cookies with the same name on a single 
document, this most frequently occurs due to error rather than intention. I've 
never received a YUI bug report about this occurrence though I have considered 
returning an array of values instead of just the first value in this case. I 
might just go do that now. :)

My initial comment still remains: retrieving the value of a single named cookie 
seems to be a much more common use case than retrieving all cookies. You can 
choose to solve the duplicate cookie name issue in a number of ways, but not 
providing a way to access a cookie by name seems like a flaw in this design.

Of course, if the main use case you're concerned about is retrieving all 
cookies, then feel free to disregard this feedback.

-Nicholas
 
__
Commander Lock: Damnit Morpheus, not everyone believes what you believe!
Morpheus: My beliefs do not require them to.

-Original Message-
From: Adam Barth [mailto:w...@adambarth.com] 
Sent: Wednesday, February 24, 2010 1:07 PM
To: Nicholas Zakas
Cc: Darin Fisher; whatwg
Subject: Re: [whatwg] HTML Cookie API

On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
 I like the idea of creating an easier way to deal with cookies (which is why 
 I wrote the YUI Cookie utility way back when). The thing that seems to be 
 missing in your proposed API is what I consider to be the most common use 
 case: retrieving the value of a single cookie. There's not many times when I 
 need to get every single cookie that's available on the page, but there are 
 plenty of times when I want to check the value of a single cookie. Using your 
 API, getting the value of a single cookie with a known name becomes:

    document.getCookies(function(cookies) {
      for (var i=0; i  cookies.length; ++i){
          if(cookies[i].name == my_cookie_name){
              doSomething(cookies[i]);
          }
      }
    });

 That seems like a lot of work just to retrieve a single cookie value.

The problem is there can be multiple cookies with the same name for a
given document.  The YUI Cookie utility seems to assume there's only
one.  We could add a facility for filtering the results of getCookies,
but that's easy enough to do correctly in JavaScript.

Adam

Re: [whatwg] should async scripts block the document's load event?

[Nicholas Zakas]

To me asynchronous fundamentally means doesn't block other things
from happening, so if async currently does block the load event from
firing then that seems very wrong to me.

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.



From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Brian Kuhn
Sent: Friday, February 12, 2010 8:03 AM
To: Jonas Sicking
Cc: Steve Souders; WHAT Working Group
Subject: Re: [whatwg] should async scripts block the document's load
event?

 

Right.  Async scripts aren't really asynchronous if they block all the
user-visible functionality that sites currently tie to window.onload.

 

I don't know if we need another attribute, or if we just need to change
the behavior for all async scripts.  But I think the best time to fix
this is now; before too many UAs implement async.

 

-Brian

 

 

 

 

On Thu, Feb 11, 2010 at 10:41 PM, Jonas Sicking jo...@sicking.cc
wrote:

Though what we want here is a DONTDELAYLOAD attribute. I.e. we want
load to start asap, but we don't want the load to hold up the load
event if all other resources finish loading before this one.

/ Jonas


On Thu, Feb 11, 2010 at 10:23 PM, Steve Souders wha...@souders.org
wrote:
 I just sent email last week proposing a POSTONLOAD attribute for
scripts.

 -Steve

 On 2/10/2010 5:18 PM, Jonas Sicking wrote:

 On Fri, Nov 6, 2009 at 4:22 PM, Brian Kuhnbnk...@gmail.com  wrote:


 No one has any thoughts on this?
 It seems to me that the purpose of async scripts is to get out of
the way
 of
 user-visible functionality.  Many sites currently attach
user-visible
 functionality to window.onload, so it would be great if async
scripts at
 least had a way to not block that event.  It would help minimize the
 affect
 that secondary-functionality like ads and web analytics have on the
user
 experience.
 -Brian


 I'm concerned that this is too big of a departure from how people are
 used toscripts behaving.

 If we do want to do something like this, one possibility would be to
 create a generic attribute that can go on things likeimg,link
 rel=stylesheet,script  etc that make the resource not block the
 'load' event.

 / Jonas



 

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[Nicholas Zakas]

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

[whatwg] Inconsistent behavior for empty-string URLs

[Nicholas Zakas]

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.

 

-Nicholas

 

__

Commander Lock: Damnit Morpheus, not everyone believes what you
believe!

Morpheus: My beliefs do not require them to.

 

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Nicholas Zakas]

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.