From jimjjewett at gmail.com  Fri Jan  1 19:22:30 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 1 Jan 2010 22:22:30 -0500
Subject: [whatwg] the cite element
Message-ID: <fb6fbf561001011922y313badb1kf687b0c5d6af686f@mail.gmail.com>

Back around Oct 15, Ian summarized his objections to letting <cite>
refer to the primary source of the information, rather than being an
oddly named synoymy for <i class=title>.


> On Thu, 8 Oct 2009, Jim Jewett wrote:

>> > I hate to be so repetitive, but why is that beneficial? What is the
>> > semantic value of this?

>> You are welcome to say that argument by authority is so weak as to be
>> invalid, but it still happens.

>> Similarly, you are welcome to say that the academic habit of crediting
>> other authors (sometimes but not always for specific publications) is
>> silly, but it still happens.

> What I'm saying is that <cite> doesn't help with either of the above. It's
> quite possible to cite people in text/plain, without any markup. What does
> <cite> _add_ that solves a real problem?

...
>> <cite> -- particularly when restyled to not be visually apparent -- may
>> be one of the few aspects of HTML which is more important to other
>> classes of products.

> Like what? Are there examples I could look at? That would be very helpful
> in terms of finding purposes for <cite> other than just italics.

I was thinking of business-rule-validators that ensure claims are
"justified", or academic-influence measures that track citation
graphs.

That said, I suspect any tool that can assume cooperative authors will
be custom, and could therefore be written to look for <span
class="citetool-pay-attention">.  So this use case may be about cruft
rather than needs.

>> > Is there as much semantic value in pointing to the primary source of a
>> > statement as there is in knowing that the word "earth" refers to the
>> > planet and not the dirt, for example? If so, what is that extra value?

When quotes are attributed to Winston Churchill (or Oscar Wilde), that
attribution is important -- generally more important than which
specific speech it came from.

>> >> dialogues and transcripts and credits and theatrical scripts are all
>> >> arguably too fine-grained for a "citation", as opposed to a "label"
>> >> or "attribution", but they are certainly real use cases where the
>> >> attribution is important.

>> > Why? This is not a rhetorical question, I'm trying to get to the use
>> > case that means that there is an actual benefit to what you are asking
>> > for.

>> They are all cases where "who said it" or "who did it" is important --
>> sometimes far more important than what they actually said or did.

> Sure, but <cite> doesn't help determine that. English helps determine
> that. (Or whatever natural language is used.) What is <cite> doing?

    Evil Lawyer:  So, when did you stop beating your wife?
    Defendant:  Never!

"Evil Lawyer" and "Defendant" aren't pronounced.  Their meanings (and
silence) are deduced from English conventions about punctuation.  I
would prefer a semantic tag.  (I'll freely agree that <cite> isn't the
perfect name, but it seems bizarre to forbid this related meaning,
while allowing generic Title Of Work.)

> <li> and <q> are both useful because of their default styling, as is
> <cite>, when used for something that works with its default styling. But
> that doesn't apply to people's names -- they are almost never made
> italics.

I actually have read scripts that used italics to indicate the
speaker's name.  I didn't find them the most readable of scripts, but
I have seen them.

>> >> I'll agree that it seems odd to have that many <cite> elements in
>> >> such close proximity, but it is the closest match I can find in the
>> >> spec, and it doesn't seem to be actually wrong. ?Searching for lines
>> >> by a particular character is a fairly common use case.

>> > Doesn't "find in page" handle that fine?

>> Not in my opinion.

> What are you expecting Web browsers to do that would make <cite> a better
> solution? Has a browser vendor expressed an interest in some UI feature
> for searching by citation name or some such?

Initially, nothing except Javascript or CSS hacks.

I'm expecting those to do something like increase the font size or
change the background for lines *I* have to memorize for *my*
character, or for cue lines that I have to recognize.


>> Because we don't have an <attrib> or even a <credit> element, and so
>> <cite> is the closest match.

> You're still not saying why you want this element. What would <attrib> be
> good for? What UI would it trigger? How would users or authors benefit?


I wouldn't expect the main use to be in normal browsing.

I would expect it to be used in License checkers that some
organizations would deploy to ensure they aren't violating copyright.
I would expect it to be used by some scrapers looking for stock
photos.  I would expect it to be used with custom CSS for some users,
who are really looking for a model or photographer rather than an
existing photograph.

>> Defining it as a synonym for <i class="title"> seems wrong in both
>> directions -- both promoting something that shouldn't be an element,
>> *and* preventing sensible use of an appropriately named element.

> Why would it be wrong to have an element to style titles?

Turning around your favorite question, what is the semantic value?

I can recommend Orson Scott Card's novel Enchantment.
I can recommend Orson Scott Card's novel "Enchantment".
I can recommend Orson Scott Card's novel <i class=title>Enchantment</i>.
I can recommend Orson Scott Card's novel <cite>Enchantment</cite>.

Is the extra value of the 4th spelling really that great?

And if the semantics are being changed anyhow, why not just move the
entire element from the "valid markup" section to the "user agents
must process" section?

-jJ

From timeless at gmail.com  Sat Jan  2 22:58:58 2010
From: timeless at gmail.com (timeless)
Date: Sun, 3 Jan 2010 06:58:58 +0000
Subject: [whatwg] window.print() when printing is not supported
In-Reply-To: <4B389C58.7020804@helsinki.fi>
References: <4B389C58.7020804@helsinki.fi>
Message-ID: <26b395e61001022258o50dfb67ay9bcee1eb88a14f45@mail.gmail.com>

On Mon, Dec 28, 2009 at 11:54 AM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:
> Hi all,
>
> currently
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#printing
> says that window.print() should prompt user to print the page, but that "For
> instance, a kiosk browser could silently ignore any invocations of the
> print() method."

I don't think silently ignoring is the right behavior.

the right behavior is offering the user a script frozen interface to
that window with a way to 'resume'.

Printing is basically "pause the great scary web". That it happens to
kill a tree in the process is not interesting.

As a user of a kiosk with a digital camera, being able to press a
print button, use my digital camera to take a picture, scroll the page
some more, take another picture, and keep doing this until i'm done
"printing" is the correct behavior.

When I'm done, i should click "done" (= close print preview).

Kiosk implementations should be encouraged to implement this.

If they don't want to implement this, they can do whatever they like,
but anything else is a disservice to the unfortunate kiosk user of a
page which does:

y=window.open(x)
 y.print();
 y.close();

From darin at chromium.org  Mon Jan  4 10:54:48 2010
From: darin at chromium.org (Darin Fisher)
Date: Mon, 4 Jan 2010 10:54:48 -0800
Subject: [whatwg] Question about pushState
In-Reply-To: <bd8f24d20912161151u5d88d52m3a6da56c49ddbc91@mail.gmail.com>
References: <bd8f24d20912161151u5d88d52m3a6da56c49ddbc91@mail.gmail.com>
Message-ID: <bd8f24d21001041054o5a7e5ec1kb27324488abc1101@mail.gmail.com>

As follow-up, I've filed these bugs:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8629
https://bugs.webkit.org/show_bug.cgi?id=33160

(Privately, Maciej Stachowiak told me that he supports changing WebKit's
pushState implementation to match Firefox, and so I have filed a bug against
the spec to get it updated to reflect what implementors are doing.)

-Darin

<https://bugs.webkit.org/show_bug.cgi?id=33160>

On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher <darin at chromium.org> wrote:

> [Apologies if this has been discussed before, but I couldn't find it in the
> archives.]
>
> Why does pushState only prune forward session history entries corresponding
> to the same document?  I would have expected it to behave like a reference
> fragment navigation, which prunes *all* forward session history entries.
>  Reason: it seems strange when a "navigation" doesn't result in a disabled
> forward button in the browser UI, so an app developer may be unsatisfied
> using pushState in place of reference fragment navigations.
>
> Thoughts?
> -Darin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100104/9fed311e/attachment.htm>

From dbaron at dbaron.org  Tue Jan  5 06:40:09 2010
From: dbaron at dbaron.org (L. David Baron)
Date: Tue, 5 Jan 2010 09:40:09 -0500
Subject: [whatwg] [html5] r4483 - [giow] (0) Clarify that <br> doesn't
 stop bidi processing. Fixing http://www.w3. [...]
In-Reply-To: <20100105111610.C649A1389D7@hixie.dreamhostps.com>
References: <20100105111610.C649A1389D7@hixie.dreamhostps.com>
Message-ID: <20100105144009.GA5105@pickering.dbaron.org>

On Tuesday 2010-01-05 03:16 -0800, whatwg at whatwg.org wrote:
(describing http://html5.org/tools/web-apps-tracker?from=4482&to=4483)
> [giow] (0) Clarify that <br> doesn't stop bidi processing.
> Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=8363

It might be worth saying that it is equivalent to LINE SEPARATOR in
terms of bidi processing, as HTML4 did:
  # With respect to bidirectional formatting, the BR element should
  # behave the same way the [ISO10646] LINE SEPARATOR character
  # behaves in the bidirectional algorithm.
     -- http://www.w3.org/TR/html4/struct/text.html#h-9.3.2.1

As I understand it, the bidi algorithm [1] has two parts:
 * resolution, in which characters are assigned embedding levels
 * reordering, in which the characters are reorderded into their
   left-to-right display order by, for each N decreasing from 63 to
   1, reversing all contiguous runs of embedding level N or higher

The importance of being a line separator is that *resolution* is run
on paragraphs (so is run on units containing line separators in the
middle), but reordering is run on lines (so it is not run on units
containing line separators).

This means that characters on one side of a line separator can
influence the directionality of characters on the other side, but
reordering can't move them to the opposite side of the BR (i.e.,
across lines).

For example the markup (where uppercase characters are
right-to-left) within a left-to-right direction block:
  HEB-<br>REW
looks like:
  -BEH
  WER
whereas the markup:
  HEB-<p>REW
looks like:
  BEH-
  WER
(the hyphen appears at the opposite end).

-David

[1] http://unicode.org/reports/tr9/

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

From nzakas at yahoo-inc.com  Tue Jan  5 12:20:39 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Tue, 5 Jan 2010 12:20:39 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <op.u5azuv1xidj3kv@simon-pieterss-macbook.local>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D17C@SNV-EXVS09.ds.corp.yahoo.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D281@SNV-EXVS09.ds.corp.yahoo.com><72E66735-4FF0-4E17-A510-C420A8C84B51@apple.com><63df84f0912150936j4faa7f04oe4ca547b71dd1e95@mail.gmail.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D3C0@SNV-EXVS09.ds.corp.yahoo.com><63df84f0912151147r5dca8f35tc5217129cef01f77@mail.gmail.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D446@SNV-EXVS09.ds.corp.yahoo.com><63df84f0912151721s94ef201k64ea81027904e5bf@mail.gmail.com><op.u4015j0xidj3kv@simon-pieterss-macbook.local><63df84f0912160821t16080bd5q5c81ba5a49ee517d@mail.gmail.com><op.u43ra1q0idj3kv@simon-pieterss-macbook.local><op.u43zcikfidj3kv@simon-pieterss-macbook.local><op.u44pvzh3idj3kv@simon-pieterss-macbook.local><4E45EC6AD219FD47AD1BC06E4EE3845D0420D768@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u5azuv1xidj3kv@simon-pieterss-macbook.local>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0443AD57@SNV-EXVS09.ds.corp.yahoo.com>

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-bounces at lists.whatwg.org
[mailto:whatwg-bounces at 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 at 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
<nzakas at yahoo-inc.com>  
wrote:

> Here are the results of testing various tags with empty URLs across
> different browsers. The table below indicates how many requests are
sent
> when the given tag is encountered on the page (curiously, Firefox 3
> sometimes sends two extra requests). Even though the <link> tags don't
> show it in the table, they all had href="".
>
> 					IE7	IE8	FF3	FF3.5
> SF4	Ch3	Op10
> <img src="">			1	1	1	0	1
> 1	0
> <link rel="stylesheet">		0	0	1	1
1
> 1	0
> <link rel="icon">			0	0	2	1
> 1	1	0
> <link rel="shortcut icon">	0	0	2	1	1
> 1	0
> <link rel="prefetch">		0	0	2	0	0
> 0	0
> <script src="">			0	0	1	1
1
> 1	0
> <iframe src="">			0	0	0	0
0
> 0	0
> <input type="image" src="">	1	1	1	0	1
> 1	0
> <object data="">			0	0	1	1
> 0	0	0
> <embed src="">			0	0	0	0
0
> 0	0
> <html manifest="">		0	0	0	0	1
> 0	0
>
> For the most part, no two browsers act the same. Safari and Chrome are
> the closest (not surprising).
>
> Apply a base URL via <base> in all cases didn't change the results,
> except in IE, where it prevented the extra image request from being
> made.

Thanks. IIRC, IE doesn't make a request when using minimized attribute  
syntax, i.e. "<img src>" (because it drops the attribute during
parsing).

-- 
Simon Pieters
Opera Software

From atwilson at google.com  Tue Jan  5 15:04:49 2010
From: atwilson at google.com (Drew Wilson)
Date: Tue, 5 Jan 2010 15:04:49 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
Message-ID: <f965ae411001051504s2f3abdc1y13f8c4da3303d4f7@mail.gmail.com>

I ran into this early last year when I was first investigating MessagePorts:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018893.html

I dimly recall that the response I got off-list (via IRC?) was that this was
expected behavior (the intended use for window.postMessage() is for
communicating with child iframes, where you can register an onload handler
to be notified when it's safe to post messages), but I agree that it would
be worthwhile to explicitly state this somewhere in the spec.

-atw

On Mon, Dec 21, 2009 at 7:24 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> Hi all,
>
> In the course of testing something today, I attempted to create a
> window and immediately post a message to it, and was surprised that it
> didn't seem to work.
>
> E.g.:
>
> var w = window.open("http://x");
> w.postMessage("hello, world", "*");
>
> w never got the message - this seemed to be consistent across Safari,
> Chrome, and FF (all I had installed on my Mac at the time, so
> apologies to Opera, IE, and anyone else I've left out).
>
> Is this supposed to work? If not, is there a reliable way for the the
> source to know when it is safe to send a message to the target? The
> only way I can think of is for the target to send a message back to
> the source, which only works if the target can get a reference to the
> source using window.opener, which may or may not be possible or
> desirable ...
>
> If this isn't supposed to work, can we state this explicitly in the spec?
>
> -- dirk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100105/354eec99/attachment.htm>

From darin at chromium.org  Tue Jan  5 16:53:09 2010
From: darin at chromium.org (Darin Fisher)
Date: Tue, 5 Jan 2010 16:53:09 -0800
Subject: [whatwg] question about the popstate event
Message-ID: <bd8f24d21001051653y66363bado7e0adad517b2114@mail.gmail.com>

I'd like to make sure that I'm understanding the spec for pushState and the
popstate event properly.

Suppose, I have the following sequence of events:

1. Page A is loaded.
2. Page A calls pushState("foo", null).
3. The user navigates to Page B.
4. The user navigates back to Page A (clicks the back button once).

Assuming the document of Page A was disposed upon navigation to Page B
(i.e., that it was not preserved in a page cache), should a popstate event
be generated as a result of step 4?

>From my reading of the spec, I would expect the following steps:

5. Page A is loaded.
6. The load event for Page A is dispatched.
7. The popstate event for Page A is dispatched.

Do I understand correctly?

Thanks,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100105/a9cdc029/attachment.htm>

From darin at chromium.org  Tue Jan  5 17:00:11 2010
From: darin at chromium.org (Darin Fisher)
Date: Tue, 5 Jan 2010 17:00:11 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
Message-ID: <bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>

The window doesn't open synchronously, so you should have to wait for
http://x/ to load (or for its document to at least be created) before you
can start communicating with it.

Note: If you instead open "about:blank" you should be able to communicate
with it synchronously since "about:blank" is loaded synchronously.  It is
special-cased.

>From the newly opened window, you could try posting a message to its opener.
 The opener could then handle that event and use it as a signal to know that
it can know begin communicating with the newly opened window.

I haven't tested any of this ;-)

-Darin


On Mon, Dec 21, 2009 at 7:24 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> Hi all,
>
> In the course of testing something today, I attempted to create a
> window and immediately post a message to it, and was surprised that it
> didn't seem to work.
>
> E.g.:
>
> var w = window.open("http://x");
> w.postMessage("hello, world", "*");
>
> w never got the message - this seemed to be consistent across Safari,
> Chrome, and FF (all I had installed on my Mac at the time, so
> apologies to Opera, IE, and anyone else I've left out).
>
> Is this supposed to work? If not, is there a reliable way for the the
> source to know when it is safe to send a message to the target? The
> only way I can think of is for the target to send a message back to
> the source, which only works if the target can get a reference to the
> source using window.opener, which may or may not be possible or
> desirable ...
>
> If this isn't supposed to work, can we state this explicitly in the spec?
>
> -- dirk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100105/c4f635c0/attachment.htm>

From jonas at sicking.cc  Tue Jan  5 17:03:44 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 5 Jan 2010 17:03:44 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com> 
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
Message-ID: <63df84f1001051703m2e8c76efj92fae47e10fac386@mail.gmail.com>

On Tue, Jan 5, 2010 at 5:00 PM, Darin Fisher <darin at chromium.org> wrote:
> The window doesn't open synchronously, so you should have to wait for
> http://x/ to load (or for its document to at least be created) before you
> can start communicating with it.
> Note: If you instead open "about:blank" you should be able to communicate
> with it synchronously since "about:blank" is loaded synchronously. ?It is
> special-cased.
> From the newly opened window, you could try posting a message to its opener.
> ?The opener could then handle that event and use it as a signal to know that
> it can know begin communicating with the newly opened window.
> I haven't tested any of this ;-)

This is a sort of suboptimal state of affairs though. Compare to
workers, which also do not load synchronously, but which you can
immediately send messages to using postMessage().

We could use a similar solution for windows postMessage as we use for
worker postMessage.

The main question is if that would break existing content.

/ Jonas

From whatwg at adambarth.com  Tue Jan  5 17:41:13 2010
From: whatwg at adambarth.com (Adam Barth)
Date: Tue, 5 Jan 2010 17:41:13 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <63df84f1001051703m2e8c76efj92fae47e10fac386@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com> 
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com> 
	<63df84f1001051703m2e8c76efj92fae47e10fac386@mail.gmail.com>
Message-ID: <7789133a1001051741p427693c4wfdf6c9f568f77756@mail.gmail.com>

On Tue, Jan 5, 2010 at 5:03 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> The main question is if that would break existing content.

The existing content would be racy because postMessage returns to the
main event loop before dispatching.  It would at least make the
content more predictable.  :)

Adam

From justin.lebar at gmail.com  Tue Jan  5 18:55:13 2010
From: justin.lebar at gmail.com (Justin Lebar)
Date: Tue, 5 Jan 2010 18:55:13 -0800
Subject: [whatwg] question about the popstate event
In-Reply-To: <bd8f24d21001051653y66363bado7e0adad517b2114@mail.gmail.com>
References: <bd8f24d21001051653y66363bado7e0adad517b2114@mail.gmail.com>
Message-ID: <c84706c71001051855x35410e25o35b321bb792996e7@mail.gmail.com>

> From my reading of the spec, I would expect the following steps:
> 5. Page A is loaded.
> 6. The load event for Page A is dispatched.
> 7. The popstate event for Page A is dispatched.

I think this is correct.  A popstate event is always dispatched
whenever a new session history entry is activated (6.10.3).

-Justin

On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher <darin at chromium.org> wrote:
> I'd like to make sure that I'm understanding the spec for pushState and the
> popstate event properly.
> Suppose, I have the following sequence of events:
> 1. Page A is loaded.
> 2. Page A calls pushState("foo", null).
> 3. The user navigates to Page B.
> 4. The user navigates back to Page A (clicks the back button once).
> Assuming the document of Page A was disposed upon navigation to Page B
> (i.e., that it was not preserved in a page cache), should a popstate event
> be generated as a result of step 4?
> From my reading of the spec, I would expect the following steps:
> 5. Page A is loaded.
> 6. The load event for Page A is dispatched.
> 7. The popstate event for Page A is dispatched.
> Do I understand correctly?
> Thanks,
> -Darin

From dpranke at chromium.org  Tue Jan  5 20:29:40 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Tue, 5 Jan 2010 20:29:40 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
Message-ID: <3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>

I understand the rationale, and the workaround you suggest does work,
(I have tested it, in FF, Safari and Chrome). But, as Jonas mentioned,
this isn't what we do with workers, and it feels counter-intuitive to
me (I'm having trouble thinking of other async messaging models that
require an application-level handshake like this before messaging can
commence). Are there reasons other than implementation complexity (an
okay reason) or backwards-compatibility (a better reason) not to have
the post work in this case? Put differently, would anything break
(other than a rather oddly written app that explicitly counted on this
behavior) if this did work?

As an alternative, would it be possible to create an onChildLoad()
event in the parent so that the parent could reliably send a message
without needing the child's cooperation? These seems only marginally
better than having the child post to the parent, so it may not be
worth it ...

-- Dirk

On Tue, Jan 5, 2010 at 5:00 PM, Darin Fisher <darin at chromium.org> wrote:
> The window doesn't open synchronously, so you should have to wait for
> http://x/ to load (or for its document to at least be created) before you
> can start communicating with it.
> Note: If you instead open "about:blank" you should be able to communicate
> with it synchronously since "about:blank" is loaded synchronously. ?It is
> special-cased.
> From the newly opened window, you could try posting a message to its opener.
> ?The opener could then handle that event and use it as a signal to know that
> it can know begin communicating with the newly opened window.
> I haven't tested any of this ;-)
> -Darin
>
> On Mon, Dec 21, 2009 at 7:24 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>>
>> Hi all,
>>
>> In the course of testing something today, I attempted to create a
>> window and immediately post a message to it, and was surprised that it
>> didn't seem to work.
>>
>> E.g.:
>>
>> var w = window.open("http://x");
>> w.postMessage("hello, world", "*");
>>
>> w never got the message - this seemed to be consistent across Safari,
>> Chrome, and FF (all I had installed on my Mac at the time, so
>> apologies to Opera, IE, and anyone else I've left out).
>>
>> Is this supposed to work? If not, is there a reliable way for the the
>> source to know when it is safe to send a message to the target? The
>> only way I can think of is for the target to send a message back to
>> the source, which only works if the target can get a reference to the
>> source using window.opener, which may or may not be possible or
>> desirable ...
>>
>> If this isn't supposed to work, can we state this explicitly in the spec?
>>
>> -- dirk
>
>

From darin at chromium.org  Tue Jan  5 21:30:17 2010
From: darin at chromium.org (Darin Fisher)
Date: Tue, 5 Jan 2010 21:30:17 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
	<3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>
Message-ID: <bd8f24d21001052130q1e4e573as37785a8bad1c3419@mail.gmail.com>

It sounds tempting to say that the postMessage should be queued until the
newly opened window is loaded, but what point in time is that exactly?  Is
that after the load event is dispatched on the newly opened window?

Note: a newly opened window can begin communicating with its opener much
earlier (via inline script execution).

However, if we try to dispatch the postMessage events before the load event
then the newly opened window may not have registered its event handlers yet.
 (A future <script> tag may define the event handler.)  So, I think we would
have to delay until the load event for the semantics to be sane.

There is perhaps a more critical issue that we should consider.  What
happens if the named window already exists?

Consider this case:

window.open("http://a/", "foo");
...
var w = window.open("http://b/", "foo");
w.postMessage("bar", "*");

I suspect the postMessage would be dispatched in this case, but the event
dispatch would probably go to the document at http://a/ instead of http://b/.
 This is because the browser has no way of knowing if http://b/ will
actually be displayable content.  It could be of a mime type that should
just be downloaded (in which case the indicated window is not navigated).

So, queuing is probably not a good idea.  Workers do not have this issue
since they cannot be "navigated" like a window.

-Darin


On Tue, Jan 5, 2010 at 8:29 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> I understand the rationale, and the workaround you suggest does work,
> (I have tested it, in FF, Safari and Chrome). But, as Jonas mentioned,
> this isn't what we do with workers, and it feels counter-intuitive to
> me (I'm having trouble thinking of other async messaging models that
> require an application-level handshake like this before messaging can
> commence). Are there reasons other than implementation complexity (an
> okay reason) or backwards-compatibility (a better reason) not to have
> the post work in this case? Put differently, would anything break
> (other than a rather oddly written app that explicitly counted on this
> behavior) if this did work?
>
> As an alternative, would it be possible to create an onChildLoad()
> event in the parent so that the parent could reliably send a message
> without needing the child's cooperation? These seems only marginally
> better than having the child post to the parent, so it may not be
> worth it ...
>
> -- Dirk
>
> On Tue, Jan 5, 2010 at 5:00 PM, Darin Fisher <darin at chromium.org> wrote:
> > The window doesn't open synchronously, so you should have to wait for
> > http://x/ to load (or for its document to at least be created) before
> you
> > can start communicating with it.
> > Note: If you instead open "about:blank" you should be able to communicate
> > with it synchronously since "about:blank" is loaded synchronously.  It is
> > special-cased.
> > From the newly opened window, you could try posting a message to its
> opener.
> >  The opener could then handle that event and use it as a signal to know
> that
> > it can know begin communicating with the newly opened window.
> > I haven't tested any of this ;-)
> > -Darin
> >
> > On Mon, Dec 21, 2009 at 7:24 PM, Dirk Pranke <dpranke at chromium.org>
> wrote:
> >>
> >> Hi all,
> >>
> >> In the course of testing something today, I attempted to create a
> >> window and immediately post a message to it, and was surprised that it
> >> didn't seem to work.
> >>
> >> E.g.:
> >>
> >> var w = window.open("http://x");
> >> w.postMessage("hello, world", "*");
> >>
> >> w never got the message - this seemed to be consistent across Safari,
> >> Chrome, and FF (all I had installed on my Mac at the time, so
> >> apologies to Opera, IE, and anyone else I've left out).
> >>
> >> Is this supposed to work? If not, is there a reliable way for the the
> >> source to know when it is safe to send a message to the target? The
> >> only way I can think of is for the target to send a message back to
> >> the source, which only works if the target can get a reference to the
> >> source using window.opener, which may or may not be possible or
> >> desirable ...
> >>
> >> If this isn't supposed to work, can we state this explicitly in the
> spec?
> >>
> >> -- dirk
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100105/c7e02fe2/attachment.htm>

From shadow2531 at gmail.com  Tue Jan  5 21:34:07 2010
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Wed, 06 Jan 2010 00:34:07 -0500
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
	<3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>
Message-ID: <op.u53i25aw1ejg13@sandra-svwliu01>

On Tue, 05 Jan 2010 23:29:40 -0500, Dirk Pranke <dpranke at chromium.org>  
wrote:

> As an alternative, would it be possible to create an onChildLoad()
> event in the parent so that the parent could reliably send a message
> without needing the child's cooperation? These seems only marginally
> better than having the child post to the parent, so it may not be
> worth it ...

In Firefox, you can do stuff like this:

var w = window.open("handler.html");
w.addEventListener("DOMContentLoaded", function(e) {
     var targetWin = e.target.defaultView.
     targetWin.postMessage("Hello", "domain");
}, false);

But, I think that only works in Firefox. In Opera at least, I'm sure it  
doesn't work.

-- 
Michael

From darin at chromium.org  Tue Jan  5 21:41:13 2010
From: darin at chromium.org (Darin Fisher)
Date: Tue, 5 Jan 2010 21:41:13 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <op.u53i25aw1ejg13@sandra-svwliu01>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
	<3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>
	<op.u53i25aw1ejg13@sandra-svwliu01>
Message-ID: <bd8f24d21001052141t727e201k145372d805b1f783@mail.gmail.com>

On Tue, Jan 5, 2010 at 9:34 PM, Michael A. Puls II <shadow2531 at gmail.com>wrote:

> On Tue, 05 Jan 2010 23:29:40 -0500, Dirk Pranke <dpranke at chromium.org>
> wrote:
>
>  As an alternative, would it be possible to create an onChildLoad()
>> event in the parent so that the parent could reliably send a message
>> without needing the child's cooperation? These seems only marginally
>> better than having the child post to the parent, so it may not be
>> worth it ...
>>
>
> In Firefox, you can do stuff like this:
>
> var w = window.open("handler.html");
> w.addEventListener("DOMContentLoaded", function(e) {
>    var targetWin = e.target.defaultView.
>    targetWin.postMessage("Hello", "domain");
> }, false);
>
> But, I think that only works in Firefox. In Opera at least, I'm sure it
> doesn't work.
>
>
The same thing works fine in WebKit-based browsers as well.  However, this
solution only works when the newly opened document is in the same origin as
the opener.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100105/a7f37503/attachment.htm>

From info at html5.jp  Tue Jan  5 23:32:20 2010
From: info at html5.jp (Futomi Hatano)
Date: Wed, 06 Jan 2010 16:32:20 +0900
Subject: [whatwg] The examples of the list attribute of the input element is
	incorrect
Message-ID: <20100106155759.7B1C.C8DE7135@html5.jp>

Hi all,

I have checked the examples of the list attribute of the input element, which have added today.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-list-attribute

There is a example which shows how to mark up fallback contents of the datalist element.

<p>
 <label>
  Enter a breed:
  <input type="text" name="breed" list="breeds">
 </label>
 <datalist id="breeds">
  <label>
   or select one from the list:
   <select name="breed">
    <option value=""> (none selected)
    <option>Abyssinian
    <option>Alpaca
    <!-- ... -->
   </select>
  </label>
 </datalist>
</p>

I think that this example is incorrect.
It works in legacy UAs as expected (i.e. the fallback contens are shown.).
But it does not work in UAs which support the datalist element as expected (i.e. the suggests are not shown.),
because the option elements do not have a value attribute.
The spec says that a value attribute is required in the option element for a suggestion.
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element

The example works in Opera 10.1, because it is based on the old spec.
In fact, the example does not work in Opera 10.5 pre-alpha.
I think that Opera 10.5 pre-alpha is correct.

I think that the example must be as follow.

<p>
 <label>
  Enter a breed:
  <input type="text" name="breed" list="breeds">
 </label>
 <datalist id="breeds">
  <label>
   or select one from the list:
   <select name="breed">
    <option value=""> (none selected)
    <option value="Abyssinian">Abyssinian
    <option value="Alpaca">Alpaca
    <!-- ... -->
   </select>
  </label>
 </datalist>
</p>

This example works in Opera(10.1, 10.5) and other UAs which does not support the datalist element as expected, except Chrome 4.

Thank you.

--
Futomi Hatano
http://www.html5.jp/
http://www.futomi.com/
http://twitter.com/futomi


From annevk at opera.com  Wed Jan  6 01:11:21 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 06 Jan 2010 10:11:21 +0100
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <bd8f24d21001052130q1e4e573as37785a8bad1c3419@mail.gmail.com>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
	<3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>
	<bd8f24d21001052130q1e4e573as37785a8bad1c3419@mail.gmail.com>
Message-ID: <op.u53s47fs64w2qv@annevk-t60>

On Wed, 06 Jan 2010 06:30:17 +0100, Darin Fisher <darin at chromium.org>  
wrote:
> I suspect the postMessage would be dispatched in this case, but the event
> dispatch would probably go to the document at http://a/ instead of  
> http://b/.

This would fail as well because of the targetOrigin argument. (Unless that  
is * I guess, but can't you just check before invoking postMessage()  
anyway?)


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

From darin at chromium.org  Wed Jan  6 09:58:15 2010
From: darin at chromium.org (Darin Fisher)
Date: Wed, 6 Jan 2010 09:58:15 -0800
Subject: [whatwg] using postMessage() to send to a newly-created window
In-Reply-To: <op.u53s47fs64w2qv@annevk-t60>
References: <3726d1bf0912211924x12a47744sa376379c6baa9336@mail.gmail.com>
	<bd8f24d21001051700n6e460f93hd859488da72ce8ba@mail.gmail.com>
	<3726d1bf1001052029r35a80682h1b99d0211d9f7bf1@mail.gmail.com>
	<bd8f24d21001052130q1e4e573as37785a8bad1c3419@mail.gmail.com>
	<op.u53s47fs64w2qv@annevk-t60>
Message-ID: <bd8f24d21001060958g23ee0e32xae016ca3b3df060c@mail.gmail.com>

On Wed, Jan 6, 2010 at 1:11 AM, Anne van Kesteren <annevk at opera.com> wrote:

> On Wed, 06 Jan 2010 06:30:17 +0100, Darin Fisher <darin at chromium.org>
> wrote:
>
>> I suspect the postMessage would be dispatched in this case, but the event
>> dispatch would probably go to the document at http://a/ instead of
>> http://b/.
>>
>
> This would fail as well because of the targetOrigin argument. (Unless that
> is * I guess, but can't you just check before invoking postMessage()
> anyway?)
>
>
It was given as "*" in the example.
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100106/6fd37c8b/attachment.htm>

From derernst at gmx.ch  Thu Jan  7 01:47:20 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 07 Jan 2010 10:47:20 +0100
Subject: [whatwg] window.print() when printing is not supported
In-Reply-To: <11e306600912281720t11425ceh129fbc919374d591@mail.gmail.com>
References: <4B389C58.7020804@helsinki.fi>
	<op.u5ne6vcb64w2qv@annevk-t60>	<4B38B334.5010307@gmx.ch>
	<4B38E5E2.1080407@mit.edu>
	<11e306600912281720t11425ceh129fbc919374d591@mail.gmail.com>
Message-ID: <4B45ADA8.2020204@gmx.ch>

Robert O'Callahan schrieb:
> On Tue, Dec 29, 2009 at 6:07 AM, Boris Zbarsky <bzbarsky at mit.edu 
> <mailto:bzbarsky at mit.edu>> wrote:
> 
>     Come to think of it, airline boarding passes are the only case in
>     which I print things from the web using either print buttons or the
>     browser's "print" functionality.  Are there other common printing
>     use cases?  What are they?
> 
> 
> I print anything that I might need access to while travelling, since I 
> don't have a smartphone and if I did I wouldn't necessarily want to 
> depend on its battery lasting the entire time spent in transit.
> 
> Some users I know make hard copies of emails and other important 
> documents as a form of backup.

I agree to all points mentioned by Robert. And these first two are 
actually cases that are not covered well today, as web mail and map 
applications are often using frames or iframes. Printing from pages 
using frames and iframes is still an annoying part of the web user 
experience. Additionnally, print versions of timetable information i.e. 
for trains are often displayed in toolbar-less popup windows, another 
annoying print experience.

I.e. in Firefox there are no "print preview" and "print preview this 
frame" (or whatever) commands available from the context menu, which 
makes printing from framed pages or toolbar-less popups really 
difficult. (The Mozilla developers do not share this POV anyway: 
https://bugzilla.mozilla.org/show_bug.cgi?id=504305)

While this is not the place to critizise browser implementations, I 
think there is a relation between the importance of print buttons (and 
thus the window.print() function) and the browsers' printing interfaces. 
I am sure that if browsers would provide easy and intuitive printing 
functionalities, the use of window.print() would tend to get marginal 
within some years.

(I understand that this is not a contribution to the original question, 
as the handling of window.print() by kiosk browsers has to be specified 
anyway. It is only a contribution to Boris' question about printing use 
cases.)

From jonas at sicking.cc  Thu Jan  7 11:41:59 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 7 Jan 2010 11:41:59 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
Message-ID: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>

Hi web fans,

So at mozilla we've been implementing and playing around with various
File APIs lately. One of the most common use cases today for file
manipulation is photo uploaders. For example to sites like flickr,
facebook, twitpic and icanhascheezburger. Some of these sites allow
additional modifications of the uploaded image, most commonly cropping
and rotating the image. But even things like manipulating colors,
adding text, and red eye reduction are things that sites do, or would
like to do.

We do already have a great tool for image manipulation in HTML, the
canvas element. However if a site wants to upload the resulting image,
after the modifications, things become more painful. Currently you
have to call toDataURL(), send that URL using XMLHttpRequest, and then
serverside convert to binary data. Things will be a little better once
XHR supports sending manually constructed binary data, but you still
have to manually convert the data url to binary data in javascript.

I suggest we add a function like:

File toFile(in DOMString name, in optional DOMString type, in any... args);

This function takes the same arguments as toDataURL(), plus an
additional 'name' argument. It produces the same result as
toDataURL(), except that it returns the result as a File object rather
than as a data-url encoded string. This can then be directly sent
using XMLHttpRequest.

/ Jonas

From nzakas at yahoo-inc.com  Thu Jan  7 13:03:03 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Thu, 7 Jan 2010 13:03:03 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0443AD57@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D17C@SNV-EXVS09.ds.corp.yahoo.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D281@SNV-EXVS09.ds.corp.yahoo.com><72E66735-4FF0-4E17-A510-C420A8C84B51@apple.com><63df84f0912150936j4faa7f04oe4ca547b71dd1e95@mail.gmail.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D3C0@SNV-EXVS09.ds.corp.yahoo.com><63df84f0912151147r5dca8f35tc5217129cef01f77@mail.gmail.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420D446@SNV-EXVS09.ds.corp.yahoo.com><63df84f0912151721s94ef201k64ea81027904e5bf@mail.gmail.com><op.u4015j0xidj3kv@simon-pieterss-macbook.local><63df84f0912160821t16080bd5q5c81ba5a49ee517d@mail.gmail.com><op.u43ra1q0idj3kv@simon-pieterss-macbook.local><op.u43zcikfidj3kv@simon-pieterss-macbook.local><op.u44pvzh3idj3kv@simon-pieterss-macbook.local><4E45EC6AD219FD47AD1BC06E4EE3845D0420D768@SNV-EXVS09.ds.corp.yahoo.com><op.u5azuv1xidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC0! 6E4EE3845
	D0443AD57@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0443AF4A@SNV-EXVS09.ds.corp.yahoo.com>

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-bounces at lists.whatwg.org
[mailto:whatwg-bounces at 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 at 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-bounces at lists.whatwg.org
[mailto:whatwg-bounces at 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 at 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
<nzakas at yahoo-inc.com>  
wrote:

> Here are the results of testing various tags with empty URLs across
> different browsers. The table below indicates how many requests are
sent
> when the given tag is encountered on the page (curiously, Firefox 3
> sometimes sends two extra requests). Even though the <link> tags don't
> show it in the table, they all had href="".
>
> 					IE7	IE8	FF3	FF3.5
> SF4	Ch3	Op10
> <img src="">			1	1	1	0	1
> 1	0
> <link rel="stylesheet">		0	0	1	1
1
> 1	0
> <link rel="icon">			0	0	2	1
> 1	1	0
> <link rel="shortcut icon">	0	0	2	1	1
> 1	0
> <link rel="prefetch">		0	0	2	0	0
> 0	0
> <script src="">			0	0	1	1
1
> 1	0
> <iframe src="">			0	0	0	0
0
> 0	0
> <input type="image" src="">	1	1	1	0	1
> 1	0
> <object data="">			0	0	1	1
> 0	0	0
> <embed src="">			0	0	0	0
0
> 0	0
> <html manifest="">		0	0	0	0	1
> 0	0
>
> For the most part, no two browsers act the same. Safari and Chrome are
> the closest (not surprising).
>
> Apply a base URL via <base> in all cases didn't change the results,
> except in IE, where it prevented the extra image request from being
> made.

Thanks. IIRC, IE doesn't make a request when using minimized attribute  
syntax, i.e. "<img src>" (because it drops the attribute during
parsing).

-- 
Simon Pieters
Opera Software

From jonas at sicking.cc  Thu Jan  7 13:09:07 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 7 Jan 2010 13:09:07 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0443AF4A@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u4015j0xidj3kv@simon-pieterss-macbook.local>
	<63df84f0912160821t16080bd5q5c81ba5a49ee517d@mail.gmail.com> 
	<op.u43ra1q0idj3kv@simon-pieterss-macbook.local>
	<op.u43zcikfidj3kv@simon-pieterss-macbook.local> 
	<op.u44pvzh3idj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D768@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u5azuv1xidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AD57@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AF4A@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <63df84f1001071309l6b78ed89q1269026dfb3035ed@mail.gmail.com>

On Thu, Jan 7, 2010 at 1:03 PM, Nicholas Zakas <nzakas at 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

From mjs at apple.com  Thu Jan  7 14:22:35 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 07 Jan 2010 14:22:35 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
Message-ID: <A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>


On Jan 7, 2010, at 11:41 AM, Jonas Sicking wrote:

> Hi web fans,
>
> So at mozilla we've been implementing and playing around with various
> File APIs lately. One of the most common use cases today for file
> manipulation is photo uploaders. For example to sites like flickr,
> facebook, twitpic and icanhascheezburger. Some of these sites allow
> additional modifications of the uploaded image, most commonly cropping
> and rotating the image. But even things like manipulating colors,
> adding text, and red eye reduction are things that sites do, or would
> like to do.
>
> We do already have a great tool for image manipulation in HTML, the
> canvas element. However if a site wants to upload the resulting image,
> after the modifications, things become more painful. Currently you
> have to call toDataURL(), send that URL using XMLHttpRequest, and then
> serverside convert to binary data. Things will be a little better once
> XHR supports sending manually constructed binary data, but you still
> have to manually convert the data url to binary data in javascript.
>
> I suggest we add a function like:
>
> File toFile(in DOMString name, in optional DOMString type, in any...  
> args);
>
> This function takes the same arguments as toDataURL(), plus an
> additional 'name' argument. It produces the same result as
> toDataURL(), except that it returns the result as a File object rather
> than as a data-url encoded string. This can then be directly sent
> using XMLHttpRequest.

I think it would make more sense to have an actual type for binary  
data (for example along the lines of my proposal on public-script- 
coord and es-discuss) and enable getting one from <canvas> and sending  
via XHR. I don't think using File for temporary in-memory binary data,  
as opposed to a file on disk, makes sense. The File should stick to  
representing files. After all, you would not make a File object to  
convert something to text for uploading. Nor would it make sense to do  
an asynchronous read from this. And under the covers, you would want  
to pass the actual binary data to the upload code, not a file with a  
file name.

Regards,
Maciej


From joaoe at opera.com  Thu Jan  7 14:27:14 2010
From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=)
Date: Thu, 07 Jan 2010 23:27:14 +0100
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
Message-ID: <op.u56onosm2q99of@coruscant>


>> This function takes the same arguments as toDataURL(), plus an
>> additional 'name' argument. It produces the same result as
>> toDataURL(), except that it returns the result as a File object rather
>> than as a data-url encoded string. This can then be directly sent
>> using XMLHttpRequest.
>
> I think it would make more sense to have an actual type for binary data  
> (for example along the lines of my proposal on public-script-coord and  
> es-discuss) and enable getting one from <canvas> and sending via XHR.

How about just overloading xhr.send() to handle a <canvas> element ?

From jonas at sicking.cc  Thu Jan  7 15:12:44 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 7 Jan 2010 15:12:44 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com> 
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
Message-ID: <63df84f1001071512x419fa571t85d2595c9e4343b5@mail.gmail.com>

On Thu, Jan 7, 2010 at 2:22 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jan 7, 2010, at 11:41 AM, Jonas Sicking wrote:
>
>> Hi web fans,
>>
>> So at mozilla we've been implementing and playing around with various
>> File APIs lately. One of the most common use cases today for file
>> manipulation is photo uploaders. For example to sites like flickr,
>> facebook, twitpic and icanhascheezburger. Some of these sites allow
>> additional modifications of the uploaded image, most commonly cropping
>> and rotating the image. But even things like manipulating colors,
>> adding text, and red eye reduction are things that sites do, or would
>> like to do.
>>
>> We do already have a great tool for image manipulation in HTML, the
>> canvas element. However if a site wants to upload the resulting image,
>> after the modifications, things become more painful. Currently you
>> have to call toDataURL(), send that URL using XMLHttpRequest, and then
>> serverside convert to binary data. Things will be a little better once
>> XHR supports sending manually constructed binary data, but you still
>> have to manually convert the data url to binary data in javascript.
>>
>> I suggest we add a function like:
>>
>> File toFile(in DOMString name, in optional DOMString type, in any...
>> args);
>>
>> This function takes the same arguments as toDataURL(), plus an
>> additional 'name' argument. It produces the same result as
>> toDataURL(), except that it returns the result as a File object rather
>> than as a data-url encoded string. This can then be directly sent
>> using XMLHttpRequest.
>
> I think it would make more sense to have an actual type for binary data (for
> example along the lines of my proposal on public-script-coord and
> es-discuss) and enable getting one from <canvas> and sending via XHR. I
> don't think using File for temporary in-memory binary data, as opposed to a
> file on disk, makes sense. The File should stick to representing files.
> After all, you would not make a File object to convert something to text for
> uploading. Nor would it make sense to do an asynchronous read from this. And
> under the covers, you would want to pass the actual binary data to the
> upload code, not a file with a file name.

The difference between a binary blob of data, and the image extracted
from a canvas element, is that the latter has a mimetype. This is
extra important here since if you call:

result = canvas.toFile("", "image/jpeg");

you won't know if the data in result is encoded as "image/jpeg", or
"image/png", since support for jpeg encoding is optional.

I don't really feel strongly about if a File object is extracted or
not, but I do think that the mimetype needs to be returned somehow, so
that it can be passed on the the XHR call. Use a File just happens to
be a convenient way to do this.

/ Jonas

From jonas at sicking.cc  Thu Jan  7 15:14:40 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 7 Jan 2010 15:14:40 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <op.u56onosm2q99of@coruscant>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com> 
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant>
Message-ID: <63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>

On Thu, Jan 7, 2010 at 2:27 PM, Jo?o Eiras <joaoe at opera.com> wrote:
>
>>> This function takes the same arguments as toDataURL(), plus an
>>> additional 'name' argument. It produces the same result as
>>> toDataURL(), except that it returns the result as a File object rather
>>> than as a data-url encoded string. This can then be directly sent
>>> using XMLHttpRequest.
>>
>> I think it would make more sense to have an actual type for binary data
>> (for example along the lines of my proposal on public-script-coord and
>> es-discuss) and enable getting one from <canvas> and sending via XHR.
>
> How about just overloading xhr.send() to handle a <canvas> element ?

I'm reluctant to overload the meaning of sending an Element object.
When a Document is passed to xhr.send() we already serialize that
document into markup, it seems likely to me that in the future we'll
want to do the same thing for Elements.

/ Jonas

From jonas at sicking.cc  Thu Jan  7 15:15:42 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 7 Jan 2010 15:15:42 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com> 
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant> 
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
Message-ID: <63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>

On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Thu, Jan 7, 2010 at 2:27 PM, Jo?o Eiras <joaoe at opera.com> wrote:
>>
>>>> This function takes the same arguments as toDataURL(), plus an
>>>> additional 'name' argument. It produces the same result as
>>>> toDataURL(), except that it returns the result as a File object rather
>>>> than as a data-url encoded string. This can then be directly sent
>>>> using XMLHttpRequest.
>>>
>>> I think it would make more sense to have an actual type for binary data
>>> (for example along the lines of my proposal on public-script-coord and
>>> es-discuss) and enable getting one from <canvas> and sending via XHR.
>>
>> How about just overloading xhr.send() to handle a <canvas> element ?
>
> I'm reluctant to overload the meaning of sending an Element object.
> When a Document is passed to xhr.send() we already serialize that
> document into markup, it seems likely to me that in the future we'll
> want to do the same thing for Elements.

Additionally, this doesn't allow specifying the encoding type, such as
JPEG or PNG, or encoding parameters, such as JPEG quality.

/ Jonas

From shumpei.shiraishi at gmail.com  Thu Jan  7 17:27:36 2010
From: shumpei.shiraishi at gmail.com (Shumpei Shiraishi)
Date: Fri, 8 Jan 2010 10:27:36 +0900
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com> 
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant> 
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com> 
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
Message-ID: <104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>

Hi.

I think the method name "toFile()" is missleading, because I agree to
the Maciej's openion.

> I don't think using File for temporary in-memory binary data, as opposed to a file on disk, makes sense.

So, how about changing the method name to "toBlob()" and signature as follows?

Blob toBlob(in optional DOMString type, in any... args);

--Shumpei

On Fri, Jan 8, 2010 at 8:15 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Thu, Jan 7, 2010 at 2:27 PM, Jo?o Eiras <joaoe at opera.com> wrote:
>>>
>>>>> This function takes the same arguments as toDataURL(), plus an
>>>>> additional 'name' argument. It produces the same result as
>>>>> toDataURL(), except that it returns the result as a File object rather
>>>>> than as a data-url encoded string. This can then be directly sent
>>>>> using XMLHttpRequest.
>>>>
>>>> I think it would make more sense to have an actual type for binary data
>>>> (for example along the lines of my proposal on public-script-coord and
>>>> es-discuss) and enable getting one from <canvas> and sending via XHR.
>>>
>>> How about just overloading xhr.send() to handle a <canvas> element ?
>>
>> I'm reluctant to overload the meaning of sending an Element object.
>> When a Document is passed to xhr.send() we already serialize that
>> document into markup, it seems likely to me that in the future we'll
>> want to do the same thing for Elements.
>
> Additionally, this doesn't allow specifying the encoding type, such as
> JPEG or PNG, or encoding parameters, such as JPEG quality.
>
> / Jonas
>

From jonas at sicking.cc  Thu Jan  7 19:59:06 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 7 Jan 2010 19:59:06 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com> 
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant> 
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com> 
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com> 
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
Message-ID: <63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>

On Thu, Jan 7, 2010 at 5:27 PM, Shumpei Shiraishi
<shumpei.shiraishi at gmail.com> wrote:
> Hi.
>
> I think the method name "toFile()" is missleading, because I agree to
> the Maciej's openion.
>
>> I don't think using File for temporary in-memory binary data, as opposed to a file on disk, makes sense.
>
> So, how about changing the method name to "toBlob()" and signature as follows?
>
> Blob toBlob(in optional DOMString type, in any... args);

This doesn't address my concern that you won't know the mime type of
the blob returned.

/ Jonas

From hsivonen at iki.fi  Fri Jan  8 01:44:05 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 8 Jan 2010 11:44:05 +0200
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant>
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
Message-ID: <0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>

On Jan 8, 2010, at 05:59, Jonas Sicking wrote:

> On Thu, Jan 7, 2010 at 5:27 PM, Shumpei Shiraishi
> <shumpei.shiraishi at gmail.com> wrote:
>> Hi.
>> 
>> I think the method name "toFile()" is missleading, because I agree to
>> the Maciej's openion.
>> 
>>> I don't think using File for temporary in-memory binary data, as opposed to a file on disk, makes sense.
>> 
>> So, how about changing the method name to "toBlob()" and signature as follows?
>> 
>> Blob toBlob(in optional DOMString type, in any... args);
> 
> This doesn't address my concern that you won't know the mime type of
> the blob returned.

Image types can be reliably distinguished from the magic number, so having the MIME type isn't critical in that sense.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From annevk at opera.com  Fri Jan  8 01:50:53 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 08 Jan 2010 10:50:53 +0100
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant>
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
	<0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>
Message-ID: <op.u57ka3kn64w2qv@annevk-t60>

On Fri, 08 Jan 2010 10:44:05 +0100, Henri Sivonen <hsivonen at iki.fi> wrote:
> Image types can be reliably distinguished from the magic number, so  
> having the MIME type isn't critical in that sense.

Since SVG this is no longer really true. Though I doubt anyone will  
support <canvas> -> SVG...


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

From privat at ni-po.com  Fri Jan  8 06:13:15 2010
From: privat at ni-po.com (Nikita Popov)
Date: Fri, 08 Jan 2010 15:13:15 +0100
Subject: [whatwg] Output of web applications
Message-ID: <4B473D7B.3050003@ni-po.com>

I think everyone who uses PHP, JavaScript, a.s.o. knows, that at some 
point the user makes something wrong and you want to throw an error 
("Your email's not valid (MX-Record not set.)") or an information ("You 
have logged in successfully.").

Know I do this using <div id="error"> or <div id="info"> analogically.

As errors or other direct responses to user interaction are not the same 
as some different text, I think there should be a possibility to mark 
them up appropriately.

I first searched in the Spec for some existing elements for output, but 
only found <samp> which is for sample output only.

I don't quite know which element name to use best, maybe:

<output>
<output error> / <output info(rmation)>
<output type="error"> / <output type="info(rmation)">
(The question is, what is <output>, error or info?)

What do you think?

From Chris.Taylor at figureout.com  Fri Jan  8 07:32:27 2010
From: Chris.Taylor at figureout.com (Chris Taylor)
Date: Fri, 8 Jan 2010 15:32:27 +0000
Subject: [whatwg] Output of web applications
In-Reply-To: <4B473D7B.3050003@ni-po.com>
References: <4B473D7B.3050003@ni-po.com>
Message-ID: <8D83F8F2930C074D94A02FAFA2E0B17201C21AC128@tpexmb01>

> Nikita Popov
> I don't quite know which element name to use best, maybe:
>
> <output>
> <output error> / <output info(rmation)>
> <output type="error"> / <output type="info(rmation)">
> (The question is, what is <output>, error or info?)
>
> What do you think?

I think having access to the full range of HTML elements for a response message is a very useful feature. For example:

<div class="error">
<h3>Sorry, there was an error</h3>
<p>There was an error with the form you just submitted. Please check the following:</p>
<ul>
<li>Your email address is valid</li>
<li>Your password and its confirmation match</li>
</ul>
</div>

Whether there is a use-case for having a particular element that appears as part of the browser chrome I'm not sure, but I think that's probably what you're getting at. For example, see the message that shows at the top of the screen when an error occurs on Twitter (sorry, I don't have an example URL).

Chris


This message has been scanned for malware by SurfControl plc. www.surfcontrol.com

From bruant at enseirb-matmeca.fr  Fri Jan  8 08:04:35 2010
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Fri, 08 Jan 2010 08:04:35 -0800
Subject: [whatwg] Output of web applications
In-Reply-To: <4B473D7B.3050003@ni-po.com>
References: <4B473D7B.3050003@ni-po.com>
Message-ID: <4B475793.2080007@enseirb-matmeca.fr>

Le 08/01/2010 06:13, Nikita Popov a ?crit :
> I think everyone who uses PHP, JavaScript, a.s.o. knows, that at some 
> point the user makes something wrong and you want to throw an error 
> ("Your email's not valid (MX-Record not set.)") or an information 
> ("You have logged in successfully.").
>
> Know I do this using <div id="error"> or <div id="info"> analogically.
>
> As errors or other direct responses to user interaction are not the 
> same as some different text, I think there should be a possibility to 
> mark them up appropriately.
>
> I first searched in the Spec for some existing elements for output, 
> but only found <samp> which is for sample output only.
>
> I don't quite know which element name to use best, maybe:
>
> <output>
> <output error> / <output info(rmation)>
> <output type="error"> / <output type="info(rmation)">
> (The question is, what is <output>, error or info?)
>
> What do you think?
First of all, an <output> element already exists :

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-output-element
"The output element represents the result of a calculation."

What I have understood about it is that it is a sort of opposite of the 
the <input> element. In HTML 4, in order to display results of 
calculations, authors used to have an <input readonly id="output"> which 
was kind of absurd. The current <output> element seems to be here to 
fill this gap.

Is it enough for your needs ?

David

From mpd at google.com  Fri Jan  8 08:49:35 2010
From: mpd at google.com (Michael Davidson)
Date: Fri, 8 Jan 2010 08:49:35 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant>
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
Message-ID: <63c0fecb1001080849l55355131wdf97ef2c92c03045@mail.gmail.com>

I don't have comments on the particulars, but I would love to see an easier
way to go from Canvas to XHR. We'd use it in Gmail for resizing/editing
photos before attaching or placing inline in an email.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100108/06093196/attachment.htm>

From dimich at google.com  Fri Jan  8 13:56:42 2010
From: dimich at google.com (Dmitry Titov)
Date: Fri, 8 Jan 2010 13:56:42 -0800
Subject: [whatwg] File API - does Blob 'track' the changes in the underlying
	file on the disk?
Message-ID: <28040fc61001081356x51969fc7i64435ef9692d392a@mail.gmail.com>

Hi,

Does the Blob, which is obtained as File (so it refers to an actual file on
disk) track the changes in the underlying file and 'mutates', or does it
represent the 'snapshot' of the file, or does it become 'invalid'?

Today, if a user selects a file using <input type=file>, and then the file
on the disk changes before the 'submit' is clicked, the form will submit the
latest version of the file.
This may be a surprisingly popular use case, when user submits a file via
form and wants to do 'last moment' changes in the file, after partial
pre-populating the form. It works 'intuitively' today.

Now, if the page decides to use XHR to upload the file, I think

var file = myInputElement.files[0];
var xhr = ...
xhr.send(file);

should also send the version of the file that exists at the moment of
xhr.send(file), not when user picked the file (for consistency with form
action).

Assuming this is desired behavior, what should the following do:

var file = myInputElement.files[0];
var blob = file.slice(0, file.size);
// ... now file on the disk changes ...
xhr.send(blob);

Will it:
- send the new version of the whole file (and update blob.size?)
- send captured number of bytes from the new version of the file (perhaps
truncated since file may be shorter now)
- send original bytes from the previous version of the file that existed
when Blob was created (sort of 'copy on write')
- throw exception
?


Thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100108/05435673/attachment.htm>

From dimich at google.com  Fri Jan  8 14:19:39 2010
From: dimich at google.com (Dmitry Titov)
Date: Fri, 8 Jan 2010 14:19:39 -0800
Subject: [whatwg] File API - does Blob 'track' the changes in the
	underlying file on the disk?
In-Reply-To: <28040fc61001081356x51969fc7i64435ef9692d392a@mail.gmail.com>
References: <28040fc61001081356x51969fc7i64435ef9692d392a@mail.gmail.com>
Message-ID: <28040fc61001081419g1d85241kbec6a3672fee6b5f@mail.gmail.com>

I think I should have used public-webapps maillist. File API is discussed
there. Sorry for spam.

On Fri, Jan 8, 2010 at 1:56 PM, Dmitry Titov <dimich at google.com> wrote:

> Hi,
>
> Does the Blob, which is obtained as File (so it refers to an actual file on
> disk) track the changes in the underlying file and 'mutates', or does it
> represent the 'snapshot' of the file, or does it become 'invalid'?
>
> Today, if a user selects a file using <input type=file>, and then the file
> on the disk changes before the 'submit' is clicked, the form will submit the
> latest version of the file.
> This may be a surprisingly popular use case, when user submits a file via
> form and wants to do 'last moment' changes in the file, after partial
> pre-populating the form. It works 'intuitively' today.
>
> Now, if the page decides to use XHR to upload the file, I think
>
> var file = myInputElement.files[0];
> var xhr = ...
> xhr.send(file);
>
> should also send the version of the file that exists at the moment of
> xhr.send(file), not when user picked the file (for consistency with form
> action).
>
> Assuming this is desired behavior, what should the following do:
>
> var file = myInputElement.files[0];
> var blob = file.slice(0, file.size);
> // ... now file on the disk changes ...
> xhr.send(blob);
>
> Will it:
> - send the new version of the whole file (and update blob.size?)
> - send captured number of bytes from the new version of the file (perhaps
> truncated since file may be shorter now)
> - send original bytes from the previous version of the file that existed
> when Blob was created (sort of 'copy on write')
> - throw exception
> ?
>
>
> Thanks,
> Dmitry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100108/a2a91560/attachment.htm>

From jonas at sicking.cc  Fri Jan  8 14:22:45 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 8 Jan 2010 14:22:45 -0800
Subject: [whatwg] File API - does Blob 'track' the changes in the
	underlying file on the disk?
In-Reply-To: <28040fc61001081356x51969fc7i64435ef9692d392a@mail.gmail.com>
References: <28040fc61001081356x51969fc7i64435ef9692d392a@mail.gmail.com>
Message-ID: <63df84f1001081422o36eef979j316f5533710babcb@mail.gmail.com>

On Fri, Jan 8, 2010 at 1:56 PM, Dmitry Titov <dimich at google.com> wrote:
> Hi,
> Does the Blob, which is obtained as File (so it refers to an actual file on
> disk) track the changes in the underlying file and 'mutates', or does it
> represent the 'snapshot' of the file, or does it become 'invalid'?
> Today, if a user selects a file using <input type=file>, and then the file
> on the disk changes before the 'submit' is clicked, the form will submit the
> latest version of the file.
> This may be a?surprisingly?popular use case, when user submits a file via
> form and?wants?to do 'last moment' changes in the file, after partial
> pre-populating the form. It works 'intuitively' today.
> Now, if the page decides to use XHR to upload the file, I think
> var file = myInputElement.files[0];
> var xhr = ...
> xhr.send(file);
> should also send the version of the file that exists at the moment of
> xhr.send(file), not when user picked the file (for consistency with form
> action).
> Assuming this is desired behavior, what should the following do:
> var file = myInputElement.files[0];
> var blob = file.slice(0, file.size);
> // ... now file on the disk changes ...
> xhr.send(blob);
> Will it:
> - send the new version of the whole file (and update blob.size?)
> - send captured number of bytes from the new version of the file (perhaps
> truncated since file may be shorter now)
> - send original bytes from the previous version of the file that existed
> when Blob was created (sort of 'copy on write')
> - throw exception
> ?

Technically, you should send this email to the webapps mailing list,
since that is where this spec is being developed.

That said, this is a really hard problem, and one that is hard to
test. One thing that we decided when we did security review on this
stuff at mozilla is that if a File object is ever passed cross origin
using postMessage, then the File object that the other origin has
should not work if the file is changed on disc. For some definition of
"not work".

/ Jonas

From whatwg at adambarth.com  Sat Jan  9 00:40:56 2010
From: whatwg at adambarth.com (Adam Barth)
Date: Sat, 9 Jan 2010 00:40:56 -0800
Subject: [whatwg] How do sandboxed iframes interact with localStorage /
	sessionStorage / databases / etc?
Message-ID: <7789133a1001090040j75b8e27aq28241bde38009315@mail.gmail.com>

The following question came up in implementing the sandbox attribute in WebKit:

[[
Description From Patrik Persson 2009-12-10 02:18:50 PST (-) [reply]
This is a followup to bug 21288, which concerned the implementation of
the HTML5 iframe sandbox attribute.

How should WebKit interpret the HTML5 spec regarding sandboxed storage
and databases?  I believe the HTML5 spec does not say much explicitly
on this, but rather relies on the origin sandboxing.  Here is my
interpretation.

* I think sessionStorage would make sense with sandboxed origins.

* I think localStorage would end up equivalent to sessionStorage in a
  sandboxed frame, making it somewhat less useful. (The unique origin
  of a sandboxed frame means, in my interpretation, that the same
  frame would not be able to access its own localStorage in another
  session.)

* Similarly, I think a sandboxed database would be useful only within
  a session.  The database could be reclaimed when the session ends.
  This defeats much of the purpose of databases, but perhaps it would
  still be useful for compatibility.

The current implementation disables storage and databases in sandboxed
frames.  There is some more discussion in the thread for bug 21288,
comments 43..49:
]] -- https://bugs.webkit.org/show_bug.cgi?id=32369

I think that disabling access to these APIs makes sense given that we
disable access to cookies.

Adam

From ian at hixie.ch  Sat Jan  9 02:12:29 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 9 Jan 2010 10:12:29 +0000 (UTC)
Subject: [whatwg] Switching to an unversioned development model
In-Reply-To: <Pine.LNX.4.62.0912111809190.29336@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0912111809190.29336@hixie.dreamhostps.com>
Message-ID: <Pine.LNX.4.62.1001090958360.17515@hixie.dreamhostps.com>


Just a quick update:

On Fri, 11 Dec 2009, Ian Hickson wrote:
> 
> Since the W3C is still focused on getting HTML5 to last call, I'll 
> maintain a WHATWG copy of the HTML spec that matches what the W3C HTML 
> WG is working on:
> 
>    http://www.whatwg.org/specs/web-apps/html5/

With the recent churn of modules in the HTML WG, in particular with the 
HTML WG's decision to publish Microdata separately from HTML5 (if at all), 
I've given up trying to keep a WHATWG copy of the HTML5 spec that matches 
what the W3C publish (it would have to be several documents, and that is a 
pain to maintain).

I'll continue to keep the WHATWG HTML draft a superset of the W3C draft, 
meaning that anything that's in HTML5 at the W3C will also be in the 
WHATWG HTML draft. Right now, the only thing that's in the WHATWG HTML 
draft only (and not in any other spec elsewhere) is the <device> element, 
which is purely experimental and might not go anywhere.

For people who were paying _really_ close attention, the separate WHATWG 
Microdata Vocabularies draft is also gone (the vocabularies are now 
defined in the WHATWG HTML spec itself again). I got rid of them as part 
of a simplification of the specs being generated, and because the W3C's 
equivalent specs were all merged into a single HTML5 Microdata subspec.


> I've updated the FAQ's explanation of what specs exist, in case you want 
> to get an overview (it's getting somewhat complicated!):
> 
>    http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F

Thanks to Lachy and others the entry above has been simplified and 
clarified a bit.


There's just over 1000 pending e-mails in the queue again (and we were at 
zero last October!), so over the next few months I hope to resume replying 
to these and get the number back down again. Right now my higher priority 
is dealing with the bugs filed in the W3C HTML WG's bug tracker, so if you 
have something urgent please either e-mail me to tell me, or file a bug 
and I'll get to it probably relatively soon.

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

From philipj at opera.com  Sat Jan  9 05:24:06 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Sat, 09 Jan 2010 14:24:06 +0100
Subject: [whatwg] Switching to an unversioned development model
In-Reply-To: <Pine.LNX.4.62.1001090958360.17515@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0912111809190.29336@hixie.dreamhostps.com>
	<Pine.LNX.4.62.1001090958360.17515@hixie.dreamhostps.com>
Message-ID: <op.u59ot8f4sr6mfa@worf>

On Sat, 09 Jan 2010 11:12:29 +0100, Ian Hickson <ian at hixie.ch> wrote:

>
> Just a quick update:
>
> On Fri, 11 Dec 2009, Ian Hickson wrote:
>>
>> Since the W3C is still focused on getting HTML5 to last call, I'll
>> maintain a WHATWG copy of the HTML spec that matches what the W3C HTML
>> WG is working on:
>>
>>    http://www.whatwg.org/specs/web-apps/html5/
>
> With the recent churn of modules in the HTML WG, in particular with the
> HTML WG's decision to publish Microdata separately from HTML5 (if at  
> all),
> I've given up trying to keep a WHATWG copy of the HTML5 spec that matches
> what the W3C publish (it would have to be several documents, and that is  
> a
> pain to maintain).
>
> I'll continue to keep the WHATWG HTML draft a superset of the W3C draft,
> meaning that anything that's in HTML5 at the W3C will also be in the
> WHATWG HTML draft. Right now, the only thing that's in the WHATWG HTML
> draft only (and not in any other spec elsewhere) is the <device> element,
> which is purely experimental and might not go anywhere.

That's unfortunate, but oh well. Is WHATWG HTML is intended to stay at  
"Working Draft" indefinitely, or does the spec status not really mean  
anything at this point?

> For people who were paying _really_ close attention, the separate WHATWG
> Microdata Vocabularies draft is also gone (the vocabularies are now
> defined in the WHATWG HTML spec itself again). I got rid of them as part
> of a simplification of the specs being generated, and because the W3C's
> equivalent specs were all merged into a single HTML5 Microdata subspec.

Yes, I was wondering if this was a bit of an accident or what. Is it the  
intention to keep these in the WHATWG HTML spec indefinitely and even add  
more vocabularies as they become needed/popular?

-- 
Philip J?genstedt
Core Developer
Opera Software

From bruant at enseirb-matmeca.fr  Sat Jan  9 10:13:02 2010
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Sat, 09 Jan 2010 10:13:02 -0800
Subject: [whatwg] Switching to an unversioned development model
In-Reply-To: <op.u59ot8f4sr6mfa@worf>
References: <Pine.LNX.4.62.0912111809190.29336@hixie.dreamhostps.com>	<Pine.LNX.4.62.1001090958360.17515@hixie.dreamhostps.com>
	<op.u59ot8f4sr6mfa@worf>
Message-ID: <4B48C72E.8030604@enseirb-matmeca.fr>

Le 09/01/2010 05:24, Philip J?genstedt a ?crit :
> On Sat, 09 Jan 2010 11:12:29 +0100, Ian Hickson <ian at hixie.ch> wrote:
>
>>
>> Just a quick update:
>>
>> On Fri, 11 Dec 2009, Ian Hickson wrote:
>>>
>>> Since the W3C is still focused on getting HTML5 to last call, I'll
>>> maintain a WHATWG copy of the HTML spec that matches what the W3C HTML
>>> WG is working on:
>>>
>>>    http://www.whatwg.org/specs/web-apps/html5/
>>
>> With the recent churn of modules in the HTML WG, in particular with the
>> HTML WG's decision to publish Microdata separately from HTML5 (if at 
>> all),
>> I've given up trying to keep a WHATWG copy of the HTML5 spec that 
>> matches
>> what the W3C publish (it would have to be several documents, and that 
>> is a
>> pain to maintain).
>>
>> I'll continue to keep the WHATWG HTML draft a superset of the W3C draft,
>> meaning that anything that's in HTML5 at the W3C will also be in the
>> WHATWG HTML draft. Right now, the only thing that's in the WHATWG HTML
>> draft only (and not in any other spec elsewhere) is the <device> 
>> element,
>> which is purely experimental and might not go anywhere.
>
> That's unfortunate, but oh well. Is WHATWG HTML is intended to stay at 
> "Working Draft" indefinitely, or does the spec status not really mean 
> anything at this point?

As said in the whatwg wiki "The point to all this is that you shouldn?t 
place too much weight on the status of the specification as a whole. You 
need to consider the stability and maturity level of each section 
individually. ".
However, I think I understand the underlying idea which is that if we 
keep adding things, the HTML5 spec will never reach the recommendation 
status (even for 2022).
The <device> element offers a very interesting potential. However, I 
have the impression that it will require years of work before having a 
first good "working draft" because of diversity of devices sorts and 
even devices serving the same purpose.
In my humble opinion, it would be wiser if the device element had its 
own separate specification and wasn't lost within an already almost one 
million pixels height spec.

While reading the whatwg wiki section "When will HTML5 be finished? ", I 
realized that it is currently hard for web authors to answer the 
question "what sections of the spec are at the 'Implemented and widely 
deployed' status ?"
It might be a good idea for communication around the HTML5 spec to keep 
an updated list of sections and subsections sorted by level of maturity. 
Another (complementary ?) idea would be to provide this information in 
the table of content by putting titles of sections/subsections in 
different colors (and/or background color). It would be a good way for 
people who are discovering HTML5 to understand what they are somehow 
"allowed" to use today.

Thanks,

David

From joepeck02 at gmail.com  Sat Jan  9 12:33:47 2010
From: joepeck02 at gmail.com (Joseph Pecoraro)
Date: Sat, 9 Jan 2010 15:33:47 -0500
Subject: [whatwg] Appcache feedback
In-Reply-To: <op.u44wncq464w2qv@annevk-t60>
References: <2FC9749E-E913-4831-9EB9-8C7FE6C669AC@gmail.com>
	<Pine.LNX.4.62.0912172116200.18249@hixie.dreamhostps.com>
	<op.u44wncq464w2qv@annevk-t60>
Message-ID: <8937C393-A7D5-4F14-BADE-A831DB6F7A2E@gmail.com>

> On Thu, 17 Dec 2009 22:44:01 +0100, Ian Hickson <ian at hixie.ch> wrote:
>> We could delay the application cache download process so that it doesn't
>> start until after the 'load' event has fired. Does anyone have an opinion
>> on this?

On Dec 17, 2009, at 5: 24PM, Michael Nordman wrote:
> I don't think we'd have to delay the update job, just the delivery of any
> events associated with the appcache until 'load' has happened to get the
> desired effect.

On Dec 18, 2009, at 7: 51AM, Anne van Kesteren wrote:
> I believe we (Opera) found this is what at least some implementations
> are doing now and we do this as well. What Michael suggested makes sense
> and I suppose as the effects are indistinguishable in the end that
> (delaying either the events or the download process) should be fine.

Mike's suggestion sounds good.

Is this in the queue to be added or could this have been forgotten about?
There was a change around the time this email thread occurred that
clarified that the download process should be performed in the
background, but nothing about the events.

- Joseph Pecoraro



From ian at hixie.ch  Sat Jan  9 13:50:27 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 9 Jan 2010 21:50:27 +0000 (UTC)
Subject: [whatwg] Switching to an unversioned development model
In-Reply-To: <4B48C72E.8030604@enseirb-matmeca.fr>
References: <Pine.LNX.4.62.0912111809190.29336@hixie.dreamhostps.com>
	<Pine.LNX.4.62.1001090958360.17515@hixie.dreamhostps.com>
	<op.u59ot8f4sr6mfa@worf> <4B48C72E.8030604@enseirb-matmeca.fr>
Message-ID: <Pine.LNX.4.62.1001092140550.17515@hixie.dreamhostps.com>

On Sat, 9 Jan 2010, Philip J?genstedt wrote:
> 
> Is WHATWG HTML is intended to stay at "Working Draft" indefinitely, or 
> does the spec status not really mean anything at this point?

The spec status is given by the little notes in the margins, which give 
the state of each section. This is unchanged; we've been using this method 
for over a year now. Anyone should feel free to keep those markers updated 
if they notice they are getting out of sync with reality.


> > For people who were paying _really_ close attention, the separate 
> > WHATWG Microdata Vocabularies draft is also gone (the vocabularies are 
> > now defined in the WHATWG HTML spec itself again). I got rid of them 
> > as part of a simplification of the specs being generated, and because 
> > the W3C's equivalent specs were all merged into a single HTML5 
> > Microdata subspec.
> 
> Yes, I was wondering if this was a bit of an accident or what. Is it the 
> intention to keep these in the WHATWG HTML spec indefinitely and even 
> add more vocabularies as they become needed/popular?

I expect we'll figure this out as Microdata gets deployed -- it may be 
that Microdata gets deployed widely but that nobody really uses standard 
vocabularies, such that we don't need them at all, or it may be that 
standard vocabularies are the main way it gets used, in which case it 
makes sense to have them right there with the microdata spec, or it may be 
that they are used occasionally but only as a small part of a wider set of 
vocabularies, in which case authors would benefit more from them being 
independent of the main spec, etc. I guess we'll play this by ear.


On Sat, 9 Jan 2010, David Bruant wrote:
> 
> As said in the whatwg wiki "The point to all this is that you shouldn?t
> place too much weight on the status of the specification as a whole. You need
> to consider the stability and maturity level of each section individually. ".

Indeed.


> However, I think I understand the underlying idea which is that if we keep
> adding things, the HTML5 spec will never reach the recommendation status (even
> for 2022).

At this point, the snapshot that is HTML_5_ is being driven through the 
more formal "WD", "LC", "CR", "REC" status by the W3C, and excludes the 
newer additions (specifically currently <device>).


> The <device> element offers a very interesting potential. However, I 
> have the impression that it will require years of work before having a 
> first good "working draft" because of diversity of devices sorts and 
> even devices serving the same purpose.

Actually right now the main blocker is the lack of a good common video 
codec (that old chestnut again!). There's not much point having it without 
a common codec -- if it's unlikely that static video providers will 
provide two or more video formats, it's even more unlikely that sites will 
be ready to do on-the-fly transcoding for video-conferencing.


> In my humble opinion, it would be wiser if the device element had its 
> own separate specification and wasn't lost within an already almost one 
> million pixels height spec.

If <device> turns out to be a good idea that works, then I think it will 
benefit from being defined along with all the other parts of HTML. When 
writing Web Forms 2, we found that it was really inconvenient for everyone 
for content to be split across multiple independent specs.


> While reading the whatwg wiki section "When will HTML5 be finished? ", I 
> realized that it is currently hard for web authors to answer the 
> question "what sections of the spec are at the 'Implemented and widely 
> deployed' status ?" It might be a good idea for communication around the 
> HTML5 spec to keep an updated list of sections and subsections sorted by 
> level of maturity. Another (complementary ?) idea would be to provide 
> this information in the table of content by putting titles of 
> sections/subsections in different colors (and/or background color). It 
> would be a good way for people who are discovering HTML5 to understand 
> what they are somehow "allowed" to use today.

Agreed. If anyone wants to volunteer to either maintain such a list or 
make changes to the status.js script to annotate the spec in such a way, I 
would be more than happy to help out. Please let me know!

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

From willeom at gmail.com  Sat Jan  9 18:53:22 2010
From: willeom at gmail.com (will surgent)
Date: Sat, 9 Jan 2010 21:53:22 -0500
Subject: [whatwg] img copyright attribute
Message-ID: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>

It would be nice if there was a copyright attribute for the HTML 5 img tag.
This would make it easy for users and search engines to filter out images
that can not be used for certain purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100109/8d11b5e1/attachment.htm>

From jonnybarnes at gmail.com  Sat Jan  9 19:10:31 2010
From: jonnybarnes at gmail.com (Jonny Barnes)
Date: Sun, 10 Jan 2010 03:10:31 +0000
Subject: [whatwg] img copyright attribute
In-Reply-To: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
Message-ID: <b8c4b2ae1001091910w72141685qabcac73ae6931171@mail.gmail.com>

2010/1/10 will surgent <willeom at gmail.com>:
> It would be nice if there was a copyright attribute for the HTML 5 img tag.
> This would make it easy for users and search engines to filter out images
> that can not be used for certain purposes.
>

Or maybe a license attribute instead, that would include copyrighted
work and stuff licensed under some CC or alternative.

From remco47 at gmail.com  Sat Jan  9 19:20:37 2010
From: remco47 at gmail.com (Remco)
Date: Sun, 10 Jan 2010 04:20:37 +0100
Subject: [whatwg] img copyright attribute
In-Reply-To: <b8c4b2ae1001091910w72141685qabcac73ae6931171@mail.gmail.com>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
	<b8c4b2ae1001091910w72141685qabcac73ae6931171@mail.gmail.com>
Message-ID: <36a11a3a1001091920p41bcf31epcd6469bbc0c98805@mail.gmail.com>

On Sun, Jan 10, 2010 at 04:10, Jonny Barnes <jonnybarnes at gmail.com> wrote:
> 2010/1/10 will surgent <willeom at gmail.com>:
>> It would be nice if there was a copyright attribute for the HTML 5 img tag.
>> This would make it easy for users and search engines to filter out images
>> that can not be used for certain purposes.
>>
>
> Or maybe a license attribute instead, that would include copyrighted
> work and stuff licensed under some CC or alternative.
>

That's also copyright.

-- 
Remco

From ian at hixie.ch  Sat Jan  9 20:18:22 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 10 Jan 2010 04:18:22 +0000 (UTC)
Subject: [whatwg] Appcache feedback
In-Reply-To: <8937C393-A7D5-4F14-BADE-A831DB6F7A2E@gmail.com>
References: <2FC9749E-E913-4831-9EB9-8C7FE6C669AC@gmail.com>
	<Pine.LNX.4.62.0912172116200.18249@hixie.dreamhostps.com>
	<op.u44wncq464w2qv@annevk-t60>
	<8937C393-A7D5-4F14-BADE-A831DB6F7A2E@gmail.com>
Message-ID: <Pine.LNX.4.62.1001100414210.17515@hixie.dreamhostps.com>

On Sat, 9 Jan 2010, Joseph Pecoraro wrote:
>
> > On Thu, 17 Dec 2009 22:44:01 +0100, Ian Hickson <ian at hixie.ch> wrote:
> >> We could delay the application cache download process so that it doesn't
> >> start until after the 'load' event has fired. Does anyone have an opinion
> >> on this?
> 
> On Dec 17, 2009, at 5: 24PM, Michael Nordman wrote:
> > I don't think we'd have to delay the update job, just the delivery of any
> > events associated with the appcache until 'load' has happened to get the
> > desired effect.
> 
> On Dec 18, 2009, at 7: 51AM, Anne van Kesteren wrote:
> > I believe we (Opera) found this is what at least some implementations
> > are doing now and we do this as well. What Michael suggested makes sense
> > and I suppose as the effects are indistinguishable in the end that
> > (delaying either the events or the download process) should be fine.
> 
> Mike's suggestion sounds good.
> 
> Is this in the queue to be added or could this have been forgotten about?
> There was a change around the time this email thread occurred that
> clarified that the download process should be performed in the
> background, but nothing about the events.

It's in the queue -- sorry for the delay in answering e-mails; I'm trying 
to get through the W3C HTML WG Bugzilla queue first, and that is taking 
longer than I expected.

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

From Simetrical+w3c at gmail.com  Sat Jan  9 20:41:52 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sat, 9 Jan 2010 23:41:52 -0500
Subject: [whatwg] img copyright attribute
In-Reply-To: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
Message-ID: <7c2a12e21001092041v73843d6ei39e3b405191de859@mail.gmail.com>

On Sat, Jan 9, 2010 at 9:53 PM, will surgent <willeom at gmail.com> wrote:
> It would be nice if there was a copyright attribute for the HTML 5 img tag.
> This would make it easy for users and search engines to filter out images
> that can not be used for certain purposes.

This is one of the things microdata/RDFa are meant to do.

From bruant at enseirb-matmeca.fr  Sat Jan  9 22:26:49 2010
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Sat, 09 Jan 2010 22:26:49 -0800
Subject: [whatwg] Comment about "6.11.8 Navigating to a fragment identifier"
Message-ID: <4B497329.9090903@enseirb-matmeca.fr>

Hi,

My comments refer to what is after the "the indicated part of the 
document" definition 
(http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document)

- There is a reference to the RFC3023 that may require a link to the 
reference section

- Step 4 of the algorithm begins with "If this step was not skipped". I 
am probably kind of niggling here (and I am sorry if it is the case), 
but, in my humble opinion, this beginning is not necessary.

- Step 6 : while there is not "the", I think that "indicated part of the 
document" should be a link to the definition of "the indicated part of 
the document".

David

From magneto4u at gmail.com  Sun Jan 10 01:24:48 2010
From: magneto4u at gmail.com (Dawid Czyzewski)
Date: Sun, 10 Jan 2010 10:24:48 +0100
Subject: [whatwg] img copyright attribute
Message-ID: <fa8a06371001100124ye628b80oa9925ebe11b50f58@mail.gmail.com>

>On Sun, Jan 10, 2010 at 04:10, Jonny Barnes <jonnybarnes at gmail.com <http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>> wrote:
>>* 2010/1/10 will surgent <willeom at gmail.com <http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>>:
*>>>* It would be nice if there was a copyright attribute for the HTML
5 img tag.
*>>>* This would make it easy for users and search engines to filter out images
*>>>* that can not be used for certain purposes.
*>>*
*>>*
*>>* Or maybe a license attribute instead, that would include copyrighted
*>>* work and stuff licensed under some CC or alternative.
*>>*
*>
>That's also copyright.

Well, not exactly, in such attribute you could also enter copyleft
licensees (such as GPL), as also "public domain", so
*"license" sounds more proper for this.*
And why img only? this would also be good for audio and video.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100110/9bd8f1df/attachment-0001.htm>

From philipj at opera.com  Sun Jan 10 01:26:24 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Sun, 10 Jan 2010 10:26:24 +0100
Subject: [whatwg] img copyright attribute
In-Reply-To: <7c2a12e21001092041v73843d6ei39e3b405191de859@mail.gmail.com>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
	<7c2a12e21001092041v73843d6ei39e3b405191de859@mail.gmail.com>
Message-ID: <op.u6a8ia1ssr6mfa@worf>

On Sun, 10 Jan 2010 05:41:52 +0100, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> On Sat, Jan 9, 2010 at 9:53 PM, will surgent <willeom at gmail.com> wrote:
>> It would be nice if there was a copyright attribute for the HTML 5 img  
>> tag.
>> This would make it easy for users and search engines to filter out  
>> images
>> that can not be used for certain purposes.
>
> This is one of the things microdata/RDFa are meant to do.
>

http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#examples-4

-- 
Philip J?genstedt
Core Developer
Opera Software

From willeom at gmail.com  Sun Jan 10 15:55:18 2010
From: willeom at gmail.com (will surgent)
Date: Sun, 10 Jan 2010 18:55:18 -0500
Subject: [whatwg] img copyright attribute
In-Reply-To: <op.u6a8ia1ssr6mfa@worf>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
	<7c2a12e21001092041v73843d6ei39e3b405191de859@mail.gmail.com>
	<op.u6a8ia1ssr6mfa@worf>
Message-ID: <c43b24a21001101555p54f2b0afva4e5693cbac57e70@mail.gmail.com>

Hmm I didn't know about that. Thanks!

On Sun, Jan 10, 2010 at 4:26 AM, Philip J?genstedt <philipj at opera.com>wrote:

> On Sun, 10 Jan 2010 05:41:52 +0100, Aryeh Gregor <Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>>
> wrote:
>
>  On Sat, Jan 9, 2010 at 9:53 PM, will surgent <willeom at gmail.com> wrote:
>>
>>> It would be nice if there was a copyright attribute for the HTML 5 img
>>> tag.
>>> This would make it easy for users and search engines to filter out images
>>> that can not be used for certain purposes.
>>>
>>
>> This is one of the things microdata/RDFa are meant to do.
>>
>>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#examples-4
>
> --
> Philip J?genstedt
> Core Developer
> Opera Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100110/11a310b2/attachment.htm>

From mjs at apple.com  Mon Jan 11 06:59:31 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Mon, 11 Jan 2010 06:59:31 -0800
Subject: [whatwg] HTML5 and different versions of the document
Message-ID: <C467BEB1-DFE2-4AEB-A8E2-7F7B88806C25@apple.com>


With the change to an unversioned development model, we now have a  
number of HTML5-related specs with different names and versions. In  
particular, the HTML5 spec link on the whatwg.org front page links to <http://www.whatwg.org/specs/web-apps/current-work/multipage/ 
 >, which used to be called "WHATWG HTML" but now is called "HTML5  
(including next generation additions still in development)".

In my opinion, it would be helpful if the WHATWG had a document called  
HTML5 that largely matched the W3C copy in scope and content, and a  
separate document that included whatever future additions and  
extensions we care to add. Having a matching document in WHATWG space  
would be helpful for a couple of reasons:

- Reduces potential for confusion about what HTML5 is.
- Makes clear what parts of the WHATWG document are also protected  
(via the W3C copy) by the W3C Patent Policy.
- Because the WHATWG copy is currently licensed under much more  
liberal terms than the W3C copy, it would be helpful to have a  
matching copy in WHATWG space to use as a basis for excerpts in  
conformance checkers, implementations, third-party reference materials  
and the like.

Logically speaking, it probably makes more sense for the "current- 
work" URL to point to the latest and greatest unversioned copy, but on  
the other hand many people already think of this URL as pointing to  
HTML5. The HTML5 link on the front page should, I think, point to  
something that actually contains HTML5, with a separate "future  
development" link.

Regards,
Maciej


From willeom at gmail.com  Mon Jan 11 10:40:12 2010
From: willeom at gmail.com (will surgent)
Date: Mon, 11 Jan 2010 13:40:12 -0500
Subject: [whatwg] img copyright attribute
In-Reply-To: <fa8a06371001100124ye628b80oa9925ebe11b50f58@mail.gmail.com>
References: <fa8a06371001100124ye628b80oa9925ebe11b50f58@mail.gmail.com>
Message-ID: <c43b24a21001111040ybdc3f31vff2ef0da570a3e6b@mail.gmail.com>

That sounds like good idea (about the audio and video elements being
included as-well). I just thought of it because Google does not allow one to
specify the copyright or license in an image search as far as I know. having
a license attribute would make it intuitive for developers to add the
license the same way title and alt attributes are specified.

On Sun, Jan 10, 2010 at 4:24 AM, Dawid Czyzewski <magneto4u at gmail.com>wrote:

> >On Sun, Jan 10, 2010 at 04:10, Jonny Barnes <jonnybarnes at gmail.com <http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>> wrote:
>
> >>* 2010/1/10 will surgent <willeom at gmail.com <http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>>:
> *>>>* It would be nice if there was a copyright attribute for the HTML 5 img tag.
> *>>>* This would make it easy for users and search engines to filter out images
> *>>>* that can not be used for certain purposes.
>
> *>>*
> *>>*
> *>>* Or maybe a license attribute instead, that would include copyrighted
> *>>* work and stuff licensed under some CC or alternative.
> *>>*
> *>
>
>
> >That's also copyright.
>
> Well, not exactly, in such attribute you could also enter copyleft licensees (such as GPL), as also "public domain", so
> *"license" sounds more proper for this.*
>
>
> And why img only? this would also be good for audio and video.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100111/4f752a53/attachment.htm>

From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Jan 11 10:45:27 2010
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Mon, 11 Jan 2010 19:45:27 +0100
Subject: [whatwg] img copyright attribute
In-Reply-To: <c43b24a21001111040ybdc3f31vff2ef0da570a3e6b@mail.gmail.com>
References: <fa8a06371001100124ye628b80oa9925ebe11b50f58@mail.gmail.com>
	<c43b24a21001111040ybdc3f31vff2ef0da570a3e6b@mail.gmail.com>
Message-ID: <20100111194527.565a9db5@desudesudesu>

will surgent <willeom at gmail.com> schrieb am Mon, 11 Jan 2010 13:40:12
-0500:

> That sounds like good idea (about the audio and video elements being
> included as-well). I just thought of it because Google does not allow
> one to specify the copyright or license in an image search as far as
> I know. having a license attribute would make it intuitive for
> developers to add the license the same way title and alt attributes
> are specified.

Okay, so there is HTML5 Microdata and RDFa that does this (and more).
If you didn't know, you can specify a license for content with
@rel=license also. What else exactly do you need ?


Cheers
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100111/799c55ee/attachment.pgp>

From brucel at opera.com  Mon Jan 11 14:29:47 2010
From: brucel at opera.com (Bruce Lawson)
Date: Mon, 11 Jan 2010 22:29:47 -0000
Subject: [whatwg] Question about header and footer
Message-ID: <op.u6d3fxknh8on37@bruce-pc>

Is it permissible for one element to have more than one child headers, or
more than one child footers?

And, if is permissible, should it be?



Bruce Lawson
www.brucelawson.co.uk
-------------------------

sent from my ZX80

From ian at hixie.ch  Mon Jan 11 15:58:32 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 11 Jan 2010 23:58:32 +0000 (UTC)
Subject: [whatwg] HTML5 and different versions of the document
In-Reply-To: <C467BEB1-DFE2-4AEB-A8E2-7F7B88806C25@apple.com>
References: <C467BEB1-DFE2-4AEB-A8E2-7F7B88806C25@apple.com>
Message-ID: <Pine.LNX.4.62.1001112348020.13493@hixie.dreamhostps.com>

On Mon, 11 Jan 2010, Maciej Stachowiak wrote:
> 
> With the change to an unversioned development model, we now have a 
> number of HTML5-related specs with different names and versions. In 
> particular, the HTML5 spec link on the whatwg.org front page links to 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/>, which 
> used to be called "WHATWG HTML" but now is called "HTML5 (including next 
> generation additions still in development)".
> 
> In my opinion, it would be helpful if the WHATWG had a document called 
> HTML5 that largely matched the W3C copy in scope and content, and a 
> separate document that included whatever future additions and extensions 
> we care to add.

The problem is that the W3C copy doesn't include everything that is HTML5. 
For example, it excludes Microdata, which is an integral part of HTML5. So 
it's not clear exactly what to generate -- should I make WHATWG copies of 
every W3C draft that comes from the WHATWG source document? That would 
double the time it takes to check things in (which already takes a long 
time), for specs which nobody is ever going to need.


> Having a matching document in WHATWG space would be helpful for a couple 
> of reasons:
> 
> - Reduces potential for confusion about what HTML5 is.

The best way to do that would be for the W3C HTML WG to not split HTML5 
into multiple specs. Then it would be easy to have and maintain parallel 
copies -- indeed we did have a parallel copy before the recent splits.


> - Makes clear what parts of the WHATWG document are also protected (via 
> the W3C copy) by the W3C Patent Policy.

Everything in the WHATWG drafts has a corresponding W3C draft.


> - Because the WHATWG copy is currently licensed under much more liberal terms
> than the W3C copy, it would be helpful to have a matching copy in WHATWG space
> to use as a basis for excerpts in conformance checkers, implementations,
> third-party reference materials and the like.

The complete.html file includes all that text under the WHATWG license.


> Logically speaking, it probably makes more sense for the "current-work" 
> URL to point to the latest and greatest unversioned copy, but on the 
> other hand many people already think of this URL as pointing to HTML5. 
> The HTML5 link on the front page should, I think, point to something 
> that actually contains HTML5, with a separate "future development" link.

HTML5 is yesterday's news. I'm fine with using the buzzword if people feel 
that is helpful, but I disagree that we would want people looking at the 
last generation of specs. Right now, there's very little new stuff, but it 
seems highly likely that we will get lots of new features going forward, 
and it would be silly to push them off into a corner.

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

From ian at hixie.ch  Mon Jan 11 18:41:31 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Jan 2010 02:41:31 +0000 (UTC)
Subject: [whatwg] Comments on @sandbox
In-Reply-To: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com>
References: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.1001120240280.8484@hixie.dreamhostps.com>

On Thu, 5 Nov 2009, Adam Barth wrote:
> 
> == allow-same-origin + allow-script ==
> 
> It's clear that adding both allow-same-origin and allow-script to 
> @sandbox at the same time make the sandbox useless because the sandboxed 
> content can simply reach outside the frame and remove the sandbox 
> attribute.  Should we disallow setting these values at the same time?  
> If an author does set both, maybe we should only pay attention to one?

Done. allow-same-origin now overrides allow-scripts.

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

From ian at hixie.ch  Mon Jan 11 18:45:21 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Jan 2010 02:45:21 +0000 (UTC)
Subject: [whatwg] Comments on @sandbox
In-Reply-To: <Pine.LNX.4.62.1001120240280.8484@hixie.dreamhostps.com>
References: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com>
	<Pine.LNX.4.62.1001120240280.8484@hixie.dreamhostps.com>
Message-ID: <Pine.LNX.4.62.1001120243190.13493@hixie.dreamhostps.com>

On Tue, 12 Jan 2010, Ian Hickson wrote:
>
> On Thu, 5 Nov 2009, Adam Barth wrote:
> > 
> > == allow-same-origin + allow-script ==
> > 
> > It's clear that adding both allow-same-origin and allow-script to 
> > @sandbox at the same time make the sandbox useless because the 
> > sandboxed content can simply reach outside the frame and remove the 
> > sandbox attribute.  Should we disallow setting these values at the 
> > same time?  If an author does set both, maybe we should only pay 
> > attention to one?
>
> Done. allow-same-origin now overrides allow-scripts.

Er, sorry. That was a momentary lapse of attention. I've reverted this 
change.

allow-same-origin and allow-scripts can be usefully set together when the 
origin of the embedded page is not the same as the origin of the embedding 
page. I'll add a warning about it being somewhat pointless to use them 
together in same-origin cases, though.

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

From ian at hixie.ch  Tue Jan 12 00:16:36 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Jan 2010 08:16:36 +0000 (UTC)
Subject: [whatwg] Comments on @sandbox
In-Reply-To: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com>
References: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.1001120256530.8484@hixie.dreamhostps.com>

On Thu, 5 Nov 2009, Adam Barth wrote:
> 
> One interesting feature of @sandbox is that the hosting page can change 
> the value of the sandbox attribute.  Even though it's clear that having 
> both allow-same-origin and allow-script at the *same* time lets the 
> sandboxed content escape, it's probably less clear to folks that first 
> setting allow-same-origin and then removing it and adding allow-script 
> is also very dangerous.
> 
> The reason is slightly subtle.  Essentially, when the frame is in the 
> allow-same-origin mode, it is very easy for the outer document to leak a 
> JavaScript object into the DOM of the inner document.  Then, when the 
> frame enters the allow-script phase, the document can abuse the leaked 
> object to XSS the outer page, as described in 
> http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf>.
> 
> The reverse sequence is also dangerous because the inner page could use 
> the techniques in this paper 
> <http://www.adambarth.com/papers/2009/adida-barth-jackson.pdf> to build 
> a fake DOM during the allow-scripts phase and confuse the outer page 
> into XSSing itself in the allow-same-origin phase.
> 
> To avoid these subtle traps for developers, I recommend to freezing the 
> privileges of a sandboxed document at the time the document is loaded 
> into the frame.

Done.

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

From lachlan.hunt at lachy.id.au  Tue Jan 12 01:19:04 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 12 Jan 2010 10:19:04 +0100
Subject: [whatwg] Question about header and footer
In-Reply-To: <op.u6d3fxknh8on37@bruce-pc>
References: <op.u6d3fxknh8on37@bruce-pc>
Message-ID: <4B4C3E88.4050706@lachy.id.au>

Bruce Lawson wrote:
> Is it permissible for one element to have more than one child headers, or
> more than one child footers?

Yes.

> And, if is permissible, should it be?

Unless we have a very good reason, I don't think we should start placing 
arbitrary restrictions on how elements can be used.  In fact, there's a 
very good reason to allow footers to be used more than once per section, 
as illustrated by the first footer element example in the spec.  I don't 
believe it's a problem for multiple headers either as the sectioning 
algorithm will create implied sections from the headings anyway.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

From brucel at opera.com  Tue Jan 12 01:40:25 2010
From: brucel at opera.com (Bruce Lawson)
Date: Tue, 12 Jan 2010 09:40:25 -0000
Subject: [whatwg] Question about header and footer
In-Reply-To: <4B4C3E88.4050706@lachy.id.au>
References: <op.u6d3fxknh8on37@bruce-pc> <4B4C3E88.4050706@lachy.id.au>
Message-ID: <op.u6eyhnhmh8on37@bruce-pc>

On Tue, 12 Jan 2010 09:19:04 -0000, Lachlan Hunt  
<lachlan.hunt at lachy.id.au> wrote:

> Bruce Lawson wrote:
>> Is it permissible for one element to have more than one child headers,  
>> or
>> more than one child footers?
>
> Yes.
>
>> And, if is permissible, should it be?
>
> Unless we have a very good reason, I don't think we should start placing  
> arbitrary restrictions on how elements can be used.  In fact, there's a  
> very good reason to allow footers to be used more than once per section,  
> as illustrated by the first footer element example in the spec.  I don't  
> believe it's a problem for multiple headers either as the sectioning  
> algorithm will create implied sections from the headings anyway.

Makes sense. Thanks Lachy.

b


-- 
Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)
www.twitter.com/brucel

From ian at hixie.ch  Tue Jan 12 03:47:27 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Jan 2010 11:47:27 +0000 (UTC)
Subject: [whatwg] Comments on @sandbox
In-Reply-To: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com>
References: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.1001121145550.8484@hixie.dreamhostps.com>

On Thu, 5 Nov 2009, Adam Barth wrote:
> 
> If a page contains a sandboxed frame, the document contained in the 
> frame is only sandboxed because the user encountered the document via 
> the frame.  If the use encounters the same document directly (e.g., in a 
> top-level browsing context), then the document will not be sandboxed.
> 
> I recommend letting servers deliver the sandbox policy both via the 
> sandbox attribute and via an HTTP header.  The value of the HTTP header 
> approach is that the document will be sandboxed in whatever context the 
> user agent loads the document.  For various esoteric reasons, I wrote up 
> a description of how this might work on Mozilla's Wiki: 
> <https://wiki.mozilla.org/Security/CSP/Sandbox>.

Based on our discussion, and inspired by Helen Wang's proposal, I've 
introduced a new MIME type text/sandboxed-html for this case. I expect CSP 
will make this more powerful going forward, but CSP doesn't solve the 
problem for legacy browsers, which this does.


(I'll be doing more work on sandbox="" in the near future. Sorry for not 
getting through all the backlog today.)

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

From timeless at gmail.com  Tue Jan 12 06:06:55 2010
From: timeless at gmail.com (timeless)
Date: Tue, 12 Jan 2010 16:06:55 +0200
Subject: [whatwg] img copyright attribute
In-Reply-To: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
Message-ID: <26b395e61001120606m26705c33j2f9e99c1cfede463@mail.gmail.com>

On Sun, Jan 10, 2010 at 4:53 AM, will surgent <willeom at gmail.com> wrote:
> It would be nice if there was a copyright attribute for the HTML 5 img tag.
> This would make it easy for users and search engines to filter out images
> that can not be used for certain purposes.

external metadata on copyright is a disaster. it gets lost immediately.

GIF and friends have supported embedding (c) into images for decades.

As google is fully capable of caching images (and obviously does so),
I question how adding a tag to html will solve a problem which is
already solved by the native image formats themselves.

For lack of a more useful reference about comment fields, i'll just
point to one application which is aware of them (although at the time
of the posting it only supported them for certain image types):
http://www.group42.com/ts-wi04.htm

From singer at apple.com  Tue Jan 12 09:46:09 2010
From: singer at apple.com (David Singer)
Date: Tue, 12 Jan 2010 09:46:09 -0800
Subject: [whatwg] img copyright attribute
In-Reply-To: <26b395e61001120606m26705c33j2f9e99c1cfede463@mail.gmail.com>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
	<26b395e61001120606m26705c33j2f9e99c1cfede463@mail.gmail.com>
Message-ID: <68C4C967-53D5-433B-99FE-C4234FDCD131@apple.com>

And it is worth saying that a copyright notice is not a license.  "Copyright Martin Luther 1517" doesn't tell you anything at all about what permissions Martin is granting you.  And rights permissions languages are much more complex...

On Jan 12, 2010, at 6:06 , timeless wrote:

> On Sun, Jan 10, 2010 at 4:53 AM, will surgent <willeom at gmail.com> wrote:
>> It would be nice if there was a copyright attribute for the HTML 5 img tag.
>> This would make it easy for users and search engines to filter out images
>> that can not be used for certain purposes.
> 
> external metadata on copyright is a disaster. it gets lost immediately.
> 
> GIF and friends have supported embedding (c) into images for decades.
> 
> As google is fully capable of caching images (and obviously does so),
> I question how adding a tag to html will solve a problem which is
> already solved by the native image formats themselves.
> 
> For lack of a more useful reference about comment fields, i'll just
> point to one application which is aware of them (although at the time
> of the posting it only supported them for certain image types):
> http://www.group42.com/ts-wi04.htm

David Singer
Multimedia and Software Standards, Apple Inc.


From nzakas at yahoo-inc.com  Tue Jan 12 11:48:12 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Tue, 12 Jan 2010 11:48:12 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <63df84f1001071309l6b78ed89q1269026dfb3035ed@mail.gmail.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u4015j0xidj3kv@simon-pieterss-macbook.local>
	<63df84f0912160821t16080bd5q5c81ba5a49ee517d@mail.gmail.com>
	<op.u43ra1q0idj3kv@simon-pieterss-macbook.local>
	<op.u43zcikfidj3kv@simon-pieterss-macbook.local>
	<op.u44pvzh3idj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D768@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u5azuv1xidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AD57@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AF4A@SNV-EXVS09.ds.corp.yahoo.com>
	<63df84f1001071309l6b78ed89q1269026dfb3035ed@mail.gmail.com>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0443B21B@SNV-EXVS09.ds.corp.yahoo.com>

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:jonas at sicking.cc] 
Sent: Thursday, January 07, 2010 1:09 PM
To: Nicholas Zakas
Cc: Simon Pieters; Maciej Stachowiak; whatwg at 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 <nzakas at 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

From ian at hixie.ch  Tue Jan 12 14:21:07 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 12 Jan 2010 22:21:07 +0000 (UTC)
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0443B21B@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u4015j0xidj3kv@simon-pieterss-macbook.local>
	<63df84f0912160821t16080bd5q5c81ba5a49ee517d@mail.gmail.com>
	<op.u43ra1q0idj3kv@simon-pieterss-macbook.local>
	<op.u43zcikfidj3kv@simon-pieterss-macbook.local>
	<op.u44pvzh3idj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D768@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u5azuv1xidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AD57@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AF4A@SNV-EXVS09.ds.corp.yahoo.com>
	<63df84f1001071309l6b78ed89q1269026dfb3035ed@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443B21B@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <Pine.LNX.4.62.1001122219190.17804@hixie.dreamhostps.com>

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.   `._.-(,_..'--(,_..'`-.;.'

From mpd at google.com  Tue Jan 12 15:16:10 2010
From: mpd at google.com (Michael Davidson)
Date: Tue, 12 Jan 2010 15:16:10 -0800
Subject: [whatwg] dataTransfer on drag events
Message-ID: <63c0fecb1001121516h590532cai8ea1116687e08652@mail.gmail.com>

Hi folks -

The table in section 7.9.3 says that the DataTransfer object should be empty
for dragenter and dragover events.

Clearly this is not the case - the example in 7.9.1 shows that, at the very
least, the DataTransfer object needs to have a 'types' attribute so that the
drag handler can determine if it can accept the drag.

The issue that I'm having is that if the DataTransfer object says that it
has Files, I have no way to determine what type those files are. (In this
case, I only want to accept image files.) I understand that the DataTransfer
shouldn't have the content of the files for security reasons, but it would
be helpful if it did contain the file names and/or MIME types.

In any case, can the table be updated to at least reflect reality (that
DataTransfer does contain 'types' and is not empty)?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100112/290f2407/attachment.htm>

From darin at chromium.org  Tue Jan 12 15:54:19 2010
From: darin at chromium.org (Darin Fisher)
Date: Tue, 12 Jan 2010 15:54:19 -0800
Subject: [whatwg] question about the popstate event
In-Reply-To: <c84706c71001051855x35410e25o35b321bb792996e7@mail.gmail.com>
References: <bd8f24d21001051653y66363bado7e0adad517b2114@mail.gmail.com>
	<c84706c71001051855x35410e25o35b321bb792996e7@mail.gmail.com>
Message-ID: <bd8f24d21001121554r640a3fe3jc57b9760eea19049@mail.gmail.com>

Hi,

I've been discussing this issue with Brady Eidson over at
https://bugs.webkit.org/show_bug.cgi?id=33224,
and his interpretation appears to be different.  (I think he may have
convinced me too.)

I'd really like some help understanding how pushState is intended to work
and to see how that lines up
with the spec.

Also, assuming Brady is correct, then I wonder why pushState was designed
this way.  It seems strange
to me that entries in session history would disappear when you navigate away
from a document that used
pushState.

-Darin


On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar <justin.lebar at gmail.com> wrote:

> > From my reading of the spec, I would expect the following steps:
> > 5. Page A is loaded.
> > 6. The load event for Page A is dispatched.
> > 7. The popstate event for Page A is dispatched.
>
> I think this is correct.  A popstate event is always dispatched
> whenever a new session history entry is activated (6.10.3).
>
> -Justin
>
> On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher <darin at chromium.org> wrote:
> > I'd like to make sure that I'm understanding the spec for pushState and
> the
> > popstate event properly.
> > Suppose, I have the following sequence of events:
> > 1. Page A is loaded.
> > 2. Page A calls pushState("foo", null).
> > 3. The user navigates to Page B.
> > 4. The user navigates back to Page A (clicks the back button once).
> > Assuming the document of Page A was disposed upon navigation to Page B
> > (i.e., that it was not preserved in a page cache), should a popstate
> event
> > be generated as a result of step 4?
> > From my reading of the spec, I would expect the following steps:
> > 5. Page A is loaded.
> > 6. The load event for Page A is dispatched.
> > 7. The popstate event for Page A is dispatched.
> > Do I understand correctly?
> > Thanks,
> > -Darin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100112/b74160dc/attachment.htm>

From dcheng at google.com  Tue Jan 12 16:00:36 2010
From: dcheng at google.com (Daniel Cheng)
Date: Tue, 12 Jan 2010 16:00:36 -0800
Subject: [whatwg] HTML5 cut/copy
Message-ID: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>

http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard

The current spec says that drop events should be fired while handling
copy/cut operations. Is this intended? The clipboard is not a DOM element;
it seems like it'd make sense only to fire the drop event for pastes.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100112/8b501ace/attachment.htm>

From nzakas at yahoo-inc.com  Tue Jan 12 16:05:42 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Tue, 12 Jan 2010 16:05:42 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <Pine.LNX.4.62.1001122219190.17804@hixie.dreamhostps.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u4015j0xidj3kv@simon-pieterss-macbook.local>
	<63df84f0912160821t16080bd5q5c81ba5a49ee517d@mail.gmail.com>
	<op.u43ra1q0idj3kv@simon-pieterss-macbook.local>
	<op.u43zcikfidj3kv@simon-pieterss-macbook.local>
	<op.u44pvzh3idj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D768@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u5azuv1xidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AD57@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443AF4A@SNV-EXVS09.ds.corp.yahoo.com>
	<63df84f1001071309l6b78ed89q1269026dfb3035ed@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0443B21B@SNV-EXVS09.ds.corp.yahoo.com>
	<Pine.LNX.4.62.1001122219190.17804@hixie.dreamhostps.com>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0443B270@SNV-EXVS09.ds.corp.yahoo.com>

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:ian at hixie.ch] 
Sent: Tuesday, January 12, 2010 2:21 PM
To: Nicholas Zakas
Cc: whatwg at 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.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Tue Jan 12 17:35:29 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Jan 2010 01:35:29 +0000 (UTC)
Subject: [whatwg] Appcache feedback
In-Reply-To: <8937C393-A7D5-4F14-BADE-A831DB6F7A2E@gmail.com>
References: <2FC9749E-E913-4831-9EB9-8C7FE6C669AC@gmail.com>
	<Pine.LNX.4.62.0912172116200.18249@hixie.dreamhostps.com>
	<op.u44wncq464w2qv@annevk-t60>
	<8937C393-A7D5-4F14-BADE-A831DB6F7A2E@gmail.com>
Message-ID: <Pine.LNX.4.62.1001122255530.8484@hixie.dreamhostps.com>

On Thu, 17 Dec 2009, Joseph Pecoraro wrote:
> > 
> > We could delay the application cache download process so that it 
> > doesn't start until after the 'load' event has fired. Does anyone have 
> > an opinion on this?
> 
> It seems pointless to provide hooks in the API that allow for a "custom 
> interface", when fundamentally they may never be triggered in an 
> otherwise compliant user agent.

On Thu, 17 Dec 2009, Michael Nordman wrote:
>
> I don't think we'd have to delay the update job, just the delivery of 
> any events associated with the appcache until 'load' has happened to get 
> the desired effect.

On Fri, 18 Dec 2009, Anne van Kesteren wrote:
> 
> I believe we (Opera) found this is what at least some implementations 
> are doing now and we do this as well. What Michael suggested makes sense 
> and I suppose as the effects are indistinguishable in the end that 
> (delaying either the events or the download process) should be fine.

Done. All the events fired during the update process are delayed if the 
Document whose ApplicationCache they are targetting hasn't loaded yet.

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

From ian at hixie.ch  Tue Jan 12 17:38:40 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Jan 2010 01:38:40 +0000 (UTC)
Subject: [whatwg] HTML5 cut/copy
In-Reply-To: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>

On Tue, 12 Jan 2010, Daniel Cheng wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard
> 
> The current spec says that drop events should be fired while handling 
> copy/cut operations. Is this intended? The clipboard is not a DOM 
> element; it seems like it'd make sense only to fire the drop event for 
> pastes.

Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks.

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

From ian at hixie.ch  Tue Jan 12 19:11:13 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Jan 2010 03:11:13 +0000 (UTC)
Subject: [whatwg] How do sandboxed iframes interact with localStorage /
 sessionStorage / databases / etc?
In-Reply-To: <7789133a1001090040j75b8e27aq28241bde38009315@mail.gmail.com>
References: <7789133a1001090040j75b8e27aq28241bde38009315@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.1001130246420.8484@hixie.dreamhostps.com>

On Sat, 9 Jan 2010, Adam Barth wrote:
>
> The following question came up in implementing the sandbox attribute in WebKit:
> 
> [[
> Description From Patrik Persson 2009-12-10 02:18:50 PST (-) [reply]
> This is a followup to bug 21288, which concerned the implementation of
> the HTML5 iframe sandbox attribute.
> 
> How should WebKit interpret the HTML5 spec regarding sandboxed storage
> and databases?  I believe the HTML5 spec does not say much explicitly
> on this, but rather relies on the origin sandboxing.  Here is my
> interpretation.
> 
> * I think sessionStorage would make sense with sandboxed origins.
> 
> * I think localStorage would end up equivalent to sessionStorage in a
>   sandboxed frame, making it somewhat less useful. (The unique origin
>   of a sandboxed frame means, in my interpretation, that the same
>   frame would not be able to access its own localStorage in another
>   session.)
> 
> * Similarly, I think a sandboxed database would be useful only within
>   a session.  The database could be reclaimed when the session ends.
>   This defeats much of the purpose of databases, but perhaps it would
>   still be useful for compatibility.
> 
> The current implementation disables storage and databases in sandboxed
> frames.  There is some more discussion in the thread for bug 21288,
> comments 43..49:
> ]] -- https://bugs.webkit.org/show_bug.cgi?id=32369
> 
> I think that disabling access to these APIs makes sense given that we
> disable access to cookies.

They now raise a SECURITY_ERR if called when the origin is not a 
scheme/host/port tuple. (This also affects other times that the origin is 
a unique ID, e.g. data: URLs in some situations.)

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

From justin.lebar at gmail.com  Tue Jan 12 19:30:06 2010
From: justin.lebar at gmail.com (Justin Lebar)
Date: Tue, 12 Jan 2010 19:30:06 -0800
Subject: [whatwg] question about the popstate event
In-Reply-To: <bd8f24d21001121554r640a3fe3jc57b9760eea19049@mail.gmail.com>
References: <bd8f24d21001051653y66363bado7e0adad517b2114@mail.gmail.com> 
	<c84706c71001051855x35410e25o35b321bb792996e7@mail.gmail.com> 
	<bd8f24d21001121554r640a3fe3jc57b9760eea19049@mail.gmail.com>
Message-ID: <c84706c71001121930n3ff7fb37kc05f1e22dc5cb411@mail.gmail.com>

If I'm understanding the bug correctly, Brady is suggesting not that a
popstate event isn't fired when we navigate back to a document which
has been unloaded from memory, but that the state object in that
popstate event is null.

As I understand it, the crux of his argument relates to the algorithm
to "update the session history with the new page" [1]:

>    2) If the navigation was initiated for entry update of an entry
>
>       1) Replace the entry being updated with a new entry representing
>          the new resource and its Document object and related state.

I think he's arguing that the set of "related state" that is copied to
the new entry does not contain the state object.  His evidence for
this is mostly textual: This state is referenced in other parts of the
spec, and in those places, it's made clear that the state consists of
scroll position and form fields:

(From comment #4 at https://bugs.webkit.org/show_bug.cgi?id=33224)
> I believe "state" in this context is not referring to "state objects", but
> rather "persisted user state" as set forth in 5.11.9 step 3:
> "For example, some user agents might want to persist the scroll position, or
> the values of form controls."

I think this is a good point from a textual perspective.

But I think it's clear that we actually want to persist state objects
across Document unloads.  If we didn't care about this use case, we
could do away with state objects altogether.  A document could just
call pushstate with no state variable and store its state objects in a
global variable indexed by an identifier in the URL.  When the page
receives a popstate, it checks its URL and grabs the relevant state
object.  Simple.  (This doesn't handle multiple entries with the same
URL, but hash navigation doesn't handle that either, so that's not a
big problem.)

My point is that state objects are pretty much useless unless you
persist them after the document has been unloaded.

I also think the fact that we take the structured clone of a state
object before saving it (and that structured clone forbids pointers to
DOM objects and whatnot) indicates that the spec intended for state
objects to stick around after document unload.  Otherwise, why bother
making a restrictive copy?

(It should go without saying that if you're saving state objects
across document unloads, you should also be saving the "has same
document" relationships between history entries.  That is, suppose
history entry A calls pushstate and creates history entry B.  Some
time later, the document for A and B is unloaded, then the user goes
back to B, which is re-fetched into a fresh Document.  Then the user
clicks back, activating A.  We should treat the activation of A from B
as an activation between two entries with the same document, and not
re-fetch A.)

Where the spec needs to be clarified to support this, I think it
should be.  But let's first agree that this is the right thing to do.

-Justin

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page

On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher <darin at chromium.org> wrote:
> Hi,
> I've been discussing this issue with Brady Eidson over
> at?https://bugs.webkit.org/show_bug.cgi?id=33224,
> and his interpretation appears to be different. ?(I think he may have
> convinced me too.)
> I'd really like some help understanding how pushState is intended to work
> and to see how that lines up
> with the spec.
> Also, assuming Brady is correct, then I wonder why pushState was designed
> this way. ?It seems strange
> to me that entries in session history would disappear when you navigate away
> from a document that used
> pushState.
> -Darin
>
> On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
>>
>> > From my reading of the spec, I would expect the following steps:
>> > 5. Page A is loaded.
>> > 6. The load event for Page A is dispatched.
>> > 7. The popstate event for Page A is dispatched.
>>
>> I think this is correct. ?A popstate event is always dispatched
>> whenever a new session history entry is activated (6.10.3).
>>
>> -Justin
>>
>> On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher <darin at chromium.org> wrote:
>> > I'd like to make sure that I'm understanding the spec for pushState and
>> > the
>> > popstate event properly.
>> > Suppose, I have the following sequence of events:
>> > 1. Page A is loaded.
>> > 2. Page A calls pushState("foo", null).
>> > 3. The user navigates to Page B.
>> > 4. The user navigates back to Page A (clicks the back button once).
>> > Assuming the document of Page A was disposed upon navigation to Page B
>> > (i.e., that it was not preserved in a page cache), should a popstate
>> > event
>> > be generated as a result of step 4?
>> > From my reading of the spec, I would expect the following steps:
>> > 5. Page A is loaded.
>> > 6. The load event for Page A is dispatched.
>> > 7. The popstate event for Page A is dispatched.
>> > Do I understand correctly?
>> > Thanks,
>> > -Darin
>
>

From darin at chromium.org  Tue Jan 12 19:37:41 2010
From: darin at chromium.org (Darin Fisher)
Date: Tue, 12 Jan 2010 19:37:41 -0800
Subject: [whatwg] question about the popstate event
In-Reply-To: <c84706c71001121930n3ff7fb37kc05f1e22dc5cb411@mail.gmail.com>
References: <bd8f24d21001051653y66363bado7e0adad517b2114@mail.gmail.com>
	<c84706c71001051855x35410e25o35b321bb792996e7@mail.gmail.com>
	<bd8f24d21001121554r640a3fe3jc57b9760eea19049@mail.gmail.com>
	<c84706c71001121930n3ff7fb37kc05f1e22dc5cb411@mail.gmail.com>
Message-ID: <bd8f24d21001121937r420f8869t9246b5733a0fb84d@mail.gmail.com>

On Tue, Jan 12, 2010 at 7:30 PM, Justin Lebar <justin.lebar at gmail.com>wrote:

> If I'm understanding the bug correctly, Brady is suggesting not that a
> popstate event isn't fired when we navigate back to a document which
> has been unloaded from memory, but that the state object in that
> popstate event is null.
>
> As I understand it, the crux of his argument relates to the algorithm
> to "update the session history with the new page" [1]:
>
> >    2) If the navigation was initiated for entry update of an entry
> >
> >       1) Replace the entry being updated with a new entry representing
> >          the new resource and its Document object and related state.
>
> I think he's arguing that the set of "related state" that is copied to
> the new entry does not contain the state object.  His evidence for
> this is mostly textual: This state is referenced in other parts of the
> spec, and in those places, it's made clear that the state consists of
> scroll position and form fields:
>
> (From comment #4 at https://bugs.webkit.org/show_bug.cgi?id=33224)
> > I believe "state" in this context is not referring to "state objects",
> but
> > rather "persisted user state" as set forth in 5.11.9 step 3:
> > "For example, some user agents might want to persist the scroll position,
> or
> > the values of form controls."
>
> I think this is a good point from a textual perspective.
>
>
Ah, yes... agreed.



> But I think it's clear that we actually want to persist state objects
> across Document unloads.  If we didn't care about this use case, we
> could do away with state objects altogether.  A document could just
> call pushstate with no state variable and store its state objects in a
> global variable indexed by an identifier in the URL.  When the page
> receives a popstate, it checks its URL and grabs the relevant state
> object.  Simple.  (This doesn't handle multiple entries with the same
> URL, but hash navigation doesn't handle that either, so that's not a
> big problem.)
>
> My point is that state objects are pretty much useless unless you
> persist them after the document has been unloaded.
>

Right!  This is the very perspective I viewed pushState from, and it also
seems to me that the feature is far less useful if state objects are not
persisted after document unload.

-Darin



>
> I also think the fact that we take the structured clone of a state
> object before saving it (and that structured clone forbids pointers to
> DOM objects and whatnot) indicates that the spec intended for state
> objects to stick around after document unload.  Otherwise, why bother
> making a restrictive copy?
>
> (It should go without saying that if you're saving state objects
> across document unloads, you should also be saving the "has same
> document" relationships between history entries.  That is, suppose
> history entry A calls pushstate and creates history entry B.  Some
> time later, the document for A and B is unloaded, then the user goes
> back to B, which is re-fetched into a fresh Document.  Then the user
> clicks back, activating A.  We should treat the activation of A from B
> as an activation between two entries with the same document, and not
> re-fetch A.)
>
> Where the spec needs to be clarified to support this, I think it
> should be.  But let's first agree that this is the right thing to do.
>
> -Justin
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page
>
> On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher <darin at chromium.org> wrote:
> > Hi,
> > I've been discussing this issue with Brady Eidson over
> > at https://bugs.webkit.org/show_bug.cgi?id=33224,
> > and his interpretation appears to be different.  (I think he may have
> > convinced me too.)
> > I'd really like some help understanding how pushState is intended to work
> > and to see how that lines up
> > with the spec.
> > Also, assuming Brady is correct, then I wonder why pushState was designed
> > this way.  It seems strange
> > to me that entries in session history would disappear when you navigate
> away
> > from a document that used
> > pushState.
> > -Darin
> >
> > On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar <justin.lebar at gmail.com>
> wrote:
> >>
> >> > From my reading of the spec, I would expect the following steps:
> >> > 5. Page A is loaded.
> >> > 6. The load event for Page A is dispatched.
> >> > 7. The popstate event for Page A is dispatched.
> >>
> >> I think this is correct.  A popstate event is always dispatched
> >> whenever a new session history entry is activated (6.10.3).
> >>
> >> -Justin
> >>
> >> On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher <darin at chromium.org>
> wrote:
> >> > I'd like to make sure that I'm understanding the spec for pushState
> and
> >> > the
> >> > popstate event properly.
> >> > Suppose, I have the following sequence of events:
> >> > 1. Page A is loaded.
> >> > 2. Page A calls pushState("foo", null).
> >> > 3. The user navigates to Page B.
> >> > 4. The user navigates back to Page A (clicks the back button once).
> >> > Assuming the document of Page A was disposed upon navigation to Page B
> >> > (i.e., that it was not preserved in a page cache), should a popstate
> >> > event
> >> > be generated as a result of step 4?
> >> > From my reading of the spec, I would expect the following steps:
> >> > 5. Page A is loaded.
> >> > 6. The load event for Page A is dispatched.
> >> > 7. The popstate event for Page A is dispatched.
> >> > Do I understand correctly?
> >> > Thanks,
> >> > -Darin
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100112/6a51b592/attachment.htm>

From beidson at apple.com  Tue Jan 12 20:26:45 2010
From: beidson at apple.com (Brady Eidson)
Date: Tue, 12 Jan 2010 20:26:45 -0800
Subject: [whatwg] question about the popstate event
In-Reply-To: <c84706c71001121930n3ff7fb37kc05f1e22dc5cb411@mail.gmail.com>
References: <bd8f24d21001051653y66363bado7e0adad517b2114@mail.gmail.com>
	<c84706c71001051855x35410e25o35b321bb792996e7@mail.gmail.com>
	<bd8f24d21001121554r640a3fe3jc57b9760eea19049@mail.gmail.com>
	<c84706c71001121930n3ff7fb37kc05f1e22dc5cb411@mail.gmail.com>
Message-ID: <00D6FEE1-EB59-4072-9AA7-71ABD6ABC4A3@apple.com>


On Jan 12, 2010, at 7:30 PM, Justin Lebar wrote:

> As I understand it, the crux of his argument relates to the algorithm
> to "update the session history with the new page" [1]:
> 
>>   2) If the navigation was initiated for entry update of an entry
>> 
>>      1) Replace the entry being updated with a new entry representing
>>         the new resource and its Document object and related state.
> 
> I think he's arguing that the set of "related state" that is copied to
> the new entry does not contain the state object.  His evidence for
> this is mostly textual: This state is referenced in other parts of the
> spec, and in those places, it's made clear that the state consists of
> scroll position and form fields:
> 
> (From comment #4 at https://bugs.webkit.org/show_bug.cgi?id=33224)
>> I believe "state" in this context is not referring to "state objects", but
>> rather "persisted user state" as set forth in 5.11.9 step 3:
>> "For example, some user agents might want to persist the scroll position, or
>> the values of form controls."
> 
> I think this is a good point from a textual perspective.

My debate with Darin has so far primarily been about how one reads the spec, and this is most certainly how I've read it.

> <long rant about why state objects should survive document unload, and that state objects are pointless if they don't>

I think you're totally right.  As I've been discussing the spec with Darin in email and the webkit.org bug I've basically come to the same conclusion.

That said...

> Where the spec needs to be clarified to support this, I think it
> should be.  But let's first agree that this is the right thing to do.

The discussion between Darin and I was about my interpretation of the spec, what I implemented based on that interpretation, and how his interpretation was different.  

I think we're now in agreement on what it *should* be, I think the spec should be explicit about it, and I think the ambiguity between "state," "state object,", and "persisted user state" is what might've led us all to misread the other's positions. 

"Entry with persisted user state" is already used quite explicitly in two places, but needs application in key place at the end of 6.11.1.

2 - If the navigation was initiated for entry update of an entry:
	1 - Replace the entry being updated with a new entry representing the new resource and its Document object and related state. The user agent may propagate state from the old entry to the new entry (e.g. scroll position).

might read:

2 - If the navigation was initiated for entry update of an entry:
	1 - Replace the entry being updated with a new entry representing the new resource and its Document object.  If the entry being updated is a state object entry the user agent must propagate the state object to the new entry.  The user agent may propagate persisted user state from the old entry to the new entry (e.g. scroll position).

Thoughts?

~Brady

PS:  On a related note...

> If I'm understanding the bug correctly, Brady is suggesting not that a
> popstate event isn't fired when we navigate back to a document which
> has been unloaded from memory, but that the state object in that
> popstate event is null.

My argument was actually indeed, that the event is not fired at all.  But as I hit up the spec to present my reasoning why, I discovered that 6.11.9 step 10 basically says that popstate events are fired for *ANY* history traversal except for fragment scrolls between non-state-object entries.

So my argument shifts to what you say - the state object in that event is null.  This was just sloppy reading on my part.

That we don't currently fire the popstate event in such cases is a WebKit bug that I have filed as https://bugs.webkit.org/show_bug.cgi?id=33571


> -Justin
> 
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page
> 
> On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher <darin at chromium.org> wrote:
>> Hi,
>> I've been discussing this issue with Brady Eidson over
>> at https://bugs.webkit.org/show_bug.cgi?id=33224,
>> and his interpretation appears to be different.  (I think he may have
>> convinced me too.)
>> I'd really like some help understanding how pushState is intended to work
>> and to see how that lines up
>> with the spec.
>> Also, assuming Brady is correct, then I wonder why pushState was designed
>> this way.  It seems strange
>> to me that entries in session history would disappear when you navigate away
>> from a document that used
>> pushState.
>> -Darin
>> 
>> On Tue, Jan 5, 2010 at 6:55 PM, Justin Lebar <justin.lebar at gmail.com> wrote:
>>> 
>>>> From my reading of the spec, I would expect the following steps:
>>>> 5. Page A is loaded.
>>>> 6. The load event for Page A is dispatched.
>>>> 7. The popstate event for Page A is dispatched.
>>> 
>>> I think this is correct.  A popstate event is always dispatched
>>> whenever a new session history entry is activated (6.10.3).
>>> 
>>> -Justin
>>> 
>>> On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher <darin at chromium.org> wrote:
>>>> I'd like to make sure that I'm understanding the spec for pushState and
>>>> the
>>>> popstate event properly.
>>>> Suppose, I have the following sequence of events:
>>>> 1. Page A is loaded.
>>>> 2. Page A calls pushState("foo", null).
>>>> 3. The user navigates to Page B.
>>>> 4. The user navigates back to Page A (clicks the back button once).
>>>> Assuming the document of Page A was disposed upon navigation to Page B
>>>> (i.e., that it was not preserved in a page cache), should a popstate
>>>> event
>>>> be generated as a result of step 4?
>>>> From my reading of the spec, I would expect the following steps:
>>>> 5. Page A is loaded.
>>>> 6. The load event for Page A is dispatched.
>>>> 7. The popstate event for Page A is dispatched.
>>>> Do I understand correctly?
>>>> Thanks,
>>>> -Darin
>> 
>> 


From hsivonen at iki.fi  Wed Jan 13 05:22:02 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 13 Jan 2010 15:22:02 +0200
Subject: [whatwg] about:blank synchronicity
Message-ID: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>

The HTML5 parser in Gecko loads all streams very asynchronously. That is, to loading a stream never finishes from the same event queue task that starts the load. This is fine for loading HTTP streams, since the general expectation is that the process of loading something from the network makes multiple trips through the event loop.

This has turned out to be a test suite compatibility problem with about:blank. Mozilla's Mochitest test suite has tests that depend about:blank in iframe having a document.body immediately upon iframe insertion to document without a trip through the event loop.

At first look, this seems like a clear case: the spec says that about:blank is navigated to synchronously. However, this is not what Gecko does (with the old parser).

Gecko (with the old parser) has these two characteristics:
 1) If a browsing context that has no document object is asked to return its document object, an about:blank-like DOM is generated into the browsing context synchronously.
 2) When a browsing context is navigated to about:blank, a task is posted to the task queue. When that task is run, about:blank is parsed to completion during the single task queue task.

As a result, in Gecko (with the old parser enabled), asking for document.body of an iframe never returns null even if navigation to about:blank isn't complete. If the navigation hasn't completed yet, a body element generated by #1 above is returned. If navigation has completed, a body element generated by #2 above is returned. Since #2 happens as a single task, it's never possible to see a browsing context that is being navigated to about:blank in an intermediate state of the parse. (The HTML5 parser breaks this by making the state where the document object has been created by nothing has been tokenized yet observable.)

Now, consider the following demo:
http://hsivonen.iki.fi/test/bz-about-blank-data.html

This makes it look like Opera and Safari were doing what the spec says and navigating the iframe synchronously to about:blank. (The use of the data: URL scheme makes the demo not work in IE.)

However, if the data: URL is changed to an http: URL, Safari no longer appears to navigate to about:blank synchronously:
http://hsivonen.iki.fi/test/bz-about-blank.html

Let's take a more careful look:
http://hsivonen.iki.fi/test/bz-about-blank-check-body.html

Opera indeed navigates to about:blank synchronously.

IE doesn't support window.stop, so let's try testing without it:
http://hsivonen.iki.fi/test/bz-about-blank-check-body-no-stop.html

IE7 neither does IE 8 doesn't appear to actually navigate synchronously.

So it appears that only Opera is doing what the spec requires. Since IE, Firefox or Safari aren't doing what the spec requires, what the spec requires can't be exactly necessary for Web compat.

What's the actual Web compat constraint when it comes to navigating to about:blank (including loading about:blank as the initial page into a newly-inserted iframe)?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From mjs at apple.com  Wed Jan 13 08:52:03 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 13 Jan 2010 08:52:03 -0800
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
Message-ID: <B0C6D21B-DA2B-4557-9493-54B536574B8D@apple.com>


On Jan 13, 2010, at 5:22 AM, Henri Sivonen wrote:

> The HTML5 parser in Gecko loads all streams very asynchronously.  
> That is, to loading a stream never finishes from the same event  
> queue task that starts the load. This is fine for loading HTTP  
> streams, since the general expectation is that the process of  
> loading something from the network makes multiple trips through the  
> event loop.
>
> This has turned out to be a test suite compatibility problem with about:blank 
> . Mozilla's Mochitest test suite has tests that depend about:blank  
> in iframe having a document.body immediately upon iframe insertion  
> to document without a trip through the event loop.
>
> At first look, this seems like a clear case: the spec says that about:blank 
>  is navigated to synchronously. However, this is not what Gecko does  
> (with the old parser).
>
> Gecko (with the old parser) has these two characteristics:
> 1) If a browsing context that has no document object is asked to  
> return its document object, an about:blank-like DOM is generated  
> into the browsing context synchronously.
> 2) When a browsing context is navigated to about:blank, a task is  
> posted to the task queue. When that task is run, about:blank is  
> parsed to completion during the single task queue task.
>
> As a result, in Gecko (with the old parser enabled), asking for  
> document.body of an iframe never returns null even if navigation to about:blank 
>  isn't complete. If the navigation hasn't completed yet, a body  
> element generated by #1 above is returned. If navigation has  
> completed, a body element generated by #2 above is returned. Since  
> #2 happens as a single task, it's never possible to see a browsing  
> context that is being navigated to about:blank in an intermediate  
> state of the parse. (The HTML5 parser breaks this by making the  
> state where the document object has been created by nothing has been  
> tokenized yet observable.)

Question: if you generate a document on the fly via early access, does  
it get replaced when the about:blank task actually completes?

It seems like if Gecko truly wanted to make about:blank synchronous,  
it should be possible simply by special-casing its load and performing  
a series of DOM calls right then and there, without ever involving the  
parser.

>
> Now, consider the following demo:
> http://hsivonen.iki.fi/test/bz-about-blank-data.html
>
> This makes it look like Opera and Safari were doing what the spec  
> says and navigating the iframe synchronously to about:blank. (The  
> use of the data: URL scheme makes the demo not work in IE.)
>
> However, if the data: URL is changed to an http: URL, Safari no  
> longer appears to navigate to about:blank synchronously:
> http://hsivonen.iki.fi/test/bz-about-blank.html

I think your test case demonstrates something that we would consider a  
bug. Though I am not sure what exactly is happening internally that  
causes it. We certainly make our best effort to load about:blank  
synchronously, though there may be unusual circumstances where that  
doesn't happen.

>
> Let's take a more careful look:
> http://hsivonen.iki.fi/test/bz-about-blank-check-body.html
>
> Opera indeed navigates to about:blank synchronously.
>
> IE doesn't support window.stop, so let's try testing without it:
> http://hsivonen.iki.fi/test/bz-about-blank-check-body-no-stop.html
>
> IE7 neither does IE 8 doesn't appear to actually navigate  
> synchronously.
>
> So it appears that only Opera is doing what the spec requires. Since  
> IE, Firefox or Safari aren't doing what the spec requires, what the  
> spec requires can't be exactly necessary for Web compat.
>
> What's the actual Web compat constraint when it comes to navigating  
> to about:blank (including loading about:blank as the initial page  
> into a newly-inserted iframe)?

I am not sure what the exact constraints are, but I believe the  
following are required:

- Accessing the document of a frame with missing, empty or about:blank  
src has to always give you an HTML document with a body, even if there  
hasn't been a chance for the event loop to run.
- A newly created iframe with missing, empty or about:blank src has to  
have an accessible document right away, without even cycling the event  
loop.

There are at least three particular scenarios that are relevant here:

1) Some sites document.write or otherwise poke at the DOM of their about:blank 
  frames or iframes in inline script, without waiting for the load  
event or anything.

2) Some sites load multiple frames, yet one expects to poke at the  
other's DOM during its load. Since load order is not guaranteed, this  
would be a race condition, if the not-yet-loaded frame had no DOM, but  
synchronous about:blank lets such sites muddle on through. Before we  
had sufficiently synchronous loading of the initial empty frame  
document, we actually encountered sites like this that broke in Safari  
but not IE or Firefox.

3) Some sites make a new iframe element using DOM calls in an event  
handler, and expect it to have an empty document that's immediately  
ready for DOM manipulation, without any intervening returns to the  
event loop.

Regards,
Maciej






From bzbarsky at MIT.EDU  Wed Jan 13 09:08:59 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 13 Jan 2010 12:08:59 -0500
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <B0C6D21B-DA2B-4557-9493-54B536574B8D@apple.com>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
	<B0C6D21B-DA2B-4557-9493-54B536574B8D@apple.com>
Message-ID: <4B4DFE2B.8070707@mit.edu>

On 1/13/10 11:52 AM, Maciej Stachowiak wrote:
> Question: if you generate a document on the fly via early access, does
> it get replaced when the about:blank task actually completes?

Yes.  More precisely, the document is replaced, but the inner window is 
not (the latter required for pages that set variables on the window 
before the load is complete).

> It seems like if Gecko truly wanted to make about:blank synchronous, it
> should be possible simply by special-casing its load and performing a
> series of DOM calls right then and there, without ever involving the
> parser.

Turns out this actually breaks at least some things that expect 
(asynchronous) onload events and the like for the about:blank load, at 
least when Henri tried doing exactly that.  I _think_ this was for cases 
where an explicit about:blank was listed as the src.  There is probably 
also various non-web code that expects various network events (start of 
network load, end of network load, etc) and the like in this 
circumstance...  We could try to hunt it all down and change it, but 
it's not exactly a trivial endeavor.  If it's necessary, it's necessary, 
of course.

> - Accessing the document of a frame with missing, empty or about:blank
> src has to always give you an HTML document with a body, even if there
> hasn't been a chance for the event loop to run.

Agreed.  This is an absolute requirement.

> - A newly created iframe with missing, empty or about:blank src has to
> have an accessible document right away, without even cycling the event
> loop.

Yes.

> 1) Some sites document.write or otherwise poke at the DOM of their
> about:blank frames or iframes in inline script, without waiting for the
> load event or anything.

Yep.  I believe Gecko treats a document.write the same way it treats a 
location set in terms of network traffic: any loads that are happening 
in that navigation context are canceled.  This is not specific to 
pending about:blank loads.  For example, if you insert an iframe with 
some http URI as @src into the DOM and then document.write into it 
immediately, then the http load will be canceled.  Nothing special about 
about:blank here.

> 2) Some sites load multiple frames, yet one expects to poke at the
> other's DOM during its load. Since load order is not guaranteed, this
> would be a race condition, if the not-yet-loaded frame had no DOM, but
> synchronous about:blank lets such sites muddle on through. Before we had
> sufficiently synchronous loading of the initial empty frame document, we
> actually encountered sites like this that broke in Safari but not IE or
> Firefox.
>
> 3) Some sites make a new iframe element using DOM calls in an event
> handler, and expect it to have an empty document that's immediately
> ready for DOM manipulation, without any intervening returns to the event
> loop.

Fully agreed on these use cases.

One question is whether in case 3 the sites expect the same DOM to be 
available later on.  It seems to be in Safari and Opera.  It's not in 
Gecko at the moment, as expected based on code inspection.   Testcase:

<!DOCTYPE html>
<html>
   <head>
     <script>
       function doTheTest() {
         alert(window.frames[0].document.documentElement.textContent);
       }
     </script>
   </head>
   <body onload="doTheTest()">
     <iframe src=""></iframe>
     <script>
       var doc = window.frames[0].document;
       doc.documentElement.appendChild(doc.createTextNode("foopy"));
     </script>
   </body>
</html>

This alerts empty string in Gecko (and doesn't show the string "foopy" 
in the iframe).

-Boris

From ian at hixie.ch  Wed Jan 13 13:56:28 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 13 Jan 2010 21:56:28 +0000 (UTC)
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
Message-ID: <Pine.LNX.4.62.1001132151390.26049@hixie.dreamhostps.com>

On Wed, 13 Jan 2010, Henri Sivonen wrote:
> 
> Gecko (with the old parser) has these two characteristics:
>  1) If a browsing context that has no document object is asked to return 
> its document object, an about:blank-like DOM is generated into the 
> browsing context synchronously.
>  2) When a browsing context is navigated to about:blank, a task is 
> posted to the task queue. When that task is run, about:blank is parsed 
> to completion during the single task queue task.

The spec currently distinguishes between the initial about:blank load 
(creation of a new browsing context), which actually doesn't involve 
navigation, and navigating to about:blank.

It seems like simply making the first one synchronous, but making the 
latter asynchronous, would satisfy your use case. Would other vendors be 
ok with this?

Would it have other problems? Are there cases other than navigation where 
about:blank being synchronous is detectable? (I couldn't find any.)

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

From hsivonen at iki.fi  Thu Jan 14 00:20:10 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Thu, 14 Jan 2010 10:20:10 +0200
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <4B4DFE2B.8070707@mit.edu>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
	<B0C6D21B-DA2B-4557-9493-54B536574B8D@apple.com>
	<4B4DFE2B.8070707@mit.edu>
Message-ID: <0ED70CC8-705B-41F6-A994-35B4D07D2E47@iki.fi>

On Jan 13, 2010, at 19:08, Boris Zbarsky wrote:

> On 1/13/10 11:52 AM, Maciej Stachowiak wrote:
>> It seems like if Gecko truly wanted to make about:blank synchronous, it
>> should be possible simply by special-casing its load and performing a
>> series of DOM calls right then and there, without ever involving the
>> parser.
> 
> Turns out this actually breaks at least some things that expect (asynchronous) onload events and the like for the about:blank load, at least when Henri tried doing exactly that.  I _think_ this was for cases where an explicit about:blank was listed as the src.

I did it after absent or empty src had been defaulted to about:blank: so empty, absent and explicit about:blank were all covered. Also, I did it for all browsing contexts--not just iframes.

The most obvious test case that broke was testing history navigation in a top-level browsing context (i.e. created in XUL--not as an iframe).

It is plausible that my attempt to fix was too na?ve and additional tweaking of the events could work. (It is indeed very likely that my attempted fix was too na?ve.) Also, making the change only for frames but not for top-level browsing contexts might be worth considering if changing this for top-level browsing contexts is too disruptive.

Which leads to the question: Are there known Web compat constraints on navigating a non-framed browsing context to about:blank via window.open() or window.location.href in a previously open()ed window?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From philipj at opera.com  Thu Jan 14 06:36:21 2010
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Thu, 14 Jan 2010 15:36:21 +0100
Subject: [whatwg] <video> abort and error should bubble for simplicity
In-Reply-To: <op.u28lm9ihsr6mfa@sisko>
References: <op.u28lm9ihsr6mfa@sisko>
Message-ID: <op.u6i1ivejatwj1d@sisko.linkoping.osa>

On Wed, 11 Nov 2009 16:36:35 +0100, Philip J?genstedt <philipj at opera.com>  
wrote:

> Since we are no longer using progress events for media elements we don't  
> have the external requirement that abort/error shouldn't bubble. I'd  
> like them to bubble, because:
>
> 1. error events fired on <source> will bubble to <video>, which is quite  
> useful if one doesn't particularly care which source failed (one need  
> not register an event handler on each individual source attribute)
>
> 2. Implementors don't have to deal with the possibility that events of  
> the same name and type sometimes bubbles and sometimes not.
>
> 3. It's the same as for <img>, which all else equals seems nice and  
> simple.
>
> I'll note that <video> abort/error events in Firefox already seems to  
> bubble while they apparently don't in Safari. We'd like to align with  
> Firefox and have the spec changed.

It looks like I was wrong. As far as I can see error/abort doesn't bubble  
in any other scenario and it seemed to be that way in Firefox because the  
error event is fired on the <video> element, or something. No spec change  
needed.

-- 
Philip J?genstedt
Core Developer
Opera Software

From levin at google.com  Thu Jan 14 12:10:08 2010
From: levin at google.com (David Levin)
Date: Thu, 14 Jan 2010 12:10:08 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <op.u57ka3kn64w2qv@annevk-t60>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant>
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
	<0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>
	<op.u57ka3kn64w2qv@annevk-t60>
Message-ID: <b902e34a1001141210n1e40654epa0227d75b6f1a7e8@mail.gmail.com>

It seems like it the method should be toBlob.

> This doesn't address my concern that you won't know the mime type of
> the blob returned.

This makes a good case to move the "readonly attrbiute DOMString type" from
File to Blob.

dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100114/67778657/attachment.htm>

From darin at chromium.org  Thu Jan 14 22:24:13 2010
From: darin at chromium.org (Darin Fisher)
Date: Thu, 14 Jan 2010 22:24:13 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <b902e34a1001141210n1e40654epa0227d75b6f1a7e8@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant>
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
	<0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>
	<op.u57ka3kn64w2qv@annevk-t60>
	<b902e34a1001141210n1e40654epa0227d75b6f1a7e8@mail.gmail.com>
Message-ID: <bd8f24d21001142224q2ec9b8a4yce49f4bcb23f11b8@mail.gmail.com>

On Thu, Jan 14, 2010 at 12:10 PM, David Levin <levin at google.com> wrote:

> It seems like it the method should be toBlob.
>
> > This doesn't address my concern that you won't know the mime type of
> > the blob returned.
>
> This makes a good case to move the "readonly attrbiute DOMString
> type" from File to Blob.
>
> dave
>
>

I like this suggestion.  It seems reasonable for a Blob, which is just a
handle to data, to have an associated media type.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100114/78e9e662/attachment.htm>

From ian at hixie.ch  Thu Jan 14 23:04:43 2010
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 15 Jan 2010 07:04:43 +0000 (UTC)
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <bd8f24d21001142224q2ec9b8a4yce49f4bcb23f11b8@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>
	<op.u56onosm2q99of@coruscant>
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
	<0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>
	<op.u57ka3kn64w2qv@annevk-t60>
	<b902e34a1001141210n1e40654epa0227d75b6f1a7e8@mail.gmail.com>
	<bd8f24d21001142224q2ec9b8a4yce49f4bcb23f11b8@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001150704180.17282@ps20323.dreamhostps.com>

On Thu, 14 Jan 2010, Darin Fisher wrote:
> On Thu, Jan 14, 2010 at 12:10 PM, David Levin <levin at google.com> wrote:
> > 
> > It seems like it the method should be toBlob.
> >
> > > This doesn't address my concern that you won't know the mime type of 
> > > the blob returned.
> >
> > This makes a good case to move the "readonly attrbiute DOMString type" 
> > from File to Blob.
> 
> I like this suggestion.  It seems reasonable for a Blob, which is just a 
> handle to data, to have an associated media type.

What type should a blob have if it is the result of slicing another file?

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

From darin at chromium.org  Fri Jan 15 00:36:26 2010
From: darin at chromium.org (Darin Fisher)
Date: Fri, 15 Jan 2010 00:36:26 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <Pine.LNX.4.64.1001150704180.17282@ps20323.dreamhostps.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<63df84f1001071514h55ff5b3cn3bccf25da7a40be0@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
	<0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>
	<op.u57ka3kn64w2qv@annevk-t60>
	<b902e34a1001141210n1e40654epa0227d75b6f1a7e8@mail.gmail.com>
	<bd8f24d21001142224q2ec9b8a4yce49f4bcb23f11b8@mail.gmail.com>
	<Pine.LNX.4.64.1001150704180.17282@ps20323.dreamhostps.com>
Message-ID: <bd8f24d21001150036v6b6670bp257021c61d795bea@mail.gmail.com>

On Thu, Jan 14, 2010 at 11:04 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 14 Jan 2010, Darin Fisher wrote:
> > On Thu, Jan 14, 2010 at 12:10 PM, David Levin <levin at google.com> wrote:
> > >
> > > It seems like it the method should be toBlob.
> > >
> > > > This doesn't address my concern that you won't know the mime type of
> > > > the blob returned.
> > >
> > > This makes a good case to move the "readonly attrbiute DOMString type"
> > > from File to Blob.
> >
> > I like this suggestion.  It seems reasonable for a Blob, which is just a
> > handle to data, to have an associated media type.
>
> What type should a blob have if it is the result of slicing another file?
>
>
I had the same thought after sending this ;-)

A slicing operation that changes the size of the file should probably clear
the type field or set it to application/octet-stream.  Perhaps Blob.type
should be settable in some cases?

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100115/0ddc9113/attachment.htm>

From hsivonen at iki.fi  Fri Jan 15 02:05:01 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 15 Jan 2010 12:05:01 +0200
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <0ED70CC8-705B-41F6-A994-35B4D07D2E47@iki.fi>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
	<B0C6D21B-DA2B-4557-9493-54B536574B8D@apple.com>
	<4B4DFE2B.8070707@mit.edu>
	<0ED70CC8-705B-41F6-A994-35B4D07D2E47@iki.fi>
Message-ID: <9C55CB59-9762-4F2A-B7C6-2963899D17BC@iki.fi>

I've located a Mozilla test case that seems to depend on the event loop task mapping of data: URL loads (http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul).

Does anyone happen to have data on whether the Web already depends on data: URLs that don't block the parser loading as a single event loop task?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From levin at google.com  Fri Jan 15 05:28:39 2010
From: levin at google.com (David Levin)
Date: Fri, 15 Jan 2010 05:28:39 -0800
Subject: [whatwg] HTMLCanvasElement.toFile()
In-Reply-To: <bd8f24d21001150036v6b6670bp257021c61d795bea@mail.gmail.com>
References: <63df84f1001071141u490ea9c6rae17abc705e3dd43@mail.gmail.com>
	<63df84f1001071515y46cb4a0brd38682fc2d560947@mail.gmail.com>
	<104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
	<63df84f1001071959t6697e21ci60dede7a9a24f264@mail.gmail.com>
	<0142798B-8724-4FD2-B044-D91B66A0FED8@iki.fi>
	<op.u57ka3kn64w2qv@annevk-t60>
	<b902e34a1001141210n1e40654epa0227d75b6f1a7e8@mail.gmail.com>
	<bd8f24d21001142224q2ec9b8a4yce49f4bcb23f11b8@mail.gmail.com>
	<Pine.LNX.4.64.1001150704180.17282@ps20323.dreamhostps.com>
	<bd8f24d21001150036v6b6670bp257021c61d795bea@mail.gmail.com>
Message-ID: <b902e34a1001150528q12f871ddwcdb7e019902105ac@mail.gmail.com>

(Basically agreeing with Darin) The empty string is what I was thinking
would be appropriate for this case. The file/blob spec,
http://www.w3.org/TR/FileAPI/, already allows for an empty string if the
mime type cannot be determined:

User agents SHOULD return the MIME type of the file, if it is known. If
implementations cannot determine the media type of the file, they MUST
return empty string.

dave


On Fri, Jan 15, 2010 at 12:36 AM, Darin Fisher <darin at chromium.org> wrote:

> On Thu, Jan 14, 2010 at 11:04 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Thu, 14 Jan 2010, Darin Fisher wrote:
>> > On Thu, Jan 14, 2010 at 12:10 PM, David Levin <levin at google.com> wrote:
>> > >
>> > > It seems like it the method should be toBlob.
>> > >
>> > > > This doesn't address my concern that you won't know the mime type of
>> > > > the blob returned.
>> > >
>> > > This makes a good case to move the "readonly attrbiute DOMString type"
>> > > from File to Blob.
>> >
>> > I like this suggestion.  It seems reasonable for a Blob, which is just a
>> > handle to data, to have an associated media type.
>>
>> What type should a blob have if it is the result of slicing another file?
>>
>>
> I had the same thought after sending this ;-)
>
> A slicing operation that changes the size of the file should probably clear
> the type field or set it to application/octet-stream.  Perhaps Blob.type
> should be settable in some cases?
>
> -Darin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100115/6e696715/attachment-0001.htm>

From Bruno.Harbulot at manchester.ac.uk  Fri Jan 15 08:59:01 2010
From: Bruno.Harbulot at manchester.ac.uk (Bruno Harbulot)
Date: Fri, 15 Jan 2010 16:59:01 +0000
Subject: [whatwg] <keygen> tag
Message-ID: <hiq6sk$9kc$1@ger.gmane.org>

Hello,

Apologies for the late participation on this topic. I've been working on 
FOAF+SSL with Henry Story (who advocated a few months ago the 
introduction of <keygen> in HTML 5 for this purpose).
I've only just found the time to investigate the certificate generation 
issue on Windows/Internet Explorer (using ActiveX, XEnroll and 
CertEnroll). I've updated this wiki page accordingly: 
http://esw.w3.org/topic/foaf%2Bssl

Whilst I'm very supportive of having a key-generation mechanism in the 
browser, I'm now not entirely sure the <keygen> tag, at least as a 
legacy of the Netscape <keygen> tag, is the correct approach.
More specifically:

1. The more modern APIs (generateCRMFRequest [1] on Firefox or 
CertEnroll/XEnroll on Internet Explorer [2]) appear to offer more 
options in general, for example, where to store the private key, is it 
exportable, etc. (I haven't looked in details, but I suspect it could be 
envisaged to use some existing key material from a software store or 
smartcard too, for example.)
This raises the question as to whether a tag is sufficient or 
appropriate to express what's required for a CA, or if an API (and more 
programming) is required.

2. The SPKAC format seems to be a legacy format. It doesn't really allow 
to convey much information that CAs would expect, unlike other formats 
used by the more modern APIs [3][4]. Perhaps it would be better to use 
one of the newer formats instead. This might break the compatibility 
with the pre-HTML 5 use of <keygen> (maybe another name than <keygen> in 
HTML5 would be better?).

Of course, the other big question is whether it's worth trying to 
standardise this <keygen> tag if there's no intent of support from major 
browser vendors (I have IE in mind here).

Best wishes,

Bruno.


[1] https://developer.mozilla.org/en/GenerateCRMFRequest
[2] http://msdn.microsoft.com/en-us/library/aa374863%28VS.85%29.aspx
[3] http://tools.ietf.org/html/rfc2986
[4] http://tools.ietf.org/html/rfc4211


From ian at hixie.ch  Mon Jan 18 04:58:16 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jan 2010 12:58:16 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <20091222122313.6BAB.C8DE7135@html5.jp>
References: <20091222122313.6BAB.C8DE7135@html5.jp>
Message-ID: <Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>

On Thu, 12 Nov 2009, Philip J?genstedt wrote:
>
> I've been playing with the microdata DOM APIs again, continuing the 
> JavaScript experimental implementation 
> <http://gitorious.org/microdatajs>. It's not small or elegant, but at 
> least some spec issues have come up in the process.
> 
> What is the http://www.w3.org/1999/xhtml/microdata# URI?

It provides a way to map microdata property names to URLs in an 
unambiguous way.



> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items
> 
> "Otherwise, if one of the other elements in pending is an ancestor 
> element of candidate, and that element is scope, then remove candidate 
> from pending."
> 
> "Otherwise, if one of the other elements in pending is an ancestor 
> element of candidate, and that element also has scope as its nearest 
> ancestor element with an itemscope attribute specified, then remove 
> candidate from pending."
> 
> The intention of these requirements seems to be to eliminate redundant 
> elements in pending, but a comment on the intention of each in the spec 
> would be helpful as it's quite cryptic right now.

Added some brief explanations.



> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata-dom-api
> 
> itemtype and itemid are both URL attributes and therefore when getting
> itemType and itemId relative URLs should be resolved (even if only absolute
> URLs are valid). Correct?

That was a correct interpretation of the spec, but was only intended to 
be the case for itemid. I've corrected the spec to say that itemType is 
just a regular DOMString with no resolution.


> itemprop and itemref are both "unordered set of unique space-separated
> tokens", but in HTMLElement only itemProp is a DOMSettableTokenList while
> itemRef is a DOMString. This doesn't really make sense, so make itemRef a
> DOMSettableTokenList too?

Fixed. That was an oversight.


> From reading the spec it's not obvious (without following cross- 
> references) that itemProp isn't just a plain string. An example using 
> .itemProp.contains(name) or similar would make this more difficult to 
> miss.

Done.



> http://www.whatwg.org/specs/vocabs/current-work/#vcard
> 
> Having clickable cross-references in this spec would help a lot when
> reviewing!

I've put them back in the HTML5 spec, which makes this a moot point.


> Grammar: Let value *be* the result of collecting the first vCard 
> subproperty named value in subitem.

Fixed.


> "Let n1 be the value of the first property named family-name in subitem, or
> the empty string if there is no such property or the property's value is
> itself an item." Why not use "collecting the first vCard subproperty" here?
> Not doing so had me trying to find how the two were different, but I couldn't
> find any differences given that the values are later escaped.

Oops. Fixed.


> There's also the issue of how newlines from textContent values are escaped.
> Applying the vCard extraction algorithm to the spec example gives:
> 
> BEGIN:VCARD
> PROFILE:VCARD
> VERSION:3.0
> SOURCE:http://foolip.org/microdatajs/demo/vcard.html
> NAME:vCard demo
> FN:Jack Bauer
> PHOTO;VALUE=URI:http://foolip.org/microdatajs/demo/jack-bauer.jpg
> ORG:Counter-Terrorist Unit;Los Angeles Division
> ADR:;;10201 W. Pico Blvd.;Los Angeles;CA;90064;United States
> GEO:34.052339;-118.410623
> TEL;TYPE=work:+1 (310)\n  597 3781
> URL;VALUE=URI:http://en.wikipedia.org/wiki/Jack_Bauer
> URL;VALUE=URI:http://www.jackbauerfacts.com/
> EMAIL:j.bauer at la.ctu.gov.invalid
> TEL;TYPE=cell:+1 (310) 555\n  3781
> NOTE:If I'm out in the field\, you may be better off\n contacting Chloe O'B
> rian if it's about\n work\, or ask Tony Almeida if\n you're interested in
> the CTU five-a-side football team we're trying\n to get going.
> AGENT;VALUE=VCARD:BEGIN:VCARD\nPROFILE:VCARD\nVERSION:3.0\nSOURCE:http://fo
> olip.org/microdatajs/demo/vcard.html\nNAME:vCard demo\nEMAIL\;VALUE=URI:ma
> ilto:c.obrian at la.ctu.gov.invalid\nFN:Chloe O'Brian\nN:O'Brian\;Chloe\;\;\;
> \nEND:VCARD\n
> AGENT:Tony Almeida
> REV:2008-07-20T21:00:00+0100
> TEL;TYPE=home:01632 960 123
> N:Bauer;Jack;;;
> END:VCARD
> 
> TEL and NOTE has line breaks that are just because of how the HTML source is
> formatted. Importing this into Gmail preserves these linebreaks which looks
> quite broken. Unless we expect text fields to contain meaningful formatting,
> perhaps simply collapsing all whitespace into a single space is OK? In the
> best of worlds <br> would be converted to \n, but I'm not sure if it's worth
> the trouble.

We're screwed either way. If we convert newlines to " ", then we lose 
formatting from <pre>. If we don't convert newlines, we gain spurious 
linebreaks (and spaces). The latter is less destructive, which is why I 
picked it, but it's not ideal, I agree.

I'd like at some point to introduce some sort of "semantic" textContent 
that handles <br>, <pre>, <bdo>, dir="", <img alt>, <del>, space- 
collapsing, and newline elimination, but there hasn't been much enthusiasm 
around the idea, and it's not clear what else it would be good for.

I've changed the example, at least, to have it work ok, and added a 
comment in the example about it.


> Finally on vCard, the final part of the extraction algorithm goes to 
> great trouble to guess what is the family name and what is the given 
> name. This guess will be broken for transliterated east Asian names 
> (CJKV that I know of, maybe others too). Just saying. Also, why is it 
> important to explicitly add N:;;;; for organizations?

This is intended to be compatible with Microformats vCard, which has 
these weird rules. If you think we should remove them, please at least 
first speak to Tantek and see why he thinks.



> http://www.whatwg.org/specs/vocabs/current-work/#vevent
> 
> "Add an iCalendar line with the type name and the value value to output."
> 
> At this point value is undefined.

Fixed.


> Given the algorithm for extracting iCal, it seems that dtstart and dtend must
> be specified using <time datetime="">, as it's only for time elements that the
> time stamps will be properly formatted (stripping - and :)

Yes. I've made this explicit (as with the URL ones).


> There are some errors in the example. I got it working by applying this diff:
> 
> --- vevent.js.orig	2009-11-11 10:52:37.000000000 +0100
> +++ vevent.js	2009-11-11 23:54:15.000000000 +0100
> @@ -1,3 +1,3 @@
> function getCalendar(node) {
> -  while (node && (!node.nodeScope || !node.itemType == 'http://microformats.org/profile/hcalendar#vevent'))
> +  while (node && (!node.itemScope || !node.itemType == 'http://microformats.org/profile/hcalendar#vevent'))
>     node = node.parentNode;

Fixed.


> @@ -26,3 +26,3 @@
>       value = value.replace(/;/g, '\\;');
> -      value = value.replace(/,/g, \\,');
> +      value = value.replace(/,/g, '\\,');
>       value = value.replace(/\n/g, '\\n');

Fixed.


> @@ -31,3 +31,3 @@
>       var name = prop.itemProp[nameIndex];
> -      if (!name.match(':') && !name.match('.'))
> +      if (!name.match(':') && !name.match('\\.'))
>         calendar += name.toUpperCase() + parameters + ':' + value + '\r\n';
> 
> Perhaps /\./ would be better to make it clear that it's a regexp.

Fixed.


> Also: if (prop.date && prop.time)
> 
> date and time aren't properties on HTMLTimeElement, I don't know what this is.

Oops. We removed .date and .time on the basis that there were no use 
cases, apparently oblivious to the use case in the spec already!


> Is there or should there be a DOM API for determining if a string is a valid
> date string other than implementing those algorithms in script?

There isn't... if you can assume the input is valid (e.g. if you wrote it 
yourself) then distinguishing a date from a datetime is easy (just test it 
against .match(/T/)), but if you want to implement the algorithm in the 
spec, you need more code.



> http://www.whatwg.org/specs/vocabs/current-work/#licensing-works
> 
> What's the n in http://n.whatwg.org/work? If this URL is going to stick, 
> it would be nice if there were also something to be seen at that page.

I've made it redirect to the spec.


> Also, the conversion to RDF section isn't really useful and seems to 
> hide some assumptions about how the properties vocabulary should be 
> prefixed with http://n.whatwg.org/work and how the 
> http://www.w3.org/1999/xhtml/microdata# prefix is supposed to be used.

I've tried to add more information here.



> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#domtokenlist
> 
> The DOM intro box doesn't explain the return value for .toggle(), you 
> have to consult the algorithm to figure it out.

Fixed.



On Sat, 14 Nov 2009, Philip J?genstedt wrote:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html#json
> 
> This was easy to implement, but the algorithm isn't guaranteed to terminate.
> 
> <div itemscope>
>  <div itemprop="foo" itemscope itemref="oops" id="oops"></div>
> </div>
> 
> This simple input causes the algorithm to recurse as the item references 
> itself.
>
> I went back to the vCard algorithm and found that it too will fail to
> terminate with this input:
> 
> <span itemscope itemtype="http://microformats.org/profile/hcard">
>  <span itemprop="agent" itemscope id="oops" itemref="oops"
>        itemtype="http://microformats.org/profile/hcard">
> </span>
> 
> vEvent is safe as the algorithm never recurses, but the RDF conversion
> algorithm would hit the same problem.

Hmm. For RDF it's a non-problem, we could just make sure that you don't 
generate the triples for a particular item more than once. For vCard and 
JSON, though, it's indeed an issue.


> The itemref mechanism allows creating arbitrary graphs of items, rather than
> the tree of items that is the intended microdata model (right?).

Graphs are intended to be supported in v2, using a mechanism 


> It's certainly possible to create loops which are less easy to spot:
> 
> <div itemscope>
>  <div itemprop="prop1" itemscope itemref="id2" id="id1"></div>
>  <div itemprop="prop2" itemscope itemref="id3" id="id2"></div>
>  ...
>  <div itemprop="propn" itemscope itemref="id1" id="idn"></div>
> </div>
> 
> Or this:
> 
> <div itemscope>
>  <div itemprop="foo" itemscope id="a">
>    <div itemprop="bar" itemscope itemref="a"></div>
>  </div>
> </div>

Or:

   <div itemscope itemref="a"></div>
   <div itemprop="p" itemscope id="a" itemref="b"></div>
   <div itemprop="q" itemscope id="b" itemref="a"></div>

...which creates an infinite tree:

   root item
     p: item
         q: item
             p: item
                 q: item
                     ...ad nauseum...

I've changed the way itemref="" is processed so that it catches loops and 
drops on the floor any nodes involving loops.


On Fri, 13 Nov 2009, Tab Atkins Jr. wrote:
> 
> Looping in data-graphs is often useful, so I'm not sure I want to throw 
> it out generally.  Your statement in the first paragraph I'm quoting, 
> though, says that you'd rather leave loops to be defined in the 
> vocabulary itself?  So loops would be done by, frex, itemprop'ing a link 
> to the other element rather than itemref'ing the other element directly?
> 
> That would probably be fine, and is compatible with a tree-based data 
> model like JSON.  Vocabs should know when loops are 
> permissible/desirable for themselves.

Indeed.


On Sat, 14 Nov 2009, Philip J?genstedt wrote:
> 
> Yes, that's basically what I'm saying. One option is to simply use 
> microdata such that the RDF you extract is the graph you want (it will 
> probably look quite ugly though). Another is always referencing subitems 
> by a mechanism other than refid. For example, in the MusicBrainz XML 
> webservice when an artist contains a release which itself references 
> artists (e.g. as the producer), a stub item is used with only artist 
> name and id, rather than including all information recursively. In 
> microdata I would do:
> 
> <section itemscope
> itemtype="http://musicbrainz.org/artist/"
> itemid="http://musicbrainz.org/artist/4d5447d7-c61c-4120-ba1b-d7f471d385b9">
>  <h1 itemprop="name">John Lennon</h1>
>  <section>
>   <h1>Releases</h1>
>   <section itemprop="release"
>    itemscope
>    itemtype="http://musicbrainz.org/release/"
>    itemid="http://musicbrainz.org/release/f237e6a0-4b0e-4722-8172-66f4930198bc"> 
>    <h1>Imagine</h1>
>    Producer:
>    <span itemprop="producer"
>     itemscope
>     itemtype="http://musicbrainz.org/artist/"
>     itemid="http://musicbrainz.org/artist/e7b587f7-e678-47c1-81dd-e7bb7855b0f9"
>     ><span itemprop="name">Phil Spector</span></span>
>   </section>
>  </section>
> </section>
> 
> Even if John Lennon were the producer here, you don't get any looping in 
> the microdata itself. If you want to know everything about the producer, 
> you should just follow the itemid... I haven't looked that much at the 
> RDF extraction algorithm yet, but I think this example might even create 
> the proper graph with loops if the producer were John Lennon.

Yes. There'd be two John Lennon items, though.


On Tue, 17 Nov 2009, Philip J?genstedt wrote:
>
> http://www.whatwg.org/specs/vocabs/current-work/#examples
> 
> The Jack Bauer example has validation issues (using http://validator.nu/)
> 
> My fix:
> 
> --- jack.html.orig	2009-11-17 11:03:03.000000000 +0100
> +++ jack.html	2009-11-17 11:03:19.000000000 +0100
> @@ -41,12 +41,12 @@
>  you're interested in the CTU five-a-side football team we're trying
>  to get going.</p>
> - <ins datetime="2008-07-20T21:00:00+0100">
> + <ins datetime="2008-07-20T21:00:00+01:00">

Fixed.


>   <span itemprop="rev" itemscope>
>    <meta itemprop="type" content="date-time">
> -   <meta itemprop="value" content="2008-07-20T21:00:00+0100">
> +   <meta itemprop="value" content="2008-07-20T21:00:00+01:00">

Fixed.


>   </span>
>   <p itemprop="tel" itemscope><strong>Update!</strong>
>   My new <span itemprop="type">home</span> phone number is
> -  <span itemprop="value">01632 960 123</span>.
> +  <span itemprop="value">01632 960 123</span>.</p>
>  </ins>
> </section>

Fixed.


On Thu, 19 Nov 2009, Philip J?genstedt wrote:
>
> In a (slightly edited) Jack Bauer example [1], Chrome, Firefox and 
> presumably Safari has the meta elements moved to head. This will 
> severely break script-based implementation of microdata, which are 
> likely to be used for the time being until the DOM API is implemented 
> natively. I can't see any workaround for this, so I suggest that <meta> 
> simply not be used for microdata, preferably by making it non-conforming 
> and removing it from the definitions/algorithms.

This is a short-term problem that only affects scripted implementations 
that are shipped with the pages, so the workaround is simple: don't use 
<meta> and <link>. Any implementations outside of the page can just fix 
their parser to be HTML5-compatible.


> For <link>, the rel attribute issue [2] needs to be settled. It seems to 
> me that sometimes requiring rel and sometimes not makes for a less 
> consistent language with more room for error.

No version of HTML has ever required rel="" (in the past <link> was valid, 
but even ignoring that, you could have used rev="" instead of rel=""). 
People seem to have survived. I don't think it's a huge problem to use it 
with itemprop="" instead.


> I hesitate to make an argument based on aesthetics, but I think 
> repurposing either <link> or <meta> for use in microdata is decidedly 
> ugly, mostly because my legacy understanding of them is as "<head> only 
> elements". In the usability study [3] there was only one example which 
> used <link> and <meta> [4]. Was there any indication then that any of 
> the test subjects were put off by either <link> or <meta>?

None that I recall, but I'd have to review the tapes to be sure.


> Both <item> and <link> are used only to include non-visible metadata in 
> the item. Philip Taylor points out in IRC that these work equally well:
> 
> <span hidden itemprop=foo>bar</span> (instead of meta)

That's bogus. Ideally we'd in fact make the microdata algorithm actively 
drop everything inside a hidden="" block, since it means it's not 
relevant. That would require even more tree walking, though, so I'd rather 
no do that.


> <a itemprop=foo href=bar></a> (instead of link)

That's far more ugly than <link>, IMHO! :-)


On Thu, 26 Nov 2009, Tim van Oostrom wrote:
>
> Hi, I made a forumpost : http://forums.whatwg.org/viewtopic.php?t=4176, 
> concerning a possible "microdata specification bug" and a bug in the 
> james.html5.org microdata extractor.
> 
> Comes down to <link/> and <meta/> elements possibly being unfit for use 
> with the itemscope attribute.
> 
> I made an example in the forum post with some nice ubb formatting .

You're right that using itemscope="" with <link> and <meta> isn't 
particularly useful. It's even more pointless on <br>, or <script>, or 
<style>. You MAY use it on any element, but it's indeed not really useful 
in most cases. It's just easier for everyone if we don't say "it can be 
used on MOST elements, but here's a list of exceptions".

Regarding the second point, I wasn't sure what you meant. id="city" should 
be fine.

I didn't really follow your other e-mails; are there any changes you think 
should be made to the spec?


On Sun, 29 Nov 2009, Philip J?genstedt wrote:
> 
> Yes, the spec certainly needs some notes on how to use <link> and 
> <meta>.

There are some examples that use them... What do you think should be 
mentioned in a note, if we add one?


> Now, back to the problem of one property, multiple items. The algorithm 
> for finding the properties of an item [2] is an attempt at optimizing 
> the search for properties starting at an item element. I think we should 
> replace this algorithm with an algorithm for finding the item of a 
> property. This was previously the case with the spec before the itemref 
> mechanism.

This would preclude using the same itemprops from multiple itemrefs. 
That's not a particularly strong use case, but it seems to odd to disallow 
it given the markup feature.


On Mon, 30 Nov 2009, Philip J?genstedt wrote:
>
> This way the microdata model is kept strictly tree-like.

The model is still tree-like. It's just that the mapping of the model to 
the DOM has multiple nodes mapped to the same DOM nodes.


On Tue, 22 Dec 2009, Futomi Hatano wrote:
> 
> I wonder if there is a typo in the example of Microdata Vocabularies: vCard.
> http://www.whatwg.org/specs/vocabs/current-work/#examples
> There are three examples. Could you see the second example?
> 
> <strong title="fn">Alfred Person</strong>
> 
> I wonder if the title attribute is incorrect.
> The itemprop attribute is correct, isn't it?
> 
> <strong itemprop="fn">Alfred Person</strong>

Thanks, fixed.

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

From jeremy at adactio.com  Mon Jan 18 07:24:46 2010
From: jeremy at adactio.com (Jeremy Keith)
Date: Mon, 18 Jan 2010 15:24:46 +0000
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
References: <20091222122313.6BAB.C8DE7135@html5.jp>
	<Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
Message-ID: <3851E773-04EF-449D-9E7B-18CA7BE414D7@adactio.com>

Hixie wrote:
>> Finally on vCard, the final part of the extraction algorithm goes to
>> great trouble to guess what is the family name and what is the given
>> name. This guess will be broken for transliterated east Asian names
>> (CJKV that I know of, maybe others too). Just saying. Also, why is it
>> important to explicitly add N:;;;; for organizations?
>
> This is intended to be compatible with Microformats vCard, which has
> these weird rules. If you think we should remove them, please at least
> first speak to Tantek and see why he thinks.

The fn optimisation pattern isn't intended to catch 100% of cases,  
just the situation "Firstname Lastname" or "Firstname Middlename  
Lastname". So if you just use fn (formatted name) and don't use n  
(name), the name will be extracted/guessed using the optimisation  
pattern.

In cases where the pattern doesn't work (e.g. "Anne van Kesteren", or  
east Asian names) you can still explicitly specify the family name and  
given name, over-riding the fn optimisation pattern. If you do this,  
you need to explicitly state this is the name (n) as well as the  
formatted name (fn).

Similarly, for organisations, you don't have to explicitly set n  
(name) if you apply both fn (formatted name) and org (organisation  
name) to a string. This time, the optimisation pattern assumes that  
the fn is the name of the organisation.

Technically, the n property is *always* required but if you use either  
of those two optimisation patterns, the n is inferred from fn.

HTH,

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From fantasai.lists at inkedblade.net  Mon Jan 18 10:44:20 2010
From: fantasai.lists at inkedblade.net (fantasai)
Date: Mon, 18 Jan 2010 10:44:20 -0800
Subject: [whatwg] bidi embedding for block-level elements
In-Reply-To: <4B4EDA92.5040303@smontagu.org>
References: <4B0D6C09.9040109@emi.ac.ma> <4B0E9A2C.7020300@diwan.com>
	<4B0F77C0.5020201@smontagu.org> <4B4B999E.1090806@inkedblade.net>
	<4B4EDA92.5040303@smontagu.org>
Message-ID: <4B54AC04.5080702@inkedblade.net>

On 01/14/2010 12:49 AM, Simon Montagu wrote:
> On 01/11/2010 11:35 PM, fantasai wrote:
>> On 11/26/2009 10:54 PM, Simon Montagu wrote:
>>>
>>> I assume your Gecko example is using a very recent version of Gecko,
>>> such as a nightly build or a beta of Firefox 3.6? I fixed this issue
>>> only a few months ago.
>>>
>>> The HTML standard does specify what to do in this case, see
>>> http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi:
>>>
>>> "When a block element that does not have a dir attribute is transformed
>>> to the style of an inline element by a style sheet, the resulting
>>> presentation should be equivalent, in terms of bidirectional formatting,
>>> to the formatting obtained by explicitly adding a dir attribute
>>> (assigned the inherited value) to the transformed element."
>>>
>>> In practice, however, since browsers are not consistent, authors will
>>> have to use CSS properties to achieve the expected results.
>>
>> Does this mean applying "unicode-bidi: embed" to all block-level
>> elements?
>> Because that seems like it fulfill those requirements.
>
> I was thinking in terms of applying "unicode-bidi: embed" ad hoc
> whenever applying "display: inline" to a specific element, but applying
> it wholesale to all block-level elements will also work, of course.

In that case, I suggest the we add it to the sample default style sheet for
HTML 4 in the CSS2.1 appendix, and recommend the HTMLWG add some wording
about block-level elements defining bidi embedding boundaries to the HTML5
spec (and perhaps using CSS's "unicode-bidi: embed" rule as an example).

~fantasai

From bzbarsky at MIT.EDU  Mon Jan 18 11:47:20 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 18 Jan 2010 14:47:20 -0500
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <9C55CB59-9762-4F2A-B7C6-2963899D17BC@iki.fi>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>	<B0C6D21B-DA2B-4557-9493-54B536574B8D@apple.com>	<4B4DFE2B.8070707@mit.edu>	<0ED70CC8-705B-41F6-A994-35B4D07D2E47@iki.fi>
	<9C55CB59-9762-4F2A-B7C6-2963899D17BC@iki.fi>
Message-ID: <4B54BAC8.9090104@mit.edu>

On 1/15/10 5:05 AM, Henri Sivonen wrote:
> I've located a Mozilla test case that seems to depend on the event loop task mapping of data: URL loads (http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul).

Er... it does?  Where?

> Does anyone happen to have data on whether the Web already depends on data: URLs that don't block the parser loading as a single event loop task?

I don't think the web depends on data: URLs at all, really, so I would 
guess "no".

-Boris

From bzbarsky at MIT.EDU  Mon Jan 18 11:53:41 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 18 Jan 2010 14:53:41 -0500
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <Pine.LNX.4.62.1001132151390.26049@hixie.dreamhostps.com>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
	<Pine.LNX.4.62.1001132151390.26049@hixie.dreamhostps.com>
Message-ID: <4B54BC45.308@mit.edu>

On 1/13/10 4:56 PM, Ian Hickson wrote:
> The spec currently distinguishes between the initial about:blank load
> (creation of a new browsing context), which actually doesn't involve
> navigation, and navigating to about:blank.
>
> It seems like simply making the first one synchronous, but making the
> latter asynchronous, would satisfy your use case. Would other vendors be
> ok with this?

In case it wasn't clear from the relevant Gecko thread, I would 
personally be fine with this.  That said, would "initial about:blank 
load" only include <iframe/> (no src at all), or also <iframe src=""/> 
or also <iframe src="about:blank"/>?  I suspect it doesn't matter that 
much, actually, but would welcome confirmation.

> Would it have other problems? Are there cases other than navigation where
> about:blank being synchronous is detectable? (I couldn't find any.)

I'm not sure what you're asking here...

-Boris

From Simetrical+w3c at gmail.com  Mon Jan 18 13:06:55 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 18 Jan 2010 16:06:55 -0500
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
References: <20091222122313.6BAB.C8DE7135@html5.jp>
	<Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
Message-ID: <7c2a12e21001181306x187cb82egf462cebfd78905d9@mail.gmail.com>

On Mon, Jan 18, 2010 at 7:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> I've made it redirect to the spec.

Could you say that the URL *should* provide human-readable information
about the vocabulary?  We all know the problems with having
centrally-stored machine-readable data about your specs, but
encouraging the URL to provide human-readable info seems helpful.  (If
they aren't supposed to be dereferenced, why use HTTP?)

> Graphs are intended to be supported in v2, using a mechanism

You seem to have left this sentence unfinished.

From julian.reschke at gmx.de  Mon Jan 18 14:03:04 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 18 Jan 2010 23:03:04 +0100
Subject: [whatwg] Microdata feedback
In-Reply-To: <7c2a12e21001181306x187cb82egf462cebfd78905d9@mail.gmail.com>
References: <20091222122313.6BAB.C8DE7135@html5.jp>	<Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
	<7c2a12e21001181306x187cb82egf462cebfd78905d9@mail.gmail.com>
Message-ID: <4B54DA98.2000506@gmx.de>

Aryeh Gregor wrote:
> On Mon, Jan 18, 2010 at 7:58 AM, Ian Hickson <ian at hixie.ch> wrote:
>> I've made it redirect to the spec.
> 
> Could you say that the URL *should* provide human-readable information
> about the vocabulary?  We all know the problems with having
> centrally-stored machine-readable data about your specs, but
> encouraging the URL to provide human-readable info seems helpful.  (If
> they aren't supposed to be dereferenced, why use HTTP?)
> ...

SHOULD return human-readable information is good, if you also add SHOULD 
NOT automatically dereference.

BR, Julian

From ian at hixie.ch  Mon Jan 18 15:02:09 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 18 Jan 2010 23:02:09 +0000 (UTC)
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <4B54BC45.308@mit.edu>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
	<Pine.LNX.4.62.1001132151390.26049@hixie.dreamhostps.com>
	<4B54BC45.308@mit.edu>
Message-ID: <Pine.LNX.4.64.1001182301190.3759@ps20323.dreamhostps.com>

On Mon, 18 Jan 2010, Boris Zbarsky wrote:
> On 1/13/10 4:56 PM, Ian Hickson wrote:
> > The spec currently distinguishes between the initial about:blank load
> > (creation of a new browsing context), which actually doesn't involve
> > navigation, and navigating to about:blank.
> > 
> > It seems like simply making the first one synchronous, but making the
> > latter asynchronous, would satisfy your use case. Would other vendors be
> > ok with this?
> 
> In case it wasn't clear from the relevant Gecko thread, I would personally be
> fine with this.  That said, would "initial about:blank load" only include
> <iframe/> (no src at all), or also <iframe src=""/> or also <iframe
> src="about:blank"/>?  I suspect it doesn't matter that much, actually, but
> would welcome confirmation.

It would include any browsing context creation, including, e.g. 
window.open(), <object> pointing to an HTML file before the HTML file is 
loaded, etc.

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

From bzbarsky at MIT.EDU  Mon Jan 18 18:27:36 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 18 Jan 2010 21:27:36 -0500
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <Pine.LNX.4.64.1001182301190.3759@ps20323.dreamhostps.com>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
	<Pine.LNX.4.62.1001132151390.26049@hixie.dreamhostps.com>
	<4B54BC45.308@mit.edu>
	<Pine.LNX.4.64.1001182301190.3759@ps20323.dreamhostps.com>
Message-ID: <4B551898.2070209@mit.edu>

On 1/18/10 6:02 PM, Ian Hickson wrote:
>> In case it wasn't clear from the relevant Gecko thread, I would personally be
>> fine with this.  That said, would "initial about:blank load" only include
>> <iframe/>  (no src at all), or also<iframe src=""/>  or also<iframe
>> src="about:blank"/>?  I suspect it doesn't matter that much, actually, but
>> would welcome confirmation.
>
> It would include any browsing context creation, including, e.g.
> window.open(),<object>  pointing to an HTML file before the HTML file is
> loaded, etc.

That wasn't quite my question.

If I have an <iframe src="about:blank"/> in my source, would there be a 
sync about:blank document creation followed by an about:blank load?  Or 
would the @src value just get ignored if it's "about:blank"?

-Boris

From ian at hixie.ch  Mon Jan 18 22:43:20 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Jan 2010 06:43:20 +0000 (UTC)
Subject: [whatwg] img copyright attribute
In-Reply-To: <68C4C967-53D5-433B-99FE-C4234FDCD131@apple.com>
References: <c43b24a21001091853t1c636d6ra3a35b6b2fde8a19@mail.gmail.com>
	<26b395e61001120606m26705c33j2f9e99c1cfede463@mail.gmail.com>
	<68C4C967-53D5-433B-99FE-C4234FDCD131@apple.com>
Message-ID: <Pine.LNX.4.64.1001190507340.3970@ps20323.dreamhostps.com>

On Sat, 9 Jan 2010, will surgent wrote:
>
> It would be nice if there was a copyright attribute for the HTML 5 img 
> tag. This would make it easy for users and search engines to filter out 
> images that can not be used for certain purposes.

On Sun, 10 Jan 2010, Jonny Barnes wrote:
> 
> Or maybe a license attribute instead, that would include copyrighted 
> work and stuff licensed under some CC or alternative.

On Sat, 9 Jan 2010, Aryeh Gregor wrote:
> 
> This is one of the things microdata/RDFa are meant to do.

On Sun, 10 Jan 2010, Philip J?genstedt wrote:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#examples-4

On Sun, 10 Jan 2010, will surgent wrote:
>
> Hmm I didn't know about that. Thanks!

On Sun, 10 Jan 2010, Dawid Czyzewski wrote:
>
> And why img only? this would also be good for audio and video.

On Mon, 11 Jan 2010, will surgent wrote:
>
> That sounds like good idea (about the audio and video elements being
> included as-well). I just thought of it because Google does not allow one to
> specify the copyright or license in an image search as far as I know. having
> a license attribute would make it intuitive for developers to add the
> license the same way title and alt attributes are specified.

On Tue, 12 Jan 2010, timeless wrote:
> 
> external metadata on copyright is a disaster. it gets lost immediately.
> 
> GIF and friends have supported embedding (c) into images for decades.
> 
> As google is fully capable of caching images (and obviously does so), I 
> question how adding a tag to html will solve a problem which is already 
> solved by the native image formats themselves.
> 
> For lack of a more useful reference about comment fields, i'll just 
> point to one application which is aware of them (although at the time of 
> the posting it only supported them for certain image types): 
> http://www.group42.com/ts-wi04.htm

Based on the above comments, I haven't changed anything -- the work 
vocabulary pretty much already addresses this use case in HTML, and 
addressing it in other formats is a problem for another working group.

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

From ian at hixie.ch  Tue Jan 19 01:50:53 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 19 Jan 2010 09:50:53 +0000 (UTC)
Subject: [whatwg] Microdata feedback
In-Reply-To: <4B54DA98.2000506@gmx.de>
References: <20091222122313.6BAB.C8DE7135@html5.jp>
	<Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
	<7c2a12e21001181306x187cb82egf462cebfd78905d9@mail.gmail.com>
	<4B54DA98.2000506@gmx.de>
Message-ID: <Pine.LNX.4.64.1001190823380.3970@ps20323.dreamhostps.com>


On Mon, 18 Jan 2010, Aryeh Gregor wrote:
> On Mon, Jan 18, 2010 at 7:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> > I've made it redirect to the spec.
> 
> Could you say that the URL *should* provide human-readable information 
> about the vocabulary?  We all know the problems with having 
> centrally-stored machine-readable data about your specs, but encouraging 
> the URL to provide human-readable info seems helpful.  (If they aren't 
> supposed to be dereferenced, why use HTTP?)

Why indeed. Is there something else we could use instead?


> > Graphs are intended to be supported in v2, using a mechanism
> 
> You seem to have left this sentence unfinished.

...using a mechanism intended for that purpose. Nothing to see here. :-)


On Mon, 18 Jan 2010, Julian Reschke wrote:
> 
> SHOULD return human-readable information is good, if you also add SHOULD 
> NOT automatically dereference.

I've added something akin to that SHOULD NOT, but the spec doesn't have a 
"specification" conformance class, so there's nothing to apply the SHOULD 
to. So I haven't added it. (I don't generally think specifications being 
conformance classes really makes much sense.)

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

From henry.story at bblfish.net  Tue Jan 19 07:07:54 2010
From: henry.story at bblfish.net (Story Henry)
Date: Tue, 19 Jan 2010 15:07:54 +0000
Subject: [whatwg] [foaf-protocols] keygen substitute for Windows?
Message-ID: <2272F99A-2D1A-46BB-95ED-215CA6AA4A70@bblfish.net>

> Hello,
> 
> Apologies for the late participation on this topic. I've been working on 
> FOAF+SSL with Henry Story (who advocated a few months ago the 
> introduction of <keygen> in HTML 5 for this purpose).
> I've only just found the time to investigate the certificate generation 
> issue on Windows/Internet Explorer (using ActiveX, XEnroll and 
> CertEnroll). I've updated this wiki page accordingly: 
> 
> http://esw.w3.org/topic/foaf%2Bssl

Thanks for this great investigative work.

> 
> Whilst I'm very supportive of having a key-generation mechanism in the 
> browser, I'm now not entirely sure the <keygen> tag, at least as a 
> legacy of the Netscape <keygen> tag, is the correct approach.

I think that part of the html5 goals is to describe how browsers actually work, without going into endless debates about how they SHOULD work. Given that Netscape, Firefox, Opera and Safari implement the <keygen> tag - and have done so for a very long time - it seems quite reasonable to describe that behaviour in html5. 

Once this is described it is then possible to find ways either to extend on the current behaviour or to find ways to improve it. Until now this topic was only something a few people could discuss.

> More specifically:
> 
> 1. The more modern APIs (generateCRMFRequest [1] on Firefox or 
> CertEnroll/XEnroll on Internet Explorer [2]) appear to offer more 
> options in general, for example, where to store the private key, is it 
> exportable, etc. (I haven't looked in details, but I suspect it could be 
> envisaged to use some existing key material from a software store or 
> smartcard too, for example.)
> This raises the question as to whether a tag is sufficient or 
> appropriate to express what's required for a CA, or if an API (and more 
> programming) is required.

I think there should be a strong preference for declarative ways of doing things if possible, ie to use HTML tags. Moving over to javascript has always seemed to me to be breaking one foundational element of the web.

As proof of the advantage of this way of working: the keygen tag has functioned across browser generations without change (I think).

Microsoft's ActiveX component on the other hand (as I understand required the calling of a Windows specific binary technology! The naming of a dll. This meant that when they changed the dll code that was written for browsers also had to change!

http://msdn.microsoft.com/en-us/library/bb931379%28VS.85%29.aspx

[[
Prior to Windows Vista, the Certificate Enrollment Control was implemented in Xenroll.dll. The Xenroll.dll library has been removed from the operating system and replaced by CertEnroll.dll.]]

The web is described with no reference to CPU architecture. I am seriously against bringing such low level aspects into day to day web programming. 

> 
> 2. The SPKAC format seems to be a legacy format. It doesn't really allow 
> to convey much information that CAs would expect, unlike other formats 
> used by the more modern APIs [3][4]. Perhaps it would be better to use 
> one of the newer formats instead. This might break the compatibility 
> with the pre-HTML 5 use of <keygen> (maybe another name than <keygen> in 
> HTML5 would be better?).

Perhaps extensions to keygen would be an interesting idea. 
At least it is document now.

> 
> Of course, the other big question is whether it's worth trying to 
> standardise this <keygen> tag if there's no intent of support from major 
> browser vendors (I have IE in mind here).

There are 3 browser vendors that have implemented it. That is enough of a precedent to standardise. If one browser vendor requires people to use binaries that tie people to their platform, it seems that it is quite clear what the reasons for that may be, and those reasons have in the past been deemed legally condemnable by both US and EU courts. Let us rather assume that that vendor decided to pursue that activity due to lack of standardisation in this space. 

Henry

> 
> Best wishes,
> 
> Bruno.
> 
> 
> [1] https://developer.mozilla.org/en/GenerateCRMFRequest
> [2] http://msdn.microsoft.com/en-us/library/aa374863%28VS.85%29.aspx
> [3] http://tools.ietf.org/html/rfc2986
> [4] http://tools.ietf.org/html/rfc4211


From andrew at deandrade.com.br  Tue Jan 19 08:59:32 2010
From: andrew at deandrade.com.br (Andrew de Andrade)
Date: Tue, 19 Jan 2010 14:59:32 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
Message-ID: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com>

I have an idea for a possible use case that as far as I can tell from
previous discussions on this list has not been considered or at least
not in the form I present below.

I have a friend whose company produces and licenses online games for
social networks such as Facebook, Orkut, etc.

One of the big problems with these games is the shear amount of static
content that must be delivered via HTTP once the application becomes
popular. In fact, if a game becomes popular overnight, the scaling
problems with this static content quickly becomes a technical and
financial problem.

To give you an idea of the magnitude and scope, more than 4 TB of
static content is streamed on a given day for one of the applications.
It's very likely that others with similarly popular applications have
encountered the same challenge.

When thinking about how to resolve this, I took my usual approach of
thinking how do we decentralize the content delivery and move towards
an agent-based message passing model so that we do not have a single
bottleneck technically and so we can dissipate the cost of delivering
this content.

My idea is to use web-sockets to allow the browser function more a
less like a bit-torrent client. Along with this, web-workers would
provide threads for handling the code that would function as a server,
serving the static content to peers also using the program.

If you have lots of users (thousands) accessing the same application,
you effectively have the equivalent of one torrent with a large swarm
of users, where the torrent is a package of the most frequently
requested static content. (I am assuming that the static content
requests follow a power law distribution, with only a few static files
being responsible for the overwhelming bulk of static data
transferred.).

As I have only superficial knowledge of the technologies involved and
the capabilities of HTML5, I passed this idea by a couple of
programmer friends to get their opinions. Generally they thought is
was a very interesting idea, but that as far as they know, the
specification as it stands now is incapable of accommodating such a
use case.

Together we arrived at a few criticisms of this idea that appear to be
resolvable:

-- Privacy issues
-- Security issues (man in the middle attack).
-- content labeling (i.e. how does the browser know what content is
truly static and therefore safe to share.)
-- content signing (i.e. is there some sort of hash that allows the
peers to confirm that the content has not been adulterated).
-- privacy issues

All in all, many of these issues have been solved by the many talented
programmers that have developed the current bit-torrent protocol,
algorithms and security features. The idea would simply to design the
HTML5 in such a way that it can permit the browser to function as a
full-fledged web-application bit-torrent client-server.

Privacy issues can be resolved by possibly defining something such as
"browser security zones" or "content label" whereby the content
provider (application developer) labels content (such as images and
CSS files) as safe to share (static content) and labels dynamic
content (such as personal photos, documents, etc.) as unsafe to share.

Also in discussing this, we come up with some potentially useful
extensions to this use case.

One would be the versioning of the "torrent file", such that the
torrent file could represent versions of the application. i.e. I
release an application that is version 1.02 and it becomes very
popular and there is a sizable swarm. At some point in the future I
release a new version with bug-fixes and additional features (such as
CSS sprites for the social network game). I should be able to
propagate this new version to all clients in the swarm so that over
some time window such as 2 to 4 hours all clients in the swarm
discover (via push or pull) the new version and end up downloading it
from the peers with the new version. The only security feature I could
see that would be required would be that once a client discovers that
their is a new version, it would hit up the original server to
download a signature/fingerprint file to verify that the new version
that it is downloading from its peers is legitimate.

The interesting thing about this idea is that it would permit large
portions of sites to exist in virtual form. Long-term I can imagine
large non-profit sites such as Wikipedia functioning on top of this
structure in such a way that it greatly reduces the amount of funding
necessary. It would be partially distributed with updates to wikipedia
being distributed via lots of tiny versions from super-nodes ? la a
Skype type P2P model.

This would also take a lot of power out of the hands of those telcos
that are anti-net neutrality. This feature would basically permit a
form of net neutrality by moving content to the fringes of the
network.

Let me know your thoughts and if you think this would be possible
using Web-sockets and web-workers, and if not, what changes would be
necessary to allow this to evolve.

Sincerely,

Andrew J. L. de Andrade
S?o Paulo, Brazil

(P.S. I consider myself a pretty technical person, but I don't really
program. I only dabble in programming as a hobby and to better
understand my colleagues. Feel free to be as technical as you want in
your reply, but please forgive me if I make or made any bonehead
mistakes.)

From dlwillson at gmail.com  Tue Jan 19 09:07:10 2010
From: dlwillson at gmail.com (dlwillson at gmail.com)
Date: Tue, 19 Jan 2010 17:07:10 +0000
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com>
Message-ID: <001485e7c6c4256f31047d8780ed@google.com>

as someone who just listens in and is not technically savvy ...but is  
helping build interactive television and film production to be browser  
based... I really want to hear more about this.

On Jan 19, 2010 11:59am, Andrew de Andrade <andrew at deandrade.com.br> wrote:
> I have an idea for a possible use case that as far as I can tell from

> previous discussions on this list has not been considered or at least

> not in the form I present below.



> I have a friend whose company produces and licenses online games for

> social networks such as Facebook, Orkut, etc.



> One of the big problems with these games is the shear amount of static

> content that must be delivered via HTTP once the application becomes

> popular. In fact, if a game becomes popular overnight, the scaling

> problems with this static content quickly becomes a technical and

> financial problem.



> To give you an idea of the magnitude and scope, more than 4 TB of

> static content is streamed on a given day for one of the applications.

> It's very likely that others with similarly popular applications have

> encountered the same challenge.



> When thinking about how to resolve this, I took my usual approach of

> thinking how do we decentralize the content delivery and move towards

> an agent-based message passing model so that we do not have a single

> bottleneck technically and so we can dissipate the cost of delivering

> this content.



> My idea is to use web-sockets to allow the browser function more a

> less like a bit-torrent client. Along with this, web-workers would

> provide threads for handling the code that would function as a server,

> serving the static content to peers also using the program.



> If you have lots of users (thousands) accessing the same application,

> you effectively have the equivalent of one torrent with a large swarm

> of users, where the torrent is a package of the most frequently

> requested static content. (I am assuming that the static content

> requests follow a power law distribution, with only a few static files

> being responsible for the overwhelming bulk of static data

> transferred.).



> As I have only superficial knowledge of the technologies involved and

> the capabilities of HTML5, I passed this idea by a couple of

> programmer friends to get their opinions. Generally they thought is

> was a very interesting idea, but that as far as they know, the

> specification as it stands now is incapable of accommodating such a

> use case.



> Together we arrived at a few criticisms of this idea that appear to be

> resolvable:



> -- Privacy issues

> -- Security issues (man in the middle attack).

> -- content labeling (ie how does the browser know what content is

> truly static and therefore safe to share.)

> -- content signing (ie is there some sort of hash that allows the

> peers to confirm that the content has not been adulterated).

> -- privacy issues



> All in all, many of these issues have been solved by the many talented

> programmers that have developed the current bit-torrent protocol,

> algorithms and security features. The idea would simply to design the

> HTML5 in such a way that it can permit the browser to function as a

> full-fledged web-application bit-torrent client-server.



> Privacy issues can be resolved by possibly defining something such as

> "browser security zones" or "content label" whereby the content

> provider (application developer) labels content (such as images and

> CSS files) as safe to share (static content) and labels dynamic

> content (such as personal photos, documents, etc.) as unsafe to share.



> Also in discussing this, we come up with some potentially useful

> extensions to this use case.



> One would be the versioning of the "torrent file", such that the

> torrent file could represent versions of the application. ie I

> release an application that is version 1.02 and it becomes very

> popular and there is a sizable swarm. At some point in the future I

> release a new version with bug-fixes and additional features (such as

> CSS sprites for the social network game). I should be able to

> propagate this new version to all clients in the swarm so that over

> some time window such as 2 to 4 hours all clients in the swarm

> discover (via push or pull) the new version and end up downloading it

> from the peers with the new version. The only security feature I could

> see that would be required would be that once a client discovers that

> their is a new version, it would hit up the original server to

> download a signature/fingerprint file to verify that the new version

> that it is downloading from its peers is legitimate.



> The interesting thing about this idea is that it would permit large

> portions of sites to exist in virtual form. Long-term I can imagine

> large non-profit sites such as Wikipedia functioning on top of this

> structure in such a way that it greatly reduces the amount of funding

> necessary. It would be partially distributed with updates to wikipedia

> being distributed via lots of tiny versions from super-nodes ? la a

> Skype type P2P model.



> This would also take a lot of power out of the hands of those telcos

> that are anti-net neutrality. This feature would basically permit a

> form of net neutrality by moving content to the fringes of the

> network.



> Let me know your thoughts and if you think this would be possible

> using Web-sockets and web-workers, and if not, what changes would be

> necessary to allow this to evolve.



> Sincerely,



> Andrew JL de Andrade

> S?o Paulo, Brazil



> (PS I consider myself a pretty technical person, but I don't really

> program. I only dabble in programming as a hobby and to better

> understand my colleagues. Feel free to be as technical as you want in

> your reply, but please forgive me if I make or made any bonehead

> mistakes.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100119/d8304a3d/attachment.htm>

From Bruno.Harbulot at manchester.ac.uk  Tue Jan 19 09:26:31 2010
From: Bruno.Harbulot at manchester.ac.uk (Bruno Harbulot)
Date: Tue, 19 Jan 2010 17:26:31 +0000
Subject: [whatwg] [foaf-protocols] keygen substitute for Windows?
In-Reply-To: <2272F99A-2D1A-46BB-95ED-215CA6AA4A70@bblfish.net>
References: <2272F99A-2D1A-46BB-95ED-215CA6AA4A70@bblfish.net>
Message-ID: <4B55EB47.5020103@manchester.ac.uk>

Hello Henry,


Story Henry wrote:
>> Whilst I'm very supportive of having a key-generation mechanism in the 
>> browser, I'm now not entirely sure the <keygen> tag, at least as a 
>> legacy of the Netscape <keygen> tag, is the correct approach.
> 
> I think that part of the html5 goals is to describe how browsers actually work, without going into endless debates about how they SHOULD work. Given that Netscape, Firefox, Opera and Safari implement the <keygen> tag - and have done so for a very long time - it seems quite reasonable to describe that behaviour in html5. 

As far as I understand, <keygen> was, if not officially deprecated, at 
least not recommended in Firefox, since the introduction of 
generateCRMFRequest.


I wouldn't say <keygen> is greatly implemented, even in Firefox.
Consider the following HTML document:

<html>
<head>
<script type="text/javascript">
function writeTagName() {
   document.getElementById("title").appendChild(
       document.createTextNode(document.getElementById("keygen").tagName));
}
</script>
</head>
<body onload="writeTagName()">
<h1 id="title"></h1><keygen id="keygen" />
</body>
</html>


In Firefox, this prints "SELECT": <keygen> is transformed on the fly 
into <select>, which breaks DOM usage. This is something that Opera and 
Safari don't do.


Even across Firefox, Opera and Safari, the behaviour of keygen isn't 
uniform.
The choice of "High grade" and "Low grade" is left to the appreciation 
of Firefox, whereas a proper CA would certainly require a bit more 
precision. In contrast, Opera offers a much longer list of key sizes, 
defaulting somewhere around 1500 bits (I don't have Opera on this machine).


One of the other points (which I think I've seen mentioned on this 
mailing list) is that <keygen> doesn't really fit as a form element. 
There's a number of parameters that can be set to generate a pair of 
keys. Why assume that the keysize (and only the keysize) is to be chosen 
by the user while all the others are set within the page? It might make 
sense, in some circumstances to have it all fixed on the page (by the 
service provider) or to let the user also chose whether to use RSA or 
RSA for example. (Along the same argument, why assume 
'md5WithRSAEncryption' and not SHA-1?)
It just looks like it doesn't belong in a form this way.


I'd go even further that this in fact: why always *generate* a key-pair?
Whether it's used for an PKIX CA or FOAF+SSL, why not let the option to 
use an existing pair of key available in whatever key store the browser 
has access to? (That would in fact be quite useful for FOAF+SSL 
applications.)
If I send a CSR to a CA for signing, does it (even can it) know where 
those keys have been generated? Perhaps it might make more sense in some 
cases to re-use an existing pair of keys available in a smart-card or 
even some software key store.


> Once this is described it is then possible to find ways either to extend on the current behaviour or to find ways to improve it. Until now this topic was only something a few people could discuss.
> 
>> More specifically:
>>
>> 1. The more modern APIs (generateCRMFRequest [1] on Firefox or 
>> CertEnroll/XEnroll on Internet Explorer [2]) appear to offer more 
>> options in general, for example, where to store the private key, is it 
>> exportable, etc. (I haven't looked in details, but I suspect it could be 
>> envisaged to use some existing key material from a software store or 
>> smartcard too, for example.)
>> This raises the question as to whether a tag is sufficient or 
>> appropriate to express what's required for a CA, or if an API (and more 
>> programming) is required.
> 
> I think there should be a strong preference for declarative ways of doing things if possible, ie to use HTML tags. Moving over to javascript has always seemed to me to be breaking one foundational element of the web.

The problem is that there's only so much one can do declaratively in 
this field, precisely because some of this involves the security 
architecture of the overall system in which the browser runs, which by 
essence will have parts that do not belong within the browser, or at 
least ought to be outside the direct reach of what HTML can do (Windows 
certificate store, Apple Keychain...).


> As proof of the advantage of this way of working: the keygen tag has functioned across browser generations without change (I think).

Well, I haven't followed the complete history of generateCRMFRequest, 
but there must be a reason why it was invented as a successor of 
<keygen>. I have no idea what the ratio of modern CAs that still use 
<keygen> vs. those that use generateCRMFRequest is. The one I use 
regularly seems to use generateCRMFRequest.


> Microsoft's ActiveX component on the other hand (as I understand required the calling of a Windows specific binary technology! The naming of a dll. This meant that when they changed the dll code that was written for browsers also had to change!
> 
> http://msdn.microsoft.com/en-us/library/bb931379%28VS.85%29.aspx
> 
> [[
> Prior to Windows Vista, the Certificate Enrollment Control was implemented in Xenroll.dll. The Xenroll.dll library has been removed from the operating system and replaced by CertEnroll..dll.]]
> 
> The web is described with no reference to CPU architecture. I am seriously against bringing such low level aspects into day to day web programming. 

As Adrian Bateman from Microsoft said in [5]: "We are prepared to 
consider creating common APIs that allow interoperability across 
browsers and also address customers' real needs either in a future 
version of the spec or as a separate work item."

Perhaps that's the way to go, having a common API similar to what's done 
for XMLHttpRequest.

While I must admit it took me a while to figure out how to write [6] for 
CertEnroll.dll, this wasn't infeasible. Perhaps a similar example on 
MSDN would have helped.

The change you're talking about isn't just a change of DLL, it's a more 
fundamental change in the handling of certificate in the overall 
infrastructure of the operating system. (Yes, a common API with sensible 
default values and what needs to be OS-specific customised there would 
help.)

You could say that Safari handles both <keygen> and the OSX's Keychain 
infrastructure, but this seems to come at the expense of certificates 
being almost unusable in the current implementation [7].


>> 2. The SPKAC format seems to be a legacy format. It doesn't really allow 
>> to convey much information that CAs would expect, unlike other formats 
>> used by the more modern APIs [3][4]. Perhaps it would be better to use 
>> one of the newer formats instead. This might break the compatibility 
>> with the pre-HTML 5 use of <keygen> (maybe another name than <keygen> in 
>> HTML5 would be better?).
> 
> Perhaps extensions to keygen would be an interesting idea. 
> At least it is document now.

I think it probably shouldn't be. Having a separate effort along the 
lines of that for XMLHttpRequest, involving CA implementors and security 
experts sounds like a better plan, rather than crippling HTML 5 with 
something that not quite fit for purpose.


>> Of course, the other big question is whether it's worth trying to 
>> standardise this <keygen> tag if there's no intent of support from major 
>> browser vendors (I have IE in mind here).
> 
> There are 3 browser vendors that have implemented it. That is enough of a precedent to standardise. If one browser vendor requires people to use binaries that tie people to their platform, it seems that it is quite clear what the reasons for that may be, and those reasons have in the past been deemed legally condemnable by both US and EU courts. Let us rather assume that that vendor decided to pursue that activity due to lack of standardisation in this space. 

I think you completely misunderstand the XEnroll vs. CertEnroll issue. 
This isn't about "binaries that tie people to their platform", this is 
about a change of API that reflects new capabilities offered by the 
platforms. The introduction of more flexibility in CertEnroll may 
reflect some actual user requirements, rather than an evil will to tie 
users to the platform. Again, according to [5], MS doesn't seem against 
a standardisation effort in that domain.

(Talking about API evolution, as far as FOAF+SSL is concerned, if 
CertEnroll was able to generated a suitable key-pair produce a 
self-signed certificate with the attributes we want, that would be a 
more convenient way than the <keygen>/pseudo-CA approach.)


Whilst, like many others, I have expressed frustration with Internet 
Explorer's own interpretation of various web standards, I can't really 
blame MS on this one. I mostly agree with Adrian Bateman's comments in 
[5], in fact.
You had written down the ActiveX mechanism as a "hack" for MSIE on the 
ESW wiki page before I edited it, but frankly, I'd consider Netscape's 
<keygen> to be as much as a hack, just made by IE's competitor. I might 
get it wrong, but considering the earliest mention of PKCS#10 I've seen 
dates from 1993 [8] and the earliest mention of <keygen> seems to be in 
the 1998 Netscape doc [9], time by which PKCS#10 was in an RFC [10], 
perhaps Netscape could have followed that standard at the time too 
instead of using SPKAC. I'm not aware of the full history of these 
standards, but I find it hard to make a judgement on who's right and 
who's wrong here.
If IE doesn't support <keygen>, it would just be too easy to be anti-MS 
and claim "they don't support standards as usual" once this <keygen> is 
in HTML 5.


I'm quite happy to have <keygen> now, since it helps demonstrate our 
FOAF+SSL work works across browsers, but I have reservations regarding 
its appropriateness as a general certificate request tool for the HTML 
of the future.


Best wishes,

Bruno.


>> [1] https://developer.mozilla.org/en/GenerateCRMFRequest
>> [2] http://msdn.microsoft.com/en-us/library/aa374863%28VS.85%29.aspx
>> [3] http://tools.ietf.org/html/rfc2986
>> [4] http://tools.ietf.org/html/rfc4211

[5] http://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
[6] 
http://github.com/harbulot/keygenapp/blob/master/samplewebapp/src/main/webapp/crosskeygen.js
[7] http://lists.apple.com/archives/apple-cdsa/2009/Apr/msg00041.html
[8] http://www.rsa.com/rsalabs/node.asp?id=2132
[9] 
http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503
[10] http://tools.ietf.org/html/rfc2314


From andrew at deandrade.com.br  Tue Jan 19 09:36:49 2010
From: andrew at deandrade.com.br (Andrew de Andrade)
Date: Tue, 19 Jan 2010 15:36:49 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <001485e7c6c4256f31047d8780ed@google.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com> 
	<001485e7c6c4256f31047d8780ed@google.com>
Message-ID: <42b395981001190936t26a03a5cgd5c9b9c054fe9b9b@mail.gmail.com>

I emailed this idea to my friend Patrich Chanezon
(<http://wordpress.chanezon.com/>, @chanezon)  from Google a few weeks
ago to get his initial thoughts on the idea as he has been posting
lots of links related to web sockets lately.

He suggested that the idea would be be implemented at the browser
level in C++. He also said that there are many privacy issues,
especially for social apps, with implementing P2P at the application
layer. Finally he added that his colleague at Google, Brad Neuberg
(<http://codinginparadise.org/>, @bradneuberg), had a related project
named Paper Airplane that he worked on from 2001 to 2004.

Here's the link to Brad's paper on Paper Airplane from 2005.

http://codinginparadise.org/paperairplane/

-- Andrew J L de Andrade
@andrewdeandrade

On Tue, Jan 19, 2010 at 3:07 PM,  <dlwillson at gmail.com> wrote:
> as someone who just listens in and is not technically savvy ...but is
> helping build interactive television and film production to be browser
> based... I really want to hear more about this.
>
> On Jan 19, 2010 11:59am, Andrew de Andrade <andrew at deandrade.com.br> wrote:
>> I have an idea for a possible use case that as far as I can tell from
>>
>> previous discussions on this list has not been considered or at least
>>
>> not in the form I present below.
>>
>>
>>
>> I have a friend whose company produces and licenses online games for
>>
>> social networks such as Facebook, Orkut, etc.
>>
>>
>>
>> One of the big problems with these games is the shear amount of static
>>
>> content that must be delivered via HTTP once the application becomes
>>
>> popular. In fact, if a game becomes popular overnight, the scaling
>>
>> problems with this static content quickly becomes a technical and
>>
>> financial problem.
>>
>>
>>
>> To give you an idea of the magnitude and scope, more than 4 TB of
>>
>> static content is streamed on a given day for one of the applications.
>>
>> It's very likely that others with similarly popular applications have
>>
>> encountered the same challenge.
>>
>>
>>
>> When thinking about how to resolve this, I took my usual approach of
>>
>> thinking how do we decentralize the content delivery and move towards
>>
>> an agent-based message passing model so that we do not have a single
>>
>> bottleneck technically and so we can dissipate the cost of delivering
>>
>> this content.
>>
>>
>>
>> My idea is to use web-sockets to allow the browser function more a
>>
>> less like a bit-torrent client. Along with this, web-workers would
>>
>> provide threads for handling the code that would function as a server,
>>
>> serving the static content to peers also using the program.
>>
>>
>>
>> If you have lots of users (thousands) accessing the same application,
>>
>> you effectively have the equivalent of one torrent with a large swarm
>>
>> of users, where the torrent is a package of the most frequently
>>
>> requested static content. (I am assuming that the static content
>>
>> requests follow a power law distribution, with only a few static files
>>
>> being responsible for the overwhelming bulk of static data
>>
>> transferred.).
>>
>>
>>
>> As I have only superficial knowledge of the technologies involved and
>>
>> the capabilities of HTML5, I passed this idea by a couple of
>>
>> programmer friends to get their opinions. Generally they thought is
>>
>> was a very interesting idea, but that as far as they know, the
>>
>> specification as it stands now is incapable of accommodating such a
>>
>> use case.
>>
>>
>>
>> Together we arrived at a few criticisms of this idea that appear to be
>>
>> resolvable:
>>
>>
>>
>> -- Privacy issues
>>
>> -- Security issues (man in the middle attack).
>>
>> -- content labeling (i.e. how does the browser know what content is
>>
>> truly static and therefore safe to share.)
>>
>> -- content signing (i.e. is there some sort of hash that allows the
>>
>> peers to confirm that the content has not been adulterated).
>>
>> -- privacy issues
>>
>>
>>
>> All in all, many of these issues have been solved by the many talented
>>
>> programmers that have developed the current bit-torrent protocol,
>>
>> algorithms and security features. The idea would simply to design the
>>
>> HTML5 in such a way that it can permit the browser to function as a
>>
>> full-fledged web-application bit-torrent client-server.
>>
>>
>>
>> Privacy issues can be resolved by possibly defining something such as
>>
>> "browser security zones" or "content label" whereby the content
>>
>> provider (application developer) labels content (such as images and
>>
>> CSS files) as safe to share (static content) and labels dynamic
>>
>> content (such as personal photos, documents, etc.) as unsafe to share.
>>
>>
>>
>> Also in discussing this, we come up with some potentially useful
>>
>> extensions to this use case.
>>
>>
>>
>> One would be the versioning of the "torrent file", such that the
>>
>> torrent file could represent versions of the application. i.e. I
>>
>> release an application that is version 1.02 and it becomes very
>>
>> popular and there is a sizable swarm. At some point in the future I
>>
>> release a new version with bug-fixes and additional features (such as
>>
>> CSS sprites for the social network game). I should be able to
>>
>> propagate this new version to all clients in the swarm so that over
>>
>> some time window such as 2 to 4 hours all clients in the swarm
>>
>> discover (via push or pull) the new version and end up downloading it
>>
>> from the peers with the new version. The only security feature I could
>>
>> see that would be required would be that once a client discovers that
>>
>> their is a new version, it would hit up the original server to
>>
>> download a signature/fingerprint file to verify that the new version
>>
>> that it is downloading from its peers is legitimate.
>>
>>
>>
>> The interesting thing about this idea is that it would permit large
>>
>> portions of sites to exist in virtual form. Long-term I can imagine
>>
>> large non-profit sites such as Wikipedia functioning on top of this
>>
>> structure in such a way that it greatly reduces the amount of funding
>>
>> necessary. It would be partially distributed with updates to wikipedia
>>
>> being distributed via lots of tiny versions from super-nodes ? la a
>>
>> Skype type P2P model.
>>
>>
>>
>> This would also take a lot of power out of the hands of those telcos
>>
>> that are anti-net neutrality. This feature would basically permit a
>>
>> form of net neutrality by moving content to the fringes of the
>>
>> network.
>>
>>
>>
>> Let me know your thoughts and if you think this would be possible
>>
>> using Web-sockets and web-workers, and if not, what changes would be
>>
>> necessary to allow this to evolve.
>>
>>
>>
>> Sincerely,
>>
>>
>>
>> Andrew J. L. de Andrade
>>
>> S?o Paulo, Brazil
>>
>>
>>
>> (P.S. I consider myself a pretty technical person, but I don't really
>>
>> program. I only dabble in programming as a hobby and to better
>>
>> understand my colleagues. Feel free to be as technical as you want in
>>
>> your reply, but please forgive me if I make or made any bonehead
>>
>> mistakes.)
>>

From henry.story at bblfish.net  Tue Jan 19 11:23:24 2010
From: henry.story at bblfish.net (Story Henry)
Date: Tue, 19 Jan 2010 19:23:24 +0000
Subject: [whatwg] [foaf-protocols] keygen substitute for Windows?
In-Reply-To: <4B55EB47.5020103@manchester.ac.uk>
References: <2272F99A-2D1A-46BB-95ED-215CA6AA4A70@bblfish.net>
	<4B55EB47.5020103@manchester.ac.uk>
Message-ID: <CE9CE9E6-621B-4EDD-8BDF-CB56ACB25BFA@bblfish.net>


On 19 Jan 2010, at 17:26, Bruno Harbulot wrote:

> Hello Henry,
> 
> 
> Story Henry wrote:
>>> Whilst I'm very supportive of having a key-generation mechanism in the browser, I'm now not entirely sure the <keygen> tag, at least as a legacy of the Netscape <keygen> tag, is the correct approach.
>> I think that part of the html5 goals is to describe how browsers actually work, without going into endless debates about how they SHOULD work. Given that Netscape, Firefox, Opera and Safari implement the <keygen> tag - and have done so for a very long time - it seems quite reasonable to describe that behaviour in html5. 
> 
> As far as I understand, <keygen> was, if not officially deprecated, at least not recommended in Firefox, since the introduction of generateCRMFRequest.
> 
> 
> I wouldn't say <keygen> is greatly implemented, even in Firefox.
> Consider the following HTML document:
> 
> <html>
> <head>
> <script type="text/javascript">
> function writeTagName() {
>  document.getElementById("title").appendChild(
>      document.createTextNode(document.getElementById("keygen").tagName));
> }
> </script>
> </head>
> <body onload="writeTagName()">
> <h1 id="title"></h1><keygen id="keygen" />
> </body>
> </html>
> 
> 
> In Firefox, this prints "SELECT": <keygen> is transformed on the fly into <select>, which breaks DOM usage. This is something that Opera and Safari don't do.

(( should not <keygen> be inside a <form> ? ))

> Even across Firefox, Opera and Safari, the behaviour of keygen isn't uniform.

I think they rarely are. This is why the WhatWG is documenting these inconsistencies...
The trick is to find overlaps in the behaviour, the differences, and the work out from there what options for development exist.

> The choice of "High grade" and "Low grade" is left to the appreciation of Firefox, whereas a proper CA would certainly require a bit more precision. In contrast, Opera offers a much longer list of key sizes, defaulting somewhere around 1500 bits (I don't have Opera on this machine).

That is not a problem if the browser user interface is different. Perhaps the different browsers have different expectations on their users abilities. Perhaps keygen can be later extended to make it possible to be more precise. It seems to me that keygen is there to produce a key in a form, and send it with the form. How it gets the key is a lot less important.


> One of the other points (which I think I've seen mentioned on this mailing list) is that <keygen> doesn't really fit as a form element. There's a number of parameters that can be set to generate a pair of keys. Why assume that the keysize (and only the keysize) is to be chosen by the user while all the others are set within the page? It might make sense, in some circumstances to have it all fixed on the page (by the service provider) or to let the user also chose whether to use RSA or RSA for example. (Along the same argument, why assume 'md5WithRSAEncryption' and not SHA-1?)
> It just looks like it doesn't belong in a form this way.

But certainly that type of thing could be added to a <keygen> extension?


> I'd go even further that this in fact: why always *generate* a key-pair?
> Whether it's used for an PKIX CA or FOAF+SSL, why not let the option to use an existing pair of key available in whatever key store the browser has access to? (That would in fact be quite useful for FOAF+SSL applications.)
> If I send a CSR to a CA for signing, does it (even can it) know where those keys have been generated? Perhaps it might make more sense in some cases to re-use an existing pair of keys available in a smart-card or even some software key store.

Good idea. Since the private keys don't leave the store, the browser could ask the user to re-use a key. In fact I would say that if a browser vendor allowed a user to do this, he would not necessarily be going against the spirit of keygen.

>> Once this is described it is then possible to find ways either to extend on the current behaviour or to find ways to improve it. Until now this topic was only something a few people could discuss.
>>> More specifically:
>>> 
>>> 1. The more modern APIs (generateCRMFRequest [1] on Firefox or CertEnroll/XEnroll on Internet Explorer [2]) appear to offer more options in general, for example, where to store the private key, is it exportable, etc. (I haven't looked in details, but I suspect it could be envisaged to use some existing key material from a software store or smartcard too, for example.)
>>> This raises the question as to whether a tag is sufficient or appropriate to express what's required for a CA, or if an API (and more programming) is required.
>> I think there should be a strong preference for declarative ways of doing things if possible, ie to use HTML tags. Moving over to javascript has always seemed to me to be breaking one foundational element of the web.
> 
> The problem is that there's only so much one can do declaratively in this field, precisely because some of this involves the security architecture of the overall system in which the browser runs, which by essence will have parts that do not belong within the browser, or at least ought to be outside the direct reach of what HTML can do (Windows certificate store, Apple Keychain...).

Why would using the Apple Keychain be a problem? Firefox could ask the Apple Keychain for a list of public certificates, and yet reuse a public key from there as you suggested above. Or Firefox could add a key to such a keychain. One would hope that would be possible at least. Indeed the nice thing about the declarative tag, is that it could hide all these implementation issues.

> 
>> As proof of the advantage of this way of working: the keygen tag has functioned across browser generations without change (I think).
> 
> Well, I haven't followed the complete history of generateCRMFRequest, but there must be a reason why it was invented as a successor of <keygen>. I have no idea what the ratio of modern CAs that still use <keygen> vs. those that use generateCRMFRequest is. The one I use regularly seems to use generateCRMFRequest.

It would be interesting indeed to learn about the reason for this. 
But it would not be surprising that generateCRMFRequest got adopted more recently, as it has been documented. Browser manufacturers seem to have a lot less problems with making special JavaScript functions and documenting those than they do creating new tag elements.

> 
> 
>> Microsoft's ActiveX component on the other hand (as I understand required the calling of a Windows specific binary technology! The naming of a dll. This meant that when they changed the dll code that was written for browsers also had to change!
>> http://msdn.microsoft.com/en-us/library/bb931379%28VS.85%29.aspx
>> [[
>> Prior to Windows Vista, the Certificate Enrollment Control was implemented in Xenroll.dll. The Xenroll.dll library has been removed from the operating system and replaced by CertEnroll..dll.]]
>> The web is described with no reference to CPU architecture. I am seriously against bringing such low level aspects into day to day web programming. 
> 
> As Adrian Bateman from Microsoft said in [5]: "We are prepared to consider creating common APIs that allow interoperability across browsers and also address customers' real needs either in a future version of the spec or as a separate work item."
> 
> Perhaps that's the way to go, having a common API similar to what's done for XMLHttpRequest.
> 
> While I must admit it took me a while to figure out how to write [6] for CertEnroll.dll, this wasn't infeasible. Perhaps a similar example on MSDN would have helped.

I am not flattering you Bruno, if I say that you are extremely knowledgeable in cryptography. Knowing cryptography, javascript, html and more is a lot to ask people. Much simple really would be if we could all have <keygen> work across browsers, and even better an improved keygen. 

JavaScript is a problem just for one reason: it can be switched off.

> The change you're talking about isn't just a change of DLL, it's a more fundamental change in the handling of certificate in the overall infrastructure of the operating system. (Yes, a common API with sensible default values and what needs to be OS-specific customised there would help.)
> 
> You could say that Safari handles both <keygen> and the OSX's Keychain infrastructure, but this seems to come at the expense of certificates being almost unusable in the current implementation [7].

yes, that's a tricky problem of how to get a lower level to make use of an upper level User Interface to get the user to make a choice. But that is a problem at the connection level, when the user has to choose which certificate he wishes to use for client side certificate connection. 

This is not a problem at the certificate creation level which is what we are discussing here.

>>> 2. The SPKAC format seems to be a legacy format. It doesn't really allow to convey much information that CAs would expect, unlike other formats used by the more modern APIs [3][4]. Perhaps it would be better to use one of the newer formats instead. This might break the compatibility with the pre-HTML 5 use of <keygen> (maybe another name than <keygen> in HTML5 would be better?).
>> Perhaps extensions to keygen would be an interesting idea. At least it is document now.
> 
> I think it probably shouldn't be. Having a separate effort along the lines of that for XMLHttpRequest, involving CA implementors and security experts sounds like a better plan, rather than crippling HTML 5 with something that not quite fit for purpose.

I am still not convinced you have made the case that it is not fit for purpose. The <keygen> tag is currently very basic. You would have to prove that no way of extending it could make it fit for purpose. That is much more difficult to prove. Also it took us one year to find the solution you have put together, and there are many more browsers coming out there on the market every day. I really would rather we all started working on simplifying life, so that we can deal with real problems (and there are an infinity of those waiting for us), rather than artificial problems such as these. 

Furthermore you would need to show that the keygen tag with its current limitations is not at all fit for a very broad range of purposes. Seems to me that one can get a lot done with the current keygen and that it is very useful.

> 
>>> Of course, the other big question is whether it's worth trying to standardise this <keygen> tag if there's no intent of support from major browser vendors (I have IE in mind here).
>> There are 3 browser vendors that have implemented it. That is enough of a precedent to standardise. If one browser vendor requires people to use binaries that tie people to their platform, it seems that it is quite clear what the reasons for that may be, and those reasons have in the past been deemed legally condemnable by both US and EU courts. Let us rather assume that that vendor decided to pursue that activity due to lack of standardisation in this space. 
> 
> I think you completely misunderstand the XEnroll vs. CertEnroll issue. This isn't about "binaries that tie people to their platform", this is about a change of API that reflects new capabilities offered by the platforms. The introduction of more flexibility in CertEnroll may reflect some actual user requirements, rather than an evil will to tie users to the platform. Again, according to [5], MS doesn't seem against a standardisation effort in that domain.

Well good. 
But again if I look at [5] I don't see that this shows that one cannot enhance keygen to make it do all the things listed by it or by you. Those all seem to be requests for improvement which could easily be specified.

> (Talking about API evolution, as far as FOAF+SSL is concerned, if CertEnroll was able to generated a suitable key-pair produce a self-signed certificate with the attributes we want, that would be a more convenient way than the <keygen>/pseudo-CA approach.)

Yes, foaf+ssl can work with self signed certificates. So I am not defending keygen out of selfish reasons. On the other hand for foaf+ssl to work well, the public key needs to be published on a remote server in RDF. So the interaction with a server is necessary - even if the server is a local machine - for desktop machines with fixed ip addresses. 

> 
> Whilst, like many others, I have expressed frustration with Internet Explorer's own interpretation of various web standards, I can't really blame MS on this one. I mostly agree with Adrian Bateman's comments in [5], in fact.
> You had written down the ActiveX mechanism as a "hack" for MSIE on the ESW wiki page before I edited it, but frankly, I'd consider Netscape's <keygen> to be as much as a hack, just made by IE's competitor. I might get it wrong, but considering the earliest mention of PKCS#10 I've seen dates from 1993 [8] and the earliest mention of <keygen> seems to be in the 1998 Netscape doc [9], time by which PKCS#10 was in an RFC [10], perhaps Netscape could have followed that standard at the time too instead of using SPKAC.

yes, SPKAC seems a bit odd of a decision.

But at least it is a data format. ActiveX ties the browser to a CPU architecture. That is a different kind of bug.


> I'm not aware of the full history of these standards, but I find it hard to make a judgement on who's right and who's wrong here.
> If IE doesn't support <keygen>, it would just be too easy to be anti-MS and claim "they don't support standards as usual" once this <keygen> is in HTML 5.

Blaming Microsoft if they don't implement standards before they are standard won't convince anyone of independent judgement. But clearly it is not a good reason not to find good standard solutions because one is worried that they have not implemented that non existent standard in the past. For all I know M$ may be quite happy with a good solution in this space...

> I'm quite happy to have <keygen> now, since it helps demonstrate our FOAF+SSL work works across browsers, but I have reservations regarding its appropriateness as a general certificate request tool for the HTML of the future.

yes, certainly it can be improved. We should leave that magic up to the WhatWG who have extensive experience in the space of taking incompatible behaviours and writing specs that work with usage towards a better future.

Thanks for all these pointers, 


	I am sure this will be of great help to this group.


	Henry

> 
> 
> Best wishes,
> 
> Bruno.
> 
> 
>>> [1] https://developer.mozilla.org/en/GenerateCRMFRequest
>>> [2] http://msdn.microsoft.com/en-us/library/aa374863%28VS.85%29.aspx
>>> [3] http://tools.ietf.org/html/rfc2986
>>> [4] http://tools.ietf.org/html/rfc4211
> 
> [5] http://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
> [6] http://github.com/harbulot/keygenapp/blob/master/samplewebapp/src/main/webapp/crosskeygen.js
> [7] http://lists.apple.com/archives/apple-cdsa/2009/Apr/msg00041.html
> [8] http://www.rsa.com/rsalabs/node.asp?id=2132
> [9] http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503
> [10] http://tools.ietf.org/html/rfc2314
> 


From melvincarvalho at gmail.com  Tue Jan 19 11:31:22 2010
From: melvincarvalho at gmail.com (Melvin Carvalho)
Date: Tue, 19 Jan 2010 20:31:22 +0100
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com>
Message-ID: <9178f78c1001191131i7fdd4dacgb98cae78535423e1@mail.gmail.com>

On Tue, Jan 19, 2010 at 5:59 PM, Andrew de Andrade
<andrew at deandrade.com.br>wrote:

> I have an idea for a possible use case that as far as I can tell from
> previous discussions on this list has not been considered or at least
> not in the form I present below.
>
> I have a friend whose company produces and licenses online games for
> social networks such as Facebook, Orkut, etc.
>
> One of the big problems with these games is the shear amount of static
> content that must be delivered via HTTP once the application becomes
> popular. In fact, if a game becomes popular overnight, the scaling
> problems with this static content quickly becomes a technical and
> financial problem.
>
> To give you an idea of the magnitude and scope, more than 4 TB of
> static content is streamed on a given day for one of the applications.
> It's very likely that others with similarly popular applications have
> encountered the same challenge.
>
> When thinking about how to resolve this, I took my usual approach of
> thinking how do we decentralize the content delivery and move towards
> an agent-based message passing model so that we do not have a single
> bottleneck technically and so we can dissipate the cost of delivering
> this content.
>
> My idea is to use web-sockets to allow the browser function more a
> less like a bit-torrent client. Along with this, web-workers would
> provide threads for handling the code that would function as a server,
> serving the static content to peers also using the program.
>
> If you have lots of users (thousands) accessing the same application,
> you effectively have the equivalent of one torrent with a large swarm
> of users, where the torrent is a package of the most frequently
> requested static content. (I am assuming that the static content
> requests follow a power law distribution, with only a few static files
> being responsible for the overwhelming bulk of static data
> transferred.).
>
> As I have only superficial knowledge of the technologies involved and
> the capabilities of HTML5, I passed this idea by a couple of
> programmer friends to get their opinions. Generally they thought is
> was a very interesting idea, but that as far as they know, the
> specification as it stands now is incapable of accommodating such a
> use case.
>
> Together we arrived at a few criticisms of this idea that appear to be
> resolvable:
>
> -- Privacy issues
> -- Security issues (man in the middle attack).
> -- content labeling (i.e. how does the browser know what content is
> truly static and therefore safe to share.)
> -- content signing (i.e. is there some sort of hash that allows the
> peers to confirm that the content has not been adulterated).
> -- privacy issues
>

Yes I sort of see this kind of thing as the future of the web.  There's an
argument to say that it should have been done 10 or even 20 years ago, but
we're still not there.  I think websockets will be a huge step forward for
this kind of thing.  One issue still remains NAT traversal, perhaps this is
what has held developers back, though notable exceptions such as skype have
provided a great UX here.

Gaming is one obvious application for this, which in many ways is the
pinnacle of software engineering.

I see this kind of technique really bringing linked data into its own
(including RDFa) where browsers become more data aware and more socially
aware and are able interchage relevant information.   Something like FOAF
(as a means to mark up data) is well suited to provide a distributed network
of peers, can certainly handle global namespaced data naming, and is getting
quite close to solving privacy and security challenges.

Im really looking forward to seeing what people start to build on top of
this technology, and your idea certainly sounds exciting.


>
> All in all, many of these issues have been solved by the many talented
> programmers that have developed the current bit-torrent protocol,
> algorithms and security features. The idea would simply to design the
> HTML5 in such a way that it can permit the browser to function as a
> full-fledged web-application bit-torrent client-server.
>
> Privacy issues can be resolved by possibly defining something such as
> "browser security zones" or "content label" whereby the content
> provider (application developer) labels content (such as images and
> CSS files) as safe to share (static content) and labels dynamic
> content (such as personal photos, documents, etc.) as unsafe to share.
>
> Also in discussing this, we come up with some potentially useful
> extensions to this use case.
>
> One would be the versioning of the "torrent file", such that the
> torrent file could represent versions of the application. i.e. I
> release an application that is version 1.02 and it becomes very
> popular and there is a sizable swarm. At some point in the future I
> release a new version with bug-fixes and additional features (such as
> CSS sprites for the social network game). I should be able to
> propagate this new version to all clients in the swarm so that over
> some time window such as 2 to 4 hours all clients in the swarm
> discover (via push or pull) the new version and end up downloading it
> from the peers with the new version. The only security feature I could
> see that would be required would be that once a client discovers that
> their is a new version, it would hit up the original server to
> download a signature/fingerprint file to verify that the new version
> that it is downloading from its peers is legitimate.
>
> The interesting thing about this idea is that it would permit large
> portions of sites to exist in virtual form. Long-term I can imagine
> large non-profit sites such as Wikipedia functioning on top of this
> structure in such a way that it greatly reduces the amount of funding
> necessary. It would be partially distributed with updates to wikipedia
> being distributed via lots of tiny versions from super-nodes ? la a
> Skype type P2P model.
>
> This would also take a lot of power out of the hands of those telcos
> that are anti-net neutrality. This feature would basically permit a
> form of net neutrality by moving content to the fringes of the
> network.
>
> Let me know your thoughts and if you think this would be possible
> using Web-sockets and web-workers, and if not, what changes would be
> necessary to allow this to evolve.
>
> Sincerely,
>
> Andrew J. L. de Andrade
> S?o Paulo, Brazil
>
> (P.S. I consider myself a pretty technical person, but I don't really
> program. I only dabble in programming as a hobby and to better
> understand my colleagues. Feel free to be as technical as you want in
> your reply, but please forgive me if I make or made any bonehead
> mistakes.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100119/a7af5332/attachment-0001.htm>

From andrew at deandrade.com.br  Tue Jan 19 11:54:27 2010
From: andrew at deandrade.com.br (Andrew de Andrade)
Date: Tue, 19 Jan 2010 17:54:27 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <9178f78c1001191131i7fdd4dacgb98cae78535423e1@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com> 
	<9178f78c1001191131i7fdd4dacgb98cae78535423e1@mail.gmail.com>
Message-ID: <42b395981001191154g660174c6j99cc8ad90027153@mail.gmail.com>

On Tue, Jan 19, 2010 at 5:31 PM, Melvin Carvalho
<melvincarvalho at gmail.com> wrote:
>
>
> On Tue, Jan 19, 2010 at 5:59 PM, Andrew de Andrade <andrew at deandrade.com.br>
> wrote:
>>
>> I have an idea for a possible use case that as far as I can tell from
>> previous discussions on this list has not been considered or at least
>> not in the form I present below.
>>
>> I have a friend whose company produces and licenses online games for
>> social networks such as Facebook, Orkut, etc.
>>
>> One of the big problems with these games is the shear amount of static
>> content that must be delivered via HTTP once the application becomes
>> popular. In fact, if a game becomes popular overnight, the scaling
>> problems with this static content quickly becomes a technical and
>> financial problem.
>>
>> To give you an idea of the magnitude and scope, more than 4 TB of
>> static content is streamed on a given day for one of the applications.
>> It's very likely that others with similarly popular applications have
>> encountered the same challenge.
>>
>> When thinking about how to resolve this, I took my usual approach of
>> thinking how do we decentralize the content delivery and move towards
>> an agent-based message passing model so that we do not have a single
>> bottleneck technically and so we can dissipate the cost of delivering
>> this content.
>>
>> My idea is to use web-sockets to allow the browser function more a
>> less like a bit-torrent client. Along with this, web-workers would
>> provide threads for handling the code that would function as a server,
>> serving the static content to peers also using the program.
>>
>> If you have lots of users (thousands) accessing the same application,
>> you effectively have the equivalent of one torrent with a large swarm
>> of users, where the torrent is a package of the most frequently
>> requested static content. (I am assuming that the static content
>> requests follow a power law distribution, with only a few static files
>> being responsible for the overwhelming bulk of static data
>> transferred.).
>>
>> As I have only superficial knowledge of the technologies involved and
>> the capabilities of HTML5, I passed this idea by a couple of
>> programmer friends to get their opinions. Generally they thought is
>> was a very interesting idea, but that as far as they know, the
>> specification as it stands now is incapable of accommodating such a
>> use case.
>>
>> Together we arrived at a few criticisms of this idea that appear to be
>> resolvable:
>>
>> -- Privacy issues
>> -- Security issues (man in the middle attack).
>> -- content labeling (i.e. how does the browser know what content is
>> truly static and therefore safe to share.)
>> -- content signing (i.e. is there some sort of hash that allows the
>> peers to confirm that the content has not been adulterated).
>> -- privacy issues
>
> Yes I sort of see this kind of thing as the future of the web.? There's an
> argument to say that it should have been done 10 or even 20 years ago, but
> we're still not there.? I think websockets will be a huge step forward for
> this kind of thing.? One issue still remains NAT traversal, perhaps this is
> what has held developers back, though notable exceptions such as skype have
> provided a great UX here.
>
> Gaming is one obvious application for this, which in many ways is the
> pinnacle of software engineering.
>
> I see this kind of technique really bringing linked data into its own
> (including RDFa) where browsers become more data aware and more socially
> aware and are able interchage relevant information. ? Something like FOAF
> (as a means to mark up data) is well suited to provide a distributed network
> of peers, can certainly handle global namespaced data naming, and is getting
> quite close to solving privacy and security challenges.
>
> Im really looking forward to seeing what people start to build on top of
> this technology, and your idea certainly sounds exciting.
>
>>
>> All in all, many of these issues have been solved by the many talented
>> programmers that have developed the current bit-torrent protocol,
>> algorithms and security features. The idea would simply to design the
>> HTML5 in such a way that it can permit the browser to function as a
>> full-fledged web-application bit-torrent client-server.
>>
>> Privacy issues can be resolved by possibly defining something such as
>> "browser security zones" or "content label" whereby the content
>> provider (application developer) labels content (such as images and
>> CSS files) as safe to share (static content) and labels dynamic
>> content (such as personal photos, documents, etc.) as unsafe to share.
>>
>> Also in discussing this, we come up with some potentially useful
>> extensions to this use case.
>>
>> One would be the versioning of the "torrent file", such that the
>> torrent file could represent versions of the application. i.e. I
>> release an application that is version 1.02 and it becomes very
>> popular and there is a sizable swarm. At some point in the future I
>> release a new version with bug-fixes and additional features (such as
>> CSS sprites for the social network game). I should be able to
>> propagate this new version to all clients in the swarm so that over
>> some time window such as 2 to 4 hours all clients in the swarm
>> discover (via push or pull) the new version and end up downloading it
>> from the peers with the new version. The only security feature I could
>> see that would be required would be that once a client discovers that
>> their is a new version, it would hit up the original server to
>> download a signature/fingerprint file to verify that the new version
>> that it is downloading from its peers is legitimate.
>>
>> The interesting thing about this idea is that it would permit large
>> portions of sites to exist in virtual form. Long-term I can imagine
>> large non-profit sites such as Wikipedia functioning on top of this
>> structure in such a way that it greatly reduces the amount of funding
>> necessary. It would be partially distributed with updates to wikipedia
>> being distributed via lots of tiny versions from super-nodes ? la a
>> Skype type P2P model.
>>
>> This would also take a lot of power out of the hands of those telcos
>> that are anti-net neutrality. This feature would basically permit a
>> form of net neutrality by moving content to the fringes of the
>> network.
>>
>> Let me know your thoughts and if you think this would be possible
>> using Web-sockets and web-workers, and if not, what changes would be
>> necessary to allow this to evolve.
>>
>> Sincerely,
>>
>> Andrew J. L. de Andrade
>> S?o Paulo, Brazil
>>
>> (P.S. I consider myself a pretty technical person, but I don't really
>> program. I only dabble in programming as a hobby and to better
>> understand my colleagues. Feel free to be as technical as you want in
>> your reply, but please forgive me if I make or made any bonehead
>> mistakes.)
>
>

I think the most interesting part of this idea is that the load scales
linearly with the demand for the content, because the site in question
only needs to serve the "torrent" file with distributed hash tables,
signatures, fingerprints, etc. In other words, the original site
exists to guarantee authenticity.

Better than that is the fact that distribution is effectively cheaper
as content becomes more valuable to the Internet collectively. A
mechanism like this would be massively useful for a Youtube or Vimeo
because video content distribution is one of the main sources of
bandwidth demand today and is static. The delivery of 1020p HD content
all of a sudden becomes very very feasible.

On the other hand, if this takes off, telcos and other providers of
"internet tubes" are going to have to worry about uplinks getting
clogged at the last mile. They should be thinking about this now,
because it represents a massive change in usage patterns for regular
internet users and not just the fringe that already uses bit-torrent.

Melvin, on your observation of NAT traversal, I think now is the time
to start thinking of implementing this with IPv6 already as the
default. Given the timelines we are talking about for HTML5 adoption,
this feature creates a very desirable feature that would push a lot of
those at the fringes of the network to adopt IPv6 sooner than they
might have otherwise.

The idea of this complementing RDFa is interesting and something I
hadn't considered yet. I'm going to think about that tonight. In fact
I need to read up on RDFa.

Andrew J L de Andrade
@andrewdeandrade

From ian at hixie.ch  Tue Jan 19 17:07:46 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 20 Jan 2010 01:07:46 +0000 (UTC)
Subject: [whatwg] Proposal for <iframe sandbox> related change to HTML5
 section 4.8.3
In-Reply-To: <ff1e8c3a0912081104v5be773bfl4f587af2e020ad96@mail.gmail.com>
References: <ff1e8c3a0912081104v5be773bfl4f587af2e020ad96@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001200105550.3970@ps20323.dreamhostps.com>

On Tue, 8 Dec 2009, Chris Evans wrote:
>
> I propose changing this text:
> 
> "This flag also prevents script from reading the document.cookie IDL
> attribute."
> 
> to
> 
> "This flag also prevents script from reading or writing the document.cookie
> IDL attribute."

Done.

However, this is a purely non-normative change -- the text above has no 
conformance requirements, and has no effect on implementations. The spec 
already actually required that both reading and writing be blocked in the 
part of the spec that actually defines the document.cookie API.

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

From hsivonen at iki.fi  Tue Jan 19 23:50:22 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 20 Jan 2010 09:50:22 +0200
Subject: [whatwg] [foaf-protocols] keygen substitute for Windows?
In-Reply-To: <4B55EB47.5020103@manchester.ac.uk>
References: <2272F99A-2D1A-46BB-95ED-215CA6AA4A70@bblfish.net>
	<4B55EB47.5020103@manchester.ac.uk>
Message-ID: <024ABA5E-51A4-40FB-872B-AF8A0088F306@iki.fi>

On Jan 19, 2010, at 19:26, Bruno Harbulot wrote:

> In Firefox, this prints "SELECT": <keygen> is transformed on the fly into <select>, which breaks DOM usage. This is something that Opera and Safari don't do.

FWIW, this is considered a bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=101019

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From hsivonen at iki.fi  Wed Jan 20 07:26:04 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 20 Jan 2010 17:26:04 +0200
Subject: [whatwg] about:blank synchronicity
In-Reply-To: <9C55CB59-9762-4F2A-B7C6-2963899D17BC@iki.fi>
References: <19E2A843-0377-464E-8970-7F6BBBD3735B@iki.fi>
	<B0C6D21B-DA2B-4557-9493-54B536574B8D@apple.com>
	<4B4DFE2B.8070707@mit.edu>
	<0ED70CC8-705B-41F6-A994-35B4D07D2E47@iki.fi>
	<9C55CB59-9762-4F2A-B7C6-2963899D17BC@iki.fi>
Message-ID: <E2B6DD23-B09D-47A3-BD47-E84C2D30D4B1@iki.fi>

On Jan 15, 2010, at 12:05, Henri Sivonen wrote:

> I've located a Mozilla test case that seems to depend on the event loop task mapping of data: URL loads (http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul).

This was most likely a misdiagnosis.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From david at davidflanagan.com  Wed Jan 20 11:58:39 2010
From: david at davidflanagan.com (David Flanagan)
Date: Wed, 20 Jan 2010 11:58:39 -0800
Subject: [whatwg] script async and defer attributes questions and confusion
Message-ID: <4B57606F.3050008@davidflanagan.com>

I'm trying to understand the async and defer attributes of the script 
tag.  Unfortunately, since script execution is so intimately tied up 
with HTML parsing, section 4.3.1 is particularly hard to make sense of.
I've got 3 questions, and 3 suggested clarifications to the spec. 
Thanks to anyone who can explain these!

First, my questions.  Are the following three statements correct?  (I'm 
only concerned with <script> tags that actually appear in a document, 
not those inserted or emitted (via document.write()) by another script.):

1) Scripts without async or defer attributes are executed in the order 
in which they appear in the document.  They are executed synchronously, 
which means that the parser must stop parsing the document while they run.

2) Scripts with the defer attribute, but without the async attribute are 
executed in the order in which they appear in the document, but their 
execution is deferred until the document has finished parsing. All these 
scripts will execute before DOMContentLoaded and the load event are 
fired.  A deferred script can assume that the entire DOM tree has been 
constructed and is ready for manipulation--these scripts do not 
generally need to register an onload event handler. A call to 
document.write() within a deferred script will blow away the current 
document and begin a new one.

3) Scripts with the async attribute are executed as their script content 
becomes available over the network, with no guarantee that they will be 
executed in the order in which they appear in the document.  The only 
guarantee is that these scripts will run before the DOMContentLoaded or 
load events are fired. Document parsing may or may not have completed 
when an async script is run, and a call to document.write() from an 
async script will have unpredictable behavior. Though the order of 
execution of async scripts is not predictable, the scripts will always 
appear to run in some serial order without concurrent execution.

Next, I suggest that the following things in the spec be clarified:

1) After describing the async and defer attributes, the spec promises:
"The exact processing details for these attributes are described below."
I take this to mean "below, somewhere in section 4.3".  In fact, 
however, the exact processing details are scattered throughout the spec, 
and understanding the attributes requires understanding section 9, I 
think. It would be nice to note this.

2) The last sentence of this paragraph:

> The second is a flag indicating whether the element was "parser-inserted". Initially, script elements must have this flag unset. It is set by the HTML parser and is used to handle document.write() calls.

made me think that the "parser-inserted" flag would only be set to true 
for scripts that were emitted through document.write() calls.  That is, 
I thought that the parser-inserted flag would be set only in unusual 
cases rather than in the most common case.  This section should explain 
the meaning of the parser-inserted flag. Instead it describes one of the 
  purposes of the flag, but that purpose is different than the purpose 
for which it is used in this section.

3) The algorithm for "running a script" adds scripts to "the list of 
scripts that will execute as soon as possible".  And 9.2.6 spins the 
event loop until this list is empty.  But I don't see anything in the 
spec that removes items from this list.  That seems like an error in the 
spec, not just a confusing bit.  Furthermore, the fact that this 
mechanism is specified as a "list" rather than as a "set" implies some 
kind of sequential execution of the scripts.  But I don't think any 
sequence is meant here.

	David Flanagan

From philipj at opera.com  Wed Jan 20 15:54:51 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Thu, 21 Jan 2010 00:54:51 +0100
Subject: [whatwg] Microdata feedback
In-Reply-To: <3851E773-04EF-449D-9E7B-18CA7BE414D7@adactio.com>
References: <20091222122313.6BAB.C8DE7135@html5.jp>
	<Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
	<3851E773-04EF-449D-9E7B-18CA7BE414D7@adactio.com>
Message-ID: <op.u6uvdpvosr6mfa@worf>

On Mon, 18 Jan 2010 16:24:46 +0100, Jeremy Keith <jeremy at adactio.com>  
wrote:

> Hixie wrote:
>>> Finally on vCard, the final part of the extraction algorithm goes to
>>> great trouble to guess what is the family name and what is the given
>>> name. This guess will be broken for transliterated east Asian names
>>> (CJKV that I know of, maybe others too). Just saying. Also, why is it
>>> important to explicitly add N:;;;; for organizations?
>>
>> This is intended to be compatible with Microformats vCard, which has
>> these weird rules. If you think we should remove them, please at least
>> first speak to Tantek and see why he thinks.
>
> The fn optimisation pattern isn't intended to catch 100% of cases, just  
> the situation "Firstname Lastname" or "Firstname Middlename Lastname".  
> So if you just use fn (formatted name) and don't use n (name), the name  
> will be extracted/guessed using the optimisation pattern.
>
> In cases where the pattern doesn't work (e.g. "Anne van Kesteren", or  
> east Asian names) you can still explicitly specify the family name and  
> given name, over-riding the fn optimisation pattern. If you do this, you  
> need to explicitly state this is the name (n) as well as the formatted  
> name (fn).

This is going to break badly whenever a template uses vCard microdata and  
its author either doesn't know the family name and given name (because the  
data was never collected) or doesn't even consider that the vcard  
conversion does this funny guesswork. If a social network site or similar  
does this, then Anne van Kesteren and Zhang Min (fictional name) will have  
their names messed up with no way of fixing it. At least I haven't seen a  
site which asks users to both fill in their full name and each component,  
which is what you need to get this right.

> Similarly, for organisations, you don't have to explicitly set n (name)  
> if you apply both fn (formatted name) and org (organisation name) to a  
> string. This time, the optimisation pattern assumes that the fn is the  
> name of the organisation.
>
> Technically, the n property is *always* required but if you use either  
> of those two optimisation patterns, the n is inferred from fn.

If this is just a technical problem with some software requiring N to be  
present, would it be OK to just output an empty N like for organizations?

-- 
Philip J?genstedt
Core Developer
Opera Software

From philipj at opera.com  Wed Jan 20 15:59:40 2010
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Thu, 21 Jan 2010 00:59:40 +0100
Subject: [whatwg] Microdata feedback
In-Reply-To: <Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
References: <20091222122313.6BAB.C8DE7135@html5.jp>
	<Pine.LNX.4.64.1001170537330.3970@ps20323.dreamhostps.com>
Message-ID: <op.u6uvlqzpsr6mfa@worf>

On Mon, 18 Jan 2010 13:58:16 +0100, Ian Hickson <ian at hixie.ch> wrote:

> I'd like at some point to introduce some sort of "semantic" textContent
> that handles <br>, <pre>, <bdo>, dir="", <img alt>, <del>, space-
> collapsing, and newline elimination, but there hasn't been much  
> enthusiasm
> around the idea, and it's not clear what else it would be good for.
>
> I've changed the example, at least, to have it work ok, and added a
> comment in the example about it.

OK. Won't hold my breath for semantic textContent, but it sounds like a  
good solution.

> On Thu, 19 Nov 2009, Philip J?genstedt wrote:
>>
>> In a (slightly edited) Jack Bauer example [1], Chrome, Firefox and
>> presumably Safari has the meta elements moved to head. This will
>> severely break script-based implementation of microdata, which are
>> likely to be used for the time being until the DOM API is implemented
>> natively. I can't see any workaround for this, so I suggest that <meta>
>> simply not be used for microdata, preferably by making it non-conforming
>> and removing it from the definitions/algorithms.
>
> This is a short-term problem that only affects scripted implementations
> that are shipped with the pages, so the workaround is simple: don't use
> <meta> and <link>. Any implementations outside of the page can just fix
> their parser to be HTML5-compatible.

OK, fair enough.

Thanks for all the other fixes, still reviewing the algorithm change...

-- 
Philip J?genstedt
Core Developer
Opera Software

From naruse at airemix.jp  Wed Jan 20 23:29:41 2010
From: naruse at airemix.jp (NARUSE, Yui)
Date: Thu, 21 Jan 2010 16:29:41 +0900
Subject: [whatwg] Question about the application/x-www-form-urlencoded
	encoding algorithm
Message-ID: <146d7afa1001202329u5eb015bdy12bdae0ab0ec470@mail.gmail.com>

In 4.10.19.4 URL-encoded form data, The
application/x-www-form-urlencoded encoding algorithm,
it says:

> For each character in the entry's name and value, apply the following subsubsteps:
>
> If the character isn't in the range U+0020, U+002A, U+002D, U+002E,
> U+0030 to U+0039, U+0041 to U+005A, U+005F, U+0061 to U+007A
> then replace the character with a string formed as follows:
> Start with the empty string, and then, taking each byte of the character
> when expressed in the selected character encoding in turn,
> append to the string a U+0025 PERCENT SIGN character (%) followed
> by two characters in the ranges U+0030 DIGIT ZERO (0) to
> U+0039 DIGIT NINE (9) and U+0041 LATIN CAPITAL LETTER A
> to U+0046 LATIN CAPITAL LETTER F representing the hexadecimal value
> of the byte (zero-padded if necessary).
>
> If the character is a U+0020 SPACE character, replace it with a single U+002B PLUS SIGN character (+).

This means, U+9670, encoded as "?x89?x41" in Shift_JIS, must be
encoded as "%89%41",
and shouldn't be "%89A"?

thanks,

-- 
NARUSE, Yui
naruse at airemix.jp

From darin at chromium.org  Thu Jan 21 01:12:41 2010
From: darin at chromium.org (Darin Fisher)
Date: Thu, 21 Jan 2010 01:12:41 -0800
Subject: [whatwg] history.back()
Message-ID: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>

In WebKit, history.back() is currently implemented asynchronously.

However, it was not always this way.  Previously, if the back navigation
corresponded to a hash change, then the back navigation would complete
synchronously.  If the back navigation corresponded to a different document,
then it would be completed asynchronously.

The HTML5 spec currently calls for the old behavior of WebKit, which happens
to match the behavior of Gecko.  Because the spec is written this way, there
is movement in WebKit to change WebKit back.

IE however appears to implement history.back() asynchronously in all cases
just like newer versions of WebKit.

I actually think this is a better behavior to spec for a couple reasons:

1)  It allows for history.back() to behave consistently regardless of the
type of navigation.
2)  It allows for the back/forward list to be decoupled from the main thread
of the rendering engine.

This last point is quite relevant to Chrome since we store the back/forward
list in a separate process.  We do this since items in the back/forward list
may actually need to be rendered using different WebKit processes.
 (Navigating in the location bar is a hint that we can spawn a new process.)

We could copy the entire back/forward list to each process and replicate
state, but that seems excessive.  Instead, simply matching the
history.back() behavior of IE avoids the need to do so.

>From a web compat perspective, it seems wise to match the behavior of IE.
 It also has other benefits.

Can we change the spec?

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/5d0a72b6/attachment.htm>

From jonas at sicking.cc  Thu Jan 21 01:16:17 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 21 Jan 2010 01:16:17 -0800
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
Message-ID: <63df84f1001210116g63865b11t5c4c1c6ca9d9fba5@mail.gmail.com>

On Thu, Jan 21, 2010 at 1:12 AM, Darin Fisher <darin at chromium.org> wrote:
> In WebKit, history.back() is currently implemented asynchronously.
> However, it was not always this way. ?Previously, if the back navigation
> corresponded to a hash change, then the back navigation would complete
> synchronously. ?If the back navigation corresponded to a different document,
> then it would be completed asynchronously.
> The HTML5 spec currently calls for the old behavior of WebKit, which happens
> to match the behavior of Gecko. ?Because the spec is written this way, there
> is movement in WebKit to change WebKit back.
> IE however appears to implement history.back() asynchronously in all cases
> just like newer versions of WebKit.
> I actually think this is a better behavior to spec for a couple reasons:
> 1) ?It allows for history.back() to behave consistently regardless of the
> type of navigation.
> 2) ?It allows for the back/forward list to be decoupled from the main thread
> of the rendering engine.
> This last point is quite relevant to Chrome since we store the back/forward
> list in a separate process. ?We do this since items in the back/forward list
> may actually need to be rendered using different WebKit processes.
> ?(Navigating in the location bar is a hint that we can spawn a new process.)
> We could copy the entire back/forward list to each process and replicate
> state, but that seems excessive. ?Instead, simply matching the
> history.back() behavior of IE avoids the need to do so.
> From a web compat perspective, it seems wise to match the behavior of IE.
> ?It also has other benefits.
> Can we change the spec?

Sounds good to me. Having all navigation be asynchronous I suspect
would have implementations benefits in Gecko too.

/ Jonas

From Olli.Pettay at helsinki.fi  Thu Jan 21 03:18:34 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 21 Jan 2010 13:18:34 +0200
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
Message-ID: <4B58380A.1020002@helsinki.fi>

On 1/21/10 11:12 AM, Darin Fisher wrote:
> In WebKit, history.back() is currently implemented asynchronously.
>
> However, it was not always this way.  Previously, if the back navigation
> corresponded to a hash change, then the back navigation would complete
> synchronously.  If the back navigation corresponded to a different
> document, then it would be completed asynchronously.
>
> The HTML5 spec currently calls for the old behavior of WebKit, which
> happens to match the behavior of Gecko.  Because the spec is written
> this way, there is movement in WebKit to change WebKit back.
>
> IE however appears to implement history.back() asynchronously in all
> cases just like newer versions of WebKit.
>
> I actually think this is a better behavior to spec for a couple reasons:
>
> 1)  It allows for history.back() to behave consistently regardless of
> the type of navigation.
> 2)  It allows for the back/forward list to be decoupled from the main
> thread of the rendering engine.
>
> This last point is quite relevant to Chrome since we store the
> back/forward list in a separate process.  We do this since items in the
> back/forward list may actually need to be rendered using different
> WebKit processes.  (Navigating in the location bar is a hint that we can
> spawn a new process.)
>
> We could copy the entire back/forward list to each process and replicate
> state, but that seems excessive.  Instead, simply matching the
> history.back() behavior of IE avoids the need to do so.
>
>  From a web compat perspective, it seems wise to match the behavior of
> IE.  It also has other benefits.
>
> Can we change the spec?
>
> -Darin


Do you propose to make all history traversal async?
back/forward/go/location.reload  ?



-Olli

From Olli.Pettay at helsinki.fi  Thu Jan 21 03:23:28 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 21 Jan 2010 13:23:28 +0200
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
Message-ID: <4B583930.9050801@helsinki.fi>

On 1/21/10 11:12 AM, Darin Fisher wrote:
>  From a web compat perspective, it seems wise to match the behavior of
> IE.
I'm not sure how important it is to copy IE here, if we aren't going to
copy IE's behavior elsewhere, like about:blank handling.

But anyway, making history.x async sounds good to me, but
have to figure out what to do with location.reload/replace.
Needs some more testing.



-Olli

From Olli.Pettay at helsinki.fi  Thu Jan 21 04:33:04 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 21 Jan 2010 14:33:04 +0200
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
Message-ID: <4B584980.1010605@helsinki.fi>

And still one thing to test and specify;
if history.back()/forward() is asynchronous,
does that mean that loading start asynchronously,
or that entries are added asynchronously to session history?

What should happen if a page calls:
history.back();
history.forward();

What if the page calls:
history.back();
history.go(-2);


And btw, some of the session history handling is anyway synchronous.
Per the current HTML5 draft calling document.open() adds a new entry to
session history immediately (IIRC, webkit is the only one which doesn't
support this).

So, after all, I'm not yet 100% sure whether making back()/forward()
async is good. This needs some more discussion, and things needs to
be specified properly.


-Olli




On 1/21/10 11:12 AM, Darin Fisher wrote:
> In WebKit, history.back() is currently implemented asynchronously.
>
> However, it was not always this way.  Previously, if the back navigation
> corresponded to a hash change, then the back navigation would complete
> synchronously.  If the back navigation corresponded to a different
> document, then it would be completed asynchronously.
>
> The HTML5 spec currently calls for the old behavior of WebKit, which
> happens to match the behavior of Gecko.  Because the spec is written
> this way, there is movement in WebKit to change WebKit back.
>
> IE however appears to implement history.back() asynchronously in all
> cases just like newer versions of WebKit.
>
> I actually think this is a better behavior to spec for a couple reasons:
>
> 1)  It allows for history.back() to behave consistently regardless of
> the type of navigation.
> 2)  It allows for the back/forward list to be decoupled from the main
> thread of the rendering engine.
>
> This last point is quite relevant to Chrome since we store the
> back/forward list in a separate process.  We do this since items in the
> back/forward list may actually need to be rendered using different
> WebKit processes.  (Navigating in the location bar is a hint that we can
> spawn a new process.)
>
> We could copy the entire back/forward list to each process and replicate
> state, but that seems excessive.  Instead, simply matching the
> history.back() behavior of IE avoids the need to do so.
>
>  From a web compat perspective, it seems wise to match the behavior of
> IE.  It also has other benefits.
>
> Can we change the spec?
>
> -Darin


From Olli.Pettay at helsinki.fi  Thu Jan 21 05:47:55 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 21 Jan 2010 15:47:55 +0200
Subject: [whatwg] history.back()
In-Reply-To: <4B584980.1010605@helsinki.fi>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<4B584980.1010605@helsinki.fi>
Message-ID: <4B585B0B.1030500@helsinki.fi>

On 1/21/10 2:33 PM, Olli Pettay wrote:
> or that entries are added asynchronously to session history?

Ok, this is not valid question in this context, since .back()/forward()
use the existing session history entry anyway.

A better question might be that when is the
"current" entry updated?


-Olli

From darin at chromium.org  Thu Jan 21 11:19:23 2010
From: darin at chromium.org (Darin Fisher)
Date: Thu, 21 Jan 2010 11:19:23 -0800
Subject: [whatwg] history.back()
In-Reply-To: <4B58380A.1020002@helsinki.fi>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<4B58380A.1020002@helsinki.fi>
Message-ID: <bd8f24d21001211119x597098ddya8a16dd1a0513029@mail.gmail.com>

On Thu, Jan 21, 2010 at 3:18 AM, Olli Pettay <Olli.Pettay at helsinki.fi>wrote:

> On 1/21/10 11:12 AM, Darin Fisher wrote:
>
>> In WebKit, history.back() is currently implemented asynchronously.
>>
>> However, it was not always this way.  Previously, if the back navigation
>> corresponded to a hash change, then the back navigation would complete
>> synchronously.  If the back navigation corresponded to a different
>> document, then it would be completed asynchronously.
>>
>> The HTML5 spec currently calls for the old behavior of WebKit, which
>> happens to match the behavior of Gecko.  Because the spec is written
>> this way, there is movement in WebKit to change WebKit back.
>>
>> IE however appears to implement history.back() asynchronously in all
>> cases just like newer versions of WebKit.
>>
>> I actually think this is a better behavior to spec for a couple reasons:
>>
>> 1)  It allows for history.back() to behave consistently regardless of
>> the type of navigation.
>> 2)  It allows for the back/forward list to be decoupled from the main
>> thread of the rendering engine.
>>
>> This last point is quite relevant to Chrome since we store the
>> back/forward list in a separate process.  We do this since items in the
>> back/forward list may actually need to be rendered using different
>> WebKit processes.  (Navigating in the location bar is a hint that we can
>> spawn a new process.)
>>
>> We could copy the entire back/forward list to each process and replicate
>> state, but that seems excessive.  Instead, simply matching the
>> history.back() behavior of IE avoids the need to do so.
>>
>>  From a web compat perspective, it seems wise to match the behavior of
>> IE.  It also has other benefits.
>>
>> Can we change the spec?
>>
>> -Darin
>>
>
>
> Do you propose to make all history traversal async?
> back/forward/go/location.reload  ?
>
>
>
My proposal is to only make history.{back,forward,go} asynchronous.

I haven't carefully reviewed location.reload, but off hand, I think it
should
behave similarly to location assignment.

My concern is really that the history traversal algorithm should not require
direct synchronous read access to session history entries other than the
current session history entry.

I think it would be best for history.{back,forward,go} to be asynchronous
to support an implementation that just sends an event all the way up to
the UI layer of a browser to synthesize a click of the corresponding
buttons.
That way an implementation can reuse most of the same code paths for
both user initiated history traversal as well as page initiated history
traversal.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/48f38bef/attachment.htm>

From mike at plan99.net  Thu Jan 21 14:24:40 2010
From: mike at plan99.net (Mike Hearn)
Date: Thu, 21 Jan 2010 23:24:40 +0100
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <42b395981001191154g660174c6j99cc8ad90027153@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com>
	<9178f78c1001191131i7fdd4dacgb98cae78535423e1@mail.gmail.com>
	<42b395981001191154g660174c6j99cc8ad90027153@mail.gmail.com>
Message-ID: <f4cd80641001211424o5fddfe78tc5cedb50136154c5@mail.gmail.com>

WebSockets doesn't let you open arbitrary ports and listen on them,
so, I don't think it can be used for what you want.

P2P in general is a lot more complicated than it sounds. It sort of
works for things like large movies and programs because they aren't
latency sensitive and chunk ordering doesn't matter (you can wait till
the end then reassemble).

But it has problems:

- A naive P2P implementation won't provide good throughput or latency
because you might end up downloading files from a mobile phone on the
other side of the world rather than a high performance CDN node inside
your local ISP. That sucks for users and also sucks for your ISP who
will probably find their transit links suddenly saturated and their
nice cheap peering links with content providers sitting idle.

- That means unless you want to have your system throttled (or in
companies/universities, possibly banned) you need to respect network
topology and have an intimate understanding of how it works. For
example the YouTube/Akamai serving systems have this intelligence but
whatever implementation you come up with won't.

- P2P is far more complicated than an HTTP download. I never use
BitTorrent because it basically never worked well for me, compared to
a regular file download. You don't see it used much outside the pirate
scene and distributing linux ISOs these days for that reason, I think.

Your friends problem has other possible solutions:

1) Harvesting low hanging fruit:
1a) Making sure every static asset is indefinitely cacheable (use
those ISP proxy caches!)
1b) Ensuring content is being compressed as effectively as possible
1c) Consider serving off a CDN like Akamai or Limelight. There is
apparently a price war going on right now.

and of course the ultimate long term solution

2) Scaling revenues in line with traffic

From Simetrical+w3c at gmail.com  Thu Jan 21 16:27:07 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 21 Jan 2010 19:27:07 -0500
Subject: [whatwg] Authoring feedback on <datalist>
Message-ID: <7c2a12e21001211627n3c922f54g619a060354cd7ab8@mail.gmail.com>

MediaWiki currently uses a search-suggest feature based on lots of
JavaScript that's used to calculate all sorts of widths and heights to
painstakingly construct an absolutely-positioned div, and reimplement
standard dropdown navigation controls on top of that.  It works pretty
well (go to en.wikipedia.org and start typing a query to see --
implementation at
<http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/mwsuggest.js?view=markup>),
but it's a horrible hack and doesn't integrate perfectly with the
system.  When I found out Opera implements <datalist>, thanks to the
helpful spec annotations, I tried rewriting mwsuggest.js to use
<datalist> where supported.

My primary feedback here is that a simpler JS API would *really* be
nice.  In this kind of situation, typically you receive some JSON or
whatnot from the server, so you have a JavaScript array that you want
to use for suggestions.  The code to make a given list the suggest
source for an input is something like:

var datalist = document.getElementById( 'arbitrary-id' );
if ( datalist == null ) {
	datalist = document.createElement( 'datalist' );
	datalist.id = 'arbitrary-id';
	document.body.appendChild( datalist );
} else {
	datalist.innerHTML = '';
}
input.setAttribute( 'list', 'arbitrary-id' );
while ( var i = 0; i < suggestions.length; i++ ) {
	var option = document.createElement( 'option' );
	option.value = suggestions[i];
	datalist.appendChild( option );
}

This is all quite awkward.  It was pointed out on IRC that there are
legitimate use-cases for declarative datalists (e.g.,
http://html5.lachy.id.au/), but I'd expect JS-constructed datalists to
be a much bigger use-case.  I can think of several sites off the top
of my head that use absolutely-positioned divs to provide search
suggestions to users, but none that do so statically.  So I think a
better API is needed -- preferably just

input.suggest = suggestions;

or similar.  The details aren't particularly important, but the
current API is really cumbersome when used from JS.

From Simetrical+w3c at gmail.com  Thu Jan 21 16:42:03 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 21 Jan 2010 19:42:03 -0500
Subject: [whatwg] Authoring feedback on <datalist>
In-Reply-To: <7c2a12e21001211627n3c922f54g619a060354cd7ab8@mail.gmail.com>
References: <7c2a12e21001211627n3c922f54g619a060354cd7ab8@mail.gmail.com>
Message-ID: <7c2a12e21001211642p4c2eed27w4dd3e1bf461614f2@mail.gmail.com>

It's also worth noting that <datalist> currently seems to be conceived
as a combobox, while search suggestions deserve totally different UI.
Opera's UI is suitable to search suggestions, but WebKit's proposed UI
is inappropriate for them:

http://docs.google.com/View?id=dch3zh37_0cf8kc8c4

There's a little drop-down arrow you have to click to get the list,
which is unexpected for search suggestions.  If a separate "suggest"
IDL attribute were added, UAs could provide different UI for that and
datalist.

From andrew at deandrade.com.br  Thu Jan 21 18:03:44 2010
From: andrew at deandrade.com.br (Andrew de Andrade)
Date: Fri, 22 Jan 2010 00:03:44 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <1b4ff0311001211144y72716b64j5ccc386f4dcf7226@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com> 
	<1b4ff0311001211144y72716b64j5ccc386f4dcf7226@mail.gmail.com>
Message-ID: <42b395981001211803s6f5e9a2cj173996c210ad0267@mail.gmail.com>

comments inline

On Thu, Jan 21, 2010 at 5:44 PM, Ivan ?u?ak <izuzak at gmail.com> wrote:
> Hi Andrew,
>
> That's an interesting idea. Here are some of my thoughts:
>
> As your Google friend noted, I'm wondering why you'd want to implement
> this on the HTML5 level, not on the browser (C++) level. Implementing
> such a protocol within the browser would probably be faster, more
> secure and a better design choice since the functionality is basically
> the same for every web application. I'm guessing the reason is that
> you do not want to achieve this by changing/extending the browser but
> rather by using new HTML5 technologies instead. Am I right?

While I realize that this is best implemented at the browser level, my
concern is if it will be an idea that would be broadly adopted by all
browser vendors if it is implemented at that level. It's an idea that
really has value once you've reached critical mass. For example, this
would be an extremely potent idea if the two most popular browsers
have implemented this by 2014 to 2015 or so. HTML5 is a web technology
spec. I imagine that putting it in the spec would greatly increase the
chances of browsers supporting this functionality.

However, I am not familiar with the politics that govern whether or
not browser product managers implement these features at the browser
level?

Being pragmatic, do you think it's possible to get widespread adoption
quickly for a feature like this as the browser level or do you agree
that this would be more likely to be adopted quickly if it was part of
a W3C spec?


>
> If so, then a major problem is that the browser is not a network
> server, rather only a client. In order for a browser A to connect
> using WebSockets to a browser B which executes some process, browser B
> must expose a network accessible end-point to which that process is
> tied i.e. the browser must expose TCP/IP end-point. I guess that the
> NAT traversal problem Melvin mentioned basically covers this.
>

Assuming that this idea really only sees adoption within a few years,
won't IPv6 resolve the issue of NAT traversal?


> If the functionality you wish to achieve is distributing serving of
> static content to clients which already acquired content, would a
> dynamically changeable HTTP redirect table implemented on the server
> cover the same functionality? E.g. 1) the client would request and
> receive a web resource from the server, 2) if indicated the resource
> was static - the client would expose the resource from it's machine by
> creating a network accessible end-point and tying a process for
> serving the content to it, 3) the client would let the server know it
> is serving the content 4) the server would register the client
> end-point as a possible server for the content, 5) when another client
> would request the resource from the server, the server would HTTP
> redirect it to the end-point of a client that is serving it. This
> solution implies that a specific resource must be fetched from a
> single server, while your idea implies fetching a resource from
> different servers in parallel (as in torrent protocols) and would
> probably be faster. What do you think?

I'm not sure. I don't really have the technical depth to evaluate this
solution. I'll ask some of my friends what they think.

>
> In a broader context of connecting both servers and client devices
> into a large network for scalable execution of applications, your idea
> reminds me of a recent blog article I read:
> http://highscalability.com/blog/2009/12/16/building-super-scalable-systems-blade-runner-meets-autonomic.html.
> Definitely have a look at it - it's a bit on the visionary side and
> longish, but worth it. I believe a planet-wide execution platform
> consisting of every network device will eventually happen and that's
> why I think we should all be contributing in that direction, which
> your idea definitely is.

I took a brief look. This article looks very interesting. I'm going to
have a gander at it tomorrow. Maybe I'll shoot the HighScalability
people an email and see if they want to comment on this idea on their
blog.

>
> Regards,
> Ivan Zuzak
>
> On Tue, Jan 19, 2010 at 17:59, Andrew de Andrade
> <andrew at deandrade.com.br> wrote:
>> I have an idea for a possible use case that as far as I can tell from
>> previous discussions on this list has not been considered or at least
>> not in the form I present below.
>>
>> I have a friend whose company produces and licenses online games for
>> social networks such as Facebook, Orkut, etc.
>>
>> One of the big problems with these games is the shear amount of static
>> content that must be delivered via HTTP once the application becomes
>> popular. In fact, if a game becomes popular overnight, the scaling
>> problems with this static content quickly becomes a technical and
>> financial problem.
>>
>> To give you an idea of the magnitude and scope, more than 4 TB of
>> static content is streamed on a given day for one of the applications.
>> It's very likely that others with similarly popular applications have
>> encountered the same challenge.
>>
>> When thinking about how to resolve this, I took my usual approach of
>> thinking how do we decentralize the content delivery and move towards
>> an agent-based message passing model so that we do not have a single
>> bottleneck technically and so we can dissipate the cost of delivering
>> this content.
>>
>> My idea is to use web-sockets to allow the browser function more a
>> less like a bit-torrent client. Along with this, web-workers would
>> provide threads for handling the code that would function as a server,
>> serving the static content to peers also using the program.
>>
>> If you have lots of users (thousands) accessing the same application,
>> you effectively have the equivalent of one torrent with a large swarm
>> of users, where the torrent is a package of the most frequently
>> requested static content. (I am assuming that the static content
>> requests follow a power law distribution, with only a few static files
>> being responsible for the overwhelming bulk of static data
>> transferred.).
>>
>> As I have only superficial knowledge of the technologies involved and
>> the capabilities of HTML5, I passed this idea by a couple of
>> programmer friends to get their opinions. Generally they thought is
>> was a very interesting idea, but that as far as they know, the
>> specification as it stands now is incapable of accommodating such a
>> use case.
>>
>> Together we arrived at a few criticisms of this idea that appear to be
>> resolvable:
>>
>> -- Privacy issues
>> -- Security issues (man in the middle attack).
>> -- content labeling (i.e. how does the browser know what content is
>> truly static and therefore safe to share.)
>> -- content signing (i.e. is there some sort of hash that allows the
>> peers to confirm that the content has not been adulterated).
>> -- privacy issues
>>
>> All in all, many of these issues have been solved by the many talented
>> programmers that have developed the current bit-torrent protocol,
>> algorithms and security features. The idea would simply to design the
>> HTML5 in such a way that it can permit the browser to function as a
>> full-fledged web-application bit-torrent client-server.
>>
>> Privacy issues can be resolved by possibly defining something such as
>> "browser security zones" or "content label" whereby the content
>> provider (application developer) labels content (such as images and
>> CSS files) as safe to share (static content) and labels dynamic
>> content (such as personal photos, documents, etc.) as unsafe to share.
>>
>> Also in discussing this, we come up with some potentially useful
>> extensions to this use case.
>>
>> One would be the versioning of the "torrent file", such that the
>> torrent file could represent versions of the application. i.e. I
>> release an application that is version 1.02 and it becomes very
>> popular and there is a sizable swarm. At some point in the future I
>> release a new version with bug-fixes and additional features (such as
>> CSS sprites for the social network game). I should be able to
>> propagate this new version to all clients in the swarm so that over
>> some time window such as 2 to 4 hours all clients in the swarm
>> discover (via push or pull) the new version and end up downloading it
>> from the peers with the new version. The only security feature I could
>> see that would be required would be that once a client discovers that
>> their is a new version, it would hit up the original server to
>> download a signature/fingerprint file to verify that the new version
>> that it is downloading from its peers is legitimate.
>>
>> The interesting thing about this idea is that it would permit large
>> portions of sites to exist in virtual form. Long-term I can imagine
>> large non-profit sites such as Wikipedia functioning on top of this
>> structure in such a way that it greatly reduces the amount of funding
>> necessary. It would be partially distributed with updates to wikipedia
>> being distributed via lots of tiny versions from super-nodes ? la a
>> Skype type P2P model.
>>
>> This would also take a lot of power out of the hands of those telcos
>> that are anti-net neutrality. This feature would basically permit a
>> form of net neutrality by moving content to the fringes of the
>> network.
>>
>> Let me know your thoughts and if you think this would be possible
>> using Web-sockets and web-workers, and if not, what changes would be
>> necessary to allow this to evolve.
>>
>> Sincerely,
>>
>> Andrew J. L. de Andrade
>> S?o Paulo, Brazil
>>
>> (P.S. I consider myself a pretty technical person, but I don't really
>> program. I only dabble in programming as a hobby and to better
>> understand my colleagues. Feel free to be as technical as you want in
>> your reply, but please forgive me if I make or made any bonehead
>> mistakes.)
>>
>

From andrew at deandrade.com.br  Thu Jan 21 18:33:10 2010
From: andrew at deandrade.com.br (Andrew de Andrade)
Date: Fri, 22 Jan 2010 00:33:10 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <f4cd80641001211424o5fddfe78tc5cedb50136154c5@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com> 
	<9178f78c1001191131i7fdd4dacgb98cae78535423e1@mail.gmail.com> 
	<42b395981001191154g660174c6j99cc8ad90027153@mail.gmail.com> 
	<f4cd80641001211424o5fddfe78tc5cedb50136154c5@mail.gmail.com>
Message-ID: <42b395981001211833l462e8981w53cd136364140e15@mail.gmail.com>

comments inline

On Thu, Jan 21, 2010 at 8:24 PM, Mike Hearn <mike at plan99.net> wrote:
> WebSockets doesn't let you open arbitrary ports and listen on them,
> so, I don't think it can be used for what you want.

that's my understanding. My question to this is if it is possible to
open arbitrary ports and listen in on them if the spec was changed. If
so, what would be the chance of making a change like this this late in
the game. What would be the advantages and disadvantages of including
this at the HTML5 spec level instead of the browser level.

At some level I feel like this should have some sort of implementation
at the spec level for security reasons. You wouldn't want the browser
to simple share all the static content from anywhere it's visited.
Instead you'd want only content that is static to be "on the DMZ" so
to speak.

Also, how would you go about making this work since ultimately you
still have some sort of implementation at the originating web server,
web application level. It appears to me that simply implementing this
at the browser level would not be enough. You'd need appropriate
functionality on the originating web server side simply to provide
instructions to the browsers.

i.e. "here's the torrent file for this web application, in it you (the
browser agent) will find a list of files available in distributed form
from your peers and the hash table to verify authenticity."

It seems to me that this idea would also complement the idea of the
manifest for offline browsing in HTML5. The torrent file would simply
be defining a manifest of files that are to be fetched from peers
instead of the originating server. The browser would also need a
central location to register itself, so that peers can discover other
peers.


>
> P2P in general is a lot more complicated than it sounds. It sort of
> works for things like large movies and programs because they aren't
> latency sensitive and chunk ordering doesn't matter (you can wait till
> the end then reassemble).

On the other hand, when the swarm is large enough this isn't that big
of a problem and this is an application where everyone is a seeder
while they are using the application. It would be idea if you wouldn't
be able to not seed and there was no such thing as a ratio and the
browser would throttle throughput automatically.

In addition to this, the application can also specify a static
location for the static content in case the client times out trying to
get the file from a peer. i.e. "Hey browser, download these files from
one of these peers. However if you don't succeed within 1500 ms, feel
free to contact me again and I'll send it to you"

>
> But it has problems:
>
> - A naive P2P implementation won't provide good throughput or latency
> because you might end up downloading files from a mobile phone on the
> other side of the world rather than a high performance CDN node inside
> your local ISP. That sucks for users and also sucks for your ISP who
> will probably find their transit links suddenly saturated and their
> nice cheap peering links with content providers sitting idle.

Any ideas on how this could be resolved?

I figure if the application is popular enough, the peers could be
geographically tagged using the "GPS" functionality of HTML5. Clients
would automatically get better connections and throughput and
preference if they choose to make their location available to the
"torrent" server so that peers can look up peers nearby.

>
> - That means unless you want to have your system throttled (or in
> companies/universities, possibly banned) you need to respect network
> topology and have an intimate understanding of how it works. For
> example the YouTube/Akamai serving systems have this intelligence but
> whatever implementation you come up with won't.

Truth is that network connectivity is getting better and better. As
aggregate and average network speeds increase around the world, this
problem will be overcome. As Eric Schmidt said back in 93 when he was
at Sun Microsystems:

"When the network becomes as fast as the processor, the computer
hollows out and spreads across the network."

I wouldn't be surprised if principles from Erlang could be borrowed
and applied to this idea, because from what I understand, Erlang has
an extremely robust agent-based message passing model with lots of
error checking and recovery features.


>
> - P2P is far more complicated than an HTTP download. I never use
> BitTorrent because it basically never worked well for me, compared to
> a regular file download. You don't see it used much outside the pirate
> scene and distributing linux ISOs these days for that reason, I think.

As a product manager myself, I don't think you see it outside those
two scenes because it doesn't hide enough of the complexity for
mainstream use. Compare the following two:

A)
Step 1: Point your browser at www.myapplication.com

B)
Step 1: Point your browser at www.torrentclient.com
Step 2: Download and install torrent client
Step 3: Configure torrent client to work well with your network if you
are behind a NAT
Step 4: Find a torrent file repository
Step 5: Find and download the torrent file you want and add it to your
torrent client if it does not already do so automatically,

Other than step 3, all the rest of those steps can be hidden from the
user with the idea I suggested. Using a P2P distritbuted application
suddenly becomes as easy as typing in a URL and clicking enter.

An as far as I can tell Step 3 can be resolved by IPv6.

>
> Your friends problem has other possible solutions:
>
> 1) Harvesting low hanging fruit:
> 1a) Making sure every static asset is indefinitely cacheable (use
> those ISP proxy caches!)
> 1b) Ensuring content is being compressed as effectively as possible
> 1c) Consider serving off a CDN like Akamai or Limelight. There is
> apparently a price war going on right now.

I'm going to check if we've done 1a.

AFAIK, we've performed 1b and we already use a CDN to distribute the
content (1c).

We've also made sure to set the etags and the last modified HTTP headers.

>
> and of course the ultimate long term solution
>
> 2) Scaling revenues in line with traffic
>

The reason I suggested the idea was to get away from cost entirely.

The more popular something is the cheaper it is to distribute it.
Bandwidth costs effectively drop with popularity. An inverse price
relationship and negative marginal cost. Imagine the impact on the
economics of information dissemination. This would turn things on its
head.

One dangerous side to this is that you would promote natural
monopolies (i.e. a stock market) in which liquidity attracts more
liquidity. It would all of a sudden be costly (relatively speaking to
get an aggregation site off the ground, because the massive players
would have hyper-economies of scale.

i.e. if their videosharing site is 25x as popular, their cost would
not be 25x the cost, but instead may be only 4x the bandwidth cost
because all the peers on their network would be providing the
necessary bandwidth in swarm form.

on the other hand. there all of a sudden is an incredible amount of
value in trying to produce quality content (you'd have a reason for
the cult of the amateur to become the cult of the individual pro).

okay, enough rambling.

From mikewse at hotmail.com  Thu Jan 21 19:04:34 2010
From: mikewse at hotmail.com (Mike Wilson)
Date: Fri, 22 Jan 2010 04:04:34 +0100
Subject: [whatwg] History API, pushState(), and related feedback
In-Reply-To: <Pine.LNX.4.62.1001140212000.29142@hixie.dreamhostps.com>
Message-ID: <009d01ca9b0f$a08843e0$0a01a8c0@mikedeskxp>

Ian Hickson wrote:
> On Wed, 19 Aug 2009, Mike Wilson wrote:
> > 
> > Currently, the design with an immutable state object and 
> the PopEvent 
> > and HashChange events triggering at somewhat insufficient 
> timings, makes 
> > it hard to build the things I'm thinking about.
> > 
> > IMO you need:
> > - an event each time you're *leaving* a history entry (in
> >   addition to HashChange triggered when entering one)
> > - allow updating existing state entries
> > - shift the whole state entry model so that state entries 
> >   belong to history entries, and are not logically inserted 
> >   "between" them (this is actually a very important 
> >   distinction)
> > 
> > I'm hoping Ian will come back with the use cases he has in 
> mind, as I am 
> > as of yet not clear on what he wants, or does not want, to 
> support with 
> > the pushState model.
> 
> Does replaceState() make it possible to do the things you're
> thinking about? If not, could you elaborate on what is not 
> possible, or is awkward, in the current design?

Yes, replaceState solves bullets two and three above.


> On Sat, 22 Aug 2009, Mike Wilson wrote:
> > 
> > Great, this seems to be exactly what I want too. In particular
> > I note the following differences from the current spec:
> > - events both when entering and leaving a history entry (I 
> >   called them hashload and hashunload but I agree it is better 
> >   to avoid "hash" as we also have state-only history entries)
> > - the same processing for "fresh" (newly navigated to) history
> >   entries as for "historical" (navigated back/forward to)
> >   history entries
> > - removal of the popstate event and exposing a read/writable 
> >   state object during the whole history entry "session"
> > 
> > About "stateactivated" naming:
> > Activated/deactivated is a bit longish. Could
> > - stateload/stateunload
> > - stateenter/stateleave
> > or others be good alternatives?
> > Is "state" the desired keyword? Or should "history" or others
> > be considered?
> > Or something playing on the "pageshow/pagehide" naming?
> > 
> > About "pageStorage" lifetime:
> > Adding on to your description, assuming we are navigating from 
> > one page (/a) to another (/b) in history without bfcache, the 
> > following would be a suitable chain of events:
> > - /a statedeactivated event
> > - /a unload event
> > - /a browser saves form fields, scrollpos, and history state obj
> > - <browser swaps out /a and loads /b>
> > - /b browser restores history state obj before any script runs
> > - /b scripts are executed and form fields and scrollpos are 
> >      restored while document content is built
> > - /b load event
> > - /b stateactivated event
> > 
> > About "pageStorage" naming:
> > I think "page" makes you think more of Document than of history
> > entries. Looking at an overview of storage areas, ordered from
> > large scopes down to fine-grained scopes may spawn some ideas:
> > 
> >   CURRENTLY DISCUSSED:
> > 
> >   Scope               Storage area / identifier
> >   -----               -------------------------
> >   user agent          window.localStorage
> >   browsing context    window.sessionStorage
> >   document            -
> >   history entry       window.pageStorage
> > 
> > If anticipating there could be a future storage area per 
> > Document, naming could be something like this:
> > 
> >   ALTERNATIVE:
> > 
> >   Scope               Storage area / identifier
> >   -----               -------------------------
> >   user agent          window.localStorage
> >   browsing context    window.sessionStorage
> >   document            document.documentStorage
> >   history entry       window.history.entryStorage
> 
> I'm a little concerned about overgeneralisation and 
> overabstraction to the 
> point of making APIs that on paper seem logical but in practice don't 
> really work. I'm not really clear on what the above is 
> proposing to solve, 
> though. Could you describe the problem with the current API 
> that the above 
> solves, ideally with reference to use cases?

I'll keep this short as there is more recent discussion:
1) The additional event is discussed later in this mail.
2) The pageStorage object is one incarnation of [a key
   value store] solving the dependency problem that appears
   when different components want to save data to the single
   session history state object

And the later part is more about general properties of
API design:
3) If a key-value store is desired, then using the same API 
   as the other key-value stores is a strength and not an over-
   generalisation. The web doesn't need yet another API.
4) Thinking about possible future additions when choosing
   names is one part (of many) of a successful design.


> On Wed, 2 Dec 2009, Mike Wilson wrote:
> 
> > 6.11.9, step 3.1.2:
> > 
> >   "The browsing context's browsing context name must be unset."
> > 
> >   It might be good with a note that the browsing context name
> >   is only switched by the user agent for history traversal to
> >   another origin, and not for navigation to a new origin.
> 
> Navigation involves a history traversal step.

Right, missed that. Good, it seems correct that browser 
context name is cleared when navigating to a new origin.


> On Wed, 23 Dec 2009, Mike Wilson wrote:
> > 
> > - get state for current session history entry 
> >   [partial support by spec (popstate), *1]
> > *1: only available in popstate event, not during rest of
> >     history entry lifetime (getter needed)
> 
> It's not really clear what the use case for this is. Could 
> you elaborate?

This is about the current API forcing cooperation upon
different components that want to store state, and having
to carry an extra copy of the current state data.

Let's say that we have two components, A and B, that are
not aware of each other but both want to save state to the
history state.

The author could make an app-global save function that
connects to all update notifications from all components
and does:
  function saveItAll() {
    History.replaceState({
      A: A.serializeState(),
      B: B.serializeState()
    });
  }

The above has two drawbacks:
- the global function has to be maintained when components
  are added or removed
- even if only one component's data is updated (triggering
  the save function), all component serialization has to
  be executed even if not changed

Trying to fix this, we would want to set each part of the
state separately so each component can handle its own
updates:

  A.saveMe: function() {...}
  ...
  B.saveMe: function() {...}

and no global coordination would be needed. But the problem
is that when A.saveMe wants to store its latest data, it
must also have all other data, and to be able to have the
latest state we need a getter:

  A.saveMe: function() {
    var data = History.getState();
    data.A = A.serializeState();
    History.replaceState(data);
  }

With this solution components can have a loose cooperation
by just agreeing on a general data format (f ex map).
Without the getter, components can no longer use the History
API directly, but instead have to call through a wrapper
that caches the latest state in a variable:

  A.saveMe: function() {
    var data = MyHistoryWrapper.getState();
    data.A = A.serializeState();
    MyHistoryWrapper.replaceState(data);
  };
  MyHistoryWrapper.replaceState = function(data) {
    this.cache = data;
    History.replaceState(data);
  };

Now components not only have to cooperate on a data format,
but also on a non-standard API.

Of course this use case had been better served by a key-
value store like pageStorage mentioned above. But having a 
getter takes us at least halfway there.


> On Wed, 23 Dec 2009, Mike Wilson wrote:
> > 
> > - allow for self-contained components to handle own state
> >   [not supported by spec, *2]
> > *2: all page parts saving state must coordinate with a 
> >     shared data structure (key/value-store or similar 
> >     needed)
> 
> This is supported, if the various components cooperate, either by all 
> registering onpopstate handlers and having a state object format that 
> allows for component ownership to be established, or by 
> having a wrapper 
> library that does dynamic dispatch of state objects. DOM APIs 
> and HTML in 
> general do not give any more than support for multiple components in 
> general -- for example, there's only one DOM, etc. Components 
> are expected 
> to be written in a cooperative way (and they often are -- there are 
> several modular frameworks for this).

The point here is that there are several frameworks for this,
and there will always be. This means that components that are
compatible with one framework and not the others, and there
is no longer a notion of a self-contained component that only
relies on standardized APIs. IMHO adding a getter, or making
the history state into a key-value store, is a cheap price to
pay API-wise to get self-contained components without any
strings attached.

> On Wed, 23 Dec 2009, Mike Wilson wrote:
> > 
> > - have a notification event when entering a history entry
> >   [almost full support in spec (popstate), *3]
> > *3: popstate event not fired for navigation with pushState
> >     (fire for navigation too needed)
> 
> If you're calling the API, you know you are, so there's no 
> need to be told 
> that you are.
<snip>
> On Wed, 23 Dec 2009, Mike Wilson wrote:
> >
> > Certainly the page code can update the state on every change of 
> > user-editable state, setting up a swarm of event handlers 
> not to miss 
> > anything important. My point is that this is not always practical, 
> > imagine f ex serializing a large tree or rich-text editor on every 
> > update event.
> 
> I don't see why this would need a notification of calling pushState().

This is because you mixed up the sequence of replies, it is
about *leaving* history entry below:

> On Wed, 23 Dec 2009, Mike Wilson wrote:
> >
> > - have a notification event when leaving current history 
> >   entry 
> >   [not supported by spec, *4]
> > *4: there is no event that fires before upcoming history
> >     entry is activated (new event needed)
> 
> On Wed, 23 Dec 2009, Justin Lebar wrote:
> > 
> > Is the use case here to allow pages to save their state 
> right before the 
> > browser navigates away?  This doesn't seem essential -- the 
> page could 
> > just call replaceState whenever the state changes -- but I 
> suppose it 
> > might be useful.
> 
> It's unclear to me what the use case is also. Note that you 
> can already 
> detect every page navigation or transition by just hooking into the 
> popstate, hashchange, and unload events.

Text from above: "My point is that this is not always practical, 
imagine f ex serializing a large tree or rich-text editor on every 
update event."
Performance is key here; if you will be storing state that takes
a performance hit to prepare for storage, then you don't want to
save it on every user keystroke or similar, you want to know when
it is time to save and do it once.

Compare f ex with step 4 in History Traversal:
| update the current entry in the browsing context's Document 
| object's History object to reflect any state that the user agent 
| wishes to persist. [...] For example, some user agents might want 
| to persist the scroll position, or the values of form controls.

Ie, this data is persisted on demand at a certain point in the
history entry's life cycle, just as I am suggesting for the 
pushState state.
With the same reasoning as for current pushState, the spec would
instead suggest that scroll position and form control values were
persisted immediately when changed, instead of at the "leave
history entry" event.


Best regards
Mike Wilson


From mjs at apple.com  Thu Jan 21 19:12:21 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 21 Jan 2010 19:12:21 -0800
Subject: [whatwg] Authoring feedback on <datalist>
In-Reply-To: <7c2a12e21001211642p4c2eed27w4dd3e1bf461614f2@mail.gmail.com>
References: <7c2a12e21001211627n3c922f54g619a060354cd7ab8@mail.gmail.com>
	<7c2a12e21001211642p4c2eed27w4dd3e1bf461614f2@mail.gmail.com>
Message-ID: <5415E8A5-6DFB-4230-93AB-8C455CC955FC@apple.com>


On Jan 21, 2010, at 4:42 PM, Aryeh Gregor wrote:

> It's also worth noting that <datalist> currently seems to be conceived
> as a combobox, while search suggestions deserve totally different UI.
> Opera's UI is suitable to search suggestions, but WebKit's proposed UI
> is inappropriate for them:
> 
> http://docs.google.com/View?id=dch3zh37_0cf8kc8c4
> 
> There's a little drop-down arrow you have to click to get the list,
> which is unexpected for search suggestions.  If a separate "suggest"
> IDL attribute were added, UAs could provide different UI for that and
> datalist.

I haven't reviewed that proposal closely, but I would expect <input type=text list=...> on Mac to use the standard Mac combobox control:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2010-01-21 at 7.10.52 PM.png
Type: image/png
Size: 10925 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/daf705a0/attachment-0001.png>
-------------- next part --------------


Likewise on Windows it should show the standard combobox instead of what is pictured there.

I would expect <input type=search list=...> to not show any extra buttons, but simply use the list much the way search suggestions work in the Safari built-in search field.

It's not clear to me that suggest=... is needed.

Regards,
Maciej


From mjs at apple.com  Thu Jan 21 19:15:49 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 21 Jan 2010 19:15:49 -0800
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
Message-ID: <8AD1E31D-074C-4871-90EF-27E6A141CC5F@apple.com>


On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:

> In WebKit, history.back() is currently implemented asynchronously.
> 
> However, it was not always this way.  Previously, if the back navigation corresponded to a hash change, then the back navigation would complete synchronously.  If the back navigation corresponded to a different document, then it would be completed asynchronously.
> 
> The HTML5 spec currently calls for the old behavior of WebKit, which happens to match the behavior of Gecko.  Because the spec is written this way, there is movement in WebKit to change WebKit back.
> 
> IE however appears to implement history.back() asynchronously in all cases just like newer versions of WebKit.
> 
> I actually think this is a better behavior to spec for a couple reasons:
> 
> 1)  It allows for history.back() to behave consistently regardless of the type of navigation.
> 2)  It allows for the back/forward list to be decoupled from the main thread of the rendering engine.
> 
> This last point is quite relevant to Chrome since we store the back/forward list in a separate process.  We do this since items in the back/forward list may actually need to be rendered using different WebKit processes.  (Navigating in the location bar is a hint that we can spawn a new process.)
> 
> We could copy the entire back/forward list to each process and replicate state, but that seems excessive.  Instead, simply matching the history.back() behavior of IE avoids the need to do so.

I don't have strong feelings either way on what the spec should require. But I don't see why this is excessive. You'd only have to store fragment navigations and pushState navigations, not the full back/forward list. It seems like a good idea anyway not to have to serialize state objects back and forth.

I asked Brady (the Safari/WebKit engineer who implemented pushState()) about this, and he told me he found that in the pushState case it sometimes made things easier from the authoring side for history.back() to be synchronous. But I don't have the details.

> 
> From a web compat perspective, it seems wise to match the behavior of IE.  It also has other benefits.
> 
> Can we change the spec?


Regards,
Maciej

From beidson at apple.com  Thu Jan 21 19:17:34 2010
From: beidson at apple.com (Brady Eidson)
Date: Thu, 21 Jan 2010 19:17:34 -0800
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
Message-ID: <CD20E8C5-1796-472D-B1A0-29BC0565778D@apple.com>


On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:

> In WebKit, history.back() is currently implemented asynchronously.
> 
> However, it was not always this way.  Previously, if the back navigation corresponded to a hash change, then the back navigation would complete synchronously.  If the back navigation corresponded to a different document, then it would be completed asynchronously.
> 
> The HTML5 spec currently calls for the old behavior of WebKit, which happens to match the behavior of Gecko.  Because the spec is written this way, there is movement in WebKit to change WebKit back.
> 
> IE however appears to implement history.back() asynchronously in all cases just like newer versions of WebKit.
> 
> I actually think this is a better behavior to spec for a couple reasons:
> 
> 1)  It allows for history.back() to behave consistently regardless of the type of navigation.

I agree it would make history.back() consistent regardless of the type of navigation.  I don't necessarily know what benefit this has.

> 2)  It allows for the back/forward list to be decoupled from the main thread of the rendering engine.

I've both brainstormed on my own and discussed this point with others who have done a lot of thought on how a multi-threaded or multi-processed WebKit may work in the future, and we all agree that synchronous history.go() does not make an MT/MP implementation difficult or impossible.

> This last point is quite relevant to Chrome since we store the back/forward list in a separate process.  We do this since items in the back/forward list may actually need to be rendered using different WebKit processes.  (Navigating in the location bar is a hint that we can spawn a new process.)
> 
> We could copy the entire back/forward list to each process and replicate state, but that seems excessive.  Instead, simply matching the history.back() behavior of IE avoids the need to do so.
> 
> From a web compat perspective, it seems wise to match the behavior of IE.  

This is often the case, yes, but not always a good enough rationalization on its own.

> It also has other benefits.

> Can we change the spec?

I've heard one concrete benefit and one theoretical benefit.
Concrete - Chrome's particular multi-process model easily fits in with asynchronous history.go()
Theoretical - Matching the behavior of IE here is important to compatibility than matching Gecko and previous Webkit behavior.

To argue in favor of the current spec:

One of the main drives for async behavior in modern programming and HTML 5 specifically has been to remove the slow and unpredictable nature of blocking I/O from the equation.  Certainly that has been a motivating factor in a lot of feedback I have given, others at Apple have given, and many outside of Apple have given to the HTML 5 spec (including those who work on Chromium).

The current synchronous traversals called for by the spec are explicitly the ones that - from the engine's standpoint - will never have i/o to block on.

More generally, asynchronicity adds complexity to using and understanding APIs as well as predicting the side effects of a particular method call.  Web developers rarely - if ever - have sympathy for the difficulties of the engineers who created the environment they are working in.

It seems that when designing and presenting an API, synchronicity should be preferred unless there's an inherent performance or scalability problem with it.  And I just don't see that problem with the specified behavior of history.go().

~Brady

> 
> -Darin


From darin at chromium.org  Thu Jan 21 20:37:39 2010
From: darin at chromium.org (Darin Fisher)
Date: Thu, 21 Jan 2010 20:37:39 -0800
Subject: [whatwg] history.back()
In-Reply-To: <8AD1E31D-074C-4871-90EF-27E6A141CC5F@apple.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<8AD1E31D-074C-4871-90EF-27E6A141CC5F@apple.com>
Message-ID: <bd8f24d21001212037k28fbf312of024bbbb31c276b@mail.gmail.com>

On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:
>
> > In WebKit, history.back() is currently implemented asynchronously.
> >
> > However, it was not always this way.  Previously, if the back navigation
> corresponded to a hash change, then the back navigation would complete
> synchronously.  If the back navigation corresponded to a different document,
> then it would be completed asynchronously.
> >
> > The HTML5 spec currently calls for the old behavior of WebKit, which
> happens to match the behavior of Gecko.  Because the spec is written this
> way, there is movement in WebKit to change WebKit back.
> >
> > IE however appears to implement history.back() asynchronously in all
> cases just like newer versions of WebKit.
> >
> > I actually think this is a better behavior to spec for a couple reasons:
> >
> > 1)  It allows for history.back() to behave consistently regardless of the
> type of navigation.
> > 2)  It allows for the back/forward list to be decoupled from the main
> thread of the rendering engine.
> >
> > This last point is quite relevant to Chrome since we store the
> back/forward list in a separate process.  We do this since items in the
> back/forward list may actually need to be rendered using different WebKit
> processes.  (Navigating in the location bar is a hint that we can spawn a
> new process.)
> >
> > We could copy the entire back/forward list to each process and replicate
> state, but that seems excessive.  Instead, simply matching the
> history.back() behavior of IE avoids the need to do so.
>
> I don't have strong feelings either way on what the spec should require.
> But I don't see why this is excessive. You'd only have to store fragment
> navigations and pushState navigations, not the full back/forward list. It
> seems like a good idea anyway not to have to serialize state objects back
> and forth.
>

We have to serialize state objects back and forth regardless so that if a
renderer process crashes, we still have the session history.  This allows us
to reload the pages, and restore relevant session history state (e.g.,
scroll position, form field values, and now state objects).



>
> I asked Brady (the Safari/WebKit engineer who implemented pushState())
> about this, and he told me he found that in the pushState case it sometimes
> made things easier from the authoring side for history.back() to be
> synchronous. But I don't have the details.


Brady and I have been discussing this too.  I'm not convinced that
synchronous history.back() makes things significantly better for content
authors.  Indeed, I'm concerned that it makes things worse.

Here's what I mean:  If history.go() sometimes results in the history
traversal completing synchronously (hash change) and sometimes not
(navigation required), then there is a loss of predictability for the
programmer.  They have to deal with event dispatch sometimes happening in a
re-entrant manner, but other times not.  A consistent model seems better to
me.

-Darin



>
> >
> > From a web compat perspective, it seems wise to match the behavior of IE.
>  It also has other benefits.
> >
> > Can we change the spec?
>
>
> Regards,
> Maciej
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/c167b768/attachment.htm>

From darin at chromium.org  Thu Jan 21 20:56:11 2010
From: darin at chromium.org (Darin Fisher)
Date: Thu, 21 Jan 2010 20:56:11 -0800
Subject: [whatwg] history.back()
In-Reply-To: <CD20E8C5-1796-472D-B1A0-29BC0565778D@apple.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<CD20E8C5-1796-472D-B1A0-29BC0565778D@apple.com>
Message-ID: <bd8f24d21001212056o54f4ccd3m6784396779c4f494@mail.gmail.com>

On Thu, Jan 21, 2010 at 7:17 PM, Brady Eidson <beidson at apple.com> wrote:

>
> On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:
>
> > In WebKit, history.back() is currently implemented asynchronously.
> >
> > However, it was not always this way.  Previously, if the back navigation
> corresponded to a hash change, then the back navigation would complete
> synchronously.  If the back navigation corresponded to a different document,
> then it would be completed asynchronously.
> >
> > The HTML5 spec currently calls for the old behavior of WebKit, which
> happens to match the behavior of Gecko.  Because the spec is written this
> way, there is movement in WebKit to change WebKit back.
> >
> > IE however appears to implement history.back() asynchronously in all
> cases just like newer versions of WebKit.
> >
> > I actually think this is a better behavior to spec for a couple reasons:
> >
> > 1)  It allows for history.back() to behave consistently regardless of the
> type of navigation.
>
> I agree it would make history.back() consistent regardless of the type of
> navigation.  I don't necessarily know what benefit this has.
>

Please see my note to Maciej regarding this.



>
> > 2)  It allows for the back/forward list to be decoupled from the main
> thread of the rendering engine.
>
> I've both brainstormed on my own and discussed this point with others who
> have done a lot of thought on how a multi-threaded or multi-processed WebKit
> may work in the future, and we all agree that synchronous history.go() does
> not make an MT/MP implementation difficult or impossible.
>

Yes, I can imagine some MT/MP implementations where that could be true.

However, as someone with a great deal of experience developing a
multi-process browser, I can tell you that this would be very expensive for
us to support.  We heavily leverage the fact that the session history list
is divorced from the rendering process / thread.  For example, session
history is modified outside of the rendering process.



>
> > This last point is quite relevant to Chrome since we store the
> back/forward list in a separate process.  We do this since items in the
> back/forward list may actually need to be rendered using different WebKit
> processes.  (Navigating in the location bar is a hint that we can spawn a
> new process.)
> >
> > We could copy the entire back/forward list to each process and replicate
> state, but that seems excessive.  Instead, simply matching the
> history.back() behavior of IE avoids the need to do so.
> >
> > From a web compat perspective, it seems wise to match the behavior of IE.
>
> This is often the case, yes, but not always a good enough rationalization
> on its own.
>

Sure, and it is not the only reason.



>
> > It also has other benefits.
>
> > Can we change the spec?
>
> I've heard one concrete benefit and one theoretical benefit.
> Concrete - Chrome's particular multi-process model easily fits in with
> asynchronous history.go()
> Theoretical - Matching the behavior of IE here is important to
> compatibility than matching Gecko and previous Webkit behavior.
>

There is also the consistency argument I made.  That is quite a concrete
benefit for programmers.




>
> To argue in favor of the current spec:
>
> One of the main drives for async behavior in modern programming and HTML 5
> specifically has been to remove the slow and unpredictable nature of
> blocking I/O from the equation.  Certainly that has been a motivating factor
> in a lot of feedback I have given, others at Apple have given, and many
> outside of Apple have given to the HTML 5 spec (including those who work on
> Chromium).
>

Yes, that is a huge motivation.  I believe there are other motivations.  For
example, asynchronous events provide a nice means to avoid re-entrancy and
the deeply nested stacks that come with them.  postMessage is asynchronous
for this reason.  The scroll event is spec'd to be asynchronous for similar
reasons.



>
> The current synchronous traversals called for by the spec are explicitly
> the ones that - from the engine's standpoint - will never have i/o to block
> on.
>
> More generally, asynchronicity adds complexity to using and understanding
> APIs as well as predicting the side effects of a particular method call.
>  Web developers rarely - if ever - have sympathy for the difficulties of the
> engineers who created the environment they are working in.
>
> It seems that when designing and presenting an API, synchronicity should be
> preferred unless there's an inherent performance or scalability problem with
> it.  And I just don't see that problem with the specified behavior of
> history.go().
>


Again, there is a consistency problem, a re-entrancy problem, etc.

>From the performance and scalability angle, I also believe that we should
not design ourselves into a corner with APIs.  I for one am very interested
in a future where more elements of an application can be split off into
separate threads.  An iframe in a separate domain being a good example where
this kind of separation is desirable.  The more synchronous events we build
into the platform (binding everything together), the more we do to defeat a
nice future where more things can be run independently on separate threads.

Imagine the case of a frame in domain A containing a frame in domain B.
 They cannot directly script each other.  They can only communicate using
postMessage.  That's nice because it allows them to run independently.  Now,
imagine that the subframe navigates itself to a reference fragment.  Why
should history.back() called by the parent frame result in blocking the
parent until the subframe traversal completes?

-Darin



>
> ~Brady
>
> >
> > -Darin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/b88471ad/attachment-0001.htm>

From darin at chromium.org  Thu Jan 21 21:34:03 2010
From: darin at chromium.org (Darin Fisher)
Date: Thu, 21 Jan 2010 21:34:03 -0800
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001212056o54f4ccd3m6784396779c4f494@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<CD20E8C5-1796-472D-B1A0-29BC0565778D@apple.com>
	<bd8f24d21001212056o54f4ccd3m6784396779c4f494@mail.gmail.com>
Message-ID: <bd8f24d21001212134t4450c27ege514018dc1b37cb@mail.gmail.com>

On Thu, Jan 21, 2010 at 8:56 PM, Darin Fisher <darin at chromium.org> wrote:

> On Thu, Jan 21, 2010 at 7:17 PM, Brady Eidson <beidson at apple.com> wrote:
>
>>
>> On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:
>>
>> > In WebKit, history.back() is currently implemented asynchronously.
>> >
>> > However, it was not always this way.  Previously, if the back navigation
>> corresponded to a hash change, then the back navigation would complete
>> synchronously.  If the back navigation corresponded to a different document,
>> then it would be completed asynchronously.
>> >
>> > The HTML5 spec currently calls for the old behavior of WebKit, which
>> happens to match the behavior of Gecko.  Because the spec is written this
>> way, there is movement in WebKit to change WebKit back.
>> >
>> > IE however appears to implement history.back() asynchronously in all
>> cases just like newer versions of WebKit.
>> >
>> > I actually think this is a better behavior to spec for a couple reasons:
>> >
>> > 1)  It allows for history.back() to behave consistently regardless of
>> the type of navigation.
>>
>> I agree it would make history.back() consistent regardless of the type of
>> navigation.  I don't necessarily know what benefit this has.
>>
>
> Please see my note to Maciej regarding this.
>
>
>
>>
>> > 2)  It allows for the back/forward list to be decoupled from the main
>> thread of the rendering engine.
>>
>> I've both brainstormed on my own and discussed this point with others who
>> have done a lot of thought on how a multi-threaded or multi-processed WebKit
>> may work in the future, and we all agree that synchronous history.go() does
>> not make an MT/MP implementation difficult or impossible.
>>
>
> Yes, I can imagine some MT/MP implementations where that could be true.
>
> However, as someone with a great deal of experience developing a
> multi-process browser, I can tell you that this would be very expensive for
> us to support.  We heavily leverage the fact that the session history list
> is divorced from the rendering process / thread.  For example, session
> history is modified outside of the rendering process.
>
>
>
>>
>> > This last point is quite relevant to Chrome since we store the
>> back/forward list in a separate process.  We do this since items in the
>> back/forward list may actually need to be rendered using different WebKit
>> processes.  (Navigating in the location bar is a hint that we can spawn a
>> new process.)
>> >
>> > We could copy the entire back/forward list to each process and replicate
>> state, but that seems excessive.  Instead, simply matching the
>> history.back() behavior of IE avoids the need to do so.
>> >
>> > From a web compat perspective, it seems wise to match the behavior of
>> IE.
>>
>> This is often the case, yes, but not always a good enough rationalization
>> on its own.
>>
>
> Sure, and it is not the only reason.
>
>
>
>>
>> > It also has other benefits.
>>
>> > Can we change the spec?
>>
>> I've heard one concrete benefit and one theoretical benefit.
>> Concrete - Chrome's particular multi-process model easily fits in with
>> asynchronous history.go()
>> Theoretical - Matching the behavior of IE here is important to
>> compatibility than matching Gecko and previous Webkit behavior.
>>
>
> There is also the consistency argument I made.  That is quite a concrete
> benefit for programmers.
>
>
>
>
>>
>> To argue in favor of the current spec:
>>
>> One of the main drives for async behavior in modern programming and HTML 5
>> specifically has been to remove the slow and unpredictable nature of
>> blocking I/O from the equation.  Certainly that has been a motivating factor
>> in a lot of feedback I have given, others at Apple have given, and many
>> outside of Apple have given to the HTML 5 spec (including those who work on
>> Chromium).
>>
>
> Yes, that is a huge motivation.  I believe there are other motivations.
>  For example, asynchronous events provide a nice means to avoid re-entrancy
> and the deeply nested stacks that come with them.  postMessage is
> asynchronous for this reason.  The scroll event is spec'd to be asynchronous
> for similar reasons.
>
>
>
>>
>> The current synchronous traversals called for by the spec are explicitly
>> the ones that - from the engine's standpoint - will never have i/o to block
>> on.
>>
>> More generally, asynchronicity adds complexity to using and understanding
>> APIs as well as predicting the side effects of a particular method call.
>>  Web developers rarely - if ever - have sympathy for the difficulties of the
>> engineers who created the environment they are working in.
>>
>> It seems that when designing and presenting an API, synchronicity should
>> be preferred unless there's an inherent performance or scalability problem
>> with it.  And I just don't see that problem with the specified behavior of
>> history.go().
>>
>
>
> Again, there is a consistency problem, a re-entrancy problem, etc.
>
> From the performance and scalability angle, I also believe that we should
> not design ourselves into a corner with APIs.  I for one am very interested
> in a future where more elements of an application can be split off into
> separate threads.  An iframe in a separate domain being a good example where
> this kind of separation is desirable.  The more synchronous events we build
> into the platform (binding everything together), the more we do to defeat a
> nice future where more things can be run independently on separate threads.
>
> Imagine the case of a frame in domain A containing a frame in domain B.
>  They cannot directly script each other.  They can only communicate using
> postMessage.  That's nice because it allows them to run independently.  Now,
> imagine that the subframe navigates itself to a reference fragment.  Why
> should history.back() called by the parent frame result in blocking the
> parent until the subframe traversal completes?
>
>
Another performance consideration:

Suppose I wanted to have a near endless session history.  To implement that
I'm very likely to use a disk-based backing store, which could imply having
to block the UI thread of a web app in order to read from disk.  That is
bad.

-Darin





> -Darin
>
>
>
>>
>> ~Brady
>>
>> >
>> > -Darin
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100121/5c00bfb8/attachment.htm>

From mjs at apple.com  Fri Jan 22 01:13:05 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 22 Jan 2010 01:13:05 -0800
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001212037k28fbf312of024bbbb31c276b@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<8AD1E31D-074C-4871-90EF-27E6A141CC5F@apple.com>
	<bd8f24d21001212037k28fbf312of024bbbb31c276b@mail.gmail.com>
Message-ID: <7DC00B68-26E8-4D74-93F8-73DACE776B16@apple.com>


On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote:

> On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak <mjs at apple.com> wrote: 
> 
> I asked Brady (the Safari/WebKit engineer who implemented pushState()) about this, and he told me he found that in the pushState case it sometimes made things easier from the authoring side for history.back() to be synchronous. But I don't have the details.
> 
> Brady and I have been discussing this too.  I'm not convinced that synchronous history.back() makes things significantly better for content authors.  Indeed, I'm concerned that it makes things worse.
> 
> Here's what I mean:  If history.go() sometimes results in the history traversal completing synchronously (hash change) and sometimes not (navigation required), then there is a loss of predictability for the programmer.  They have to deal with event dispatch sometimes happening in a re-entrant manner, but other times not.  A consistent model seems better to me.

I don't really have strong feelings about this at present. But I think the most important deciding factor should be what is the best behavior for authors. It seems like the implementation details are something that can be worked out either way, so implementation challenge should be a tiebreaker at best.

You are correct that consistency is good. However, whether a navigation to a different document is asynchronous can barely be observed - it's not like any code from the current document will run after the navigation anyway. For within-document navigations, I could imagine synchronous behavior might make some things easier to code - you could call history.back() to pop the state stack, and your code running afterwards could assume you'd successfully traversed to the new state. On the other hand, I could also imagine it's harder. And history.back is probably not used all that much in modern Web apps anyway. That's why I don't have a very good picture of which approach is better.

Regards,
MAciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/59ea34b3/attachment.htm>

From ian at hixie.ch  Fri Jan 22 02:08:53 2010
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jan 2010 10:08:53 +0000 (UTC)
Subject: [whatwg] history.back()
In-Reply-To: <bd8f24d21001212134t4450c27ege514018dc1b37cb@mail.gmail.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<CD20E8C5-1796-472D-B1A0-29BC0565778D@apple.com>
	<bd8f24d21001212056o54f4ccd3m6784396779c4f494@mail.gmail.com>
	<bd8f24d21001212134t4450c27ege514018dc1b37cb@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001220800040.6554@ps20323.dreamhostps.com>

On Thu, 21 Jan 2010, Darin Fisher wrote:
>
> In WebKit, history.back() is currently implemented asynchronously.

It's not clear to me what you mean by "asynchronously".

Do you mean that the events fire asynchronously? That the Location object 
is updated asynchronously? That the decision about whether the call is a 
noop or not is fired asynchronously? That the navigation, if one is 
necessary, is done asynchronously? Are we talking about same-frame, or 
cross-frame? Same-origin, or cross-origin? Traversal from one entry in one 
document to another entry in the same document, or in another document?

I made some demos to test this out, and it seems that IE8 behaves 
differently whether it's cross-frame or same-frame. I'd really rather we 
define this in a way that is consistent for all ways of invoking the API. 
It does the Location changes synchronously if invoked in-page, and 
asynchronously if the traversal affects another page.

For simple cases, Firefox consistently does the Location change 
synchronously. Opera (10.x on Windows), Safari (4 for Windows), and Chrome 
do it async. But complicated cases make these descriptions simplistic.

   http://www.hixie.ch/tests/adhoc/dom/level0/history/sync-vs-async/


> IE however appears to implement history.back() asynchronously in all 
> cases just like newer versions of WebKit.

That doesn't appear to be completely accurate.


> From a web compat perspective, it seems wise to match the behavior of 
> IE. It also has other benefits.
> 
> Can we change the spec?

Yes, but that won't make it async if the goal is to match IE.


On Thu, 21 Jan 2010, Jonas Sicking wrote:
> 
> Sounds good to me. Having all navigation be asynchronous I suspect would 
> have implementations benefits in Gecko too.

It would be a reasonably minor change to the spec. I'm happy to go either 
way on this. The problem is I don't know exactly what "async" vs "sync" 
really means in this context, since the algorithms are quite complicated.


On Thu, 21 Jan 2010, Olli Pettay wrote:
>
> And still one thing to test and specify;
> if history.back()/forward() is asynchronous,
> does that mean that loading start asynchronously,
> or that entries are added asynchronously to session history?
> 
> What should happen if a page calls:
> history.back();
> history.forward();
> 
> What if the page calls:
> history.back();
> history.go(-2);

Indeed. There are the kinds of questions I am curious about.

Another is what should happen if a page goes back() past its fragment 
identifier entries, and then modifies the document or alerts the location? 
What location should it get? Which document should it mutate? (test 007)

How about:

   location.hash = 'a';
   /* spin event loop */
   history.back();
   location.hash = 'b';
   history.forward();
   alert(location.hash);
   /* spin event loop */
   alert(location.hash);

What does this alert? (test 008)

How about:

   location.hash = 'x';
   location.hash = 'a';
   /* spin event loop */
   history.back();
   /* spin event loop */
   history.forward();
   location.hash = 'b';
   /* spin event loop */
   history.back();
   /* spin event loop */
   alert(location.hash);

What does this alert? (test 010)


> And btw, some of the session history handling is anyway synchronous. Per 
> the current HTML5 draft calling document.open() adds a new entry to 
> session history immediately (IIRC, webkit is the only one which doesn't 
> support this).

Another example is navigating to a fragment identifier, which in all 
browsers I tested changes the Location object immediately also.


As I see it these are the criteria that we have to consider here in making 
a decision, in order of importance:

 * Compatibility.
   It seems that browsers are quite inconsistent here, and so it's likely 
   that we have some room to maneuver. Nobody has mentioned any 
   particular bugs in sites caused by implementing this one way or 
   another. I am not convinced that compatibility is a factor at this 
   point.

 * Consistency for authors
   I think whatever solution we come up with we should make sure it is 
   sane for authors. In this case, however, pretty much any model works,
   so this doesn't really help decide what is best, so long as we are 
   consistent in how we specify and implement it.

 * Implementation concerns
   This may be the deciding factor, in particular due to the multiprocess 
   session history issues Darin raised.

 * Specification sanity
   I think we can probably make any model work in the spec, without even 
   much of a rewrite being needed. It's just a matter of saying when 
   things happen, for which the spec now has considerable infrastructure.


Does anyone have any opinions on how the examples above should work? How 
should document.open() and location's setter interact with history.back()? 
Should navigation to fragment identifiers asynchronously set Location? 
Should Location be set synchronously but with the session history actually 
being updated asynchronously using a task, so that .back() and .forward() 
calls get interleaved with the Location setter? Should document.open() 
synchronously clear the session history, or should it asynchronously queue 
a task and do it that way? Should we, instead of using tasks that could 
run much later (e.g. if the script has previously invoked a bunch of 
setTimeout(0)s), add a step to the event loop so that after each task, any 
history traversal that's been queued up gets processed immediately?

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

From andrew at deandrade.com.br  Fri Jan 22 03:48:37 2010
From: andrew at deandrade.com.br (Andrew de Andrade)
Date: Fri, 22 Jan 2010 09:48:37 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <1b4ff0311001220108u3b6f4695j1305da9bc43e389d@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com>
	<9178f78c1001191131i7fdd4dacgb98cae78535423e1@mail.gmail.com>
	<42b395981001191154g660174c6j99cc8ad90027153@mail.gmail.com>
	<f4cd80641001211424o5fddfe78tc5cedb50136154c5@mail.gmail.com>
	<42b395981001211833l462e8981w53cd136364140e15@mail.gmail.com>
	<1b4ff0311001220108u3b6f4695j1305da9bc43e389d@mail.gmail.com>
Message-ID: <4E6A9194-BDBC-4E77-9518-DBFF669ED4EA@deandrade.com.br>


On 22/01/2010, at 07:08, Ivan ?u?ak <izuzak at gmail.com> wrote:

> On Fri, Jan 22, 2010 at 03:33, Andrew de Andrade
> <andrew at deandrade.com.br> wrote:
>> comments inline
>
>>> - A naive P2P implementation won't provide good throughput or  
>>> latency
>>> because you might end up downloading files from a mobile phone on  
>>> the
>>> other side of the world rather than a high performance CDN node  
>>> inside
>>> your local ISP. That sucks for users and also sucks for your ISP who
>>> will probably find their transit links suddenly saturated and their
>>> nice cheap peering links with content providers sitting idle.
>>
>> Any ideas on how this could be resolved?
>>
>> I figure if the application is popular enough, the peers could be
>> geographically tagged using the "GPS" functionality of HTML5. Clients
>> would automatically get better connections and throughput and
>> preference if they choose to make their location available to the
>> "torrent" server so that peers can look up peers nearby.
>
> Good idea. Also, not all content would be declared to be served by
> clients. E.g. the index page of a web application could be served by
> the origin server, while some other content (scripts? images?) linked
> to from the index page could be fetched from nearby clients (e.g. when
> the client requests the index page from the server, the server could
> also point to nearby clients serving images).
>
> Ivan

All these complementary features of HTML5 are one reason I figured  
that this may be an interesting idea to suggest here instead of the  
IETF, however it's entirely possible that this idea should be  
implemented at both the browser and the web application level. Clearly  
it doesn't make sense to make every web app developer implement a lot  
of the heavy p2p work at the application layer, on the other hand  
features like geolocation, manifests, etc may be complementary  
features to make this idea more robust and performatic.

another idea maybe to have the web app's "bittorrent" file added as a  
server side include in the index.html file just like CSS files are,  
thus giving the browser an option on how to best handle the page.

Andrew de Andrade
@andrewdeandrade

From gleicon at gmail.com  Fri Jan 22 03:54:04 2010
From: gleicon at gmail.com (Gleicon Moraes)
Date: Fri, 22 Jan 2010 09:54:04 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <1b4ff0311001220058u66408ec4vfdf4177e154fd509@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com>
	<1b4ff0311001211144y72716b64j5ccc386f4dcf7226@mail.gmail.com>
	<42b395981001211803s6f5e9a2cj173996c210ad0267@mail.gmail.com>
	<1b4ff0311001220058u66408ec4vfdf4177e154fd509@mail.gmail.com>
Message-ID: <fb983f4a1001220354l6e9be1e0mdce7fad50aec071a@mail.gmail.com>

My 2c (as of talking to myself trying to figure out how to do a prototype of
this)...

I'm not sure where such service would belong, but it would suffer the same
problem that early VoIP systems suffered behind a firewall... While one
would be able to open a socket and serve data, there would have to be some
kind of uPnP or NAT integration to make it visible to the web (or a
tunneling solution as those old http-tunnel stuff).

Apart from that, I think it would be something like embedding a webserver
(or better yet embedding node.js [http://nodejs.org/]) in the same level as
the javascript API is implemented and allow pure or pre-arranged sockets to
be open.

AFAIK, using websockets, the browser initiates a connection with the server,
which will proceed upgrading the connection type and opening a two way
communication with the server and from now on the application defines the
line protocol. At least is what I gathered when doing this:
http://github.com/gleicon/txwebsockets

That way, apart from the browser doing this 2-way connection, it could open
a standard tcp socket, or better, a kind of special server and register
itself on a DHT or tracker (that I think would need to be an obligatory
step).

The p2p like mesh network is a great idea, but I think it would take some
security heads thinking around on what socket/server models it would be safe
to let a browser start, a framework for the tracker registering and a
sandbox akin to crossdomain.xml to protect it from turning to a giant
botnet.

I think this kind of thinking would be great with w3c behind it (and a wide
open discussion on security issues), as I think the node.js approach could
be "quicker" to implement browser-wise...

gm



On Fri, Jan 22, 2010 at 6:58 AM, Ivan ?u?ak <izuzak at gmail.com> wrote:

> On Fri, Jan 22, 2010 at 03:03, Andrew de Andrade
> <andrew at deandrade.com.br> wrote:
> > comments inline
> >
> > On Thu, Jan 21, 2010 at 5:44 PM, Ivan ?u?ak <izuzak at gmail.com> wrote:
> >> As your Google friend noted, I'm wondering why you'd want to implement
> >> this on the HTML5 level, not on the browser (C++) level. Implementing
> >> such a protocol within the browser would probably be faster, more
> >> secure and a better design choice since the functionality is basically
> >> the same for every web application. I'm guessing the reason is that
> >> you do not want to achieve this by changing/extending the browser but
> >> rather by using new HTML5 technologies instead. Am I right?
> >
> > While I realize that this is best implemented at the browser level, my
> > concern is if it will be an idea that would be broadly adopted by all
> > browser vendors if it is implemented at that level. It's an idea that
> > really has value once you've reached critical mass. For example, this
> > would be an extremely potent idea if the two most popular browsers
> > have implemented this by 2014 to 2015 or so. HTML5 is a web technology
> > spec. I imagine that putting it in the spec would greatly increase the
> > chances of browsers supporting this functionality.
> >
> > However, I am not familiar with the politics that govern whether or
> > not browser product managers implement these features at the browser
> > level?
> >
> > Being pragmatic, do you think it's possible to get widespread adoption
> > quickly for a feature like this as the browser level or do you agree
> > that this would be more likely to be adopted quickly if it was part of
> > a W3C spec?
>
> I think there are two separate issues here. First, if this idea is to
> be widely adopted and implemented - I believe there must be an open
> specification of it. And there are basically two ways of doing this -
> by having it proposed by a specific browser vendor or by having it
> proposed by a standardization organisation like the W3C or IETF. And
> yes, you're right - having something proposed by W3C versus a specific
> browser vendor - I'd say it's more likely to catch on if the W3C puts
> it foot behind it.
>
> Second, there is a difference between a) implementing the idea in the
> browser engine versus b) implementing it as a part of the application
> executing on the browser engine. The same functionality can be
> achieved by defining a protocol which browsers would implement as a
> part their engine (e.g. using some other available protocol instead of
> WebSockets (e.g. plan old HTTP or SPDY) and threads instead of
> WebWorkers) or by creating web applications where each application
> would implement this protocol itself using application level
> technologies (i.e. the proposed WebSockets and WebWorkers tech). In
> essence, it doesn't matter which technology you use to implement it as
> long as it implements the protocol you define. So, since technologies
> used for implementation are open and available, why would the W3C
> wan't this implemented at the application level versus the browser
> level? Both scenarios require changes to both the server of an
> application and the browser.
>
> >> If so, then a major problem is that the browser is not a network
> >> server, rather only a client. In order for a browser A to connect
> >> using WebSockets to a browser B which executes some process, browser B
> >> must expose a network accessible end-point to which that process is
> >> tied i.e. the browser must expose TCP/IP end-point. I guess that the
> >> NAT traversal problem Melvin mentioned basically covers this.
> >>
> >
> > Assuming that this idea really only sees adoption within a few years,
> > won't IPv6 resolve the issue of NAT traversal?
>
> I'm not familiar with NAT traversal or what other novelties IPv6
> introduces other than a broader address space, so I may be wrong when
> saying this but - only by switching from IPv4 to IPv6 will not solve
> this problem. The browser would still be a client initiating
> connections to other network entities, not a server accepting
> connections from those clients. Or as Mike put it: "WebSockets doesn't
> let you open arbitrary ports and listen on them". I'm not getting into
> how hard this is to do, I'm just saying that it's something which is
> necessary.
>
> >> In a broader context of connecting both servers and client devices
> >> into a large network for scalable execution of applications, your idea
> >> reminds me of a recent blog article I read:
> >>
> http://highscalability.com/blog/2009/12/16/building-super-scalable-systems-blade-runner-meets-autonomic.html
> .
> >> Definitely have a look at it - it's a bit on the visionary side and
> >> longish, but worth it. I believe a planet-wide execution platform
> >> consisting of every network device will eventually happen and that's
> >> why I think we should all be contributing in that direction, which
> >> your idea definitely is.
> >
> > I took a brief look. This article looks very interesting. I'm going to
> > have a gander at it tomorrow. Maybe I'll shoot the HighScalability
> > people an email and see if they want to comment on this idea on their
> > blog.
>
> I believe Todd from HighScalability will like the idea. It's a
> direction in which lots of people see the Internet/WWW going. I hope
> you didn't get me wrong with my comments - I like your idea of
> distributing the load towards clients.
>
> Cheers,
> Ivan
>



-- 
More cowbell, please !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/f5f0fb18/attachment.htm>

From andrew at deandrade.com.br  Fri Jan 22 06:48:08 2010
From: andrew at deandrade.com.br (Andrew de Andrade)
Date: Fri, 22 Jan 2010 12:48:08 -0200
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
	application
In-Reply-To: <1b4ff0311001220058u66408ec4vfdf4177e154fd509@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com> 
	<1b4ff0311001211144y72716b64j5ccc386f4dcf7226@mail.gmail.com> 
	<42b395981001211803s6f5e9a2cj173996c210ad0267@mail.gmail.com> 
	<1b4ff0311001220058u66408ec4vfdf4177e154fd509@mail.gmail.com>
Message-ID: <42b395981001220648v71881f67k77676bda01493e2@mail.gmail.com>

On Fri, Jan 22, 2010 at 6:58 AM, Ivan ?u?ak <izuzak at gmail.com> wrote:

> I think there are two separate issues here. First, if this idea is to
> be widely adopted and implemented - I believe there must be an open
> specification of it. And there are basically two ways of doing this -
> by having it proposed by a specific browser vendor or by having it
> proposed by a standardization organisation like the W3C or IETF. And
> yes, you're right - having something proposed by W3C versus a specific
> browser vendor - I'd say it's more likely to catch on if the W3C puts
> it foot behind it.
>


I'm wondering if anyone from either webkit, mozilla, opera, the W3C or
IETF can chime in here and shed light on what the correct process
would be to present this idea for consideration either as a standard
(W3C or IETF) or for browser adoption as open code (Webkit, Mozilla,
Opera, etc.)


> Second, there is a difference between a) implementing the idea in the
> browser engine versus b) implementing it as a part of the application
> executing on the browser engine. The same functionality can be
> achieved by defining a protocol which browsers would implement as a
> part their engine (e.g. using some other available protocol instead of
> WebSockets (e.g. plan old HTTP or SPDY) and threads instead of
> WebWorkers) or by creating web applications where each application
> would implement this protocol itself using application level
> technologies (i.e. the proposed WebSockets and WebWorkers tech). In
> essence, it doesn't matter which technology you use to implement it as
> long as it implements the protocol you define. So, since technologies
> used for implementation are open and available, why would the W3C
> wan't this implemented at the application level versus the browser
> level? Both scenarios require changes to both the server of an
> application and the browser.

It appears to me that implementing it at the application level would
create a richer development environment for web app devs to exploit
the underlying features more directly.

Anyone have any other ideas as to the pros and cons of implementing
this at the browser level or the web app level?


>
> I'm not familiar with NAT traversal or what other novelties IPv6
> introduces other than a broader address space, so I may be wrong when
> saying this but - only by switching from IPv4 to IPv6 will not solve
> this problem. The browser would still be a client initiating
> connections to other network entities, not a server accepting
> connections from those clients. Or as Mike put it: "WebSockets doesn't
> let you open arbitrary ports and listen on them". I'm not getting into
> how hard this is to do, I'm just saying that it's something which is
> necessary.
>

The only familiarity I have with IPv6 are my Apple Airport routers at
home. I know there are different options like node or tunnel in the
settings page. It sounds like that if your computer is connected as a
node, your router is connected as a tunnel and your provider supports
IPv6, then this should all work with IPv6 without lots of
complications.

Given the time it would take to coordinate and execute and idea like
this, I figure that it may be best to develop the idea with IPv6 as
the primary layer 2 protocol.

Someone please correct me if I am mistaken.

>
> I believe Todd from HighScalability will like the idea. It's a
> direction in which lots of people see the Internet/WWW going. I hope
> you didn't get me wrong with my comments - I like your idea of
> distributing the load towards clients.
>

I sent a message to Todd alerting him of this thread, so that he can
take a look and consider blogging about it if it seems interesting to
him.

I didn't get you wrong on the comments. There's tons of brilliant
people participating in the WHAT-WG mailing lists and as I only have
an idea and I don't have the technical knowledge, I figured this would
be the best place to get comments, criticisms and feedback. The more
critical people are about the idea the better. Discussion leads to
better developed ideas.

From bzbarsky at MIT.EDU  Fri Jan 22 07:45:24 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 22 Jan 2010 10:45:24 -0500
Subject: [whatwg] history.back()
In-Reply-To: <7DC00B68-26E8-4D74-93F8-73DACE776B16@apple.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>	<8AD1E31D-074C-4871-90EF-27E6A141CC5F@apple.com>	<bd8f24d21001212037k28fbf312of024bbbb31c276b@mail.gmail.com>
	<7DC00B68-26E8-4D74-93F8-73DACE776B16@apple.com>
Message-ID: <4B59C814.7070602@mit.edu>

On 1/22/10 4:13 AM, Maciej Stachowiak wrote:
> However, whether a navigation
> to a different document is asynchronous can barely be observed - it's
> not like any code from the current document will run after the
> navigation anyway.

If the script is navigating its own document, yes.  If it's navigating a 
subframe or popup window, it's pretty easy to observe whether the 
navigation is synchronous.

-Boris

From darin at chromium.org  Fri Jan 22 09:57:51 2010
From: darin at chromium.org (Darin Fisher)
Date: Fri, 22 Jan 2010 09:57:51 -0800
Subject: [whatwg] history.back()
In-Reply-To: <7DC00B68-26E8-4D74-93F8-73DACE776B16@apple.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<8AD1E31D-074C-4871-90EF-27E6A141CC5F@apple.com>
	<bd8f24d21001212037k28fbf312of024bbbb31c276b@mail.gmail.com>
	<7DC00B68-26E8-4D74-93F8-73DACE776B16@apple.com>
Message-ID: <bd8f24d21001220957m54f35737ud143723abba0660a@mail.gmail.com>

On Fri, Jan 22, 2010 at 1:13 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote:
>
> On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> I asked Brady (the Safari/WebKit engineer who implemented pushState())
>> about this, and he told me he found that in the pushState case it sometimes
>> made things easier from the authoring side for history.back() to be
>> synchronous. But I don't have the details.
>
>
> Brady and I have been discussing this too.  I'm not convinced that
> synchronous history.back() makes things significantly better for content
> authors.  Indeed, I'm concerned that it makes things worse.
>
> Here's what I mean:  If history.go() sometimes results in the history
> traversal completing synchronously (hash change) and sometimes not
> (navigation required), then there is a loss of predictability for the
> programmer.  They have to deal with event dispatch sometimes happening in a
> re-entrant manner, but other times not.  A consistent model seems better to
> me.
>
>
> I don't really have strong feelings about this at present. But I think the
> most important deciding factor should be what is the best behavior for
> authors. It seems like the implementation details are something that can be
> worked out either way, so implementation challenge should be a tiebreaker at
> best.
>

That's fair, and I completely agree in principle.

The reality of the situation of course is that implementation challenges
matter a lot.  If implementation costs are high and the benefits of
modifying the code are relatively low, then we are likely to end up with
browsers having inconsistent behavior for some time.



> You are correct that consistency is good. However, whether a navigation to
> a different document is asynchronous can barely be observed - it's not like
> any code from the current document will run after the navigation anyway. For
> within-document navigations, I could imagine synchronous behavior might make
> some things easier to code - you could call history.back() to pop the state
> stack, and your code running afterwards could assume you'd successfully
> traversed to the new state. On the other hand, I could also imagine it's
> harder. And history.back is probably not used all that much in modern Web
> apps anyway. That's why I don't have a very good picture of which approach
> is better.
>

Isn't this what popstate and hashchange notifications are for?  Afterall,
the user could also press the back button, and the developer would probably
be concerned with that case too.

-Darin



>
> Regards,
> MAciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/8586fcea/attachment.htm>

From darin at chromium.org  Fri Jan 22 10:15:06 2010
From: darin at chromium.org (Darin Fisher)
Date: Fri, 22 Jan 2010 10:15:06 -0800
Subject: [whatwg] history.back()
In-Reply-To: <Pine.LNX.4.64.1001220800040.6554@ps20323.dreamhostps.com>
References: <bd8f24d21001210112h22a8f100j2d74ced9b1dce7b5@mail.gmail.com>
	<CD20E8C5-1796-472D-B1A0-29BC0565778D@apple.com>
	<bd8f24d21001212056o54f4ccd3m6784396779c4f494@mail.gmail.com>
	<bd8f24d21001212134t4450c27ege514018dc1b37cb@mail.gmail.com>
	<Pine.LNX.4.64.1001220800040.6554@ps20323.dreamhostps.com>
Message-ID: <bd8f24d21001221015o6c357290k9019307ebb2d9688@mail.gmail.com>

On Fri, Jan 22, 2010 at 2:08 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 21 Jan 2010, Darin Fisher wrote:
> >
> > In WebKit, history.back() is currently implemented asynchronously.
>
> It's not clear to me what you mean by "asynchronously".
>
> Do you mean that the events fire asynchronously? That the Location object
> is updated asynchronously? That the decision about whether the call is a
> noop or not is fired asynchronously? That the navigation, if one is
> necessary, is done asynchronously? Are we talking about same-frame, or
> cross-frame? Same-origin, or cross-origin? Traversal from one entry in one
> document to another entry in the same document, or in another document?
>

To clarify:

history.{back,forward,go} begin by scheduling a task on the current thread
to run later.  From that task, the history traversal algorithm is executed.




>
> I made some demos to test this out, and it seems that IE8 behaves
> differently whether it's cross-frame or same-frame. I'd really rather we
> define this in a way that is consistent for all ways of invoking the API.
> It does the Location changes synchronously if invoked in-page, and
> asynchronously if the traversal affects another page.
>

That's very interesting.



>
> For simple cases, Firefox consistently does the Location change
> synchronously. Opera (10.x on Windows), Safari (4 for Windows), and Chrome
> do it async. But complicated cases make these descriptions simplistic.
>
>   http://www.hixie.ch/tests/adhoc/dom/level0/history/sync-vs-async/
>
>
> > IE however appears to implement history.back() asynchronously in all
> > cases just like newer versions of WebKit.
>
> That doesn't appear to be completely accurate.
>

I was only testing the cross frame case.  Thank you for testing more
thoroughly.



>
>
> > From a web compat perspective, it seems wise to match the behavior of
> > IE. It also has other benefits.
> >
> > Can we change the spec?
>
> Yes, but that won't make it async if the goal is to match IE.
>
>
> On Thu, 21 Jan 2010, Jonas Sicking wrote:
> >
> > Sounds good to me. Having all navigation be asynchronous I suspect would
> > have implementations benefits in Gecko too.
>
> It would be a reasonably minor change to the spec. I'm happy to go either
> way on this. The problem is I don't know exactly what "async" vs "sync"
> really means in this context, since the algorithms are quite complicated.
>
>
> On Thu, 21 Jan 2010, Olli Pettay wrote:
> >
> > And still one thing to test and specify;
> > if history.back()/forward() is asynchronous,
> > does that mean that loading start asynchronously,
> > or that entries are added asynchronously to session history?
> >
> > What should happen if a page calls:
> > history.back();
> > history.forward();
> >
> > What if the page calls:
> > history.back();
> > history.go(-2);
>
> Indeed. There are the kinds of questions I am curious about.
>
> Another is what should happen if a page goes back() past its fragment
> identifier entries, and then modifies the document or alerts the location?
> What location should it get? Which document should it mutate? (test 007)
>
> How about:
>
>   location.hash = 'a';
>   /* spin event loop */
>   history.back();
>   location.hash = 'b';
>   history.forward();
>   alert(location.hash);
>   /* spin event loop */
>   alert(location.hash);
>

It would be nice if the navigation and history traversal algorithms did not
proceed while the page is blocked on a modal alert.



>
> What does this alert? (test 008)
>
> How about:
>
>   location.hash = 'x';
>   location.hash = 'a';
>   /* spin event loop */
>   history.back();
>   /* spin event loop */
>   history.forward();
>   location.hash = 'b';
>   /* spin event loop */
>   history.back();
>   /* spin event loop */
>   alert(location.hash);
>
> What does this alert? (test 010)
>
>
> > And btw, some of the session history handling is anyway synchronous. Per
> > the current HTML5 draft calling document.open() adds a new entry to
> > session history immediately (IIRC, webkit is the only one which doesn't
> > support this).
>
> Another example is navigating to a fragment identifier, which in all
> browsers I tested changes the Location object immediately also.
>
>
> As I see it these are the criteria that we have to consider here in making
> a decision, in order of importance:
>
>  * Compatibility.
>   It seems that browsers are quite inconsistent here, and so it's likely
>   that we have some room to maneuver. Nobody has mentioned any
>   particular bugs in sites caused by implementing this one way or
>   another. I am not convinced that compatibility is a factor at this
>   point.
>
>  * Consistency for authors
>   I think whatever solution we come up with we should make sure it is
>   sane for authors. In this case, however, pretty much any model works,
>   so this doesn't really help decide what is best, so long as we are
>   consistent in how we specify and implement it.
>
>  * Implementation concerns
>   This may be the deciding factor, in particular due to the multiprocess
>   session history issues Darin raised.
>
>  * Specification sanity
>   I think we can probably make any model work in the spec, without even
>   much of a rewrite being needed. It's just a matter of saying when
>   things happen, for which the spec now has considerable infrastructure.
>
>
> Does anyone have any opinions on how the examples above should work? How
> should document.open() and location's setter interact with history.back()?
> Should navigation to fragment identifiers asynchronously set Location?
>

I think it would be risky to make navigation to fragment identifiers
asynchronously set Location.  All browsers do so synchronously today, so I
wouldn't be surprised to find that it matters.

I suspect that history.{back,forward,go} are not widely used, whereas
location="#foo" is probably used a lot.

One reason why history.{back,forward,go} may be underused is that there is
no sure fire way to know that you aren't at the beginning of session history
or at the end.  The browser only provides history.length.  It does not
provide a history.index, so you would have to keep track of where you are
manually.  That could be problematic, especially considering the page cache
feature of some browsers.



> Should Location be set synchronously but with the session history actually
> being updated asynchronously using a task, so that .back() and .forward()
> calls get interleaved with the Location setter?


I think this would be problematic in other cases.  Imagine this scenario:

location="#a";
pushState("b", "b", "#b");
location="#c";  // generates a synchronous popstate event




> Should document.open()
> synchronously clear the session history, or should it asynchronously queue
> a task and do it that way? Should we, instead of using tasks that could
> run much later (e.g. if the script has previously invoked a bunch of
> setTimeout(0)s), add a step to the event loop so that after each task, any
> history traversal that's been queued up gets processed immediately?
>

non-FIFO queuing makes me nervous ;-)

-Darin



>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/8da34afd/attachment-0001.htm>

From ian at hixie.ch  Fri Jan 22 12:22:08 2010
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 22 Jan 2010 20:22:08 +0000 (UTC)
Subject: [whatwg] Web-sockets + Web-workers to produce a P2P website or
 application
In-Reply-To: <42b395981001220648v71881f67k77676bda01493e2@mail.gmail.com>
References: <42b395981001190859v145de32bkc574b62345ff7eaa@mail.gmail.com> 
	<1b4ff0311001211144y72716b64j5ccc386f4dcf7226@mail.gmail.com> 
	<42b395981001211803s6f5e9a2cj173996c210ad0267@mail.gmail.com> 
	<1b4ff0311001220058u66408ec4vfdf4177e154fd509@mail.gmail.com>
	<42b395981001220648v71881f67k77676bda01493e2@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001222013020.19555@ps20323.dreamhostps.com>

On Fri, 22 Jan 2010, Andrew de Andrade wrote:
> 
> I'm wondering if anyone from either webkit, mozilla, opera, the W3C or
> IETF can chime in here and shed light on what the correct process
> would be to present this idea for consideration either as a standard
> (W3C or IETF) or for browser adoption as open code (Webkit, Mozilla,
> Opera, etc.)

I can't speak for the W3C or IETF, but for the WHATWG, the process is 
described in the FAQ:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

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

From Simetrical+w3c at gmail.com  Fri Jan 22 13:24:46 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 22 Jan 2010 16:24:46 -0500
Subject: [whatwg] Authoring feedback on <datalist>
In-Reply-To: <5415E8A5-6DFB-4230-93AB-8C455CC955FC@apple.com>
References: <7c2a12e21001211627n3c922f54g619a060354cd7ab8@mail.gmail.com>
	<7c2a12e21001211642p4c2eed27w4dd3e1bf461614f2@mail.gmail.com>
	<5415E8A5-6DFB-4230-93AB-8C455CC955FC@apple.com>
Message-ID: <7c2a12e21001221324w68011a76xb4ec76449b49b6bc@mail.gmail.com>

On Thu, Jan 21, 2010 at 10:12 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> I haven't reviewed that proposal closely, but I would expect <input type=text list=...> on Mac to use the standard Mac combobox control:
>
> Likewise on Windows it should show the standard combobox instead of what is pictured there.
>
> I would expect <input type=search list=...> to not show any extra buttons, but simply use the list much the way search suggestions work in the Safari built-in search field.

That works for me.  It doesn't cover the case where you want to take
over suggestions for something other than search, but I don't know of
anyone doing that.  Then again, I didn't even know what a combobox was
until this week, so I'm probably not the best to ask about that.  :)

> It's not clear to me that suggest=... is needed.

Well, a simple JS API would be useful independent of UI issues.  It's
a pain to have to create a datalist, make up an arbitrary id for it,
associate it with the input, and loop through your list to add
<option> children.  I'd expect to be able to do that in one line, if
search suggest is a major intended use case here.

From dcheng at google.com  Fri Jan 22 13:38:49 2010
From: dcheng at google.com (Daniel Cheng)
Date: Fri, 22 Jan 2010 13:38:49 -0800
Subject: [whatwg] HTML5 cut/copy
In-Reply-To: <Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>
	<Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
Message-ID: <cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>

Two more questions about implementation details:

Cut/copy:
Does it make sense to fire a drag event at all? The spec says that drag
events should be fired at the source node every 350ms (presumably to allow
the source node to cancel a drag after it started), but a cut/copy takes
place "instantaneously". If drag events should be fired during cut/copy,
should the clipboard be restored to its original state if the drag event is
cancelled? It would make sense, but might make implementations more
complicated.

Paste:
It seems like there is no time a dragleave event would ever fire. A paste
essentially goes through the drag and drop loop once; the only possible
transition is for the current target element to go from null to non-null.

Daniel

On Tue, Jan 12, 2010 at 5:38 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 12 Jan 2010, Daniel Cheng wrote:
> >
> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard
> >
> > The current spec says that drop events should be fired while handling
> > copy/cut operations. Is this intended? The clipboard is not a DOM
> > element; it seems like it'd make sense only to fire the drop event for
> > pastes.
>
> Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/9474015b/attachment.htm>

From mjs at apple.com  Fri Jan 22 17:19:57 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 22 Jan 2010 17:19:57 -0800
Subject: [whatwg] HTML5 cut/copy
In-Reply-To: <cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>
	<Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
	<cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>
Message-ID: <82906B4B-251A-43EF-A3A1-A90108B99EF4@apple.com>


On Jan 22, 2010, at 1:38 PM, Daniel Cheng wrote:

> Two more questions about implementation details:
> 
> Cut/copy:
> Does it make sense to fire a drag event at all? The spec says that drag events should be fired at the source node every 350ms (presumably to allow the source node to cancel a drag after it started), but a cut/copy takes place "instantaneously". If drag events should be fired during cut/copy, should the clipboard be restored to its original state if the drag event is cancelled? It would make sense, but might make implementations more complicated.
> 
> Paste:
> It seems like there is no time a dragleave event would ever fire. A paste essentially goes through the drag and drop loop once; the only possible transition is for the current target element to go from null to non-null.

I don't think it makes sense to have cut/copy/paste use drag events.

1) Browsers already have specific events for cut/copy/paste - those three plus beforepaste are used in content, including in major sites, so they must be implemented for Web compatibility regardless of anything else. It seems unwise for HTML5 to document a brand new untested way to do events for cut/copy/paste, but not document the existing way that is needed for Web compatibility. Thus, even if cut/copy/paste operations continue to fire the drag events, the pre-existing events should be documented.

2) In native UI, it is not always the case that drag-and-drop is possible whenever cut/copy/paste is. For example, in Preview on Mac OS X, if you select a rectangular piece of an image, you can cut or copy it, but you can't drag it.

3) In native UI, even when cut/copy/paste and drag are both possible, they do not always have the same effect. For example, it's common that in reorderable lists you can drag to reorder, but on the Mac at least they rarely allow reordering via cut/copy/paste. Instead there are specific key bindings for reordering (often including up or down arrows with modifiers). Drag and drop also has positional information that is lacking for cut/copy/paste. When dragging files in a file manager's icon view, you can drop the icon at the exact position of your choice, but cut/copy/paste often inserts in a position based on the current arrangement. This requires an actual distinction between operations.

4) In native UI, it is not always the case that cut/copy/paste is possible whenever drag-and-drop is. For example, bookmarks in Safari's Bookmarks Bar can be dragged to reorder, but cannot be cut and pasted. The keyboard-accessible interface for reordering the bookmarks bar is via the bookmarks manager.

5) The drag and drop event sequence is way too complicated to use for the simple case of customizing copy/paste behavior. Many of its fiddly details are simply not applicable.

Filed as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8800>.

Regards,
Maciej


> Daniel
> 
> On Tue, Jan 12, 2010 at 5:38 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 12 Jan 2010, Daniel Cheng wrote:
> >
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#copy-to-clipboard
> >
> > The current spec says that drop events should be fired while handling
> > copy/cut operations. Is this intended? The clipboard is not a DOM
> > element; it seems like it'd make sense only to fire the drop event for
> > pastes.
> 
> Oops. Fixed. It should have been dragstart, drag, and dragend. Thanks.
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/f83ca5c7/attachment.htm>

From kit at iqmultimedia.com.au  Sat Jan 23 00:41:12 2010
From: kit at iqmultimedia.com.au (Kit Grose)
Date: Sat, 23 Jan 2010 19:41:12 +1100
Subject: [whatwg] Authoring feedback on <datalist>
In-Reply-To: <7c2a12e21001221324w68011a76xb4ec76449b49b6bc@mail.gmail.com>
References: <7c2a12e21001211627n3c922f54g619a060354cd7ab8@mail.gmail.com>
	<7c2a12e21001211642p4c2eed27w4dd3e1bf461614f2@mail.gmail.com>
	<5415E8A5-6DFB-4230-93AB-8C455CC955FC@apple.com>
	<7c2a12e21001221324w68011a76xb4ec76449b49b6bc@mail.gmail.com>
Message-ID: <1079C0D2-C766-497D-BF4C-085E4C70A8BE@iqmultimedia.com.au>

I agree with Aryeh in principle; when you're updating the suggestions on every keypress, extra processing and DOM manipulation at the Javascript level would be good to avoid.

As far as Aryeh's lack of other use-cases for comboboxes in general, a good place to use one would be for inline additions of keywords/metadata tags in a web application or on a web site. It would allow for trivial entry of new metadata tags using existing ones if available or any arbitrary new one if required.

I've also built apps that have used autocompletes for things like email addresses/usernames in private messaging fields and other similar situations. Unlike search applications, these fields are often used inline within other fields/containers. I would hope that Maciej's example (using the standard OS X combo box) would permit significant CSS styling to fit that scenario.

?Kit

From ian at hixie.ch  Sat Jan 23 02:30:51 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 23 Jan 2010 10:30:51 +0000 (UTC)
Subject: [whatwg] Drag-and-drop feedback
In-Reply-To: <cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com> 
	<Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
	<cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001222234130.6554@ps20323.dreamhostps.com>

On Mon, 17 Aug 2009, Jian Li wrote:
>
> In order to download the attachment from an Internet mail application, 
> the user will have to click the attachment link and a "save" dialog will 
> pop up to let the user select the destination folder. This will normally 
> involves multiple clicks. Native application, like Outlook, can let the 
> user drag attachments directly into the destination place, i.e. desktop, 
> which is really convenient.
>
> We propose adding a specific format string to the DataTransfer object: 
> "DownloadURL". The data associated with the "DownloadURL" format should 
> be parsed similar to the "URL" format. When the drag ends in another 
> application, the remote file described in the associated data URL should 
> be downloaded and provided to the target application.

How would this be exposed to other apps? Is it possible in Windows to drop 
something and then have the application that received the drop wait for a 
download (which could take hours) to complete? How does that work?

If we can rely on the download happening before the drag, then we could 
add something to the DataTransfer object to add File objects.


On Fri, 4 Sep 2009, Jens Alfke wrote:
> On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
> > 
> > However, I think the addition of the deferred setData methods could be 
> > added today in a way that is completely backwards compatible with 
> > current implementations and would still be of great benefit. 
> > Specifically, my request for deferring the calling of toString on 
> > non-string objects as such:
> > 
> > event.dataTransfer.setData("something", { toString: function() { 
> > return expensiveFunctionCall(); } });
> > 
> > This would allow me to submit patches to Firefox and WebKit that would 
> > solve the current performance issues which are literally blocking my 
> > ability to switch from "fake" drag and drop to "native" drag and drop. 
> > At the same time, this should still work today in all browsers that 
> > implement setData because the object is coerced into a string 
> > immediately for you, thus not requiring immediate action on their part 
> > to change anything.
> 
> +1. A real drag-n-drop API has to support promised data.

I agree with this in principle, but I think we should wait for DND to be 
properly implemented in current browsers before adding this.


On Tue, 12 Jan 2010, Michael Davidson wrote:
> 
> The table in section 7.9.3 says that the DataTransfer object should be 
> empty for dragenter and dragover events.
> 
> Clearly this is not the case - the example in 7.9.1 shows that, at the 
> very least, the DataTransfer object needs to have a 'types' attribute so 
> that the drag handler can determine if it can accept the drag.

I've tried to clarify what "empty" is supposed to mean here.


> The issue that I'm having is that if the DataTransfer object says that 
> it has Files, I have no way to determine what type those files are. (In 
> this case, I only want to accept image files.) I understand that the 
> DataTransfer shouldn't have the content of the files for security 
> reasons, but it would be helpful if it did contain the file names and/or 
> MIME types.

I could provide a second attribute with the types of the files, would that 
work? I suppose if we did this, we should remove the "Files" fake type. 
That might not be a bad idea in general, it's kind of a hack. I'm not sure 
how I feel about having multiple different ways of representing the data 
in a DataTransfer object... It would give a clean precedent for adding 
other features, though, like promises, which some people have requested.


On Fri, 22 Jan 2010, Daniel Cheng wrote:
>
> Two more questions about implementation details:
> 
> Cut/copy:
> Does it make sense to fire a drag event at all? The spec says that drag
> events should be fired at the source node every 350ms (presumably to allow
> the source node to cancel a drag after it started), but a cut/copy takes
> place "instantaneously".

I've clarified the spec to say that the loop has to happen immediately and 
then only repeat every 350ms if it's still active.


> If drag events should be fired during cut/copy, should the clipboard be 
> restored to its original state if the drag event is cancelled? It would 
> make sense, but might make implementations more complicated.

The idea is for the cut/copy to be done exactly as if it was a drag to a 
hypothetical clipboard window, meaning everything happens in the "drop" 
part, so yes.


> Paste:
> It seems like there is no time a dragleave event would ever fire. A paste
> essentially goes through the drag and drop loop once; the only possible
> transition is for the current target element to go from null to non-null.

The 'dragleave' event can fire during a paste if the drag is canceled.

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

From ian at hixie.ch  Sat Jan 23 03:19:41 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 23 Jan 2010 11:19:41 +0000 (UTC)
Subject: [whatwg] HTML5 cut/copy
In-Reply-To: <82906B4B-251A-43EF-A3A1-A90108B99EF4@apple.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>
	<Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
	<cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>
	<82906B4B-251A-43EF-A3A1-A90108B99EF4@apple.com>
Message-ID: <Pine.LNX.4.64.1001231030570.6554@ps20323.dreamhostps.com>

On Fri, 22 Jan 2010, Maciej Stachowiak wrote:
> 
> I don't think it makes sense to have cut/copy/paste use drag events.
> 
> 1) Browsers already have specific events for cut/copy/paste - those 
> three plus beforepaste are used in content, including in major sites, so 
> they must be implemented for Web compatibility regardless of anything 
> else. It seems unwise for HTML5 to document a brand new untested way to 
> do events for cut/copy/paste, but not document the existing way that is 
> needed for Web compatibility. Thus, even if cut/copy/paste operations 
> continue to fire the drag events, the pre-existing events should be 
> documented.

Are there sites that use them for useful purposes but that do not support 
drag and drop? (If so, I'd like to study them to see what can be learnt 
from them. Last I checked, use of the copy/paste events was almost 
uniformly for anti-user reasons, and I couldn't find any sites that made 
good use of them.)


> 2) In native UI, it is not always the case that drag-and-drop is 
> possible whenever cut/copy/paste is. For example, in Preview on Mac OS 
> X, if you select a rectangular piece of an image, you can cut or copy 
> it, but you can't drag it.

Is there a good reason for this?


> 3) In native UI, even when cut/copy/paste and drag are both possible, 
> they do not always have the same effect. For example, it's common that 
> in reorderable lists you can drag to reorder, but on the Mac at least 
> they rarely allow reordering via cut/copy/paste. Instead there are 
> specific key bindings for reordering (often including up or down arrows 
> with modifiers).

The HTML5 drag-and-drop model (or rather, the IE drag-and-drop model that 
it is based on) doesn't really work for this case anyway, regardless of 
the copy/paste issue, since there doesn't seem to be any sane way to 
distinguish between an in-page drag and a drag to an external application 
such as a clipboard. If you can drag to a clipboard, I don't see why we 
would _disallow_ the copy/paste interaction.


> Drag and drop also has positional information that is lacking for 
> cut/copy/paste. When dragging files in a file manager's icon view, you 
> can drop the icon at the exact position of your choice, but 
> cut/copy/paste often inserts in a position based on the current 
> arrangement. This requires an actual distinction between operations.

The API does support that distinction -- when the operation was performed 
without position information, the screenX and screenY coordinates will be 
zero.


> 4) In native UI, it is not always the case that cut/copy/paste is 
> possible whenever drag-and-drop is. For example, bookmarks in Safari's 
> Bookmarks Bar can be dragged to reorder, but cannot be cut and pasted. 
> The keyboard-accessible interface for reordering the bookmarks bar is 
> via the bookmarks manager.

Is there any reason to disallow that model though? If it was free to 
support it, would you still have disabled it?


> 5) The drag and drop event sequence is way too complicated to use for 
> the simple case of customizing copy/paste behavior. Many of its fiddly 
> details are simply not applicable.

The drag and drop event sequence is way too complicated to use for drag- 
and-drop, let alone copy/paste. But if you've done the work to get drag- 
and-drop working, it seems silly to have to do even _more_ work to get 
copy/paste working as well.


In any case, while the above points are all good points, the reason for 
emulating copy/paste using the drag-and-drop model is actually to ensure 
that pages that use the (primarily mouse-based) drag-and-drop model are 
still accessible to keyboard users, and to ensure that the model is indeed 
in fact device-independent, and as such, I don't think they are a 
convincing argument to remove the feature. While it is true that Apple can 
be trusted to provide a keyboard-accessible UI, I think it would be 
optimistic of us to assume that everyone who provides a drag-and-drop UI 
thinks about how it can be used by non-mouse users.

Independent of this, though, I agree that we should specify the copy/paste 
events, if they are indeed used on pages that don't support drag-and-drop. 
Are these events documented anywhere?


> Filed as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8800>.

FWIW, sending a mail to the WHATWG list has the same effect as filing a 
bug, there's no need to do both.

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

From herenvardo at gmail.com  Sat Jan 23 03:52:46 2010
From: herenvardo at gmail.com (Eduard Pascual)
Date: Sat, 23 Jan 2010 12:52:46 +0100
Subject: [whatwg] Drag-and-drop feedback
In-Reply-To: <Pine.LNX.4.64.1001222234130.6554@ps20323.dreamhostps.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com> 
	<Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
	<cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com> 
	<Pine.LNX.4.64.1001222234130.6554@ps20323.dreamhostps.com>
Message-ID: <6ea53251001230352r32930042maeb44570a97ce7fe@mail.gmail.com>

On Sat, Jan 23, 2010 at 11:30 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 17 Aug 2009, Jian Li wrote:
>> [...]
>> The issue that I'm having is that if the DataTransfer object says that
>> it has Files, I have no way to determine what type those files are. (In
>> this case, I only want to accept image files.) I understand that the
>> DataTransfer shouldn't have the content of the files for security
>> reasons, but it would be helpful if it did contain the file names and/or
>> MIME types.
>
> I could provide a second attribute with the types of the files, would that
> work? I suppose if we did this, we should remove the "Files" fake type.
> That might not be a bad idea in general, it's kind of a hack. I'm not sure
> how I feel about having multiple different ways of representing the data
> in a DataTransfer object... It would give a clean precedent for adding
> other features, though, like promises, which some people have requested.
Would it be possible to provide a list of "drag items" (to call them
somehow) instead of, or in addition to, the current info provided by
the DataTransfer object?
More formally, add a property of type "DragItemList" that might be
called "DragItems". The "DragItem" type (building brick for
"DragItemList") could provide the data and meta-data for each object
being dragged (that'd be the getData, clearData, and setData methods,
a readonly string "type" and a readonly boolean "isFile").
In principle, that list could actually replace the DataTransfer
object. In order to keep compatibility with existing content, either
of these approaches could work:
1) Actually replace the DataTransfer object with the DragItemList, but
make the DragItemList type implement DataTransfer's interface.
2) Instead of replacing, add the list as a new
field/property/attribute/whatever-you-call-it to the DataTransfer
object.
This approach would solve the issues of dragging multiple files and
the potential drop targets needing to check the metadata (such as the
type); but in addition would seamlessly adapt if in the future a
mechanism of performing a multi-object drag appear. Keeping in mind
how many modern software can already handle "multiple" selections,
that seems a quite near feature.
For example, in some word processors it's possible to hold the Ctrl
key while dragging the mouse over the text to select additional text
fragments: when such a "split" selection is dragged or sent to the
clipboard, the text fragments are typically concatenated; but if the
drop or paste target is any kind of list, it would be reasonable (and
in some cases a significant upgrade in usefulness) to import the
fragments as separate entries for the list. As long as the drag (or
cut/copy) source provides some metadata to identify the boundaries of
each fragment, this functionality enhancement would be quite easy to
implement (currently, it is impossible on most contexts).

Anyway, that's just an idea.
BTW, all the type and member names used in the proposal are arbitrary
and can be changing for anything more convenient. The only purpose of
those names was to describe what they represent.

Regards,
Eduard Pascual

From dcheng at google.com  Sat Jan 23 11:09:33 2010
From: dcheng at google.com (Daniel Cheng)
Date: Sat, 23 Jan 2010 11:09:33 -0800
Subject: [whatwg] event.dataTransfer formats
Message-ID: <cdc844f71001231109m3f60f55bt6c7b1f4c1013d7a2@mail.gmail.com>

>
> Formats are generally given by MIME types, with some values special-cased
> for legacy reasons. For the purposes of this API, however, the format
> strings are opaque, case-sensitive, strings, and the empty string is a valid
> format string.


RFC 2616 has this to say about MIME types:

> The type, subtype, and parameter attribute names are case-insensitive.


IE also ignores case for format strings:

>     <script>

      window.clipboardData.setData('Text', 'FAILURE');

      window.clipboardData.setData('tEXT', 'SUCCESS');

      alert(window.clipboardData.getData('Text'));

    </script>

results in an alert saying 'SUCCESS'.

Given that, would it make sense to change the spec to make format strings
case-insensitive?

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100123/89a9635f/attachment.htm>

From mjs at apple.com  Sat Jan 23 15:08:03 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Sat, 23 Jan 2010 15:08:03 -0800
Subject: [whatwg] HTML5 cut/copy
In-Reply-To: <Pine.LNX.4.64.1001231030570.6554@ps20323.dreamhostps.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>
	<Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
	<cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>
	<82906B4B-251A-43EF-A3A1-A90108B99EF4@apple.com>
	<Pine.LNX.4.64.1001231030570.6554@ps20323.dreamhostps.com>
Message-ID: <860E4A61-70AE-4446-AACF-1B438CD36BB1@apple.com>


On Jan 23, 2010, at 3:19 AM, Ian Hickson wrote:

> On Fri, 22 Jan 2010, Maciej Stachowiak wrote:
>> 
>> I don't think it makes sense to have cut/copy/paste use drag events.
>> 
>> 1) Browsers already have specific events for cut/copy/paste - those 
>> three plus beforepaste are used in content, including in major sites, so 
>> they must be implemented for Web compatibility regardless of anything 
>> else. It seems unwise for HTML5 to document a brand new untested way to 
>> do events for cut/copy/paste, but not document the existing way that is 
>> needed for Web compatibility. Thus, even if cut/copy/paste operations 
>> continue to fire the drag events, the pre-existing events should be 
>> documented.
> 
> Are there sites that use them for useful purposes but that do not support 
> drag and drop? (If so, I'd like to study them to see what can be learnt 
> from them. Last I checked, use of the copy/paste events was almost 
> uniformly for anti-user reasons, and I couldn't find any sites that made 
> good use of them.)

Here are some sites that use cut/copy/paste event listeners. Given the nature of the sites, I do not believe these event listeners are set for user-hostile purposes. But the way I got this information (by instrumenting my copy of WebKit) does not lend itself to revealing the particular purpose for which the listeners are set:

https://mail.google.com/ (only when you call up the compose window)
    beforecut
    beforepaste
    cut
    paste

http://google.com/
    paste  (it's on the main input field, but the JS is obfuscated so I can't tell what it does - no drag event listeners)

http://mail.yahoo.com/ (after logging in, and additional listeners are set when you focus the compose window)
    paste
    cut

http://docs.google.com/  (when viewing a Document)
    beforecut
    beforepaste
    cut
    copy
    paste

http://docs.google.com/  (create a new presentation and click an editable text area)
    beforecut
    beforepaste
    cut
    paste

http://hotmail.com/ (when opening compose window)
    cut
    paste

http://livejournal.com/ (in the "Post a New Entry" view)
    paste

http://me.com/ (Sign in page; likely more after that but that would cost money to test)
    paste




> 
>> 2) In native UI, it is not always the case that drag-and-drop is 
>> possible whenever cut/copy/paste is. For example, in Preview on Mac OS 
>> X, if you select a rectangular piece of an image, you can cut or copy 
>> it, but you can't drag it.
> 
> Is there a good reason for this?

The bottom line is that it's a design choice and shouldn't be forced by the API. Although I'm not the UI designer responsible for this decision, my best guess is that this would interfere with the lasso selection gesture. Whether it's a really great reason or not, I'd be hesitant to design an API that second-guesses our UI designers.


> 
>> 3) In native UI, even when cut/copy/paste and drag are both possible, 
>> they do not always have the same effect. For example, it's common that 
>> in reorderable lists you can drag to reorder, but on the Mac at least 
>> they rarely allow reordering via cut/copy/paste. Instead there are 
>> specific key bindings for reordering (often including up or down arrows 
>> with modifiers).
> 
> The HTML5 drag-and-drop model (or rather, the IE drag-and-drop model that 
> it is based on) doesn't really work for this case anyway, regardless of 
> the copy/paste issue, since there doesn't seem to be any sane way to 
> distinguish between an in-page drag and a drag to an external application 
> such as a clipboard. If you can drag to a clipboard, I don't see why we 
> would _disallow_ the copy/paste interaction.

That sounds like a design flaw with the drag and drop model. Sounds like something to fix, not something to compound with another design flaw.

> 
> 
>> Drag and drop also has positional information that is lacking for 
>> cut/copy/paste. When dragging files in a file manager's icon view, you 
>> can drop the icon at the exact position of your choice, but 
>> cut/copy/paste often inserts in a position based on the current 
>> arrangement. This requires an actual distinction between operations.
> 
> The API does support that distinction -- when the operation was performed 
> without position information, the screenX and screenY coordinates will be 
> zero.

That's exactly the problem. Paste is not equivalent to a drop at (0, 0) in screen coordinates (unless you assume that a valid drop target can never be at (0, 0), but that is not a correct assumption in general). Granted, this could be fixed by having an explicit flag to indicate "no position".


> 
>> 4) In native UI, it is not always the case that cut/copy/paste is 
>> possible whenever drag-and-drop is. For example, bookmarks in Safari's 
>> Bookmarks Bar can be dragged to reorder, but cannot be cut and pasted. 
>> The keyboard-accessible interface for reordering the bookmarks bar is 
>> via the bookmarks manager.
> 
> Is there any reason to disallow that model though? If it was free to 
> support it, would you still have disabled it?

The items in the bookmarks bar can actually be keyboard focused (in full keyboard access mode), so it would have been almost free to support cut & paste. It was a design choice to avoid making the interaction too complex, not a matter of insufficient resources to implement the behavior.


> 
>> 5) The drag and drop event sequence is way too complicated to use for 
>> the simple case of customizing copy/paste behavior. Many of its fiddly 
>> details are simply not applicable.
> 
> The drag and drop event sequence is way too complicated to use for drag- 
> and-drop, let alone copy/paste. But if you've done the work to get drag- 
> and-drop working, it seems silly to have to do even _more_ work to get 
> copy/paste working as well.

Sure, but apparently it's common to want to customize copy/paste behavior without doing drag-and-drop at all. Which is fine and should be allowed.

> 
> In any case, while the above points are all good points, the reason for 
> emulating copy/paste using the drag-and-drop model is actually to ensure 
> that pages that use the (primarily mouse-based) drag-and-drop model are 
> still accessible to keyboard users, and to ensure that the model is indeed 
> in fact device-independent, and as such, I don't think they are a 
> convincing argument to remove the feature.

There's really two aspects of the feature:

A) Drag-and-drop events are the *only* way to do cut and paste, and the specific events for them are undefined. This is clearly not necessary to achieve the above accessibility property. Thus, accessibility considerations are not a valid reason to fail to specify the legacy events, since they are widely implemented and used on popular sites. But I see below that you agree with this point.

B) Anything that handles drag-and-drop will also handle interaction via cut/copy/paste. But this is not sufficient to give automatic keyboard accessibility to anything done via drag-and-drop:
    I. It doesn't guarantee that drag sources or drop targets are keyboard focusable. Without the ability to focus, the abilities to copy and paste are not very useful.
    II. Drag and drop is often used for specific positioning within an area, and cut-and-paste cannot replicate that.
    III. Drag-like gestures within the page or within a single element can (and in fact often do) just use mouse events (mousedown, mouseup, mousemove, etc). The weird cut/copy/paste linkage does not help this case, and might even discourage authors more from using proper drag events.

For users with motor impairments, the most thorough way to provide accessibility to drag-and-drop UIs is to have a method for stepwise control of the mouse pointer and a "sticky" click. For users with visual impairments, it may be desirable to have similar "sticky drag" behavior, though fine positioning may not at this point be a consideration. I think those are the best things to do at the browser/OS level.

In both cases, it's best to make sure that anything that can be done via drag-and-drop can be done in at least one other way. Sometimes cut/copy/paste is the best way, but not always. 

Thus, making drag-and-drop always accessible via cut-and-paste seems well-meaning but I think it is ultimately misguided. Therefore I am not sure this aspect of the feature is justified either.

One possibility is to make cut/copy/paste binding the default, but let authors opt out if they have some better alternate UI in mind. I'm not sure of the best design for that.

> While it is true that Apple can be trusted to provide a keyboard-accessible UI, I think it would be 
> optimistic of us to assume that everyone who provides a drag-and-drop UI 
> thinks about how it can be used by non-mouse users.

We trust not only ourselves, but also our application developers to get this right. It's true that a lot of Web development is not done with careful thought to HI and accessibility considerations, but I don't think a technical solution is practical in this case.


> Independent of this, though, I agree that we should specify the copy/paste 
> events, if they are indeed used on pages that don't support drag-and-drop. 
> Are these events documented anywhere?

I cannot vouch for the accuracy or completeness of this information, but here's some docs:

http://msdn.microsoft.com/en-us/library/ms533051(VS.85).aspx
https://developer.mozilla.org/en/DOM/element#Event_Handlers
http://www.quirksmode.org/dom/events/cutcopypaste.html


> 
>> Filed as <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8800>.
> 
> FWIW, sending a mail to the WHATWG list has the same effect as filing a 
> bug, there's no need to do both.

I've been planning to file this bug for a while. (Or maybe more than one, since adding the cut/copy/paste events is really a separate issue from whether cut/copy/paste operations are bound to drag events.) But I chose to also send an email since there was a topical thread about it.

I realize that it has the same effect for you either way, but it doesn't have the same effect for me. It's much easier for me to track bugs I have filed than to track email feedback that could lead to meaningful changes.

I'll gladly just close the bug myself if the email discussion leads to sufficient changes (or convinces me that further change is not called for).

Regards,
Maciej


From ian at hixie.ch  Sun Jan 24 02:52:24 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 24 Jan 2010 10:52:24 +0000 (UTC)
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com>
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com>
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com>
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>

On Fri, 11 Dec 2009, Michal Zalewski wrote:
> 
> 1) IFRAME semantics make it exceedingly cumbersome to sandbox short 
> snippets of text, and this task is perhaps the most common and pressing 
> XSS-related challenge. Unless the document is constructed on client side 
> by JavaScript, sites would need to use opaque data: URLs, or put up with 
> a lot of additional HTTP roundtrips, to utilize sandboxed IFRAMEs for 
> this purpose. [ There is also the problem of formatting and positioning 
> IFRAME content, although the seamless attribute would fix this. ]

I've introduced srcdoc="" to largely handle this. There is an example in 
the spec showing how it can be used.


> The ability to sandbox SPANs or DIVs using a token-guarded approach
> (<span sandbox="random_token"></span sandbox="same_token">) is, on the
> other hand, considerably easier on the developer, and probably has a
> very similar implementation complexity.

This has been proposed before. The concern is that many authors would be 
likely to make mistakes in their selection of "random" tokens that would 
lead to significant flaws in the deployment of the feature.

srcdoc="" is less prone to errors. Only " and & characters need to be 
escaped. If the " character is not escaped, then a single " character in 
the input will cause the comment to break. This is likely to be caught 
early. If the & character is not escaped, correctness and fidelity will 
suffer, but it will not lead to security errors.


> 2) Renderers suck dealing with IFRAMEs, and will probably continue to
> do so for time being. This means that a typical, moderately complex
> application (say, as a discussion forum or a social site), where
> hundreds of user-controlled strings may need to be present to display
> user content - the mechanism would have an unacceptable load time and
> memory footprint. In fact, people are already coming up with
> lightweight alternatives with a significant functionality overlap (and
> different security controls). Microsoft has toStaticHTML(), while a
> standardized implementation is being discussed here right now in a
> separate thread.

I agree that we should investigate other options too (<iframe> boxes 
aren't suitable for everything), but I don't think that current 
implementation problems with <iframe> should necessarily prevent us from 
investigating sandboxed iframes too.

In certain contexts, e.g. reddit comments, it may be the case that instead 
of one sandboxed <iframe> per comment, the best way to do things is 
instead one sandboxed iframe for all the comments, with scripts disabled 
and allow-same-origin enabled, so that scripts can poke into the page and 
set event handlers on all the relevant links.


> Isn't the benefit of keeping the design slightly simpler (and 
> realistically, limited to relatively few usage scenarios) negated by the 
> fact that alternative solutions to other narrow problems would need to 
> emerge elsewhere? The browser coming with several different script 
> sanitizers with completely different APIs and security controls does not 
> strike me as a desirable outcome (all the flavors of SOP are a testament 
> to this). If the anser is not a strong "no", maybe the token-guarded DIV 
> / SPAN approach is a better alternative?

I agree in principle that fewer features are better than more features, 
but we have to take into account that many of the people deploying these 
features know nothing about security. We have to ensure that the security 
aspects of features like this (like what to escape, what security tokens 
need to be generated) are aligned with the practical aspects of features 
like this (like what results in the page appearing to work, regardless of 
the state of security).


> Now, that aside - on a more pragmatic level, I have two extra comments:
> 
> 1) The utility of the SOP sandboxing behavior outlined in the spec is
> diminished if we have no way to actually *enforce* that the IFRAMEd
> resource would only be rendered in such a context. If I am serving
> user-supplied, unsanitized HTML, it is obviously safe to do <iframe
> sandbox src="show.cgi?id=1234"></iframe> - but where do we prevent the
> attacker from calling http://my_site/show.cgi?id=1234 directly, and
> bypassing the filter?

I've introduced text/html-sandboxed for this purpose.


> 2.1) The ability to disable loading of external resources (images, 
> scripts, etc) in the sandboxed document. The common usage scenario is 
> when you do not want the displayed document to "phone home" for privacy 
> reasons, for example in a web mail system.

Good point. Should we make sandbox="" disable off-origin network requests?


> 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually 
> be approximated with the excommunicated <plaintext> tag, or with 
> Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or 
> DIVs, however, it would be pretty damn useful for displaying text 
> content without the need to escape &, <, >, etc. "Pure" security benefit 
> is limited, but as a phishing prevention and display correctness 
> measure, it makes sense.

I don't really understand the use case here; could you elaborate?


On Sun, 13 Dec 2009, Michal Zalewski replied to Tab:
> >
> > I believe that the @doc attribute, discussed in the original threads 
> > about @sandbox, will be introduced to deal with that. ?It'll take 
> > plain html as a string, avoiding the opaqueness and larger escaping 
> > requirements of a data:// url, as the only thing you'll have to escape 
> > is whichever quote you're using to surround the value.
> 
> That doesn't strike me as a robust way to prevent XSS - the primary 
> reason why we need sandboxing to begin with is that people have a 
> difficulty properly parsing, serializing, or escaping HTML; so replacing 
> this with a mechanism that still requires escaping is perhaps 
> suboptimal.

There's a world of difference between "properly parsing, serializing, or 
escaping HTML" and "escaping quotes and ampersands".


> > ?More importantly, though, it puts a significant burden on authors to 
> > generate unpredictable tokens. ?Is this difficult? ?No, of course not. 
> > But people *will* do it badly, copypasting a single token in all their 
> > <iframe>s or similar.
> 
> People already need to do this well for XSRF defenses to work, and I'd 
> wager it's a much simpler and better-defined problem than real-world 
> HTML parsing and escaping could realistically be. It is also very easy 
> to delegate this task to existing functions in common web frameworks.

Do people get CSRF right more often than simply escaping characters? It 
seems implausible that authors get complex cryptographic properties right 
more often than a simple set of substitutions, but I suppose stranger 
things are true on the Web.


> Also, a single token on a returned page, as long as it's unpredictable 
> across user sessions, should not be a significant issue.

I'm just worried that some people would just a constant string.


On Sun, 13 Dec 2009, Adam Barth wrote:
> 
> I agree that we need something to help with content received by 
> cross-site XMLHttpRequest and postMessage.  For those use cases, we're 
> already running script, so a design like toStaticHTML seems better than 
> <jail>.

If the data is to be rendered into a block-level box, it seems that 
srcdoc="" might actually handle that case too.


On Sun, 13 Dec 2009, Michal Zalewski replied to Adam:
> >
> > The @sandbox seems like a better fit for the advertising use case.
>
> I am not contesting this, to be clear - I am aware of many cases where 
> it would be very useful - but gadgets are a fairly small part of the 
> Internet, and seems like a unified solution would be more desirable than 
> several very different APIs with different granularity.
> 
> The toStaticHTML-alike will address another specific uses, but will 
> leave applications that can't rely on JS exclusively for their rendering 
> needs (which I'd wager is still a majority) out in the cold; which would 
> probably lead to a yet another XSS prevention / HTML sandboxing approach 
> emerging later on.
> 
> I haven't really seen a compelling argument why all these can't be 
> unified without a significant increase in code or spec complexity - 
> maybe one exists.

What would they be unified under? I don't think anyone has proposed 
anything that solves all the problems that CSP, sandbox="", srcdoc="", 
toStaticHTML(), httpOnly, text/html-sandboxed, and the various other 
"security" mechanisms introduced to the platform over the past few years 
would solve without introducing more complexity overall.

There are many problems to solve. It seems logical that we'd end up with 
many solutions.


On Sun, 13 Dec 2009, Michal Zalewski replied to Adam:
> >
> > That seems like a backwards way of proceeding. ?Do you have a proposal 
> > for unification besides the <jail> tag?
> 
> The only fundamental objection I have heard against it is the trouble 
> with XML representation.

Well, it also doesn't really solve all the problems. For example, it 
doesn't solve the "embedding external content safely" problem.


> The other option is to simply require a traditional CDATA-esque behavior 
> or a tag parameter - which would place the burden on the author to 
> filter out / escape a single exact string or a quote, but would be 
> similar otherwise.

That's similar to what srcdoc="" does when used with sandbox="".


> It's obviously less secure - because while the token-based approach
> actually requires the user to explicitly come up with a token, however
> poor it might be; whereas here, there is no way to enforce escaping.

The token-based approach could lead an author to just coming up with a 
constant token, which is just as useless as not enforcing escaping, except 
that the author had to wonder how to get security to use it, and thus the 
author will have a false sense of security whose only likely failure mode 
is an actual attack. Compare this to srcdoc="", where the failure mode is 
the use of a quote mark, and is thus likely to happen much earlier than an 
attack. It's also easier to understand the failure mode. "The token has to 
be unguessable" is harder to explain than "quotes have to be escaped".


> From Tab's response, looks like it's being considered, too - @doc + 
> @seamless. What's strikes me as a bit ironic is that this way, we're 
> overloading IFRAME to become something else entirely, and after 
> rejecting token-guards, settling for an option that is definitely not 
> perfect, and in practice, I think, is bound to be less secure.

I don't really follow the "something else entirely" bit. Also, why would 
it be less secure? What is the attack scenario?


On Sun, 13 Dec 2009, Michal Zalewski wrote:
> 
> Huh? But that's not the point I am making... I am not arguing that 
> iframe sandbox should be abandoned as a bad idea - quite the opposite.
> 
> I was merely suggesting that we *expand* the same logic, and the same 
> excellent security control granularity, to span and div; this seems like 
> it would not increase the implementation complexity in any significant 
> way.

I don't understand the proposal then. What is the problem it is solving, 
and how does it solve it?


> We could then allow these to be populated with secure contents in three 
> ways:
> 
> 1) Guarded closing tag - this is simple and bullet-proof; but may 
> conflict with XML serializations, and hence require some hacks,

I strongly disagree with the characterisation of this idea as "simple and 
bullet-proof", at least for anyone who doesn't understand cryptography.


> 2) CDATA or @doc-like approaches. Less secure because it does not 
> enforce a security control, but less contentious, and already being 
> considered for IFRAMEs.

I don't understand what you mean by "does not enforce a security control", 
or how a guarded closing tag does "enforce a security control".


> 3) .innerHTML, which would be then safe by default, without the need for 
> .innerSafeHTML (and the associated ambiguities) or explicit 
> .toStaticHTML calls.

To run scripts in a safe environment, we need to have a separate global 
object, which is why we're using <iframe> for it. This supports the 
equivalent of ".innerHTML" as you describe (.srcdoc).

If you just want something that blocks scripts, plugins, forms, targeted 
links, etc, without a separate document, then it's not clear to me that 
that is something that is sanely achievable. It would require complex 
changes all over the place.

What is the use case this is targetted at?


On Sun, 13 Dec 2009, Adam Barth wrote:
> 
> I'm very interested in a solution that works for the following use 
> cases:
> 
> 1) A web page wants to display untrusted (i.e., restricted) HTML 
> received via cross-site XMLHttpRequest or postMessage.

Do you have a concrete use case for which <iframe> doesn't work?


> 2) A blog wishes to display many comments containing untrusted (i.e., 
> restricted) HTML.

It seems <iframe srcdoc> works well for this case. You can even safely 
enable scripts in the comments, so that people can upload little 
calculator-like things or games, not that I would recommend that!


On Sun, 13 Dec 2009, Michal Zalewski wrote:
> 
> [...] this really strikes me as throwing random ideas at the wall, and 
> seeing which ones stick.

Welcome to Web standards development. :-)


> Furthermore, in this particular case, I am really concerned that the 
> spec is at odds with itself - you mention certain specific use cases, 
> but the spec seems to be after a broader goal: sandboxing user-supplied 
> content in general. In doing so, it gives some bad advice (again, the 
> user content example is exploitable, at least until the arrival of some 
> out-of-scope security mechanism to prevent it).

I've added a warning to the spec pointing out that the text/html-sandboxed 
MIME type has to be used in that case.


On Sun, 13 Dec 2009, Aryeh Gregor wrote:
> 
> So instead, why not just use the standard escaping mechanisms we already 
> have?  Allow a sandbox attribute on all elements that can contain 
> phrasing or flow content.  Any such element with a sandbox attribute 
> will be required to contain no literal <>'" before the closing tag.  If 
> any of those four characters is encountered, the element is treated as 
> having no contents.  Otherwise, the browser unescapes all characters 
> with special meanings ("&lt;" -> "<", "&gt;" -> ">", "&amp;" -> "&", 
> etc.) and then treats the resulting string as the inner HTML of the 
> element, parsing it like regular HTML, but the contents are sandboxed.
> 
> Examples:
> 
> <span sandbox>This span will work normally, except for being 
> sandboxed.</span>
> 
> <span sandbox>This span will be <em>empty</em> in the DOM, even though 
> it contains no evil content, because otherwise authors will forget to 
> escape the contents of the sandbox.</span>
> 
> <span sandbox>&lt;span&gt;But this span will have another span as its 
> child, sandboxed.  The regular parser sees no entities here, only a 
> nested span!&lt;/span&gt;</span>
> 
> <span sandbox>It would be safe to allow this to work, since it only 
> contains an apostrophe, but let's not, so that lack of escaping is 
> easier to catch.  This span is therefore also empty.</span>

What would the "sandbox" do, other than require one level of escaping? 
i.e. what is it protecting against?

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

From whatwg at adambarth.com  Sun Jan 24 03:19:10 2010
From: whatwg at adambarth.com (Adam Barth)
Date: Sun, 24 Jan 2010 12:19:10 +0100
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com> 
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com> 
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com> 
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com> 
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
Message-ID: <7789133a1001240319j64d99102h9818d712f64c602a@mail.gmail.com>

On Sun, Jan 24, 2010 at 11:52 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 11 Dec 2009, Michal Zalewski wrote:
>> 2.1) The ability to disable loading of external resources (images,
>> scripts, etc) in the sandboxed document. The common usage scenario is
>> when you do not want the displayed document to "phone home" for privacy
>> reasons, for example in a web mail system.
>
> Good point. Should we make sandbox="" disable off-origin network requests?

In general, stopping malicious content from exfiltrating data isn't
practical.  For example, even including a single hyperlink is often
sufficient to exfiltrate a large amount of data.  In user agents that
prefetch DNS, the user doesn't even need to click on the link.

> On Sun, 13 Dec 2009, Adam Barth wrote:
>> I'm very interested in a solution that works for the following use
>> cases:
>>
>> 1) A web page wants to display untrusted (i.e., restricted) HTML
>> received via cross-site XMLHttpRequest or postMessage.
>
> Do you have a concrete use case for which <iframe> doesn't work?

<iframe sandbox srcdoc> might work nicely for this use case, actually,
especially because setting srcdoc from the DOM removes the need to
escape ".

Adam

From ian at hixie.ch  Sun Jan 24 03:24:53 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 24 Jan 2010 11:24:53 +0000 (UTC)
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <7789133a1001240319j64d99102h9818d712f64c602a@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com> 
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com> 
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com> 
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com> 
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
	<7789133a1001240319j64d99102h9818d712f64c602a@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1001241124310.19555@ps20323.dreamhostps.com>

On Sun, 24 Jan 2010, Adam Barth wrote:
> On Sun, Jan 24, 2010 at 11:52 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 11 Dec 2009, Michal Zalewski wrote:
> >> 2.1) The ability to disable loading of external resources (images, 
> >> scripts, etc) in the sandboxed document. The common usage scenario is 
> >> when you do not want the displayed document to "phone home" for 
> >> privacy reasons, for example in a web mail system.
> >
> > Good point. Should we make sandbox="" disable off-origin network 
> > requests?
> 
> In general, stopping malicious content from exfiltrating data isn't 
> practical.  For example, even including a single hyperlink is often 
> sufficient to exfiltrate a large amount of data.  In user agents that 
> prefetch DNS, the user doesn't even need to click on the link.

Ok. Then I won't add it.


> > On Sun, 13 Dec 2009, Adam Barth wrote:
> >> I'm very interested in a solution that works for the following use
> >> cases:
> >>
> >> 1) A web page wants to display untrusted (i.e., restricted) HTML
> >> received via cross-site XMLHttpRequest or postMessage.
> >
> > Do you have a concrete use case for which <iframe> doesn't work?
> 
> <iframe sandbox srcdoc> might work nicely for this use case, actually,
> especially because setting srcdoc from the DOM removes the need to
> escape ".

Cool.

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

From Simetrical+w3c at gmail.com  Sun Jan 24 11:50:20 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sun, 24 Jan 2010 14:50:20 -0500
Subject: [whatwg] Authoring feedback on <datalist>
In-Reply-To: <1079C0D2-C766-497D-BF4C-085E4C70A8BE@iqmultimedia.com.au>
References: <7c2a12e21001211627n3c922f54g619a060354cd7ab8@mail.gmail.com>
	<7c2a12e21001211642p4c2eed27w4dd3e1bf461614f2@mail.gmail.com>
	<5415E8A5-6DFB-4230-93AB-8C455CC955FC@apple.com>
	<7c2a12e21001221324w68011a76xb4ec76449b49b6bc@mail.gmail.com>
	<1079C0D2-C766-497D-BF4C-085E4C70A8BE@iqmultimedia.com.au>
Message-ID: <7c2a12e21001241150r227eab4dw236cc79c03b36989@mail.gmail.com>

On Sat, Jan 23, 2010 at 3:41 AM, Kit Grose <kit at iqmultimedia.com.au> wrote:
> I agree with Aryeh in principle; when you're updating the suggestions on every keypress, extra processing and DOM manipulation at the Javascript level would be good to avoid.

I don't think this is a big issue.  Users aren't going to be hitting a
key more than once every few tens of milliseconds, and for search
suggest, you're almost certainly going to wait for the user to pause
before sending the query to the mothership (else it would be obsolete
before it even reached the destination).  But the current API could be
a lot simpler to use from JS -- it's currently a pain in the neck.

From Simetrical+w3c at gmail.com  Sun Jan 24 12:09:32 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sun, 24 Jan 2010 15:09:32 -0500
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com>
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com>
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com>
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com>
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
Message-ID: <7c2a12e21001241209uff7c922w1708b107263a1009@mail.gmail.com>

On Sun, Jan 24, 2010 at 5:52 AM, Ian Hickson <ian at hixie.ch> wrote:
> What would the "sandbox" do, other than require one level of escaping?
> i.e. what is it protecting against?

<span sandbox>$something</sandbox> was meant to be more or less the
same as <iframe sandbox srcdoc="$something">.  The latter achieves the
same effect but is cleaner and makes more sense.  I must not have
known about the doc="" proposal at that point, but I can't remember
what I was thinking more than a month ago.

On Sun, Jan 24, 2010 at 6:19 AM, Adam Barth <whatwg at adambarth.com> wrote:
> In general, stopping malicious content from exfiltrating data isn't
> practical. ?For example, even including a single hyperlink is often
> sufficient to exfiltrate a large amount of data. ?In user agents that
> prefetch DNS, the user doesn't even need to click on the link.

DNS prefetching doesn't tell you anything except that someone viewed
the link, right?  And maybe what their ISP is, in a typical case.
Including an image tells you their IP address, User-Agent, and so on.

How can you get any data out of a link with no DNS prefetching?  Some
users will click the link, but not all.  Maybe quite a lot if you
allow arbitrary CSS, of course . . . you could easily make the whole
post a link.  But "everyone who clicks on a given post for some
reason" is still a lot less than "all viewers", which is what image
inclusions will do.

From whatwg at adambarth.com  Sun Jan 24 22:29:42 2010
From: whatwg at adambarth.com (Adam Barth)
Date: Mon, 25 Jan 2010 06:29:42 +0000
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <7c2a12e21001241209uff7c922w1708b107263a1009@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com> 
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com> 
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com> 
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com> 
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com> 
	<7c2a12e21001241209uff7c922w1708b107263a1009@mail.gmail.com>
Message-ID: <7789133a1001242229o7b978271oe1e1644a10785b40@mail.gmail.com>

On Sun, Jan 24, 2010 at 8:09 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Sun, Jan 24, 2010 at 6:19 AM, Adam Barth <whatwg at adambarth.com> wrote:
>> In general, stopping malicious content from exfiltrating data isn't
>> practical. ?For example, even including a single hyperlink is often
>> sufficient to exfiltrate a large amount of data. ?In user agents that
>> prefetch DNS, the user doesn't even need to click on the link.
>
> DNS prefetching doesn't tell you anything except that someone viewed
> the link, right? ?And maybe what their ISP is, in a typical case.
> Including an image tells you their IP address, User-Agent, and so on.

That depends what information the attacker encodes in the host name.
Recall that we're imaging the attacker gets to run JavaScript within
the sandbox, so, for example, the attacker can read the user agent and
encode that in the host name.

> How can you get any data out of a link with no DNS prefetching? ?Some
> users will click the link, but not all. ?Maybe quite a lot if you
> allow arbitrary CSS, of course . . . you could easily make the whole
> post a link. ?But "everyone who clicks on a given post for some
> reason" is still a lot less than "all viewers", which is what image
> inclusions will do.

Well, given that the attacker can use CSS, the attacker can make the
hyperlink fill the entre content area (or at least the area occupied
by the iframe).  The attacker can also use the :hover selector to make
interesting things happen when the user mouses over the link.

The point is that stopping exfiltration is a losing battle that we
shouldn't bother to play.

Adam

From tkent at chromium.org  Mon Jan 25 01:55:25 2010
From: tkent at chromium.org (TAMURA, Kent)
Date: Mon, 25 Jan 2010 18:55:25 +0900
Subject: [whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
Message-ID: <b7b4ecf81001250155o72f4a174hf28ca51bea55db8e@mail.gmail.com>



On setting, if the  
valueAsNumber<http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasnumber>  
attribute
> does not apply, as defined for the  
> input<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element>
>   element's  
> type<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type>  
> attribute's
> current state, then throw  
> anINVALID_STATE_ERR<http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#invalid_state_err>  
> exception.
> Otherwise, if the  
> valueAsDate<http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasdate>  
> attribute
> applies, run the algorithm to convert a Date object to a  
> string<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-date-string>  
> defined
> for that state, passing it a Date object whose time value is the new
> value, and set the  
> value<http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-fe-value>  
> of
> the element to resulting string. Otherwise, run the algorithm to convert a
> number to a  
> string<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-number-string>,
> as defined for that state, on the new value, and set the  
> value<http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-fe-value>  
> of
> the element to resulting string.


It seems the current spec doesn't define behavior in a case of setting NaN
or Infinitiy to HTMLInputElement::valueAsNumber.
Because 'input.valueAsDate = null' makes the value empty, I think
'input.valueAsNumber = Number.NaN' also makes the value empty.

-- 
TAMURA Kent
Software Engineer, Google



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100125/ee3c401d/attachment.htm>

From excors+whatwg at gmail.com  Mon Jan 25 02:10:20 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Mon, 25 Jan 2010 10:10:20 +0000
Subject: [whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
In-Reply-To: <b7b4ecf81001250155o72f4a174hf28ca51bea55db8e@mail.gmail.com>
References: <b7b4ecf81001250155o72f4a174hf28ca51bea55db8e@mail.gmail.com>
Message-ID: <ea09c0d11001250210l5086ab89ubbeb45e45c41e6fd@mail.gmail.com>

On Mon, Jan 25, 2010 at 9:55 AM, TAMURA, Kent <tkent at chromium.org> wrote:
> It seems the current spec doesn't define behavior in a case of setting NaN
> or Infinitiy to HTMLInputElement::valueAsNumber.

http://whatwg.org/html5#float-nan : "Except where otherwise specified,
if an IDL attribute that is a floating point number type (float) is
assigned an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERR
exception must be raised."

This case seems to apply for valueAsNumber.

-- 
Philip Taylor
excors at gmail.com

From tkent at chromium.org  Mon Jan 25 02:13:01 2010
From: tkent at chromium.org (TAMURA, Kent)
Date: Mon, 25 Jan 2010 19:13:01 +0900
Subject: [whatwg] HTMLInputElement::valueAsNumber and NaN Infinity
In-Reply-To: <ea09c0d11001250210l5086ab89ubbeb45e45c41e6fd@mail.gmail.com>
References: <b7b4ecf81001250155o72f4a174hf28ca51bea55db8e@mail.gmail.com>
	<ea09c0d11001250210l5086ab89ubbeb45e45c41e6fd@mail.gmail.com>
Message-ID: <b7b4ecf81001250213k3f3c37e7u614c63e94efa9ec@mail.gmail.com>



On Mon, Jan 25, 2010 at 19:10, Philip Taylor  
<excors+whatwg at gmail.com<excors%2Bwhatwg at gmail.com>
> wrote:

> On Mon, Jan 25, 2010 at 9:55 AM, TAMURA, Kent <tkent at chromium.org> wrote:
> > It seems the current spec doesn't define behavior in a case of setting
> NaN
> > or Infinitiy to HTMLInputElement::valueAsNumber.

> http://whatwg.org/html5#float-nan : "Except where otherwise specified,
> if an IDL attribute that is a floating point number type (float) is
> assigned an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERR
> exception must be raised."

> This case seems to apply for valueAsNumber.


Oh, that's right. I overlooked it.
Thanks!

-- 
TAMURA Kent
Software Engineer, Google



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100125/a9b0f907/attachment.htm>

From simonp at opera.com  Mon Jan 25 03:33:15 2010
From: simonp at opera.com (Simon Pieters)
Date: Mon, 25 Jan 2010 12:33:15 +0100
Subject: [whatwg] skipping timeupdate (was: Re: [html5] r4621 - [e] (0)
 Clarify when the drag-and-drop steps run.)
In-Reply-To: <20100123102935.A098E80580DB@ps20323.dreamhostps.com>
References: <20100123102935.A098E80580DB@ps20323.dreamhostps.com>
Message-ID: <op.u626dpgmidj3kv@simon-pieterss-macbook.local>

On Sat, 23 Jan 2010 11:29:35 +0100, <whatwg at whatwg.org> wrote:

> Author: ianh
> Date: 2010-01-23 02:29:33 -0800 (Sat, 23 Jan 2010)
> New Revision: 4621
>
> Modified:
>    complete.html
>    index
>    source
> Log:
> [e] (0) Clarify when the drag-and-drop steps run.


> Modified: source
> ===================================================================
> --- source	2010-01-23 00:14:19 UTC (rev 4620)
> +++ source	2010-01-23 10:29:33 UTC (rev 4621)
> @@ -20949,7 +20949,7 @@
>   <div class="example">
> -   <p class="xxx">example for srcdoc here</p>
> +   <p class="XXX">example for srcdoc here</p>
>   </div>
> @@ -71486,27 +71486,33 @@
>    Initially, it has the value "none". It is updated by the user agent
>    as described in the steps below.</p>
> -  <p>User agents must, every 350ms (&#xB1;200ms), perform the
> -  following steps in sequence. (If the user agent is still performing
> -  the previous iteration of the sequence when the next iteration
> -  becomes due, the user agent must not execute the overdue iteration,
> -  effectively "skipping missed frames" of the drag-and-drop
> -  operation.)</p>
> +  <p>User agents must, as soon as the drag operation is initiated and
> +  every 350ms (&#xB1;200ms) thereafter for as long as the drag
> +  operation is ongoing, <span>queue a task</span> to perform the
> +  following steps in sequence:</p>
>   <ol>
>    <li>
> -    <p>First, the user agent must fire a <code
> -    title="event-drag">drag</code> event at the <span>source
> -    node</span>. If this event is canceled, the user agent must set
> -    the <span>current drag operation</span> to none (no drag
> -    operation).</p>
> +    <p>If the user agent is still performing the previous iteration of
> +    the sequence (if any) when the next iteration becomes due, the
> +    user agent must not execute the overdue iteration, effectively
> +    "skipping missed frames" of the drag-and-drop operation.</p>

Should timeupdate also "skip missed frames"? (I think Firefox does as a  
consequence of skipping frames while script is running and firing  
timeupdate for each frame. Opera currently queues up the events, IIRC.)


>    </li>
>    <li>
> +    <p>The user agent must fire a <code title="event-drag">drag</code>
> +    event at the <span>source node</span>. If this event is canceled,
> +    the user agent must set the <span>current drag operation</span> to
> +    none (no drag operation).</p>
> +
> +   </li>
> +
> +   <li>
> +
>      <p>Next, if the <code title="event-drag">drag</code> event was not
>      canceled and the user has not ended the drag-and-drop operation,
>      the user agent must check the state of the drag-and-drop
>
> _______________________________________________
> Commit-Watchers mailing list
> Commit-Watchers at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
>


-- 
Simon Pieters
Opera Software

From Simetrical+w3c at gmail.com  Mon Jan 25 09:39:04 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 25 Jan 2010 12:39:04 -0500
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <7789133a1001242229o7b978271oe1e1644a10785b40@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com>
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com>
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com>
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com>
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
	<7c2a12e21001241209uff7c922w1708b107263a1009@mail.gmail.com>
	<7789133a1001242229o7b978271oe1e1644a10785b40@mail.gmail.com>
Message-ID: <7c2a12e21001250939x72017b63s1deb449511ebcec4@mail.gmail.com>

On Mon, Jan 25, 2010 at 1:29 AM, Adam Barth <whatwg at adambarth.com> wrote:
> That depends what information the attacker encodes in the host name.
> Recall that we're imaging the attacker gets to run JavaScript within
> the sandbox

If we're assuming that, then yes, it's probably hopeless.  But are we
assuming that?  The given use-case was webmail -- that would be
expected to disable scripts in the sandbox, no?

> The point is that stopping exfiltration is a losing battle that we
> shouldn't bother to play.

Even if scripting is disabled?

From whatwg at adambarth.com  Mon Jan 25 11:16:27 2010
From: whatwg at adambarth.com (Adam Barth)
Date: Mon, 25 Jan 2010 19:16:27 +0000
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <7c2a12e21001250939x72017b63s1deb449511ebcec4@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com> 
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com> 
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com> 
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com> 
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com> 
	<7c2a12e21001241209uff7c922w1708b107263a1009@mail.gmail.com> 
	<7789133a1001242229o7b978271oe1e1644a10785b40@mail.gmail.com> 
	<7c2a12e21001250939x72017b63s1deb449511ebcec4@mail.gmail.com>
Message-ID: <7789133a1001251116s5e080f67qc8d2fc472fcc4b96@mail.gmail.com>

On Mon, Jan 25, 2010 at 5:39 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Mon, Jan 25, 2010 at 1:29 AM, Adam Barth <whatwg at adambarth.com> wrote:
>> That depends what information the attacker encodes in the host name.
>> Recall that we're imaging the attacker gets to run JavaScript within
>> the sandbox
>
> If we're assuming that, then yes, it's probably hopeless. ?But are we
> assuming that? ?The given use-case was webmail -- that would be
> expected to disable scripts in the sandbox, no?
>
>> The point is that stopping exfiltration is a losing battle that we
>> shouldn't bother to play.
>
> Even if scripting is disabled?

Blocking exfiltration has a long history on the web.  In fact, the
first security model for the web, before the same-origin policy, was
based on stopping exfiltration.  Ultimately, Netscape gave up on that
approach and tried the same-origin policy, which is what we're still
using today.  More recently, there have been some academic papers
studying the idea of preventing exfiltration after XSS attacks,
including some prototype implementations.  None of the implementations
I'm aware of have had their security claims stand up to close
scrutiny.

Of course, none of that means it would be impossible to add a security
feature to the web based on blocking exfiltration.  If that's
something you're passionate about, I'd encourage you to build a
prototype system by modifying one of the open source browsers.  If you
find a clever way of doing that, there are a number of folks in the
academic would who would love to hear how.  In particular, the Web 2.0
Security & Privacy Workshop might be a good venue to share your
findings:

http://w2spconf.com/2010/

That venue is particularly inviting to papers written by
non-academics.  You can see some of the papers from previous years to
get a feel for the style, etc.

Adam

From lcamtuf at coredump.cx  Mon Jan 25 11:51:33 2010
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Mon, 25 Jan 2010 11:51:33 -0800
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com>
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com>
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com>
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com>
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
Message-ID: <448e9a321001251151p7408b3begfcdf3a2df2082d4e@mail.gmail.com>

> I've introduced srcdoc="" to largely handle this. There is an example in
> the spec showing how it can be used.

Yup, sounds good.

> This has been proposed before. The concern is that many authors would be
> likely to make mistakes in their selection of "random" tokens that would
> lead to significant flaws in the deployment of the feature.
>
> srcdoc="" is less prone to errors. Only " and & characters need to be
> escaped. If the " character is not escaped, then a single " character in
> the input will cause the comment to break.

My counterargument, as stated later in the thread, is quite simple:
the former *forces* you to implement a security mechanism, else the
functionality will break. You can still use a bad token, but you are
required to make the effort.

In that regard, the comparison to XSRF is probably not valid; a vast
majority of XSRF bugs occurs not because people pick poor tokens (in
fact, that's really a majority), but because they don't use them at
all. From that perspectiv, srcdoc="..." is very similar to XSRF -
people will mess it up simply by not thinking about the correct
escaping.

That said, I am not really arguing against srcdoc="..."; I think it's
an OK feature. My point is simply that I would love to see less
fragmentation when it comes to XSS defenses and the granularity of
security controls. The initial proposal of <iframe> sandboxes solved a
very narrow use case, and other, unrelated designs started to spring
up elsewhere. This wouldn't be bad by itself, but while the security
controls on <iframes> were pretty great (with some tweaks, such as
text/html-sandboxed), they would not be reflected in other APIs, which
I thought is unfortunate.

If we extend sandboxed iframes with srcdoc, seamless frames,
text/html-sandboxed, and <iframe> rendering performance improvements,
it actually becomes close to a comprehensive solution, and I am happy
with this (other than a vague feeling that we just repurposed <iframe>
to be some sort of a <span> ;-).

> I've introduced text/html-sandboxed for this purpose.

Yup, I noticed. Looks great. It does make me wonder about two things, though:

1) Some other security mechanisms (CORS, anti-clickjacking controls,
XSS filter controls) rely on separate HTTP headers instead. Is there a
compelling reason not to follow that lead - or better yet, to unify
all security headers to conserve space?

2) People may conceivably want to sandbox other document types (e.g.,
SVG, RSS, or other XML-based formats rendered natively, and offering
scripting capabilities). Do we want to create "-sandboxed" MIME types
for each? The header approach would fix this, too.

>> 2.1) The ability to disable loading of external resources (images,
>> scripts, etc) in the sandboxed document. The common usage scenario is
>> when you do not want the displayed document to "phone home" for privacy
>> reasons, for example in a web mail system.
>
> Good point. Should we make sandbox="" disable off-origin network requests?

That would be great. I think Adam proposed we have a separate
sandbox="..." toggle for this. Whether it's on or off by default
probably doesn't matter much.

>> 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually
>> be approximated with the excommunicated <plaintext> tag, or with
>> Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or
>> DIVs, however, it would be pretty damn useful for displaying text
>> content without the need to escape &, <, >, etc. "Pure" security benefit
>> is limited, but as a phishing prevention and display correctness
>> measure, it makes sense.
>
> I don't really understand the use case here; could you elaborate?

One use case is a web forum or a web mail interface where you want to
display a message, but specifically don't want HTML formatting. Or,
performance permitting, the same could be used for any text-only entry
fields displayed on a page. These are common XSS vectors, and they are
not readily addressed by sandboxed <iframe> + srcdoc="...", because
this will not render as expected:

User's favorite smiley face is: <iframe srcdoc="&lt;O&gt;_&lt;O&gt;"></iframe>

Having a drop-in solution for this would be pretty nice, and very easy
to implement, too: just force text/plain, do not sniff.

> Do people get CSRF right more often than simply escaping characters? It
> seems implausible that authors get complex cryptographic properties right
> more often than a simple set of substitutions, but I suppose stranger
> things are true on the Web.

Keep in mind that pretty much every web application already needs to
safely generate unique, unpredictable tokens - for session identifiers
that guard authenticated sessions. If they can't get it right, they
are hosed anyway - but problems here are not horribly common, in my
experience at least, and web app frameworks do a decent job of helping
developers by providing token-generating facilities.

As noted earlier, the vast majority of issues with XSS and XSRF
defenses is that you explicitly need to think about them, and a
failure to do so has no obvious side effects. From that perspective,
any solution that requires a security mechanism to be used is far
better.

>> Also, a single token on a returned page, as long as it's unpredictable
>> across user sessions, should not be a significant issue.
> I'm just worried that some people would just a constant string.

Sure; but there's a difference between the near certainty of
forgetting to escape something, somewhere, in a complex web app (in
fact, I did so on several occasions in my code, despite making a
living by pointing these issues to others on a daily basis) - and
willingly sabotaging your app. Browser vendors / standards bodies are
partly at fault for the former, but have no obligation to prevent the
latter.

>> I was merely suggesting that we *expand* the same logic, and the same
>> excellent security control granularity, to span and div; this seems like
>> it would not increase the implementation complexity in any significant
>> way.
>
> I don't understand the proposal then. What is the problem it is solving,
> and how does it solve it?

It makes it possible to conveniently sandbox small, inline snippets of
user input on HTML pages, without a significant performance penalty.
As noted, if <iframe> rendering speed is improved instead, and srcdoc
and seamless rendering is implemented, the two proposals become
roughly equivalent, though (spare for the argument over srcdoc="..."
versus guard tokens). It does feel a bit odd to turn an <iframe> into
something that looks like <span>, swims like <span>, and quacks like
<span> - but that's mostly an aesthetic objection that shouldn't
matter much (a labored argument could be made that it will not be
obvious you can and should use <iframe> this way, so some people may
not fully utilize the security benefits it offers - but...)

> I don't understand what you mean by "does not enforce a security control",
> or how a guarded closing tag does "enforce a security control".

If you have the intent to display user-controlled input, you have three options:

<span>[server-sanitized string]</span>
<iframe srcdoc="[server-escaped string]"></iframe>
<span guard=[token]>[any string]</span guard=[token]>

The first two options will not immediately fail if you forget about or
mess up escaping or sanitization - and people to, all the time. The
last option just works, unless you purposefully sabotage your code by
using "1234", or can't generate a random number / session token on
server side (in which case, you are hosed already - session cookies
can be guessed, too). The last option strikes me as a bit less
error-prone.

/mz

From whatwg at adambarth.com  Mon Jan 25 11:57:46 2010
From: whatwg at adambarth.com (Adam Barth)
Date: Mon, 25 Jan 2010 19:57:46 +0000
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <448e9a321001251151p7408b3begfcdf3a2df2082d4e@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com> 
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com> 
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com> 
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com> 
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com> 
	<448e9a321001251151p7408b3begfcdf3a2df2082d4e@mail.gmail.com>
Message-ID: <7789133a1001251157wad0fbdia684472f77639a1c@mail.gmail.com>

On Mon, Jan 25, 2010 at 7:51 PM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
> 1) Some other security mechanisms (CORS, anti-clickjacking controls,
> XSS filter controls) rely on separate HTTP headers instead. Is there a
> compelling reason not to follow that lead - or better yet, to unify
> all security headers to conserve space?

The reason to use a MIME type here is to trick legacy browsers into
not rendering the response as HTML.

Adam

From lcamtuf at coredump.cx  Mon Jan 25 12:05:46 2010
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Mon, 25 Jan 2010 12:05:46 -0800
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <7789133a1001251157wad0fbdia684472f77639a1c@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com>
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com>
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com>
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com>
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com>
	<448e9a321001251151p7408b3begfcdf3a2df2082d4e@mail.gmail.com>
	<7789133a1001251157wad0fbdia684472f77639a1c@mail.gmail.com>
Message-ID: <448e9a321001251205p1f26d3b9u52d2688a06755bc4@mail.gmail.com>

> The reason to use a MIME type here is to trick legacy browsers into
> not rendering the response as HTML.

Legacy browsers probably will, anyway :-(

/mz

From jackalmage at gmail.com  Mon Jan 25 12:32:46 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 25 Jan 2010 14:32:46 -0600
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <448e9a321001251151p7408b3begfcdf3a2df2082d4e@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com> 
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com> 
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com> 
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com> 
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com> 
	<448e9a321001251151p7408b3begfcdf3a2df2082d4e@mail.gmail.com>
Message-ID: <dd0fbad1001251232r5d02b717pb2e8faaa458ae484@mail.gmail.com>

On Mon, Jan 25, 2010 at 1:51 PM, Michal Zalewski <lcamtuf at coredump.cx> wrote:
>> This has been proposed before. The concern is that many authors would be
>> likely to make mistakes in their selection of "random" tokens that would
>> lead to significant flaws in the deployment of the feature.
>>
>> srcdoc="" is less prone to errors. Only " and & characters need to be
>> escaped. If the " character is not escaped, then a single " character in
>> the input will cause the comment to break.
>
> My counterargument, as stated later in the thread, is quite simple:
> the former *forces* you to implement a security mechanism, else the
> functionality will break. You can still use a bad token, but you are
> required to make the effort.

Ah, but the devil is in the details.

Of the two escaping requirements for @srcdoc, only escaping " is
required for security reasons. (Forgetting to escape & will just
result in spurious entities sometimes, but no security issues.)
However, use of " in comments should be reasonably common, and if it
is left unescaped, will immediately truncate the content there (the
rest of the comment will attempt to be interpreted as attributes or
other elements).

Thus, if you fail to escape your "s, it should fail *quickly* and
*obviously* on *innocuous* content.  As well, as soon as it happens,
the obvious fix is the correct one.

On the other hand, getting your token-generation wrong will only fail
when someone guesses your guard token and attacks your site.  Ordinary
comments will still work just fine.

> If we extend sandboxed iframes with srcdoc, seamless frames,
> text/html-sandboxed, and <iframe> rendering performance improvements,
> it actually becomes close to a comprehensive solution, and I am happy
> with this (other than a vague feeling that we just repurposed <iframe>
> to be some sort of a <span> ;-).

In the end that's sorta what we're doing.  ^_^

> 1) Some other security mechanisms (CORS, anti-clickjacking controls,
> XSS filter controls) rely on separate HTTP headers instead. Is there a
> compelling reason not to follow that lead - or better yet, to unify
> all security headers to conserve space?

HTTP headers won't cause the content to fail in browsers that don't
understand them.  Mimetypes will in at least *some* legacy browsers.
I know that some versions of IE do content-sniffing for HTML-like
content.

> 2) People may conceivably want to sandbox other document types (e.g.,
> SVG, RSS, or other XML-based formats rendered natively, and offering
> scripting capabilities). Do we want to create "-sandboxed" MIME types
> for each? The header approach would fix this, too.

Possibly.  Are those document types going to be rendered in any way?
SVG can be sent with an HTML mimetype now, at least.

>>> 2.1) The ability to disable loading of external resources (images,
>>> scripts, etc) in the sandboxed document. The common usage scenario is
>>> when you do not want the displayed document to "phone home" for privacy
>>> reasons, for example in a web mail system.
>>
>> Good point. Should we make sandbox="" disable off-origin network requests?
>
> That would be great. I think Adam proposed we have a separate
> sandbox="..." toggle for this. Whether it's on or off by default
> probably doesn't matter much.

I think this is a good idea.  Adam argues against it being effective
for preventing exfiltration, but it's also useful for the common
use-case of disabling images in comments.  This would also prevent
people using <video> or <audio> in comments.  It would still allow the
site author to allow self-hosted files to be used with any of these
tags, but it would protect from, say, goatse trolls.

>>> 2.2) The ability to disable HTML parsing. On IFRAMEs, this can actually
>>> be approximated with the excommunicated <plaintext> tag, or with
>>> Content-Type: text/plain / data:text/plain,. On token-guarded SPANs or
>>> DIVs, however, it would be pretty damn useful for displaying text
>>> content without the need to escape &, <, >, etc. "Pure" security benefit
>>> is limited, but as a phishing prevention and display correctness
>>> measure, it makes sense.
>>
>> I don't really understand the use case here; could you elaborate?
>
> One use case is a web forum or a web mail interface where you want to
> display a message, but specifically don't want HTML formatting. Or,
> performance permitting, the same could be used for any text-only entry
> fields displayed on a page. These are common XSS vectors, and they are
> not readily addressed by sandboxed <iframe> + srcdoc="...", because
> this will not render as expected:
>
> User's favorite smiley face is: <iframe srcdoc="&lt;O&gt;_&lt;O&gt;"></iframe>
>
> Having a drop-in solution for this would be pretty nice, and very easy
> to implement, too: just force text/plain, do not sniff.

I agree with this as well.  I very commonly have inputs that should
take plaintext only, not html.

> <span>[server-sanitized string]</span>
> <iframe srcdoc="[server-escaped string]"></iframe>
> <span guard=[token]>[any string]</span guard=[token]>
>
> The first two options will not immediately fail if you forget about or
> mess up escaping or sanitization - and people to, all the time. The
> last option just works, unless you purposefully sabotage your code by
> using "1234", or can't generate a random number / session token on
> server side (in which case, you are hosed already - session cookies
> can be guessed, too). The last option strikes me as a bit less
> error-prone.

As I said above, the second one *should* fail, quite quickly, with
ordinary harmless content if you forget to escape the " in it, and the
way to fix it is both trivial and obvious.  On the other hand, the
third one you've listed will appear to work perfectly fine as long as
you can at least match your tokens on either end, but won't fail until
someone guesses your tokens and attacks you.  (And even then, it might
not be immediately obvious - they could put only non-visible content
after their smuggled-in </span guard=[token]>, so there's no visible
effect from the attack.)

Summary of suggestions to follow.

~TJ

From jackalmage at gmail.com  Mon Jan 25 12:52:28 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 25 Jan 2010 14:52:28 -0600
Subject: [whatwg] some thoughts on sandboxed IFRAMEs
In-Reply-To: <dd0fbad1001251232r5d02b717pb2e8faaa458ae484@mail.gmail.com>
References: <448e9a320912081120w733fbf95ob8ddb81d6069a2c7@mail.gmail.com> 
	<448e9a320912112018t6ca81e36g43b533a16f826a95@mail.gmail.com> 
	<7c2a12e20912131614g14906aud4d6482d1676204d@mail.gmail.com> 
	<448e9a320912131741x71aacd38gd9e7d119a311aee2@mail.gmail.com> 
	<Pine.LNX.4.64.1001240343120.6554@ps20323.dreamhostps.com> 
	<448e9a321001251151p7408b3begfcdf3a2df2082d4e@mail.gmail.com> 
	<dd0fbad1001251232r5d02b717pb2e8faaa458ae484@mail.gmail.com>
Message-ID: <dd0fbad1001251252q16b28845ha3faf486a51f5a02@mail.gmail.com>

Michal Zalewski brings up several good suggestions for improvements to
@sandbox that would make it more useful for embedding general
untrusted user content.  As well, Shelley Powers brought up a few
common uses that I think could fit into this model and prove useful.

1) Prevent cross-origin resource loads
--------------------------------------
Adam Barth rightfully points out that this only stops certain classes
of data exfiltration attacks, and so probably isn't worthwhile as a
solution to that matter.  However, I think this would also be very
useful for general comments, to prevent, for example, shock trolls
from putting goatse images in your comment threads.  It would also
prevent <video> and <audio> embeds from working.

However, it would still allow the site owner to allow particular files
to be embedded with <img>, <audio>, or <video>, if they just host them
on their own origin and set allow-same-origin in the sandbox flags.
This is already a relatively normal practice, but it's accomplished
through attempts at filtering.

Note that this would also prevent resource embeds using data urls, as
they have a unique origin.

2) Prevent all HTML parsing (rendering as text/plain)
-----------------------------------------------------
I think it's pretty common for certain areas of a comment form, such
as username, email, or title, to be meant as ordinary plaintext
without any special formatting allowed.  Right now that means you have
to run html escapes over the content, which isn't difficult.  Would it
be appropriate to move this into sandbox as well, though, to make it
even easier?

3) Prevent no-input actions
---------------------------
Sorry, the title is unclear - I mainly intend this as preventing
<audio autoplay> and the like.  Any sort of action that could be both
annoying and would take place without the user's consent.  This is
inherently ill-defined, which may be a problem, but it could be
tightened up to say precisely which features should be shut down.  It
might need to be revised as new features get added, though.

4) Stricter resource limits
---------------------------
Shelley Powers states that she disallows SVG in the comments on her
blog because of the risk of someone DOSing her users by writing highly
resource-intensive SVG.  This could be fixed in a general sense by
having the ability to opt into very strict resource limits per iframe
- it the limit is exceeded, the browser would simply bail and end
processing in that iframe.  I'm not certain how practical this is from
an engineering standpoint, however.  There's no need to set precise
limits on this - each browser should understand the platform it's
running on well enough to know what an 'appropriate' resource amount
is for this sort of thing.  Phones would cut off iframes much sooner
than a desktop, a browser might take advantage of system load
information to dynamically alter its cutoff point, etc.


Are there other reasonable improvements that could be made to <iframe
sandbox> to make it more suitable for wrapping things such as blog
comments?  Ideally, production-level sites with relatively normal
requirements should be able to use *solely* <iframe sandbox> to
protect their users from untrusted content.  (Though, of course, it
would be only a part of the site's defenses until the userbase with
non-supporting browsers drops low enough to ignore.)  Do others
believe this is an achievable goal, or conversely believe it is not?

~TJ

From jianli at chromium.org  Mon Jan 25 15:38:31 2010
From: jianli at chromium.org (Jian Li)
Date: Mon, 25 Jan 2010 15:38:31 -0800
Subject: [whatwg] Drag-and-drop feedback
In-Reply-To: <Pine.LNX.4.64.1001222234130.6554@ps20323.dreamhostps.com>
References: <cdc844f71001121600r1888810dmeb044735c359e947@mail.gmail.com>
	<Pine.LNX.4.62.1001130135560.8484@hixie.dreamhostps.com>
	<cdc844f71001221338o577acb7bk62c738a54d952141@mail.gmail.com>
	<Pine.LNX.4.64.1001222234130.6554@ps20323.dreamhostps.com>
Message-ID: <a95818c31001251538r667c62c7y92173539241e7097@mail.gmail.com>

On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 17 Aug 2009, Jian Li wrote:
> >
> > In order to download the attachment from an Internet mail application,
> > the user will have to click the attachment link and a "save" dialog will
> > pop up to let the user select the destination folder. This will normally
> > involves multiple clicks. Native application, like Outlook, can let the
> > user drag attachments directly into the destination place, i.e. desktop,
> > which is really convenient.
> >
> > We propose adding a specific format string to the DataTransfer object:
> > "DownloadURL". The data associated with the "DownloadURL" format should
> > be parsed similar to the "URL" format. When the drag ends in another
> > application, the remote file described in the associated data URL should
> > be downloaded and provided to the target application.
>
> How would this be exposed to other apps? Is it possible in Windows to drop
> something and then have the application that received the drop wait for a
> download (which could take hours) to complete? How does that work?
>
> If we can rely on the download happening before the drag, then we could
> add something to the DataTransfer object to add File objects.
>
>
We cannot do the download before the drag because the drop target might not
accept the drag or the user might press ESC to cancel the drag-and-drop. We
do not want to do any unnecessary download before we know for sure that the
user really wants it.

It could be possible that the target application could be blocked for long
time if we do not provide the drag-and-drop information in a nice way. On
Windows, we could provide a download file in two ways: file path or file
stream. For the former way, a file has to be downloaded first before the
target application can consume it and thus the target application will be
blocked until the download completes. For the latter way, we use the file
stream to transfer the data between the source application and the target
application and thus the target application will not be blocked if it uses a
background thread (this is what Windows Shell does). On MacOSX, a file
stream is also used for such purpose.

However, we need to provide more metadata about the download when we call
DataTransfer.setData("DownloadURL", ...). This is because on Windows we need
to know about the file name and size when the drag is initiated. We can wait
till we get the headers to extract the file name and size but this is
blocking. Even more, if the http chunk mode is used, we cannot get the size
from the headers. On MacOSX, we need to provide the mime type and file name.
Could we consider adding mime type, file name and size information into the
data value parameter of setData method? For example,
    dataTransfer.setData("DownloadURL", "text/plain:1000:
http://example.com/download.txt");


>
> On Fri, 4 Sep 2009, Jens Alfke wrote:
> > On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
> > >
> > > However, I think the addition of the deferred setData methods could be
> > > added today in a way that is completely backwards compatible with
> > > current implementations and would still be of great benefit.
> > > Specifically, my request for deferring the calling of toString on
> > > non-string objects as such:
> > >
> > > event.dataTransfer.setData("something", { toString: function() {
> > > return expensiveFunctionCall(); } });
> > >
> > > This would allow me to submit patches to Firefox and WebKit that would
> > > solve the current performance issues which are literally blocking my
> > > ability to switch from "fake" drag and drop to "native" drag and drop.
> > > At the same time, this should still work today in all browsers that
> > > implement setData because the object is coerced into a string
> > > immediately for you, thus not requiring immediate action on their part
> > > to change anything.
> >
> > +1. A real drag-n-drop API has to support promised data.
>
> I agree with this in principle, but I think we should wait for DND to be
> properly implemented in current browsers before adding this.
>
>
> On Tue, 12 Jan 2010, Michael Davidson wrote:
> >
> > The table in section 7.9.3 says that the DataTransfer object should be
> > empty for dragenter and dragover events.
> >
> > Clearly this is not the case - the example in 7.9.1 shows that, at the
> > very least, the DataTransfer object needs to have a 'types' attribute so
> > that the drag handler can determine if it can accept the drag.
>
> I've tried to clarify what "empty" is supposed to mean here.
>
>
> > The issue that I'm having is that if the DataTransfer object says that
> > it has Files, I have no way to determine what type those files are. (In
> > this case, I only want to accept image files.) I understand that the
> > DataTransfer shouldn't have the content of the files for security
> > reasons, but it would be helpful if it did contain the file names and/or
> > MIME types.
>
> I could provide a second attribute with the types of the files, would that
> work? I suppose if we did this, we should remove the "Files" fake type.
> That might not be a bad idea in general, it's kind of a hack. I'm not sure
> how I feel about having multiple different ways of representing the data
> in a DataTransfer object... It would give a clean precedent for adding
> other features, though, like promises, which some people have requested.
>
>
> On Fri, 22 Jan 2010, Daniel Cheng wrote:
> >
> > Two more questions about implementation details:
> >
> > Cut/copy:
> > Does it make sense to fire a drag event at all? The spec says that drag
> > events should be fired at the source node every 350ms (presumably to
> allow
> > the source node to cancel a drag after it started), but a cut/copy takes
> > place "instantaneously".
>
> I've clarified the spec to say that the loop has to happen immediately and
> then only repeat every 350ms if it's still active.
>
>
> > If drag events should be fired during cut/copy, should the clipboard be
> > restored to its original state if the drag event is cancelled? It would
> > make sense, but might make implementations more complicated.
>
> The idea is for the cut/copy to be done exactly as if it was a drag to a
> hypothetical clipboard window, meaning everything happens in the "drop"
> part, so yes.
>
>
> > Paste:
> > It seems like there is no time a dragleave event would ever fire. A paste
> > essentially goes through the drag and drop loop once; the only possible
> > transition is for the current target element to go from null to non-null.
>
> The 'dragleave' event can fire during a paste if the drag is canceled.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100125/82c64251/attachment-0001.htm>

From slightlyoff at google.com  Mon Jan 25 15: