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: , ,
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
Sub
heus: "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] I
: "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.wh
al 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 se
lto: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
wrote:
> Just curious if anyone knows why
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-st
ded.
-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: Nicho
t you
believe!"
Morpheus: "My beliefs do not require them to."
-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas
Sent: Friday, December 11, 2009 10:15 AM
To: Simon Pieters; Anne van Kesteren; Ary
;
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
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: , ,
g.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
wrote:
> Here's what I would
..@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 wrote:
> On Wed, 16 Dec 200
Simon,
Here's a list for the first four I mentioned:
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
IE 8 and earlier: d
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, 1
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 tags don't
show it in the table, the
Apologies, the formatting didn't come out how I had hoped. :)
Here's another attempt:
IE7 IE8 FF3 FF3.5
1 1 1 0
0 0 1 1
0 0 2
ot;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;
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 , ,
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
;
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 2
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 believ
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 w
_
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,
s, 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
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-vali
mmander 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
uesday, 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 wrote:
> Yes, that's precisely what I'm talking about. It seems to me that this w
r 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.whatw
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
incurrin
remy 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 wrote:
On Wed, Apr 7, 2010 at 5:44 PM, Jeremy
___
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] Pro
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 d
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
ow
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 wrote:
It might be worth integrating this into IndexedDB as it seems like
people are more r
___
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 exp
t;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
king
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 wrote:
> If a site could create multiple Storage ar
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 wrote:
> Y
al 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 Or
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
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
;
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
Kesteren [mailto:ann...@opera.com]
Sent: Tuesday, October 19, 2010 12:54 AM
To: wha...@whatwg.org; Nicholas Zakas
Subject: Re: [whatwg] Question regarding event: in server-sent events
On Mon, 18 Oct 2010 19:38:46 +0200, Nicholas Zakas
wrote:
> Just for my own understanding, what you're sayi
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 brin
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, encode
In section 4.4.5 (the aside element), an example is given that shows
being used within .
Section 4.4.3 (the nav element), explains that this would be an inappropriate
use of (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 el
nks.
-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,
Problem Statement:
Loading JavaScript onto a page poses several performance issues. With a regular
yle 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.
t 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
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 usef
namic 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 Sickin
]
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:
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 t
>> 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
I had thought a bit about a new rel for s, 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 to execute a script
when
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
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 pro
oposal 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
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=en&authkey=CJ6z2ZgO
Summary of changes:
* Changed "noexecute" to "preload"
* No HT
_
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, 20
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
ld 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;
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
After chatting a bit with Boris, it seems important for implementation that a
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
HTML5 currently requires the scoped attribute for 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