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
!
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
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
: 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
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
: 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
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
__
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
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
__
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
, 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
: 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
...@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
-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
, 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
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
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
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
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
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
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
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
...@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
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
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
, 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
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
, 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
, 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
...@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
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
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
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
...@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
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
, 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
[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
: 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
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 event
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
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
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
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
.
-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
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
, 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
!
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
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
. 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
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
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
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
] 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
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
...@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
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
...@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
: 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
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
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
-
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
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 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,
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
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
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
: 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
-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
...@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
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)
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
73 matches
Mail list logo
