From whatwg at adambarth.com  Tue Dec  1 00:14:09 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Tue, 1 Dec 2009 00:14:09 -0800
Subject: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
In-Reply-To: <3690291C-51B2-4A21-AF3D-E704FB85B9DA@apple.com>
References: <7789133a0911301555k60e48190k24df1fb23ec60406@mail.gmail.com> 
	<37DDCFB0-030F-450A-95E7-476535238D4F@apple.com>
	<7789133a0911301832h79199a60q7487007b28a38b7d@mail.gmail.com> 
	<3690291C-51B2-4A21-AF3D-E704FB85B9DA@apple.com>
Message-ID: <7789133a0912010014n5c9c599eseee250ec4c532243@mail.gmail.com>

Your main point is well taken.

There are some technical reasons why tag whitelisting makes more sense
for inline content.  For example, consider the case you mentioned on
webkit-dev: @id.  Inline, @id is problematic because the ids exist in
a per-frame namespace, whereas they're harmless when the untrusted
content has an entire iframe to itself.  Of course, @id is not unique
in this respect.  For example, <input type=password> will likely get
autofilled by the password manager inline and @style can be used to
draw all over the page without an iframe's layout contraints.

That said, I'm not married to a design with a tag-level whitelist.  Do
you have a specific alternative in mind?

Adam


On Mon, Nov 30, 2009 at 7:43 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Nov 30, 2009, at 6:32 PM, Adam Barth wrote:
>
>> On Mon, Nov 30, 2009 at 5:43 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> 1) It seems like this API is harder to use than a sandboxed iframe. To
>>> use
>>> it correctly, you need to determine a whitelist of safe elements and
>>> attributes; providing an explicit whitelist at least of tags is
>>> mandatory.
>>> With a sandboxed iframe, as a Web developer you can just ask the browser
>>> to
>>> turn off unsafe things and not worry about designing a security policy.
>>> Besides ease of use, there is also the concern that a server-side
>>> filtering
>>> whitelist may be buggy, and if you apply the same whitelist on the client
>>> side as backup instead of doing something high level like "disable
>>> scripting" then you are less likely to benefit from defense in depth,
>>> since
>>> you may just replicate the bug.
>>
>> I should follow up with folks in the ruby-on-rails community to see
>> how they view their sanitize API. ?The one person I asked had a
>> positive opinion, but we should get a bigger sample size.
>
> For server-side sanitization, this kind of explicit API is pretty much the
> only thing you can do.
>
>>
>> I think updateWithSanitizedHTML has different use cases than @sandbox.
>> I think the killer applications for @sandbox are advertisements and
>> gadgets. ?In those cases, the developer wants most of the browser's
>> functionality, but wants to turn off some dangerous stuff (like
>> plug-ins). ?For updateWithSanitizedHTML, the killer application is
>> something like blog comments, where you basically want text with some
>> formatting tags (bold, italics, and maybe images depending on the
>> forum).
>
> I can imagine use cases where allowing very open-ended but script-free
> content is desirable. For example, consider a hosted blog service that wants
> to let blog authors write nearly arbitrary HTML, but without allowing
> script. @sandbox would not be a good solution for that use case. In general
> it does not seem sensible to me that the choice of tag whitelisting vs
> high-level feature whitelisting is tied to the choice of embedding content
> directly vs. creating a frame. Is there a technical reason these two choices
> have to be tied?
>
>>
>>> 2) It seems like this API loses one of the big benefits of sanitizing
>>> HTML
>>> in the browser implementation. Specifically, in theory it's safe to say
>>> "allow everything except any construct that would result in script/code
>>> running". You can't do that on the server side - blacklisting is not
>>> sound
>>> because you can't predict the capabilities of all browsers. But the
>>> browser
>>> can predict its own capabilities. Sandboxed iframes do allow for this.
>>
>> The benefit is that you know you're getting the right parsing. ?You're
>> not going to be tripped up by <img/src=javascript: and friends.
>
> It's true, this is a benefit. However, it seems like even if you whitelist
> tags, being able to say "no script" at a high level
>
>> Also, this API is useful in cases where you don't have a server to help
>> you
>> sanitize your input. ?One example I saw recently was a GreaseMonkey
>> script that wanted to add EXIF metadata to Flickr. ?Basically, the
>> script grabbed the EXIF data from api.flickr.com and added it to the
>> current page. ?Unfortunately, that meant I could use this GreaseMonkey
>> script to XSS Flickr by adding HTML to my EXIF metadata. ?Sure, there
>> are other ways of solving the problem (I asked the developer to build
>> the DOM in memory and use innerText), but you want something simple
>> for these cases.
>
> If the EXIF metadata is supposed to be text-only, it seems like
> updateWithSanitizedHTML would not be easier to use than innerText, or in any
> way superior. For cases where it is actually desirable to allow some markup,
> it's not clear to me that giving explicit whitelists of what is allowed is
> the simple choice.
>
>>
>>> I think the benefits of filtering by tag/attribute/scheme for advanced
>>> experts are outweighed by these two disadvantages for basic use, compared
>>> to
>>> something simple like the original staticInnerHTML idea. Another possible
>>> alternative is to express how to sanitize at a higher level, using
>>> something
>>> similar to sandboxed iframe feature strings.
>>
>> If you think of @sandbox as being optimized for rich untrusted content
>> and updateWithSanitizedHTML as being optimized for poor untrusted
>> content, then you'll see that's what the API does already. ?The
>> feature string Slashdot wants for its comments is ("a b strong i em",
>> "href"), but another message board might want something different.
>> For example, 4chan might want ("img", "src alt"). ?I don't think these
>> require particularly advanced experts to understand.
>
> updateWithSanitizedHTML and @sandbox both provide features that the other
> does not for reasons that do not seem technically necessary. For example,
> updateWithSanitizedHTML could easily have an "allow everything except
> script" mode, and @sandbox could easily allow per-tag whitelisting. Then the
> choice would be between the resource cost of a frame, and the sandboxing
> features that it's impractical to provide without a frame (limiting content
> to a bounding box while still allowing styling, allowing script without
> affecting the containing content, etc).
>
>>
>>> Here's a problem that exists with both this API and also innerStaticHTML:
>>>
>>> 3) There is no secure and efficient way to append sanitized contents to
>>> an
>>> element that already has children. This may result in authors appending
>>> with
>>> innerHTML += ?(inefficient and insecure!) or insertAdjecentHTML()
>>> (efficient
>>> but still insecure!). I'm willing to concede that use cases other than
>>> "replace existing contents" and "append to existing contents" are fairly
>>> exotic.
>>
>> Maybe we need insertAdjecentSanitizedHTML instead or in addition. ?;)
>
> Perhaps. The verb "update" is generic enough that it could handle different
> kinds of mutations with flags, but perhaps that means it is too vague for a
> security-sensitive API.
>
> Regards,
> Maciej
>
>

From ian at hixie.ch  Tue Dec  1 01:36:51 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 1 Dec 2009 09:36:51 +0000 (UTC)
Subject: [whatwg] Web Workers: Worker.onmessage
In-Reply-To: <op.u28lsksdidj3kv@zcorpandell.linkoping.osa>
References: <op.u28j73uyidj3kv@zcorpandell.linkoping.osa>
	<op.u28lsksdidj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0912010930230.1141@hixie.dreamhostps.com>

On Wed, 11 Nov 2009, Simon Pieters wrote:
> On Wed, 11 Nov 2009 16:05:53 +0100, Simon Pieters <simonp at opera.com> wrote:
> > 
> > Shouldn't setting onmessage on a Worker object enable the port message 
> > queue?
> > 
> > Currently step 8 of the "run a worker" algorithm enables the port 
> > message queue for the WorkerGlobalObjectScope side, but it is never 
> > enabled when going in the other direction, if I'm reading the spec 
> > correctly.
> 
> Hmm. Actually, step 12 and 13 of the Worker constructor enable the port 
> message queue for both the inside and outside ports. Why does the "run a 
> worker" algorithm enable one of them again? Isn't it too early to enable 
> the port message queues before the worker has run and set 'onmessage'?

I suppose that if the worker is slow to start up, it could conceivably 
receive a message before the event loop exists, which would lead to poorly 
defined behaviour. I've removed the inner port opening from the 
constructor's algorithm.

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

From ian at hixie.ch  Tue Dec  1 02:28:10 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 1 Dec 2009 10:28:10 +0000 (UTC)
Subject: [whatwg] [Web workers] An attribute describing the "best"
 number of worker to invoke in a delegation use case
In-Reply-To: <4AFCA9DB.5000103@mit.edu>
References: <4AFB7EB5.7010001@enseirb-matmeca.fr> <4AFB81E0.7000100@mit.edu>
	<4AFC4AB5.7020606@enseirb-matmeca.fr> <4AFC66A7.2010404@mit.edu>
	<4AFC72D1.9020904@enseirb-matmeca.fr> <4AFC7F8A.1050703@mit.edu>
	<4AFCA74D.80905@enseirb-matmeca.fr> <4AFCA9DB.5000103@mit.edu>
Message-ID: <Pine.LNX.4.62.0912010942380.1141@hixie.dreamhostps.com>

On Wed, 11 Nov 2009, David Bruant wrote:
> 
> This is a new proposal taking into account the feedback I recieved to 
> the "[WebWorkers] About the delegation example" message.
> 
> In the delegation example of the WebWorker spec, we can see this line :
> "var num_workers = 10;"
> 
> My concern is about the arbitrarity of the "10".

I agree that it's suboptimal. However, I think realistically a good 
implementation of parallel work would need some sort of dynamic 
performance tuning, continuously slowly ramping up the number of workers 
while it increases throughput, and when throughput decreases, switching to 
reducing the number of workers until throughput increases again. That 
would probably be too complicated to show in an example in the spec.


> My proposal is to add an attribute to the navigator object to write this :
> "var num_workers = navigator.optimalWorkerNumber;
> var items_per_worker = 10000000/num_workers;" (uneven dividing can
> easily be solved)
> (the name "optimalWorkerNumber" is not good, but I will use it in the
> rest of this e-mail)

optimalWorkerNumber is a function of time and of the algorithm that the 
worker implements. I don't think it would solve the problem.


> This attribute have the following properties :
> - It's only dependant on the hardware, the operating system and the
> WebWorker implementation (thus, it is not dynamically computed by the
> user agent at each call and two calls in the same
> hardware//OS//WebWorker implementation have the same result).
> - In the same running conditions (same memory available, same number of
> process running concurrently...) running the "same algorithm" (an easy
> delegation algorithm) has a significantly better performance with
> (navigator.optimalWorkerNumber) workers than
> (navigator.optimalWorkerNumber - 1) workers
> - In the same running conditions, running the same algorithm has no
> significantly better performance with (navigator.optimalWorkerNumber +1)
> workers than (navigator.optimalWorkerNumber) workers

I do not think it is possible to satisfy all of the above conditions at 
the same time.


On Thu, 12 Nov 2009, David Bruant wrote, in response to Boris saying much 
the same as what I wrote above:
>
> => You're perfectly right. I reformulate the definition of "running
> conditions" (appearing in condition 2 and 3) as :
> "same memory available, same number of process running concurrently, no
> other worker running working on the same document".

On Thu, 12 Nov 2009, Boris Zbarsky wrote:
> 
> That doesn't help that much, unfortunately.  Most simply, consider a 
> quad-core chip and workers that are completely cpu-bound.  If there are 
> no other processes running, the optimal number of workers is 4.  If 
> there is one other process which is also completely cpu-bound running, 
> the optimal number of workers is 3 (in the sense that 4 may well not 
> satisfy your condition 3). This is really the same issue as having one 
> worker running, but it's some process not under the browser's control.
> 
> If, on the other hand, the workers are I/O bound (esp. network I/O 
> latency bound), then the optimal number of workers can well be larger 
> than the number of cores...

On Thu, 12 Nov 2009, David Bruant wrote:
>
> => If you are comparing "no other processes running" and "one other 
> process which is also completely cpu-bound running", you are not in what 
> I've called "same running conditions". (because the number of concurrent 
> processes is different).

The point is that the constant can't be constant if it has to return a 
different number based on conditions outside the UA's control.


> I reformulate this way the conditions 2 and 3:
> - In "blank conditions" (no other processes/thread running on the CPU,
> enough memory to allocate the workers), running the same algorithm (an
> easy delegation algorithm) has significantly better performances with
> (navigator.optimalWorkerNumber) dedicated workers than with
> (navigator.optimalWorkerNumber -1) dedicated workers
> - In "blank conditions", running the same algorithm has no significantly
> better performances with (navigator.optimalWorkerNumber+1) dedicated
> workers than with (navigator.optimalWorkerNumber) dedicated workers

This isn't especially useful, since "blank conditions" are never met by a 
running script (for one, the script is running).


> Just to remind, the purpose of this attribute is to decide, at the
> beginning of a delegation algorithm what is the "optimal" number of
> workers to divide the work in a way that is optimal regarding the
> hardware, the OS and the worker implementation.
> No matter the running conditions, 2 calls return the same value for the
> same hardware//OS//Worker implementation.
> The idea behind this property is that even if you start running the
> algorithm with a lot of concurrent processes, you create a number of
> workers that cannot be ran concurrently at the beginning, but you may
> use optimally the ressources later (if the other processes/threads stop
> running, what you cannot control, but can still hope that it happens
> during the "algorithm lifetime". According to the spec, "workers are
> expected to be long-lived").

Basically, this would encourage authors to always use too many workers, as 
far as I can tell.


On Thu, 12 Nov 2009, David Bruant wrote:
>
> => I think it happens very often. While I'm writing this e-mail, "no 
> process" is running. About fifty processes are runnable, but not 
> running. They are passively waiting. My CPU is barely used.

You're lucky. :-) My CPU is almost always at at least 25%.


> My point is that this number may be available very easily. For example, 
> in my dual-core, Linux, Firefox 3.5, the number is 2. Why spare an 
> information that can be useful and reliable (more than measurement at 
> least !) ?

It's actually probably quite rarely 2. It depends on all kinds of factors, 
like the kind of algorithm, what other programs are running, etc.


I still haven't added this feature, as I do not believe the arguments 
presented form a convincing case. However, if you are still interested in 
persuing this feature, I encourage you to convince a browser vendor to 
implement it, as discussed here:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

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

From kornel at geekhood.net  Tue Dec  1 02:38:57 2009
From: kornel at geekhood.net (=?UTF-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Tue, 1 Dec 2009 10:38:57 +0000
Subject: [whatwg] updateWithSanitizedHTML (was Re:  innerStaticHTML)
In-Reply-To: <7789133a0911301555k60e48190k24df1fb23ec60406@mail.gmail.com>
References: <7789133a0911301555k60e48190k24df1fb23ec60406@mail.gmail.com>
Message-ID: <BA03DC53-1DA2-460D-ADA3-BD0116735889@geekhood.net>

> The WebKit community is considering taking up such an experimental
> implementation.  Here's my current proposal for how this might work:
>
> http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTJzbTY1cWJrNA&hl=en
>
> I would appreciate any feedback on the design.

Whitelist requires developers to know about potential risks of each  
element/property, and that's not obvious to everyone: e.g. one might  
want to allow object/embed (for harmless YouTube videos) without  
realizing that it enables XSS.

It's also non-obvious that style attribute is XSS risk (via behavior  
property). Higher-level filtering option could allow style attribute,  
and only filter out that property. Current proposal would need another  
whitelist for CSS properties.

And even whitelist for CSS properties couldn't be used to implement  
"No external access" policy (allow images with data: urls, allow http:  
links, but not http: images). This would be useful for webmails and  
other places where website doesn't want to allow 3rd parties tracking  
views.

"No clickjacking" option might be useful as well.

-- 
regards, Kornel Lesi?ski


From lachlan.hunt at lachy.id.au  Tue Dec  1 05:28:32 2009
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 01 Dec 2009 14:28:32 +0100
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <op.u370v5d3sr6mfa@nog>
References: <op.u370v5d3sr6mfa@nog>
Message-ID: <4B151A00.1030602@lachy.id.au>

Philip J?genstedt wrote:
> As currently speced, the proper usage of <figure> is:
>
> <figure>
> <dd><img src="bunny.jpg" alt="A Bunny"></dd>
> <dt>The Cutest Animal</dt>
> </figure>
>
> Apart from all that has been said about legacy parsing, leaking style in
> IE, etc I would (perhaps not be the first to) add:
>
> 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how
> often authors will get it wrong, I think everyone agrees that (all else
> equal) a syntax which is harder to confuse/mistype is better.

Yes, I expect we'll see a lot of authors get them reversed, using the dd 
for the caption if they want the caption below the content.  This is 
likely to occur since existing authors have already learned that dt 
comes before dd when used within a dl, and because old habbits die hard, 
they're likely to repeat the pattern within figure.

> 2. Only the caption needs to be marked up, the content is implicitly
> everything else. While some content may need a wrapping element for
> styling, e.g. <img> usually does not.
>
> 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.)

Some additional reasons why using dt/dd in figure is a bad solution:

The simplest workaround presented so far to solve the styling issue in 
IE is basically to do this:

<div class="figure">
   <figure>
     <dd><img src="image" alt="..."></dd>
     <dt>Caption</dt>
   </figure>
</div>

And then rather than style the figure itself, give some style to the div 
because some styles don't work properly when applied to the figure. 
This effectively makes the figure element itself entirely useless, 
especially given that all browsers lack support for it.

It would be far easier for authors to just stick with this entirely hack 
free alternative that doesn't use the new elements:

<div class="figure">
   <img src="image" alt="...">
   <p class="caption">Caption</p>
</div>

At least until browsers actually implement support for <figure> and 
IE6/7's market share becomes negligible.  It will take a couple of years 
for those events to occur, and there's no need to rush into using the 
new elements yet.

> The main difficulty with coming up with something better seems to have
> been finding a name for an element which isn't already taken. If that's
> the only issue, why not just take some inspiration from <time pubdate>
> and use an attribute instead?
>
> <figure>
> <img src="bunny.jpg" alt="A Bunny">
> <p caption>The Cutest Animal</p>
> </figure>

I was the first one to suggest that on IRC a while ago, but I'm not 
convinced it's a good idea.  Although it's certainly better than using 
dt/dd.

See IRC logs here.
http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1525
http://krijnhoetmer.nl/irc-logs/whatwg/20090918#l-1133

The original idea for using the attribute was that it could apply to a 
wide range of elements, like p, div, etc.  But that makes it difficult 
for browsers to provide sensible default styling for captions, since it 
requires carefully overriding existing defaults for so many other elements.

To some extent, it even makes it difficult for authors to provide 
reasonable styles if they can't guarantee which elements content writers 
will choose for their caption.  Imagine designing a CMS template with 
some default styles for figure and caption, the CSS in the template 
would have to deal with so many possible element choices just for the 
caption, it'll be difficult to get it right and test everything.

Limiting the caption attribute to just the p element, or just div or 
something, might help, but I'd still expect authors to end up using it 
on other elements anyway.

There are only 2 sensible options for element choices: <legend> or 
introducing a new element.  Using dt/dd is *not* and was never a 
sensible choice for figure, and the idea must be dropped.

Since Hixie is adamant that introducing a new element for the caption 
isn't going to happen, and I've yet to find a way to convince him 
otherwise, that leaves us with legend.

Although legend has it's own styling issues in browsers, these will 
eventually be resolved in a couple of years.  Therefore, the best 
solution is to revert the spec back to using legend for figure, but 
strongly discourage authors from using these new elements yet, until the 
implementation issues are resolved.

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

From privat at ni-po.com  Tue Dec  1 06:33:28 2009
From: privat at ni-po.com (Nikita Popov)
Date: Tue, 01 Dec 2009 15:33:28 +0100
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <4B151A00.1030602@lachy.id.au>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
Message-ID: <4B152938.2010309@ni-po.com>


> The original idea for using the attribute was that it could apply to a 
> wide range of elements, like p, div, etc.  But that makes it difficult 
> for browsers to provide sensible default styling for captions, since 
> it requires carefully overriding existing defaults for so many other 
> elements.
>
> To some extent, it even makes it difficult for authors to provide 
> reasonable styles if they can't guarantee which elements content 
> writers will choose for their caption.  Imagine designing a CMS 
> template with some default styles for figure and caption, the CSS in 
> the template would have to deal with so many possible element choices 
> just for the caption, it'll be difficult to get it right and test 
> everything.
This does make sense. Would be really hard, for sure.
> There are only 2 sensible options for element choices: <legend> or 
> introducing a new element.  Using dt/dd is *not* and was never a 
> sensible choice for figure, and the idea must be dropped.
As caption and legend have much too many backwards compatibility issues, 
the only possible solution is either a new element or dropping the whole 
figure-thing. The second thing should really be taken into account. 
Better no syntax than bad syntax :)

What tag-titles could be used to mark the captions up? I thought of 
<desc> or <description> (first is better). Does not seem to be taken, 
but I don't know whether it is as intuitive. (But I as a German, who 
can't speak English very well, would search for "html5 image 
description" next after "html5 caption".)

MfG Nikita Popov

From jackalmage at gmail.com  Tue Dec  1 06:38:32 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 1 Dec 2009 08:38:32 -0600
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <4B151A00.1030602@lachy.id.au>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
Message-ID: <dd0fbad0912010638q4e4d7c12o121d90cec1a0dc96@mail.gmail.com>

On Tue, Dec 1, 2009 at 7:28 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> To some extent, it even makes it difficult for authors to provide reasonable
> styles if they can't guarantee which elements content writers will choose
> for their caption. ?Imagine designing a CMS template with some default
> styles for figure and caption, the CSS in the template would have to deal
> with so many possible element choices just for the caption, it'll be
> difficult to get it right and test everything.

There are a multitude of "reset" style sheets on the web today that
don't seem to have a problem removing virtually all default styling
from elements.  It would not be difficult to modify one to strip a
@caption element down to bare bones and then restyle as desired.

~TJ

From philipj at opera.com  Tue Dec  1 07:01:07 2009
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 01 Dec 2009 16:01:07 +0100
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <4B152938.2010309@ni-po.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<4B152938.2010309@ni-po.com>
Message-ID: <op.u39lb5faatwj1d@sisko.linkoping.osa>

On Tue, 01 Dec 2009 15:33:28 +0100, Nikita Popov <privat at ni-po.com> wrote:

>> There are only 2 sensible options for element choices: <legend> or  
>> introducing a new element.  Using dt/dd is *not* and was never a  
>> sensible choice for figure, and the idea must be dropped.
> As caption and legend have much too many backwards compatibility issues,  
> the only possible solution is either a new element or dropping the whole  
> figure-thing.

or a new attribute

-- 
Philip J?genstedt
Core Developer
Opera Software

From whatwg at adambarth.com  Tue Dec  1 07:05:13 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Tue, 1 Dec 2009 07:05:13 -0800
Subject: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
In-Reply-To: <BA03DC53-1DA2-460D-ADA3-BD0116735889@geekhood.net>
References: <7789133a0911301555k60e48190k24df1fb23ec60406@mail.gmail.com> 
	<BA03DC53-1DA2-460D-ADA3-BD0116735889@geekhood.net>
Message-ID: <7789133a0912010705h5895b205p7fc1e8c4c44ab01c@mail.gmail.com>

2009/12/1 Kornel Lesi?ski <kornel at geekhood.net>:
>> The WebKit community is considering taking up such an experimental
>> implementation. ?Here's my current proposal for how this might work:
>>
>>
>> http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTJzbTY1cWJrNA&hl=en
>>
>> I would appreciate any feedback on the design.
>
> Whitelist requires developers to know about potential risks of each
> element/property, and that's not obvious to everyone: e.g. one might want to
> allow object/embed (for harmless YouTube videos) without realizing that it
> enables XSS.

That's true.  It would be interesting to know how often developers
screw this up with Ruby-on-Rails' version of the API.

> It's also non-obvious that style attribute is XSS risk (via behavior
> property). Higher-level filtering option could allow style attribute, and
> only filter out that property. Current proposal would need another whitelist
> for CSS properties.

Script-in-CSS is subtle enough that it's explicitly blocked (like
javascript URLs).

> And even whitelist for CSS properties couldn't be used to implement "No
> external access" policy (allow images with data: urls, allow http: links,
> but not http: images). This would be useful for webmails and other places
> where website doesn't want to allow 3rd parties tracking views.

I don't think an no external access policy is worth supporting
explicitly.  If it falls out of a general design, that's great, but I
don't think the use case is compelling enough to accept the design
constraints required to support it.

> "No clickjacking" option might be useful as well.

I don't have a clear idea how this would work.  Did you have something
different in mind than X-Frame-Options (already supported by WebKit)?

Adam

From lachlan.hunt at lachy.id.au  Tue Dec  1 07:07:05 2009
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 01 Dec 2009 16:07:05 +0100
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <dd0fbad0912010638q4e4d7c12o121d90cec1a0dc96@mail.gmail.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<dd0fbad0912010638q4e4d7c12o121d90cec1a0dc96@mail.gmail.com>
Message-ID: <4B153119.4000005@lachy.id.au>

Tab Atkins Jr. wrote:
> On Tue, Dec 1, 2009 at 7:28 AM, Lachlan Hunt<lachlan.hunt at lachy.id.au>  wrote:
>> To some extent, it even makes it difficult for authors to provide reasonable
>> styles if they can't guarantee which elements content writers will choose
>> for their caption.  Imagine designing a CMS template with some default
>> styles for figure and caption, the CSS in the template would have to deal
>> with so many possible element choices just for the caption, it'll be
>> difficult to get it right and test everything.
>
> There are a multitude of "reset" style sheets on the web today that
> don't seem to have a problem removing virtually all default styling
> from elements.  It would not be difficult to modify one to strip a
> @caption element down to bare bones and then restyle as desired.

Applying reset styles alone and making all elements look the same 
basically defeats the purpose of being able to use a range of different 
elements, and is very likely not what an author would ultimately want.

Reset styles are just used to give different elements a more level 
playing field for new styles, and so authors would then still have to go 
through all the elements and style them appropriately for use as a 
caption.  Plus, authors have to worry about cascading issues from other 
styles in their own stylesheets.

Say, for instance, an author had applied special styles to paragraphs in 
some special type of section:

#foo p { margin-left: 1em; }

And then a content writer puts a figure in there using <p caption>, but 
the CSS author failed to adequately account for figures being used in 
that section, despite doing:

p[caption] { margin: 0; }

Due to specificity, the first rule would apply regardless and the 
caption would get a potentially unwanted margin.

I know there are ways to work around the issue, such as using !important 
or finding ways to increase the specificity of the latter selector, but 
the point is that introducing unnecessary element clashes creates 
needless complexities that should be avoided.

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

From jackalmage at gmail.com  Tue Dec  1 07:15:36 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 1 Dec 2009 09:15:36 -0600
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <4B153119.4000005@lachy.id.au>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<dd0fbad0912010638q4e4d7c12o121d90cec1a0dc96@mail.gmail.com>
	<4B153119.4000005@lachy.id.au>
Message-ID: <dd0fbad0912010715h238655e9ud23ad62f9bfdb1c3@mail.gmail.com>

On Tue, Dec 1, 2009 at 9:07 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Applying reset styles alone and making all elements look the same basically
> defeats the purpose of being able to use a range of different elements, and
> is very likely not what an author would ultimately want.

Heh, you either want consistent styling, in which case you use a
reset, or you want element-specific styling, in which you don't.
Can't have it both ways.  ^_^

> Reset styles are just used to give different elements a more level playing
> field for new styles, and so authors would then still have to go through all
> the elements and style them appropriately for use as a caption. ?Plus,
> authors have to worry about cascading issues from other styles in their own
> stylesheets.
>
> Say, for instance, an author had applied special styles to paragraphs in
> some special type of section:
>
> #foo p { margin-left: 1em; }
>
> And then a content writer puts a figure in there using <p caption>, but the
> CSS author failed to adequately account for figures being used in that
> section, despite doing:
>
> p[caption] { margin: 0; }
>
> Due to specificity, the first rule would apply regardless and the caption
> would get a potentially unwanted margin.
>
> I know there are ways to work around the issue, such as using !important or
> finding ways to increase the specificity of the latter selector, but the
> point is that introducing unnecessary element clashes creates needless
> complexities that should be avoided.

This is a valid complaint.

~TJ

From kornel at geekhood.net  Tue Dec  1 07:15:55 2009
From: kornel at geekhood.net (=?UTF-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Tue, 1 Dec 2009 15:15:55 +0000
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <4B152938.2010309@ni-po.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<4B152938.2010309@ni-po.com>
Message-ID: <C8C546B5-32C5-4079-8F9F-0761A4A44D1F@geekhood.net>

On 1 Dec 2009, at 14:33, Nikita Popov wrote:

> As caption and legend have much too many backwards compatibility  
> issues

It's not bad I think. I've played a little with the live DOM viewer  
and this seems usable:

<figure>
   content
   <caption><div class=caption>foo</div></caption>
</figure>

caption start/end tag is completely ignored, so at lest there's no  
negative side effect. You only need another styling hook. It's not any  
worse than suggested hack for <dd>.

To ease transition, HTML5 might allow wrapping <caption> in <table>  
without any rows:

<figure>
   content
   <table><caption>foo</caption></table>
</figure>

This gives good DOM and styling in all browsers (with createElement  
hack in IE of course).

This caption can be styled differently from real table captions using  
caption:only-child selector.

Saying that caption of table in figure is also figure's caption IMHO  
makes sense even for real tables (is there a need for doubly-captioned  
figure-table?)

-- 
regards, Kornel


From philipj at opera.com  Tue Dec  1 07:36:08 2009
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 01 Dec 2009 16:36:08 +0100
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <4B151A00.1030602@lachy.id.au>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
Message-ID: <op.u39myiceatwj1d@sisko.linkoping.osa>

On Tue, 01 Dec 2009 14:28:32 +0100, Lachlan Hunt  
<lachlan.hunt at lachy.id.au> wrote:

> Philip J?genstedt wrote:
>> As currently speced, the proper usage of <figure> is:
>>
>> <figure>
>> <dd><img src="bunny.jpg" alt="A Bunny"></dd>
>> <dt>The Cutest Animal</dt>
>> </figure>
>>
>> Apart from all that has been said about legacy parsing, leaking style in
>> IE, etc I would (perhaps not be the first to) add:
>>
>> 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how
>> often authors will get it wrong, I think everyone agrees that (all else
>> equal) a syntax which is harder to confuse/mistype is better.
>
> Yes, I expect we'll see a lot of authors get them reversed, using the dd  
> for the caption if they want the caption below the content.  This is  
> likely to occur since existing authors have already learned that dt  
> comes before dd when used within a dl, and because old habbits die hard,  
> they're likely to repeat the pattern within figure.
>
>> 2. Only the caption needs to be marked up, the content is implicitly
>> everything else. While some content may need a wrapping element for
>> styling, e.g. <img> usually does not.
>>
>> 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone  
>> else's.)
>
> Some additional reasons why using dt/dd in figure is a bad solution:
>
> The simplest workaround presented so far to solve the styling issue in  
> IE is basically to do this:
>
> <div class="figure">
>    <figure>
>      <dd><img src="image" alt="..."></dd>
>      <dt>Caption</dt>
>    </figure>
> </div>
>
> And then rather than style the figure itself, give some style to the div  
> because some styles don't work properly when applied to the figure. This  
> effectively makes the figure element itself entirely useless, especially  
> given that all browsers lack support for it.
>
> It would be far easier for authors to just stick with this entirely hack  
> free alternative that doesn't use the new elements:
>
> <div class="figure">
>    <img src="image" alt="...">
>    <p class="caption">Caption</p>
> </div>
>
> At least until browsers actually implement support for <figure> and  
> IE6/7's market share becomes negligible.  It will take a couple of years  
> for those events to occur, and there's no need to rush into using the  
> new elements yet.
>
>> The main difficulty with coming up with something better seems to have
>> been finding a name for an element which isn't already taken. If that's
>> the only issue, why not just take some inspiration from <time pubdate>
>> and use an attribute instead?
>>
>> <figure>
>> <img src="bunny.jpg" alt="A Bunny">
>> <p caption>The Cutest Animal</p>
>> </figure>
>
> I was the first one to suggest that on IRC a while ago, but I'm not  
> convinced it's a good idea.  Although it's certainly better than using  
> dt/dd.
>
> See IRC logs here.
> http://krijnhoetmer.nl/irc-logs/whatwg/20090917#l-1525
> http://krijnhoetmer.nl/irc-logs/whatwg/20090918#l-1133
>
> The original idea for using the attribute was that it could apply to a  
> wide range of elements, like p, div, etc.  But that makes it difficult  
> for browsers to provide sensible default styling for captions, since it  
> requires carefully overriding existing defaults for so many other  
> elements.

You only need to provide styles for the elements you're using which  
wouldn't work with a simple generic style such as.

figure>[caption] { margin-left: 1em; font-weight: bold; }

Please, no examples where this doesn't work. It's obvious, but also very  
easy to fix.


> To some extent, it even makes it difficult for authors to provide  
> reasonable styles if they can't guarantee which elements content writers  
> will choose for their caption.  Imagine designing a CMS template with  
> some default styles for figure and caption, the CSS in the template  
> would have to deal with so many possible element choices just for the  
> caption, it'll be difficult to get it right and test everything.

Imaginary template language:

<figure>
<@content@>
<div caption><@caption@></div>
</figure>

Does everything you could do with a new element. Almost everyone else will  
probably get by without wrapping divs though.

> Limiting the caption attribute to just the p element, or just div or  
> something, might help, but I'd still expect authors to end up using it  
> on other elements anyway.
>
> There are only 2 sensible options for element choices: <legend> or  
> introducing a new element.  Using dt/dd is *not* and was never a  
> sensible choice for figure, and the idea must be dropped.
>
> Since Hixie is adamant that introducing a new element for the caption  
> isn't going to happen, and I've yet to find a way to convince him  
> otherwise, that leaves us with legend.
>
> Although legend has it's own styling issues in browsers, these will  
> eventually be resolved in a couple of years.  Therefore, the best  
> solution is to revert the spec back to using legend for figure, but  
> strongly discourage authors from using these new elements yet, until the  
> implementation issues are resolved.
>

If all of the ideas are rejected I agree that it would be better to drop  
figure, but I hope it won't come to that. A pointer to any parsing/styling  
issues of legend would be appreciated for reference.

-- 
Philip J?genstedt
Core Developer
Opera Software

From philipj at opera.com  Tue Dec  1 07:39:53 2009
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 01 Dec 2009 16:39:53 +0100
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <op.u39myiceatwj1d@sisko.linkoping.osa>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<op.u39myiceatwj1d@sisko.linkoping.osa>
Message-ID: <op.u39m4rtlatwj1d@sisko.linkoping.osa>

On Tue, 01 Dec 2009 16:36:08 +0100, Philip J?genstedt <philipj at opera.com>  
wrote:

> You only need to provide styles for the elements you're using which  
> wouldn't work with a simple generic style such as.
>
> figure>[caption] { margin-left: 1em; font-weight: bold; }
>
> Please, no examples where this doesn't work. It's obvious, but also very  
> easy to fix.

Sent too early... this part is about author styles. I don't think there  
should be a default browser style at all.

-- 
Philip J?genstedt
Core Developer
Opera Software

From kornel at geekhood.net  Tue Dec  1 08:03:47 2009
From: kornel at geekhood.net (=?UTF-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Tue, 1 Dec 2009 16:03:47 +0000
Subject: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
In-Reply-To: <7789133a0912010705h5895b205p7fc1e8c4c44ab01c@mail.gmail.com>
References: <7789133a0911301555k60e48190k24df1fb23ec60406@mail.gmail.com>
	<BA03DC53-1DA2-460D-ADA3-BD0116735889@geekhood.net>
	<7789133a0912010705h5895b205p7fc1e8c4c44ab01c@mail.gmail.com>
Message-ID: <2502AF94-5039-4729-9C47-7489D06AB196@geekhood.net>


>> And even whitelist for CSS properties couldn't be used to implement  
>> "No
>> external access" policy (allow images with data: urls, allow http:  
>> links,
>> but not http: images). This would be useful for webmails and other  
>> places
>> where website doesn't want to allow 3rd parties tracking views.
>
> I don't think an no external access policy is worth supporting
> explicitly.  If it falls out of a general design, that's great, but I
> don't think the use case is compelling enough to accept the design
> constraints required to support it.

I think it is quite important for privacy. Otherwise "web bugs" can be  
placed and used to track every use of content in every mashup.

Most often I'd like formatted text in applications to be just text,  
_completely_ passive.

>> "No clickjacking" option might be useful as well.
>
> I don't have a clear idea how this would work.  Did you have something
> different in mind than X-Frame-Options (already supported by WebKit)?


On a second thought clickjacking is probably not the right term for  
what I have in mind, although it's a similar issue.

The problem is that content added in DOM could use styles to overlay  
web application's "chrome" and steal data with forms or redirect  
standard links/buttons to phising site, e.g. <form action=evil  
style="position:fixed; top:0; right:0"> that's positioned on top of  
website's standard login form.

Position:fixed escapes elements with  
"position:relative;overflow:hidden", so AFAIK this cannot be prevented  
without removal of all position:fixed styles from untrusted content.

Such hack has been used on auction site allegro.pl, where auctions'  
descriptions are allowed to use CSS. In that particular case content  
should have been filtered server-side, but I imagine webmails, web- 
based feed readers and all kinds of mashups dynamically loading  
untrusted content could face similar problems, and having <iframe> for  
every bit of content is sometimes problematic.

-- 
regards, Kornel


From whatwg at adambarth.com  Tue Dec  1 08:39:41 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Tue, 1 Dec 2009 08:39:41 -0800
Subject: [whatwg] updateWithSanitizedHTML (was Re: innerStaticHTML)
In-Reply-To: <2502AF94-5039-4729-9C47-7489D06AB196@geekhood.net>
References: <7789133a0911301555k60e48190k24df1fb23ec60406@mail.gmail.com> 
	<BA03DC53-1DA2-460D-ADA3-BD0116735889@geekhood.net>
	<7789133a0912010705h5895b205p7fc1e8c4c44ab01c@mail.gmail.com> 
	<2502AF94-5039-4729-9C47-7489D06AB196@geekhood.net>
Message-ID: <7789133a0912010839t4b637c7cj9834051e9d34a7f4@mail.gmail.com>

2009/12/1 Kornel Lesi?ski <kornel at geekhood.net>:
>>> And even whitelist for CSS properties couldn't be used to implement "No
>>> external access" policy (allow images with data: urls, allow http: links,
>>> but not http: images). This would be useful for webmails and other places
>>> where website doesn't want to allow 3rd parties tracking views.
>>
>> I don't think an no external access policy is worth supporting
>> explicitly. ?If it falls out of a general design, that's great, but I
>> don't think the use case is compelling enough to accept the design
>> constraints required to support it.
>
> I think it is quite important for privacy. Otherwise "web bugs" can be
> placed and used to track every use of content in every mashup.
>
> Most often I'd like formatted text in applications to be just text,
> _completely_ passive.

I agree that it's a nice benefit of some designs, but, in my opinion,
it's not nearly as important as addressing the security issues.

More concretely, suppose you want to let folks include hyperlinks in
sanitized HTML, which I suspect many people will want to do.  You've
already lost the battle against web bugs because of DNS prefetch.

>>> "No clickjacking" option might be useful as well.
>>
>> I don't have a clear idea how this would work. ?Did you have something
>> different in mind than X-Frame-Options (already supported by WebKit)?
>
> On a second thought clickjacking is probably not the right term for what I
> have in mind, although it's a similar issue.
>
> The problem is that content added in DOM could use styles to overlay web
> application's "chrome" and steal data with forms or redirect standard
> links/buttons to phising site, e.g. <form action=evil style="position:fixed;
> top:0; right:0"> that's positioned on top of website's standard login form.
>
> Position:fixed escapes elements with "position:relative;overflow:hidden", so
> AFAIK this cannot be prevented without removal of all position:fixed styles
> from untrusted content.
>
> Such hack has been used on auction site allegro.pl, where auctions'
> descriptions are allowed to use CSS. In that particular case content should
> have been filtered server-side, but I imagine webmails, web-based feed
> readers and all kinds of mashups dynamically loading untrusted content could
> face similar problems, and having <iframe> for every bit of content is
> sometimes problematic.

I agree that this is a threat worth addressing.  That's one reason why
an API that blocks only script is insufficient for inline use cases.
Notice that my proposal does mitigate this threat.

Adam

From hugh.guiney at gmail.com  Tue Dec  1 16:01:56 2009
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Tue, 1 Dec 2009 19:01:56 -0500
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <op.u39m4rtlatwj1d@sisko.linkoping.osa>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au> 
	<op.u39myiceatwj1d@sisko.linkoping.osa>
	<op.u39m4rtlatwj1d@sisko.linkoping.osa>
Message-ID: <2a1386f80912011601k65601884r39d699f97b901f9a@mail.gmail.com>

Is there a reason we can't reuse <legend> (or <label>)? I don't think
giving <p> an attribute that it can only use inside of <figure> is
very straightforward.

From jackalmage at gmail.com  Tue Dec  1 16:08:48 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 1 Dec 2009 18:08:48 -0600
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <2a1386f80912011601k65601884r39d699f97b901f9a@mail.gmail.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<op.u39myiceatwj1d@sisko.linkoping.osa>
	<op.u39m4rtlatwj1d@sisko.linkoping.osa>
	<2a1386f80912011601k65601884r39d699f97b901f9a@mail.gmail.com>
Message-ID: <dd0fbad0912011608t7d5e8bd5pa8c251e130d067ce@mail.gmail.com>

On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> Is there a reason we can't reuse <legend> (or <label>)? I don't think
> giving <p> an attribute that it can only use inside of <figure> is
> very straightforward.

Yes.  <legend> is documented as having rendering issues in all current
browsers if placed outside of a <fieldset> (for example, in some
browsers it will *generate a fieldset* around itself).  <label>
doesn't have appropriate keyboard accessibility when used for
<details>.

The @caption proposal isn't for an attribute on <p> only, but rather
for an attribute on any element that is a child of a <figure>.  (It's
just that most of the time using a <p> is most appropriate.)

~TJ

From ian at hixie.ch  Tue Dec  1 17:58:50 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 2 Dec 2009 01:58:50 +0000 (UTC)
Subject: [whatwg] [WebWorkers] Advocation to provide the DOM API to the
 workers
In-Reply-To: <4AFCC2A0.1030202@enseirb-matmeca.fr>
References: <4AFCC2A0.1030202@enseirb-matmeca.fr>
Message-ID: <Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com>

On Thu, 12 Nov 2009, David Bruant wrote:
>
> I was waiting for Firefox to stop freezing on the HTML5 spec page (it 
> freezes about one minute each time I visit the one-page version) and I 
> tried to think of a way to "design" this page in a way that wouldn't 
> freeze my browser.

The easiest way is to disable the scripts, which you can do by appending 
?slow-browser to the page's URL, as in:

   http://www.whatwg.org/specs/web-apps/current-work/?slow-browser


> One good way I have found would be to cut the whole page into several 
> parts (one the server side, what is already done in the multi-page 
> version) and to launch several workers. Each worker gets one part of the 
> whole page in the background and could give it to the browsing context 
> which will append the right part at the right place.

As others have noted, the slowness turns out to not be parsing, but to be 
a bunch of scripts that are doing various things such as adding the 
sidebar annotations, setting up the <dfn> cross-references, and generating 
the short table of contents.

Plus, since browsers don't have thread-safe DOM implementations, we 
actually can't expose the DOM in workers. Maybe one day. :-)

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

From mjs at apple.com  Tue Dec  1 18:58:32 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 01 Dec 2009 18:58:32 -0800
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <dd0fbad0912011608t7d5e8bd5pa8c251e130d067ce@mail.gmail.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<op.u39myiceatwj1d@sisko.linkoping.osa>
	<op.u39m4rtlatwj1d@sisko.linkoping.osa>
	<2a1386f80912011601k65601884r39d699f97b901f9a@mail.gmail.com>
	<dd0fbad0912011608t7d5e8bd5pa8c251e130d067ce@mail.gmail.com>
Message-ID: <5234A34D-42B7-4E4E-A1EB-367192BB4F72@apple.com>


On Dec 1, 2009, at 4:08 PM, Tab Atkins Jr. wrote:

> On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney <hugh.guiney at gmail.com>  
> wrote:
>> Is there a reason we can't reuse <legend> (or <label>)? I don't think
>> giving <p> an attribute that it can only use inside of <figure> is
>> very straightforward.
>
> Yes.  <legend> is documented as having rendering issues in all current
> browsers if placed outside of a <fieldset> (for example, in some
> browsers it will *generate a fieldset* around itself).  <label>
> doesn't have appropriate keyboard accessibility when used for
> <details>.

It's not just rendering issues - all current browsers produce a broken  
DOM when you include <legend> outside of <fieldset>, ranging from  
dropping the <legend> element entirely to creating a fieldset to doing  
the IE thing of adding void elements named "legend" and "/legend" (but  
without the usual script workaround.

I don't think keyboard accessibility is a problem for <label>.  
<details> itself can be made focusable. I believe the only technical  
issues with <label> are:

1) Some sites already have style rules for <label> based on the  
assumption that it is only ever used for form labels. So they would  
have to tweak their CSS to be able to use <details>. I don't think  
this argument is very strong.

2) Using <label> could create issues in present-day browsers if the  
label includes a form control. Specifically the label would be  
considered the label of the form control if it has no other label,  
which may not be appropriate. This is somewhat unlikely but not  
altogether impossible.

Opinions on the seriousness of these two issues vary, but I must  
concede that the dt/dd solution does not have these two specific  
problems.

BTW the current alternate proposal in the HTML Working Group is to  
replace <dt>/<dd> with a <fltcap> element to use as the label for both  
<figure> and <details>: <http://esw.w3.org/topic/HTML/ChangeProposals/DdDt 
 >.

Regards,
Maciej


From ian at hixie.ch  Tue Dec  1 21:17:13 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 2 Dec 2009 05:17:13 +0000 (UTC)
Subject: [whatwg] Interface objects in Web Workers
In-Reply-To: <op.u3yihuocidj3kv@zcorpandell.linkoping.osa>
References: <op.u3yihuocidj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0912020458010.15540@hixie.dreamhostps.com>

On Wed, 25 Nov 2009, Simon Pieters wrote:
>
> The "Interface objects and constructors" section says
> 
> "There must be no interface objects and constructors available in the 
> global scope of scripts whose script's global object is a 
> WorkerGlobalScope object except for the following:"
> 
> WorkerGlobalScope, WorkerLocation, Navigator, AbstractWorker, ErrorEvent 
> are not in the list. Is this intentional? If they're intended to not 
> create interface objects, it would be clearer if the IDLs had 
> [NoInterfaceObject].

I've changed that section to be more precise legalese that automatically 
does the right thing.


> Should EventTarget and Event be in the list?

These are now automatically covered by the new magical text in the 
aforementioned section. (Basically I said that any interfaces relevant to 
exposed APIs are automatically to be available.)

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

From ian at hixie.ch  Tue Dec  1 21:36:17 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 2 Dec 2009 05:36:17 +0000 (UTC)
Subject: [whatwg] createEvent() in Web Workers?
In-Reply-To: <op.u3ztbcjvidj3kv@simon-pieterss-macbook.local>
References: <op.u3ztbcjvidj3kv@simon-pieterss-macbook.local>
Message-ID: <Pine.LNX.4.62.0912020519040.15540@hixie.dreamhostps.com>

On Thu, 26 Nov 2009, Simon Pieters wrote:
>
> There's ErrorEvent.initErrorEvent, and dispatchEvent is exposed in 
> workers, but there's no createEvent (because there's no document). Are 
> there use cases for sending events in a worker? Should we expose 
> createEvent somewhere? Should we remove initErrorEvent?

I don't want to remove initErrorEvent() because that would just cause 
troubles later if we ever add createEvent().

In the meantime, though, I don't see a really compelling reason to add 
event creation to the worker API set, so I haven't changed anything there 
for now. If DOM3 Events adds constructors or whatever, it can expose them 
to Workers easily enough.

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

From hugh.guiney at gmail.com  Wed Dec  2 00:58:50 2009
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Wed, 2 Dec 2009 03:58:50 -0500
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <5234A34D-42B7-4E4E-A1EB-367192BB4F72@apple.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au> 
	<op.u39myiceatwj1d@sisko.linkoping.osa>
	<op.u39m4rtlatwj1d@sisko.linkoping.osa> 
	<2a1386f80912011601k65601884r39d699f97b901f9a@mail.gmail.com> 
	<dd0fbad0912011608t7d5e8bd5pa8c251e130d067ce@mail.gmail.com> 
	<5234A34D-42B7-4E4E-A1EB-367192BB4F72@apple.com>
Message-ID: <2a1386f80912020058r2f229823u2c98ae2da520bd11@mail.gmail.com>

On Tue, Dec 1, 2009 at 7:08 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> The @caption proposal isn't for an attribute on <p> only, but rather
> for an attribute on any element that is a child of a <figure>.  (It's
> just that most of the time using a <p> is most appropriate.)

Ah, OK. Well, given the circumstances, this does seem like the best
approach, though I feel conditionally allowing certain attributes
depending on an element's context is a step in the wrong direction.
It's confusing given the way HTML will have worked up until that
point; as a document author, although I expect elements themselves
only to be allowed in certain contexts, I also expect them to carry
all of their attributes with them when they are; i.e., attributes are
perceived as belonging to the element within which they are set, not
the parent of that element.

Most of us agree that a more semantic element would be ideal here, yet
we can't use one [yet] because of current technical limitations. That
sounds like the very situation microformats was created to address.
What if we used @itemprop as a placeholder for a future figure-caption
element? To make things less verbose, <figure> could have an implied
@itemscope and @itemtype unless specifically overwritten by the
author.

Ex:

<figure>
<img src="figure.gif" alt="graph">
<p itemprop="caption">The findings</p>
</figure>

On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> It's not just rendering issues - all current browsers produce a broken DOM
> when you include <legend> outside of <fieldset>, ranging from dropping the
> <legend> element entirely to creating a fieldset to doing the IE thing of
> adding void elements named "legend" and "/legend" (but without the usual
> script workaround.

Is this issue being addressed by the latest DOM specification? It
seems there should really be a standard behavior for browsers when
encountering unknown or unexpected elements that ensures that the next
version of HTML is not similarly encumbered by this.

From mjs at apple.com  Wed Dec  2 01:03:25 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 02 Dec 2009 01:03:25 -0800
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <2a1386f80912020058r2f229823u2c98ae2da520bd11@mail.gmail.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<op.u39myiceatwj1d@sisko.linkoping.osa>
	<op.u39m4rtlatwj1d@sisko.linkoping.osa>
	<2a1386f80912011601k65601884r39d699f97b901f9a@mail.gmail.com>
	<dd0fbad0912011608t7d5e8bd5pa8c251e130d067ce@mail.gmail.com>
	<5234A34D-42B7-4E4E-A1EB-367192BB4F72@apple.com>
	<2a1386f80912020058r2f229823u2c98ae2da520bd11@mail.gmail.com>
Message-ID: <50FEC837-9AAA-49B1-AD9E-3D7E052956C2@apple.com>


On Dec 2, 2009, at 12:58 AM, Hugh Guiney wrote:

>
> On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>> It's not just rendering issues - all current browsers produce a  
>> broken DOM
>> when you include <legend> outside of <fieldset>, ranging from  
>> dropping the
>> <legend> element entirely to creating a fieldset to doing the IE  
>> thing of
>> adding void elements named "legend" and "/legend" (but without the  
>> usual
>> script workaround.
>
> Is this issue being addressed by the latest DOM specification? It
> seems there should really be a standard behavior for browsers when
> encountering unknown or unexpected elements that ensures that the next
> version of HTML is not similarly encumbered by this.

HTML5 parsing requirements will fix this both for <legend> and for  
unknown elements.

For what it's worth, all non-IE browsers handle unknown elements in a  
consistent way, and IE can be made to do so by first creating an  
instance of said element in script. <legend> is not a new element  
though, it has a longstanding use in <fieldset> many of it's  
particular oddities stem from the fact that browsers have only  
expected it to appear inside <fieldset>, where it has specialized  
rendering.

Regards,
Maciej


From simonp at opera.com  Wed Dec  2 01:11:08 2009
From: simonp at opera.com (Simon Pieters)
Date: Wed, 02 Dec 2009 10:11:08 +0100
Subject: [whatwg] <figure><img><* caption>
In-Reply-To: <5234A34D-42B7-4E4E-A1EB-367192BB4F72@apple.com>
References: <op.u370v5d3sr6mfa@nog> <4B151A00.1030602@lachy.id.au>
	<op.u39myiceatwj1d@sisko.linkoping.osa>
	<op.u39m4rtlatwj1d@sisko.linkoping.osa>
	<2a1386f80912011601k65601884r39d699f97b901f9a@mail.gmail.com>
	<dd0fbad0912011608t7d5e8bd5pa8c251e130d067ce@mail.gmail.com>
	<5234A34D-42B7-4E4E-A1EB-367192BB4F72@apple.com>
Message-ID: <op.u4azsubtidj3kv@simon-pieterss-macbook.local>

On Wed, 02 Dec 2009 03:58:32 +0100, Maciej Stachowiak <mjs at apple.com>  
wrote:

>
> On Dec 1, 2009, at 4:08 PM, Tab Atkins Jr. wrote:
>
>> On Tue, Dec 1, 2009 at 6:01 PM, Hugh Guiney <hugh.guiney at gmail.com>  
>> wrote:
>>> Is there a reason we can't reuse <legend> (or <label>)? I don't think
>>> giving <p> an attribute that it can only use inside of <figure> is
>>> very straightforward.
>>
>> Yes.  <legend> is documented as having rendering issues in all current
>> browsers if placed outside of a <fieldset> (for example, in some
>> browsers it will *generate a fieldset* around itself).  <label>
>> doesn't have appropriate keyboard accessibility when used for
>> <details>.
>
> It's not just rendering issues - all current browsers produce a broken  
> DOM when you include <legend> outside of <fieldset>, ranging from  
> dropping the <legend> element entirely to creating a fieldset to doing  
> the IE thing of adding void elements named "legend" and "/legend" (but  
> without the usual script workaround.
>
> I don't think keyboard accessibility is a problem for <label>. <details>  
> itself can be made focusable. I believe the only technical issues with  
> <label> are:
>
> 1) Some sites already have style rules for <label> based on the  
> assumption that it is only ever used for form labels. So they would have  
> to tweak their CSS to be able to use <details>. I don't think this  
> argument is very strong.
>
> 2) Using <label> could create issues in present-day browsers if the  
> label includes a form control. Specifically the label would be  
> considered the label of the form control if it has no other label, which  
> may not be appropriate. This is somewhat unlikely but not altogether  
> impossible.

3) If <label> were used for the caption, it would not be possible to use  
<label> as a form control label inside the figure caption (use case: "hot  
or not").

4) If <label> were used for the caption, it would not be possible to use  
<label> as the figure content (can't think of a compelling use case for  
this, but it's currently allowed).


> Opinions on the seriousness of these two issues vary, but I must concede  
> that the dt/dd solution does not have these two specific problems.
>
> BTW the current alternate proposal in the HTML Working Group is to  
> replace <dt>/<dd> with a <fltcap> element to use as the label for both  
> <figure> and <details>:  
> <http://esw.w3.org/topic/HTML/ChangeProposals/DdDt >.
>
> Regards,
> Maciej
>


-- 
Simon Pieters
Opera Software

From ian at hixie.ch  Wed Dec  2 02:06:34 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 2 Dec 2009 10:06:34 +0000 (UTC)
Subject: [whatwg] localStorage feedback
In-Reply-To: <5dd9e5c50911251156m6ed5fdedt26ca7d1c7354eb85@mail.gmail.com>
References: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> 
	<Pine.LNX.4.62.0911251107210.10133@hixie.dreamhostps.com>
	<4B0D6663.7080908@mit.edu>
	<5dd9e5c50911251156m6ed5fdedt26ca7d1c7354eb85@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912020537520.15540@hixie.dreamhostps.com>


Summary: I haven't removed the storage mutex, but I did adjust when it is 
released slightly to handle some cases that had been missed before.

On Thu, 29 Oct 2009, Darin Fisher wrote:
> On Mon, Oct 12, 2009 at 7:07 PM, Ian Hickson <ian at hixie.ch> wrote:
> > >
> > > the problem here is that localStorage is a pile of global variables. 
> > > we are trying to give people global variables without giving them 
> > > tools to synchronize access to them.  the claim i've heard is that 
> > > developers are not savy enough to use those tools properly.  i agree 
> > > that developers tend to use tools without fully understanding them.  
> > > ok, but then why are we giving them global variables?
> >
> > The global variables have implicit locks such that you can build the 
> > tools for explicit locking on top of them:
> >
> >   // run this first, in one script block
> >   var id = localStorage['last-id'] + 1;
> >   localStorage['last-id'] = id;
> >   localStorage['email-ready-' + id] = "0"; // "begin"
> >
> >   // these can run each in separate script blocks as desired
> >   localStorage['email-subject-' + id] = subject;
> >   localStorage['email-from-' + id] = from;
> >   localStorage['email-to-' + id] = to;
> >   localStorage['email-body-' + id] = body;
> >
> >   // run this last
> >   localStorage['email-ready-' + id] = "1"; // "commit"
>
> Dividing up work like this into separate SCRIPT elements to scope the 
> locking seems really awkward to me.

Oh I agree, I'm just saying that your original point -- that we are trying 
to give people global variables without giving them tools to synchronize 
access to them -- is mistaken insofar as we _are_ trying to give them 
tools to synchronise access, that's what this whole thread is basically 
about. It just happens that those tools have unfortunate side-effects 
(they can require synchronous blocking of other processes running code for 
the same domain).


> > > The current API exposes race conditions to the web.  The implicit 
> > > dropping of the storage lock is that.  In Chrome, we'll have to drop 
> > > an existing lock whenever a new lock is acquired.  That can happen 
> > > due to a variety of really odd cases (usually related to nested 
> > > loops or nested JS execution), which will be difficult for 
> > > developers to predict, especially if they are relying on third-party 
> > > JS libraries.
> > >
> > > This issue seems to be discounted for reasons I do not understand.
> >
> > You can only lose the lock in very specific conditions. Those 
> > conditions are rarely going to interact with code that actually does 
> > storage work in a way that relies on the lock:
> >
> >  - changing document.domain
> >  - history.back(), .forward(), .go(n)
> >  - invoking a plugin
> >  - alert(), confirm(), prompt(), print()
> >  - showModalDialog()
> >  - yieldForStorageUpdates()
> >
> > I discussed this in more detail here: 
> > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html
>
> You are right that the conditions are specific, but I don't know that 
> that is the exhaustive list.

If it's not, then we should fix it.


> Rather than defining unlock points, I would implement implicit unlocking 
> by having any nested attempt to acquire a lock cause the existing lock 
> to be dropped. Nesting can happen in the cases you mention, but 
> depending on the UA, it may happen for other reasons too.

I don't think this is equivalent at all. Most of the release points are 
points where the thread is about to hang (sync XHR, alert(), etc) and we 
want to unlock other processes. The plugin case is about third-party code 
causing a deadlock through undetectable thread synchronisation (e.g. where 
a plugin causes code in another process to try to grab the lock and waits 
for that to complete before handing control back to the UA). The nesting 
defence only helps in the case of preventing deadlocks with two processes 
trying to grab different domains' locks in reverse order from each other, 
as far as I can tell, which is just a subset of the cases where it is 
released per the spec.


> This combined with the fact that most people use JS libraries means that 
> the coder is not going to have an easy time knowing when these specific 
> conditions are met.  I don't think defining a set of allowed unlock 
> points is sufficient to make this API not be a minefield for users.

I don't think anyone is arguing that this is ideal. I do think it's orders 
of magnitude better than having the API be always racy even without any 
libraries being involved.



> For example, a JS library might evolve to use flash for something small 
> (like storage or sound) that it previously didn't use when I first 
> developed my code. Voila, now my storage lock is released out from under 
> me.

At least this is documentable.


On Sat, 31 Oct 2009, Darin Fisher wrote:
> 
> Unlock if yieldForStorageUpdates is called.
> Unlock when returning from script execution.
> Unlock if another attempt to lock occurs (any form of nesting).
> 
> In the third case, I'd probably log something to the JS console to alert 
> developers.

You'll also need to unlock for cases like alert(), prompt(), sync XHR, and 
so on (the enumerated cases above that temporarily hang the thread).

This seems like a fine implementation strategy. Please let me know if you 
find any cases where it happens other than those in the spec though.


> So, we are currently on track to support this feature without locking.  
> In the future, we might add locking.  I've also considered other 
> solutions, like copy-on-write, which could obviously lead to data loss, 
> but at least it would ensure stability/consistency within a scripts 
> execution.  I would like it if the spec were open to such 
> implementations.

The spec would either require such behaviour or not; I don't think we 
should explicitly allow multiple different (non-interoperable) behaviours. 
That's worse than the race conditions, IMHO.


On Mon, 2 Nov 2009, Robert O'Callahan wrote:
> 
> I think this would make the spec too dependent on implementation 
> details. If your implementation needlessly or accidentally "nests" 
> script execution --- e.g. by firing an event synchronously that should 
> be, or could be, asynchronous --- then you'd still conform to your spec 
> while the behaviour you present to authors gets quietly worse.
> 
> If your description is (or can be, after suitable modifications) 
> equivalent to what the spec currently says, but the equivalence is 
> subtle (which it would be!), then I think they should *both* be in the 
> spec, and the spec should say they're equivalent. Then if we find 
> they're not equivalent, we clearly have a bug in the spec which must be 
> fixed --- not carte blanche to proceed in an undesirable direction. It 
> would be a sort of spec-level assertion.

I would rather not require potentially conflicting things in the spec. 
Historically, I've found that people tend to just ignore one of the 
requirements (picking whichever one is most convenient for them to ignore) 
and not report it.


On Mon, 2 Nov 2009, Darin Fisher wrote:
> 
> I think the spec currently calls attention to only some situations that 
> could lead to nesting of implicitly acquired storage locks.
>
> I previously described some other situations, which you and others 
> indicated should be treated as WebKit and IE bugs.  I didn't look very 
> far to dig those up.  After some more thought, I came up with these 
> additional cases that the spec doesn't cover:
> 
> 1a) Given a page (domain A) containing an iframe (domain B), have the 
> outer page navigate the inner frame to "about:blank".  This navigation 
> completes synchronously, and the unload handler for the iframe runs 
> before the navigation request completes.  This is true of all browsers.

Good point. I've made the navigation algorithm release the mutex, and made 
some related changes to make sure that all synchronous events are 
similarly safe. (To make things easier to reason about, I also made all 
history.go() calls and anything else that navigates the history simply 
always release the mutex.)


> 1b) Suppose the inner page has a pending XMLHttpRequest when the outer 
> frame navigates the inner frame.  The XHR's onabort handler would run 
> before the navigation to "about:blank" completes.

Per XHR2, the 'abort' event doesn't fire in this case.


> 2) Set a break point in the Mozilla JS debugger.  This runs a nested 
> event loop each time you single step so that it can drive the rest of 
> the browser UI.
> 3) Install a Firefox extension that runs a nested event loop in response 
> to an event generated by content.  I debugged many Firefox crashes 
> resulting from extensions that do this kind of thing for various 
> reasons.

Both of these are non-conforming situations. There's a whole bunch of 
situations that act differently under the debugger; releasing the storage 
mutex in those cases is a UA-specific behaviour and is the least of your 
problems as a programmer.


> It seems odd to me that this behavior was put into the spec without any 
> implementation experience to guide it.  The only multi-process 
> implementations that I know of do not have a storage mutex.

Implementation experience _did_ guide it. In fact, that is pretty much the 
only reason this is in the spec.


On Tue, 3 Nov 2009, Darin Fisher wrote:
> 
> Will we just keep amending the spec each time we find such a possible 
> case?

Yes.


> I think it is far saner to say that any nesting leads to unlocking the 
> storage mutex.  The spec can then list cases where this nesting might 
> occur.

It wouldn't make sense to spec it that way. The spec just has one mutex, 
it's not per-origin -- that you can implement it per-domain is an 
optimisation that is enabled by design, but it isn't how the spec defines 
it. So you can never block, the way the spec is written (since there's no 
way to ever do a synchronisation of multiple processes).

In addition, as mentioned above, the storage mutex is released in many 
cases other than just those that could lead to a thread grabbing the mutex 
on behalf of two origins at once.

I guess I could add a note in the "obtain the storage mutex" algorithm 
saying that if the UA implements the storage mutex per-origin, then it 
should never be able to reach this algorithm while holding the mutex from 
an origin different than the one it's about to try to grab. Would that 
help? I'm not sure it makes sense to say that, though, given the lack of 
per-origin mutexes in the spec.


> >> 2) Set a break point in the Mozilla JS debugger.  This runs a nested 
> >> event loop each time you single step so that it can drive the rest of 
> >> the browser UI.
> >>
> >> 3) Install a Firefox extension that runs a nested event loop in 
> >> response to an event generated by content.  I debugged many Firefox 
> >> crashes resulting from extensions that do this kind of thing for 
> >> various reasons.
> >
> > These are internal Mozilla issues and should not be allowed to 
> > influence the design of the Web platform. They'll probably change for 
> > multi-process anyway.
> 
> OK, but my point is that the spec should afford implementors with the 
> ability to unlock the storage mutex at other times for reasons not 
> mentioned in the spec.

How do we do that without making the mutex-free implementation correct?


> OK. Please note my objection to the storage mutex.

I think everyone objects to the storage mutex. The problem is we have 
nothing better. Race conditions aren't better.


On Tue, 3 Nov 2009, Jeremy Orlow wrote:
> 
> If we do this, we need to re-visit ways that scripts can tell whether 
> the lock has been dropped.  I can't remember which idea was most in 
> favor last time we talked about it, but a counter that increments every 
> time LocalStorage is unlocked sticks out in my mind.  (Scripts can check 
> the counter, do something that could cause unlocking, and then verify 
> the counter is still the same after.)

The counter could be a boolean -- does the event loop have the lock [for 
the origin of the first script]. I would recommend implementing this as 
a property window.navigator.webkitStorageUpdatesLocked which is true when 
the lock is obtained and false when it is released. If people find it 
useful, we can add it to the language.


> Another option that just came to mind is to have some flag that says 
> "throw an exception whenever there's been a serialization violation".

Could you elaborate on this?


On Wed, 4 Nov 2009, Rob Ennals wrote:
> 
> How about this for a solution for the localStorage mutex problem:
> 
> "the user agent MAY release the storage mutex on *any* API operation 
> except localStorage itself"
> 
> This guarantees that the common case of "several storage operations in a 
> row with nothing in-between" works, but gives the implementors the 
> freedom to release the storage mutex wherever else they find they need 
> to.
> 
> I ran this by a few people at the W3C tpac (where I am now) and everyone 
> I talked to seemed to think this would work.

On Thu, 5 Nov 2009, Jeremy Orlow wrote:
>
> Leaving the language open might not be terribly useful to a typical web 
> developer since they're not going to read the spec and probably aren't 
> going to have a very firm idea of whether what they're doing could 
> unlock storage or not.  Experimentation wouldn't work very well since 
> each platform could be wildly different (since a lot of possible 
> behaviors fall between the MAY and the MAY NOT in the proposed spec).
> 
> Another concern is that the worst case performance aspects of 
> LocalStorage remain.  I cringe every time I think of one event loop 
> blocking another.
>
> But I will admit that the average time would be better--especially if 
> we're unlocking fairly aggressively.

On Sat, 7 Nov 2009, Chris Jones wrote:
> 
> IMHO, this is actually worse than the current proposal of a global mutex 
> :S. This proposal makes atomicity guarantees not only library-dependent, 
> but browser-implementation-dependent.  For example
> 
>   a = localStorage.x()
>   jquery.foo()
>   b = localStorage.y()
> 
> If |jquery.foo()| were, say, parsing JSON or determining selector 
> matching, it might involve "browser API calls" in some browser, and in 
> others not.
> 
> Worse, if |jquery.foo()| involves accessing browser-managed things like 
> computed DOM attributes, then even in the *same* browser it might result 
> in sometimes needing a "browser API call", and sometimes only needing a 
> JS-only call.  (Depending on DOM attribute cache status, if present.)
> 
> This of course of depends on the definition of "browser API call", but I 
> interpret this as approximately meaning "calling from JS to C++".
> 
> These objections are in addition to those made by Jeremy Orlow 
> concerning a script-managed, possibly cross-process mutex, which I also 
> find unpleasant.

On Sun, 8 Nov 2009, Adam Barth wrote:
> 
> As I mentioned to Ian at TPAC, one way to make this more predictable is 
> to release the lock on *every* function call and return.  This provides 
> content enough atomicity to build whatever locks it needs.

On Mon, 9 Nov 2009, Robert O'Callahan wrote:
> 
> Then simple refactorings that should be semantics-preserving --- like 
> extracting a block of code into a shared function --- would break 
> atomicity. This also places a new burden on JS implementations.

On Mon, 23 Nov 2009, Rob Ennals wrote:
>
> The planned model is that if you don't want to lose the storage mutex 
> then you shouldn't call any code that you didn't write yourself. Any 
> external library (e.g. jquery) should be assumed to release the storage 
> mutex. Perhaps that should be made explicit in the spec?
> 
> We want to guarantee essential things like "several localStorage ops in 
> a row are atomic", and make sure any language-level transformations that 
> people expect to be semantics preserving remain so (e.g. moving code 
> into a function), while still giving the browser the ability to release 
> the mutex whenever it might need to.

On Tue, 24 Nov 2009, Rob Ennals wrote:
>
> Yes. I think that *any* DOM operation, including getElementById should 
> be allowed to release the storage mutex. If we start specifying 
> particular categories of API that do or do not release the mutex then 
> thing will just get confusing, or we will find that we have missed 
> something important.
> 
> The basic rule of thumb should be that if you want to do an atomic 
> storage operation then you do the following:
> 
> 1.) Gather all the data that you want to use in your storage transaction 
> (using whatever DOM call you need)
>
> 2.) Perform a sequence of storage operations, not interrupted by any 
> calls to any API or external library.
> 
> This is consistent with the way that systems programmers write 
> concurrent sections. You gather all your data using whatever 
> potentially-blocking APIs you need (e.g. opening files), and then hold 
> your lock for as brief a period of time as possible while doing the 
> updates you need.
> 
> If you run your browser in "super-warnings-enabled" mode then you could 
> have it warn you if you did anything remotely suspect between calls to 
> localStorage (e.g. calling a function defined by an external javascript 
> file or calling an API).
> 
> As you say, from a programmers point of view, it would be much nicer if 
> programmers could use whatever APIs they liked, without having to worry 
> about losing the storage mutex, however, as we have seen earlier in this 
> list, that isn't something that the browser vendors believe they can 
> implement. Some operations unavoidably *have* to release the storage 
> mutex, and it is surprisingly difficult to specify what operations these 
> are, or when they might be called.
> 
> If we are going to fix the current spec, and give users something that 
> they can understand, then I see little alternative but to tell them that 
> *all* APIs and external libraries may release the storage mutex. It 
> isn't perfect, but it does at least give users an invariant that they 
> can understand, that they can be sure will always hold, and that can be 
> implemented by all browsers. Moreover, it allows a programmer to do 
> essential basic things like implement a test and set lock.

On Tue, 24 Nov 2009, Jonas Sicking wrote:
> 
> It seems to me that the only difference between what we have now (in the 
> spec), and your suggestion, would be that implementations could in more 
> cases claim to follow the spec. I.e. the only difference seems to be one 
> of PR for implementations. Nothing that would actually help web authors.

On Tue, 24 Nov 2009, Boris Zbarsky wrote:
> On 11/24/09 7:46 PM, Rob Ennals wrote:
> > E.g., I may want to write:
> > 
> > x = localStorage.bla
> > localStorage.bla = x+1
> 
> If that's happening at global scope, the latter line involves global 
> variable access, which involves DOM operations (in particular, looking 
> for windows of that name), no?

On Tue, 24 Nov 2009, Rob Ennals wrote:
>
> Yeah. Such things could be confusing. Perhaps we would want to 
> explicitly specify that global variable access does not release the 
> storage mutex (I'm assuming there is no reason you would ever want it to 
> do so?).
> 
> More generally, the basic principle of this proposal is to specify what 
> *doesn't* release the storage mutex, rather than specifying what *does*, 
> since previous efforts to enumerate everything that releases the storage 
> mutex seem to have got stuck.

On Tue, 24 Nov 2009, Mike Shaver wrote:
>
> How would the browser distinguish between
> 
> storage-operation-1
> inadvertent-API-call
> storage-operation-2-that-should-be-atomic-with-1
> 
> and
> 
> storage-operation-1
> API-calls-to-gather-data-for-another-transaction
> storage-operation-2-that-is-unrelated-to-1
> 
> ?  Seems like that's a necessary distinction if it's not to just warn 
> all over the place uselessly!

On Tue, 24 Nov 2009, Rob Ennals wrote:
> 
> I can imagine that this could get particularly noisy if you use a 
> library which decides to use localStorage itself, and so you aren't 
> aware that localStorage has been used previously elsewhere.
> 
> One simple fix to avoid these warnings would be to introduce two 
> functions, startAtomic and endAtomic, that a user uses to explicitly 
> declare what they think is atomic. startAtomic declares that you are 
> starting an atomic localStorage section, and returns a token. endAtomic 
> declares that you are ending an atomic localStorage section, and takes 
> the token as an argument.
> 
> All localStorage that isn't between startAtomic and endAtomic is assumed 
> to be part of the same atomic transaction. The only reason to use 
> startAtomic and endAtomic is to suppress warnings by making it clear 
> that things are *intended* to be part of different atomic blocks. They 
> would typically be used only in libraries, and not by a user's own code.

On Wed, 25 Nov 2009, Mike Shaver wrote:
> On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson <ian at hixie.ch> wrote:
> > Reading or writing a property on a native object doesn't do it, so
> >
> > ? window['x'].document.forms['y'].value = 'foo';
> >
> > ...doesn't release the mutex, though this (identical code) would:
> >
> > ? window['x'].document.forms.namedItem('y').value = 'foo';
> >
> > ...because of namedItem() call.
> 
> I don't think that we can reasonably expect web developers to do that 
> kind of analysis, since they are likely to be working through libraries 
> and other sources of indirection.
> 
> (Especially since I bet there is a lot of documentation describing those 
> two cases as being entirely identical in behaviour.)

On Wed, 25 Nov 2009, Boris Zbarsky wrote:
> On 11/25/09 6:20 AM, Ian Hickson wrote:
> >     - script calling a method implemented in native code on a host object
> 
> If this is a MUST, this seems like a possible compat issue depending on 
> whether the method is native or library-provided, at the very least. 
> There's also been talk at least in Gecko of self-hosting some DOM 
> methods in JS (e.g. getElementById), at which point they will no longer 
> be implemented in native code.
> 
> I'm not sure this is a fatal issue (and I haven't been following this 
> thread closely enough in general to be sure of anything); just pointing 
> out that it's an issue.

On Wed, 25 Nov 2009, Darin Fisher wrote:
> 
> I had a similar thought as it pertains to Chrome.  I also worry about 
> having to do some "storage mutex" processing for every native call.  
> That seems like unfortunate overhead.

On Wed, 25 Nov 2009, Jeremy Orlow wrote:
> 
> Good point.  So even if it's a MUST, it'll be dependent on the platform. 
> And thus not terribly "standard".
> 
> I'd say the current language is better than this proposed change.

I've left the spec as is, since Rob's proposal didn't get a good 
reception.


On Wed, 25 Nov 2009, Jeremy Orlow wrote:
> 
> I know that we've discussed approximations of run to completion before, 
> but maybe it's worth one more shot:  What if on the first use of 
> document.cookie or local storage we took a snapshot of both and used 
> that during the task's execution.  All writes would be queued up until 
> the task finishes, at which point they'd be written to the central 
> version of the cookie and/or local storage.  This would provide a 
> consistent view of data for the duration of the task and would solve 
> almost all the atomicity problems except |document.cookie = 
> document.cookie + "foo";|.  For that, I'd suggest adding a method that 
> allows scripts to do atomic modifications to storage within a callback.
> 
> I can understand everyone's desire to have completely serializable 
> semantics for local storage access and cookies (if you don't count the 
> servers' interaction with them), but maybe we need to go back to use 
> cases.  In a world with WebDatabase/WebSimpleDB, I really don't see 
> anyone turning to LocalStorage except for more basic uses.  Most of 
> which I'm guessing need consistent reads much more than serialization of 
> everything.
> 
> And let's be realistic.  IE has had this problem with document.cookie 
> for a long time.  And IE8 now has this problem with localStorage.  
> Given that in the best case (MS and all others implement the storage 
> mutex) web developers will not be able to assume localStorage and 
> document.cookie access is atomic for many years at a minimum, I think 
> we're being pretty unrealistic about how much the storage mutex is going 
> to improve anyone's life.  Let's come up with an approximation, give 
> developers a callback for atomic access, and be done with it.

As far as I can tell, this wouldn't remove race problems. It would in fact 
make it impossible to avoid them, since as far as I can tell you can't 
build a sane locking mechanism based on the above.

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

From mikewse at hotmail.com  Wed Dec  2 02:28:58 2009
From: mikewse at hotmail.com (Mike Wilson)
Date: Wed, 2 Dec 2009 11:28:58 +0100
Subject: [whatwg] two minor things in history traversal
Message-ID: <03a701ca733a$428573a0$0a01a8c0@mikedeskxp>

6.11.9, step 3.1:

  To me, this text:

    "If the browsing context is a top-level browsing context 
    (and not an auxiliary browsing context)"

  seems to imply that an auxiliary b-c is not a top-level b-c.
  This is subjective of course, but it might be a good thing to
  rephrase the sentence into something like:

    "If the browsing context is a top-level browsing context 
    which is not an auxiliary browsing context"

  or:

    "If the browsing context is a top-level browsing context 
    (but not an auxiliary browsing context)"

  Or, I guess it would also be possible to invent a new term
  for "independent top-level browsing contexts" or something
  in the same spirit.

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.

Best regards
Mike Wilson


From jorlow at chromium.org  Wed Dec  2 02:31:16 2009
From: jorlow at chromium.org (Jeremy Orlow)
Date: Wed, 2 Dec 2009 02:31:16 -0800
Subject: [whatwg] localStorage feedback
In-Reply-To: <Pine.LNX.4.62.0912020537520.15540@hixie.dreamhostps.com>
References: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> 
	<Pine.LNX.4.62.0911251107210.10133@hixie.dreamhostps.com> 
	<4B0D6663.7080908@mit.edu>
	<5dd9e5c50911251156m6ed5fdedt26ca7d1c7354eb85@mail.gmail.com> 
	<Pine.LNX.4.62.0912020537520.15540@hixie.dreamhostps.com>
Message-ID: <5dd9e5c50912020231t7e86ceddve28e83702f0492c9@mail.gmail.com>

On Wed, Dec 2, 2009 at 2:06 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 3 Nov 2009, Jeremy Orlow wrote:
> >
> > If we do this, we need to re-visit ways that scripts can tell whether
> > the lock has been dropped.  I can't remember which idea was most in
> > favor last time we talked about it, but a counter that increments every
> > time LocalStorage is unlocked sticks out in my mind.  (Scripts can check
> > the counter, do something that could cause unlocking, and then verify
> > the counter is still the same after.)
>
> The counter could be a boolean -- does the event loop have the lock [for
> the origin of the first script]. I would recommend implementing this as
> a property window.navigator.webkitStorageUpdatesLocked which is true when
> the lock is obtained and false when it is released. If people find it
> useful, we can add it to the language.
>

If it's a boolean, it's possible that it was implicitly unlocked and then
re-locked.  If you have a counter, you can simply check that the count is
the same as when you started.


> > Another option that just came to mind is to have some flag that says
> > "throw an exception whenever there's been a serialization violation".
>
> Could you elaborate on this?
>

You'd have some boolean property that defaults to false (say
navigator.throwOnStorageMutexDeadlocks) that when set to true would cause an
exception to be thrown either immediately or the next time you try to do a
localStorage operation before either calling
navigator.yieldForStorageUpdates or the task ending.


On Wed, 25 Nov 2009, Jeremy Orlow wrote:
> >
> > I know that we've discussed approximations of run to completion before,
> > but maybe it's worth one more shot:  What if on the first use of
> > document.cookie or local storage we took a snapshot of both and used
> > that during the task's execution.  All writes would be queued up until
> > the task finishes, at which point they'd be written to the central
> > version of the cookie and/or local storage.  This would provide a
> > consistent view of data for the duration of the task and would solve
> > almost all the atomicity problems except |document.cookie =
> > document.cookie + "foo";|.  For that, I'd suggest adding a method that
> > allows scripts to do atomic modifications to storage within a callback.
> >
> > I can understand everyone's desire to have completely serializable
> > semantics for local storage access and cookies (if you don't count the
> > servers' interaction with them), but maybe we need to go back to use
> > cases.  In a world with WebDatabase/WebSimpleDB, I really don't see
> > anyone turning to LocalStorage except for more basic uses.  Most of
> > which I'm guessing need consistent reads much more than serialization of
> > everything.
> >
> > And let's be realistic.  IE has had this problem with document.cookie
> > for a long time.  And IE8 now has this problem with localStorage.
> > Given that in the best case (MS and all others implement the storage
> > mutex) web developers will not be able to assume localStorage and
> > document.cookie access is atomic for many years at a minimum, I think
> > we're being pretty unrealistic about how much the storage mutex is going
> > to improve anyone's life.  Let's come up with an approximation, give
> > developers a callback for atomic access, and be done with it.
>
> As far as I can tell, this wouldn't remove race problems. It would in fact
> make it impossible to avoid them, since as far as I can tell you can't
> build a sane locking mechanism based on the above.
>

I don't understand what you mean by building a sane locking mechanism.

The idea is that we'd have near-run-to-completion semantics when using local
storage normally (via repeatable reads semantics on localStorage and
document.cookie) and actual run-to-completion semantics (serializable) if
you use the callback based mechanism for localStorage access.

Given that network based cookie access is essentially repeatable read
semantics and both cookie and localStorage in IE and Chrome aren't even that
currently, I'd say that such semantics seem good enough.  The fact that
Chrome has never gotten any complaints about the racy behavior of its
current document.cookie implementation is some evidence to support that.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091202/63ad33c8/attachment.htm>

From ian at hixie.ch  Wed Dec  2 02:56:59 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 2 Dec 2009 10:56:59 +0000 (UTC)
Subject: [whatwg] localStorage feedback
In-Reply-To: <5dd9e5c50912020231t7e86ceddve28e83702f0492c9@mail.gmail.com>
References: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> 
	<Pine.LNX.4.62.0911251107210.10133@hixie.dreamhostps.com>
	<4B0D6663.7080908@mit.edu>
	<5dd9e5c50911251156m6ed5fdedt26ca7d1c7354eb85@mail.gmail.com> 
	<Pine.LNX.4.62.0912020537520.15540@hixie.dreamhostps.com>
	<5dd9e5c50912020231t7e86ceddve28e83702f0492c9@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912021046000.32245@hixie.dreamhostps.com>

On Wed, 2 Dec 2009, Jeremy Orlow wrote:
> On Wed, Dec 2, 2009 at 2:06 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 3 Nov 2009, Jeremy Orlow wrote:
> > >
> > > If we do this, we need to re-visit ways that scripts can tell 
> > > whether the lock has been dropped.  I can't remember which idea was 
> > > most in favor last time we talked about it, but a counter that 
> > > increments every time LocalStorage is unlocked sticks out in my 
> > > mind.  (Scripts can check the counter, do something that could cause 
> > > unlocking, and then verify the counter is still the same after.)
> >
> > The counter could be a boolean -- does the event loop have the lock 
> > [for the origin of the first script]. I would recommend implementing 
> > this as a property window.navigator.webkitStorageUpdatesLocked which 
> > is true when the lock is obtained and false when it is released. If 
> > people find it useful, we can add it to the language.
> 
> If it's a boolean, it's possible that it was implicitly unlocked and 
> then re-locked.  If you have a counter, you can simply check that the 
> count is the same as when you started.

Oh, I see. I misunderstood how the counter would work (I thought you meant 
it would go down again when unlocking).

Yeah, that would work too. webkitStorageUpdatesLockedCount or something.


> > > Another option that just came to mind is to have some flag that says 
> > > "throw an exception whenever there's been a serialization 
> > > violation".
> >
> > Could you elaborate on this?
> 
> You'd have some boolean property that defaults to false (say 
> navigator.throwOnStorageMutexDeadlocks) that when set to true would 
> cause an exception to be thrown either immediately or the next time you 
> try to do a localStorage operation before either calling 
> navigator.yieldForStorageUpdates or the task ending.

This would basically just be a development aid, then?

I would be a bit worried about people accidentally enabling that kind of 
thing in production code and ending up with even more confusing 
user-facing bugs. It's generally been the kind of thing we've avoided 
standardising in the platform. It might make sense as some kind of 
UA-specific development aid, though.


> On Wed, 25 Nov 2009, Jeremy Orlow wrote:
> > >
> > > I know that we've discussed approximations of run to completion 
> > > before, but maybe it's worth one more shot:  What if on the first 
> > > use of document.cookie or local storage we took a snapshot of both 
> > > and used that during the task's execution.  All writes would be 
> > > queued up until the task finishes, at which point they'd be written 
> > > to the central version of the cookie and/or local storage.  This 
> > > would provide a consistent view of data for the duration of the task 
> > > and would solve almost all the atomicity problems except 
> > > |document.cookie = document.cookie + "foo";|.  For that, I'd suggest 
> > > adding a method that allows scripts to do atomic modifications to 
> > > storage within a callback.
> > >
> > > I can understand everyone's desire to have completely serializable 
> > > semantics for local storage access and cookies (if you don't count 
> > > the servers' interaction with them), but maybe we need to go back to 
> > > use cases.  In a world with WebDatabase/WebSimpleDB, I really don't 
> > > see anyone turning to LocalStorage except for more basic uses.  
> > > Most of which I'm guessing need consistent reads much more than 
> > > serialization of everything.
> > >
> > > And let's be realistic.  IE has had this problem with 
> > > document.cookie for a long time.  And IE8 now has this problem with 
> > > localStorage. Given that in the best case (MS and all others 
> > > implement the storage mutex) web developers will not be able to 
> > > assume localStorage and document.cookie access is atomic for many 
> > > years at a minimum, I think we're being pretty unrealistic about how 
> > > much the storage mutex is going to improve anyone's life.  Let's 
> > > come up with an approximation, give developers a callback for atomic 
> > > access, and be done with it.
> >
> > As far as I can tell, this wouldn't remove race problems. It would in 
> > fact make it impossible to avoid them, since as far as I can tell you 
> > can't build a sane locking mechanism based on the above.
> 
> I don't understand what you mean by building a sane locking mechanism.
> 
> The idea is that we'd have near-run-to-completion semantics when using 
> local storage normally (via repeatable reads semantics on localStorage 
> and document.cookie) and actual run-to-completion semantics 
> (serializable) if you use the callback based mechanism for localStorage 
> access.

If we decide to introduce a whole new API, then there are lots of things 
we could do that would make this much better, yes. I am not planning on 
introducing a fourth new storage API this year, though. I figure the Web 
needs time to get a handle on the ones we're introducing already.

Without the additional API, I think it makes the storage mechanism much 
less reliable than no storage mutex at all. It would make it much more 
likely to have a race condition, since, if I'm understanding your proposal 
correctly, it maximises the time between the reads and the writes.


> Given that network based cookie access is essentially repeatable read 
> semantics and both cookie and localStorage in IE and Chrome aren't even 
> that currently, I'd say that such semantics seem good enough.  The fact 
> that Chrome has never gotten any complaints about the racy behavior of 
> its current document.cookie implementation is some evidence to support 
> that.

I'm not convinced this is the kind of bug that would ever get reported. 

For localStorage, developers wouldn't see it, it would only be seen long 
after the fact by users who happened to once have multiple tabs open on 
the same page, in the form of data corruption.

For cookies, it's an extremely unlikely problem to occur, given the way 
cookies are generally processed (infrequent access; typically either 
write or read only, not both; writes are typically idempotent; etc) and if 
it did, it's even more likely to be blamed on random things than anyone 
realising it's a race condition.

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

From bringert at google.com  Wed Dec  2 03:32:07 2009
From: bringert at google.com (Bjorn Bringert)
Date: Wed, 2 Dec 2009 11:32:07 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
Message-ID: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>

We've been watching our colleagues build native apps that use speech
recognition and speech synthesis, and would like to have JavaScript
APIs that let us do the same in web apps. We are thinking about
creating a lightweight and implementation-independent API that lets
web apps use speech services. Is anyone else interested in that?

Bjorn Bringert, David Singleton, Gummi Hafsteinsson

-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

From jonas at sicking.cc  Wed Dec  2 07:22:19 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 2 Dec 2009 07:22:19 -0800
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
Message-ID: <63df84f0912020722j9e02702uaaca00528c1631f@mail.gmail.com>

On Wed, Dec 2, 2009 at 3:32 AM, Bjorn Bringert <bringert at google.com> wrote:
> We've been watching our colleagues build native apps that use speech
> recognition and speech synthesis, and would like to have JavaScript
> APIs that let us do the same in web apps. We are thinking about
> creating a lightweight and implementation-independent API that lets
> web apps use speech services. Is anyone else interested in that?
>
> Bjorn Bringert, David Singleton, Gummi Hafsteinsson

Short answer: Yes, very :)

Longer answer: APIs for accessing microphone and camera is something
that I think is very needed. There's several aspects to this, ranging
from simply uploading video/audio clips using an <input type=file>
element, to streaming APIs that allow video/audio conferancing using a
browser, to being able to do video/audio processing/playback inside
the browser.

There's a ton of work here to be done, anywhere you are willing to
help would be hugely appreciated.

/ Jonas

From mike at plan99.net  Wed Dec  2 08:55:40 2009
From: mike at plan99.net (Mike Hearn)
Date: Wed, 2 Dec 2009 17:55:40 +0100
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
Message-ID: <f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com>

Is speech support a feature of the web page, or the web browser?

On Wed, Dec 2, 2009 at 12:32 PM, Bjorn Bringert <bringert at google.com> wrote:
> We've been watching our colleagues build native apps that use speech
> recognition and speech synthesis, and would like to have JavaScript
> APIs that let us do the same in web apps. We are thinking about
> creating a lightweight and implementation-independent API that lets
> web apps use speech services. Is anyone else interested in that?
>
> Bjorn Bringert, David Singleton, Gummi Hafsteinsson
>
> --
> Bjorn Bringert
> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
> Palace Road, London, SW1W 9TQ
> Registered in England Number: 3977902
>

From bringert at google.com  Wed Dec  2 09:17:42 2009
From: bringert at google.com (Bjorn Bringert)
Date: Wed, 2 Dec 2009 17:17:42 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com>
Message-ID: <1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com>

I think that it would be best to extend the browser with a JavaScript
speech API intended for use by web apps. That is, only web apps that
use the speech API would have speech support. But it should be
possible to use such an API to write browser extensions (using
Greasemonkey, Chrome extensions etc) that allow speech control of the
browser and speech synthesis of web page contents. Doing it the other
way around seems like it would reduce the flexibility for web app
developers.

/Bjorn

On Wed, Dec 2, 2009 at 4:55 PM, Mike Hearn <mike at plan99.net> wrote:
> Is speech support a feature of the web page, or the web browser?
>
> On Wed, Dec 2, 2009 at 12:32 PM, Bjorn Bringert <bringert at google.com> wrote:
>> We've been watching our colleagues build native apps that use speech
>> recognition and speech synthesis, and would like to have JavaScript
>> APIs that let us do the same in web apps. We are thinking about
>> creating a lightweight and implementation-independent API that lets
>> web apps use speech services. Is anyone else interested in that?
>>
>> Bjorn Bringert, David Singleton, Gummi Hafsteinsson
>>
>> --
>> Bjorn Bringert
>> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
>> Palace Road, London, SW1W 9TQ
>> Registered in England Number: 3977902
>>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

From taka.atsushi at googlemail.com  Wed Dec  2 09:18:05 2009
From: taka.atsushi at googlemail.com (ATSUSHI TAKAYAMA)
Date: Wed, 2 Dec 2009 12:18:05 -0500
Subject: [whatwg] Syntax of void element
In-Reply-To: <9cef076f0911301642w12f7e855h629229e1347e35d@mail.gmail.com>
References: <9cef076f0911301642w12f7e855h629229e1347e35d@mail.gmail.com>
Message-ID: <9cef076f0912020918h6aedfa52n6badb1f4d6c130d4@mail.gmail.com>

Hi WHATWG members,

This was posted by Akatsuki Kitamura on the W3C Japanese Interest
Group Mailing List.

The section 9.2.1 of HTML5 spec says;

Start tags must have the following format:
1. The first character of a start tag must be a U+003C LESS-THAN SIGN
character (<).
2. The next few characters of a start tag must be the element's tag name.
3. If there are to be any attributes in the next step, there must
first be one or more space characters.
4. Then, the start tag may have a number of attributes, the syntax for
which is described below. Attributes may be separated from each other
by one or more space characters.
5. After the attributes, there may be one or more space characters.
(Some attributes are required to be followed by a space. See the
attributes section below.)
6. Then, if the element is one of the void elements, or if the element
is a foreign element, then there may be a single U+002F SOLIDUS
character (/). This character has no effect on void elements, but on
foreign elements it marks the start tag as self-closing.
7. Finally, start tags must be closed by a U+003E GREATER-THAN SIGN
character (>).

As far as I understand, if I want to write a void element with no
attribute, such as the br, I do steps 1 ("<" character) and 2 (tag
name), then ignore 3 and 4. In the step 5, since I don't have any
attributes, the "after the attribute" situation does not apply here,
so I ignore it too. Then I close the tag by going through step 6 ("/"
character) and step 7 (">" character).

Akatsuki's question was that if you write space characters before
closing the tag like the following, if they are still valid or not.

<br >
<br />

I think the step 5 should be written as;

After the attributes, or after the element's tag name if there are no
attributes, then there may be one or more space characters.

Thanks,
A. Takayama

From jonas at sicking.cc  Wed Dec  2 10:04:31 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 2 Dec 2009 10:04:31 -0800
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com> 
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com> 
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com>
Message-ID: <63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com>

On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert <bringert at google.com> wrote:
> I think that it would be best to extend the browser with a JavaScript
> speech API intended for use by web apps. That is, only web apps that
> use the speech API would have speech support. But it should be
> possible to use such an API to write browser extensions (using
> Greasemonkey, Chrome extensions etc) that allow speech control of the
> browser and speech synthesis of web page contents. Doing it the other
> way around seems like it would reduce the flexibility for web app
> developers.

Hmm.. I guess I misunderstood your original proposal.

Do you want the browser to expose an API that converts speech to text?
Or do you want the browser to expose access to the microphone so that
you can do speech to text convertion in javascript?

If the former, could you describe your use cases in more detail?

/ Jonas

From dresende at thinkdigital.pt  Wed Dec  2 10:23:23 2009
From: dresende at thinkdigital.pt (Diogo Resende)
Date: Wed, 2 Dec 2009 18:23:23 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
Message-ID: <1259778203.7253.3.camel@nasgul.local>

I missunderstood too. It would be great to have the ability to access
the microphone and record+upload or stream sound to the web server.

-- 
D.


On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote:
> On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert <bringert at google.com> wrote:
> > I think that it would be best to extend the browser with a JavaScript
> > speech API intended for use by web apps. That is, only web apps that
> > use the speech API would have speech support. But it should be
> > possible to use such an API to write browser extensions (using
> > Greasemonkey, Chrome extensions etc) that allow speech control of the
> > browser and speech synthesis of web page contents. Doing it the other
> > way around seems like it would reduce the flexibility for web app
> > developers.
> 
> Hmm.. I guess I misunderstood your original proposal.
> 
> Do you want the browser to expose an API that converts speech to text?
> Or do you want the browser to expose access to the microphone so that
> you can do speech to text convertion in javascript?
> 
> If the former, could you describe your use cases in more detail?
> 
> / Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091202/b9ef823f/attachment.pgp>

From bringert at google.com  Wed Dec  2 11:17:58 2009
From: bringert at google.com (Bjorn Bringert)
Date: Wed, 2 Dec 2009 19:17:58 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1259778203.7253.3.camel@nasgul.local>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com>
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com>
	<63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com>
	<1259778203.7253.3.camel@nasgul.local>
Message-ID: <1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com>

I agree that being able to capture and upload audio to a server would
be useful for a lot of applications, and it could be used to do speech
recognition. However, for a web app developer who just wants to
develop an application that uses speech input and/or output, it
doesn't seem very convenient, since it requires server-side
infrastructure that is very costly to develop and run. A
speech-specific API in the browser gives browser implementors the
option to use on-device speech services provided by the OS, or
server-side speech synthesis/recognition.

/Bjorn

On Wed, Dec 2, 2009 at 6:23 PM, Diogo Resende <dresende at thinkdigital.pt> wrote:
> I missunderstood too. It would be great to have the ability to access
> the microphone and record+upload or stream sound to the web server.
>
> --
> D.
>
>
> On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote:
>> On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert <bringert at google.com> wrote:
>> > I think that it would be best to extend the browser with a JavaScript
>> > speech API intended for use by web apps. That is, only web apps that
>> > use the speech API would have speech support. But it should be
>> > possible to use such an API to write browser extensions (using
>> > Greasemonkey, Chrome extensions etc) that allow speech control of the
>> > browser and speech synthesis of web page contents. Doing it the other
>> > way around seems like it would reduce the flexibility for web app
>> > developers.
>>
>> Hmm.. I guess I misunderstood your original proposal.
>>
>> Do you want the browser to expose an API that converts speech to text?
>> Or do you want the browser to expose access to the microphone so that
>> you can do speech to text convertion in javascript?
>>
>> If the former, could you describe your use cases in more detail?
>>
>> / Jonas
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

From joaoe at opera.com  Wed Dec  2 11:25:31 2009
From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=)
Date: Wed, 02 Dec 2009 20:25:31 +0100
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
Message-ID: <op.u4br8tck2q99of@id-c0981>

On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert <bringert at google.com>  
wrote:

> We've been watching our colleagues build native apps that use speech
> recognition and speech synthesis, and would like to have JavaScript
> APIs that let us do the same in web apps. We are thinking about
> creating a lightweight and implementation-independent API that lets
> web apps use speech services. Is anyone else interested in that?
>
> Bjorn Bringert, David Singleton, Gummi Hafsteinsson
>

This exists already, but only Opera supports it, although there are  
problems with the library we use for speech recognition.

http://www.w3.org/TR/xhtml+voice/
http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/

Would be nice to revive that specification and get vendor buy-in.



-- 

Jo?o Eiras
Core Developer, Opera Software ASA, http://www.opera.com/

From dresende at thinkdigital.pt  Wed Dec  2 11:40:11 2009
From: dresende at thinkdigital.pt (Diogo Resende)
Date: Wed, 2 Dec 2009 19:40:11 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
Message-ID: <1259782811.7253.8.camel@nasgul.local>

If you're able to read from the mic, you don't need to upload. You could
save it locally (for example for voice memos). The read+upload was just
2 steps I sugested instead of direct streaming. Speech recognition could
be done separatly. One could use the mic to capture a voice note. Other
could use the speech recognition without the mic (saved file?). Divide
and conquer :)

-- 
Diogo Resende <dresende at thinkdigital.pt>
ThinkDigital

On Wed, 2009-12-02 at 19:17 +0000, Bjorn Bringert wrote:
> I agree that being able to capture and upload audio to a server would
> be useful for a lot of applications, and it could be used to do speech
> recognition. However, for a web app developer who just wants to
> develop an application that uses speech input and/or output, it
> doesn't seem very convenient, since it requires server-side
> infrastructure that is very costly to develop and run. A
> speech-specific API in the browser gives browser implementors the
> option to use on-device speech services provided by the OS, or
> server-side speech synthesis/recognition.
> 
> /Bjorn
> 
> On Wed, Dec 2, 2009 at 6:23 PM, Diogo Resende <dresende at thinkdigital.pt> wrote:
> > I missunderstood too. It would be great to have the ability to access
> > the microphone and record+upload or stream sound to the web server.
> >
> > --
> > D.
> >
> >
> > On Wed, 2009-12-02 at 10:04 -0800, Jonas Sicking wrote:
> >> On Wed, Dec 2, 2009 at 9:17 AM, Bjorn Bringert <bringert at google.com> wrote:
> >> > I think that it would be best to extend the browser with a JavaScript
> >> > speech API intended for use by web apps. That is, only web apps that
> >> > use the speech API would have speech support. But it should be
> >> > possible to use such an API to write browser extensions (using
> >> > Greasemonkey, Chrome extensions etc) that allow speech control of the
> >> > browser and speech synthesis of web page contents. Doing it the other
> >> > way around seems like it would reduce the flexibility for web app
> >> > developers.
> >>
> >> Hmm.. I guess I misunderstood your original proposal.
> >>
> >> Do you want the browser to expose an API that converts speech to text?
> >> Or do you want the browser to expose access to the microphone so that
> >> you can do speech to text convertion in javascript?
> >>
> >> If the former, could you describe your use cases in more detail?
> >>
> >> / Jonas
> >
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091202/bf89b0a0/attachment.pgp>

From ap at webkit.org  Wed Dec  2 12:04:38 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Wed, 02 Dec 2009 12:04:38 -0800
Subject: [whatwg] Web Sockets URL
Message-ID: <644ACF88-438C-4526-A544-FF513A1AE38B@webkit.org>

Currently, the Web Sockets API spec says that the WebSocket.URL  
attribute must just return a value that was passed to the WebSocket  
constructor. This doesn't match how many other url accessors work, and  
consequentially, it doesn't match what currently happens in WebKit.

I think it makes more sense to return a resolved URL - e.g. (new  
WebSocket("ws://host/path/../")).URL would return "ws://host/".

- WBR, Alexey Proskuryakov


From jonas at sicking.cc  Wed Dec  2 14:20:12 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 2 Dec 2009 14:20:12 -0800
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com> 
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com> 
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com> 
	<63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com> 
	<1259778203.7253.3.camel@nasgul.local>
	<1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com>
Message-ID: <63df84f0912021420p77637c9atd022b1ac0e904478@mail.gmail.com>

On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert <bringert at google.com> wrote:
> I agree that being able to capture and upload audio to a server would
> be useful for a lot of applications, and it could be used to do speech
> recognition. However, for a web app developer who just wants to
> develop an application that uses speech input and/or output, it
> doesn't seem very convenient, since it requires server-side
> infrastructure that is very costly to develop and run. A
> speech-specific API in the browser gives browser implementors the
> option to use on-device speech services provided by the OS, or
> server-side speech synthesis/recognition.

Again, it would help a lot of you could provide use cases and
requirements. This helps both with designing an API, as well as
evaluating if the use cases are common enough that a dedicated API is
the best solution.

/ Jonas

From daveburke at google.com  Wed Dec  2 16:50:20 2009
From: daveburke at google.com (Dave Burke)
Date: Thu, 3 Dec 2009 00:50:20 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <op.u4br8tck2q99of@id-c0981>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<op.u4br8tck2q99of@id-c0981>
Message-ID: <6e608abf0912021650h52d6c6f2ha44d8559f181c3e8@mail.gmail.com>

We're envisaging a simpler programmatic API that looks familiar to the
modern Web developer but one which avoids the legacy of dialog system
languages.

Dave

On Wed, Dec 2, 2009 at 7:25 PM, Jo?o Eiras <joaoe at opera.com> wrote:

> On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert <bringert at google.com>
> wrote:
>
>  We've been watching our colleagues build native apps that use speech
>> recognition and speech synthesis, and would like to have JavaScript
>> APIs that let us do the same in web apps. We are thinking about
>> creating a lightweight and implementation-independent API that lets
>> web apps use speech services. Is anyone else interested in that?
>>
>> Bjorn Bringert, David Singleton, Gummi Hafsteinsson
>>
>>
> This exists already, but only Opera supports it, although there are
> problems with the library we use for speech recognition.
>
> http://www.w3.org/TR/xhtml+voice/
> http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/
>
> Would be nice to revive that specification and get vendor buy-in.
>
>
>
> --
>
> Jo?o Eiras
> Core Developer, Opera Software ASA, http://www.opera.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091203/d5eb5a66/attachment.htm>

From joaoe at opera.com  Wed Dec  2 17:20:36 2009
From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=)
Date: Thu, 03 Dec 2009 02:20:36 +0100
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <6e608abf0912021650h52d6c6f2ha44d8559f181c3e8@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<op.u4br8tck2q99of@id-c0981>
	<6e608abf0912021650h52d6c6f2ha44d8559f181c3e8@mail.gmail.com>
Message-ID: <op.u4b8ompo2q99of@coruscant>

On Thu, 03 Dec 2009 01:50:20 +0100, Dave Burke <daveburke at google.com>  
wrote:

> We're envisaging a simpler programmatic API that looks familiar to the
> modern Web developer but one which avoids the legacy of dialog system
> languages.
>

Ok. I referenced that XHTML+Voice because there is already a specification  
with markup, css 2 aural stylesheets and javascript APIs, and one  
implementation.
I quite sure someone can revisit this whole issue, and refactor the  
xhtml+voice specification into something more acceptable and implementable.
I don't think anyone would implement it the way it is.


> Dave
>
> On Wed, Dec 2, 2009 at 7:25 PM, Jo?o Eiras <joaoe at opera.com> wrote:
>
>> On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert <bringert at google.com>
>> wrote:
>>
>>  We've been watching our colleagues build native apps that use speech
>>> recognition and speech synthesis, and would like to have JavaScript
>>> APIs that let us do the same in web apps. We are thinking about
>>> creating a lightweight and implementation-independent API that lets
>>> web apps use speech services. Is anyone else interested in that?
>>>
>>> Bjorn Bringert, David Singleton, Gummi Hafsteinsson
>>>
>>>
>> This exists already, but only Opera supports it, although there are
>> problems with the library we use for speech recognition.
>>
>> http://www.w3.org/TR/xhtml+voice/
>> http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/
>>
>> Would be nice to revive that specification and get vendor buy-in.
>>
>>
>>
>> --
>>
>> Jo?o Eiras
>> Core Developer, Opera Software ASA, http://www.opera.com/
>>


From kit at iqmultimedia.com.au  Wed Dec  2 18:31:27 2009
From: kit at iqmultimedia.com.au (Kit Grose)
Date: Thu, 3 Dec 2009 13:31:27 +1100
Subject: [whatwg] HTML5 video element - default to fallback in cases
 where UA can't play format
In-Reply-To: <7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
Message-ID: <634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>

On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:

> On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose <kit at iqmultimedia.com.au> wrote:
>> Can I get some sort of an understanding on why this behaviour (non-
>> descript error in supported UAs rather than using the fallback content
>> that can provide alternate access methods) would be preferred?
> 
> Suppose browsers fell back to the contents if they couldn't play any
> of the sources.  Then what happens if the browser isn't sure whether
> it can play a video until it's started loading it?  This would be
> extremely common -- it would happen any time the source is given with
> src="", or if <source> elements are given with no type="", or even if
> there was a type="" but the browser wasn't sure it supported the exact
> versions or didn't fully trust the author or whatnot.  Then does the
> browser not load the contents until it figures out it can't play the
> video, then load the contents at some undefined later time?  So
> scripts execute out of order and so on?

Sorry to resurrect an old thread but I was using my iPhone and had an extra couple of questions about this I was hoping people might be able to answer for me.

The iPhone (and other similar devices) are restricted to certain file formats and even bitrates/image sizes. When the iPhone encounters our <video> element, I can supply a non-compatible video (still in an MP4 container) and the iPhone knows to mark the video in place as non-playable. If I whack in a compatible H.264 video, the video is shown as playable.

Can someone explain to me how this works, given Aryeh's response above? Surely if the iPhone can determine its capacity to be able to play a video file, other UAs could do likewise and fall back on the content accordingly as UAs with zero <video> support do?

?Kit

From info at html5.jp  Wed Dec  2 22:48:01 2009
From: info at html5.jp (Futomi Hatano)
Date: Thu, 03 Dec 2009 15:48:01 +0900
Subject: [whatwg] value content attribute of <input>
Message-ID: <20091203154535.BED9.C8DE7135@html5.jp>

Hi all

Could you please see the section in the spec?
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element

There is a table which includes summarizes which of content attributes, IDL attributes, methods, and events apply to each state.
Is the value content attribute needed to include to the table, isn't it?

--
Futomi Hatano
www.html5.jp


From ukai at chromium.org  Wed Dec  2 23:49:23 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Thu, 3 Dec 2009 16:49:23 +0900
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
Message-ID: <de17d48e0912022349g6e66533clf8e75aa38015723e@mail.gmail.com>

I've question about thread to run Web Socket feedback from the protocol.

If server sends back handshake response and a data frame, and close
immediately, fast enough to run JavaScript on browser, how readyState should
be?
1) When client recognizes handshake response header, it changes readyState
to OPEN  and queue a task to fire a simple event named "open".
2) Then client reads a data frame, and queue a task to fire a MessageEvent.
3) Then client recognizes the socket is closed, it changes readyState to
CLOSED and queue a task to fire a simple event named "close".

I'm wondering this process should be done on the same thread of the
JavaScript, or may be on the different thread.
If it should run on the same thread,  1) would be processed after JavaScript
code is processed. Thus, readyState is OPEN when it receives "open" event.
However, if it may run on the different thread, 1)-3) might be processed
before JavaScript code is processed.  So, readyState might be CLOSED when it
receives "open" event.

Which is correct behavior?
It seems WebKit/Mac does former, and Chromium does latter, so
LayoutTests/websocket/tests/simple.html would fail with Chromium.

-- 
ukai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091203/9caa9029/attachment.htm>

From bringert at google.com  Thu Dec  3 04:06:05 2009
From: bringert at google.com (Bjorn Bringert)
Date: Thu, 3 Dec 2009 12:06:05 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <63df84f0912021420p77637c9atd022b1ac0e904478@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com>
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com>
	<63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com>
	<1259778203.7253.3.camel@nasgul.local>
	<1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com>
	<63df84f0912021420p77637c9atd022b1ac0e904478@mail.gmail.com>
Message-ID: <1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com>

On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert <bringert at google.com> wrote:
>> I agree that being able to capture and upload audio to a server would
>> be useful for a lot of applications, and it could be used to do speech
>> recognition. However, for a web app developer who just wants to
>> develop an application that uses speech input and/or output, it
>> doesn't seem very convenient, since it requires server-side
>> infrastructure that is very costly to develop and run. A
>> speech-specific API in the browser gives browser implementors the
>> option to use on-device speech services provided by the OS, or
>> server-side speech synthesis/recognition.
>
> Again, it would help a lot of you could provide use cases and
> requirements. This helps both with designing an API, as well as
> evaluating if the use cases are common enough that a dedicated API is
> the best solution.
>
> / Jonas

I'm mostly thinking about speech web apps for mobile devices. I think
that's where speech makes most sense as an input and output method,
because of the poor keyboards, small screens, and frequent hands/eyes
busy situations (e.g. while driving). Accessibility is the other big
reason for using speech.

Some ideas for use cases:

- Search by speaking a query
- Speech-to-speech translation
- Voice Dialing (could open a tel: URI to actually make the call)
- Dialog systems (e.g. the canonical pizza ordering system)
- Lightweight JavaScript browser extensions (e.g. Greasemonkey /
Chrome extensions) for using speech with any web site, e.g, for
accessibility.

Requirements:

- Web app developer side:
   - Allows both speech recognition and synthesis.
   - Easy to use API. Makes simple things easy and advanced things possible.
   - Doesn't require web app developer to develop / run his own speech
recognition / synthesis servers.
   - (Natural) language-neutral API.
   - Allows developer-defined application specific grammars / language models.
   - Allows multilingual applications.
   - Allows easy localization of speech apps.

- Implementor side:
   - Easy enough to implement that it can get wide adoption in browsers.
   - Allows implementor to use either client-side or server-side
recognition and synthesis.

-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

From dresende at thinkdigital.pt  Thu Dec  3 04:32:02 2009
From: dresende at thinkdigital.pt (Diogo Resende)
Date: Thu, 3 Dec 2009 12:32:02 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
Message-ID: <1259843522.5368.1.camel@nasgul.local>

I agree 100%. Still, I think the access to the mic and the speech
recognition could be separated.

-- 
Diogo Resende <dresende at thinkdigital.pt>
ThinkDigital

On Thu, 2009-12-03 at 12:06 +0000, Bjorn Bringert wrote:
> On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> > On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert <bringert at google.com> wrote:
> >> I agree that being able to capture and upload audio to a server would
> >> be useful for a lot of applications, and it could be used to do speech
> >> recognition. However, for a web app developer who just wants to
> >> develop an application that uses speech input and/or output, it
> >> doesn't seem very convenient, since it requires server-side
> >> infrastructure that is very costly to develop and run. A
> >> speech-specific API in the browser gives browser implementors the
> >> option to use on-device speech services provided by the OS, or
> >> server-side speech synthesis/recognition.
> >
> > Again, it would help a lot of you could provide use cases and
> > requirements. This helps both with designing an API, as well as
> > evaluating if the use cases are common enough that a dedicated API is
> > the best solution.
> >
> > / Jonas
> 
> I'm mostly thinking about speech web apps for mobile devices. I think
> that's where speech makes most sense as an input and output method,
> because of the poor keyboards, small screens, and frequent hands/eyes
> busy situations (e.g. while driving). Accessibility is the other big
> reason for using speech.
> 
> Some ideas for use cases:
> 
> - Search by speaking a query
> - Speech-to-speech translation
> - Voice Dialing (could open a tel: URI to actually make the call)
> - Dialog systems (e.g. the canonical pizza ordering system)
> - Lightweight JavaScript browser extensions (e.g. Greasemonkey /
> Chrome extensions) for using speech with any web site, e.g, for
> accessibility.
> 
> Requirements:
> 
> - Web app developer side:
>    - Allows both speech recognition and synthesis.
>    - Easy to use API. Makes simple things easy and advanced things possible.
>    - Doesn't require web app developer to develop / run his own speech
> recognition / synthesis servers.
>    - (Natural) language-neutral API.
>    - Allows developer-defined application specific grammars / language models.
>    - Allows multilingual applications.
>    - Allows easy localization of speech apps.
> 
> - Implementor side:
>    - Easy enough to implement that it can get wide adoption in browsers.
>    - Allows implementor to use either client-side or server-side
> recognition and synthesis.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091203/3a725284/attachment.pgp>

From philipj at opera.com  Thu Dec  3 05:13:50 2009
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Thu, 03 Dec 2009 14:13:50 +0100
Subject: [whatwg] HTML5 video element - default to fallback in cases
 where UA can't play format
In-Reply-To: <634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
	<634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
Message-ID: <op.u4c5pcz0sr6mfa@sisko>

On Thu, 03 Dec 2009 03:31:27 +0100, Kit Grose <kit at iqmultimedia.com.au>  
wrote:

> On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:
>
>> On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose <kit at iqmultimedia.com.au>  
>> wrote:
>>> Can I get some sort of an understanding on why this behaviour (non-
>>> descript error in supported UAs rather than using the fallback content
>>> that can provide alternate access methods) would be preferred?
>>
>> Suppose browsers fell back to the contents if they couldn't play any
>> of the sources.  Then what happens if the browser isn't sure whether
>> it can play a video until it's started loading it?  This would be
>> extremely common -- it would happen any time the source is given with
>> src="", or if <source> elements are given with no type="", or even if
>> there was a type="" but the browser wasn't sure it supported the exact
>> versions or didn't fully trust the author or whatnot.  Then does the
>> browser not load the contents until it figures out it can't play the
>> video, then load the contents at some undefined later time?  So
>> scripts execute out of order and so on?
>
> Sorry to resurrect an old thread but I was using my iPhone and had an  
> extra couple of questions about this I was hoping people might be able  
> to answer for me.
>
> The iPhone (and other similar devices) are restricted to certain file  
> formats and even bitrates/image sizes. When the iPhone encounters our  
> <video> element, I can supply a non-compatible video (still in an MP4  
> container) and the iPhone knows to mark the video in place as  
> non-playable. If I whack in a compatible H.264 video, the video is shown  
> as playable.
>
> Can someone explain to me how this works, given Aryeh's response above?  
> Surely if the iPhone can determine its capacity to be able to play a  
> video file, other UAs could do likewise and fall back on the content  
> accordingly as UAs with zero <video> support do?

I know nothing about the iPhone, but any UA can know if it can play a  
resource or not simply by trying and adjusting the UI as appropriate. One  
*could* use the same hooks to display fallback content in those cases, but  
it is a very bad idea. Apart from the things Aryeh mention, because of how  
the resource selection algorithm works, you can never know if there will  
be a playable resource later, so there's no point where it's appropriate  
to show the fallback content. The only remaining option is flip-flopping  
between replaced content (video) and fallback content, which don't want  
(especially considering that the fallback content is likely to contain  
<object> for Flash or some other legacy fallback).

-- 
Philip J?genstedt
Core Developer
Opera Software

From workmad3 at gmail.com  Thu Dec  3 05:16:25 2009
From: workmad3 at gmail.com (David Workman)
Date: Thu, 3 Dec 2009 13:16:25 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1259843522.5368.1.camel@nasgul.local>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com>
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com>
	<63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com>
	<1259778203.7253.3.camel@nasgul.local>
	<1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com>
	<63df84f0912021420p77637c9atd022b1ac0e904478@mail.gmail.com>
	<1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com>
	<1259843522.5368.1.camel@nasgul.local>
Message-ID: <4a60c8650912030516p42f6f64ar2cdc8ed204d31466@mail.gmail.com>

I agree. The application should be able to choose a source for speech
commands, or give the user a choice of options for a speech source. It also
provides a much better separation of APIs, allowing the development of a
speech API that doesn't depend on or interfere in any way with the
development of a microphone/audio input device API.

2009/12/3 Diogo Resende <dresende at thinkdigital.pt>

> I agree 100%. Still, I think the access to the mic and the speech
> recognition could be separated.
>
> --
> Diogo Resende <dresende at thinkdigital.pt>
> ThinkDigital
>
> On Thu, 2009-12-03 at 12:06 +0000, Bjorn Bringert wrote:
> > On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> > > On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert <bringert at google.com>
> wrote:
> > >> I agree that being able to capture and upload audio to a server would
> > >> be useful for a lot of applications, and it could be used to do speech
> > >> recognition. However, for a web app developer who just wants to
> > >> develop an application that uses speech input and/or output, it
> > >> doesn't seem very convenient, since it requires server-side
> > >> infrastructure that is very costly to develop and run. A
> > >> speech-specific API in the browser gives browser implementors the
> > >> option to use on-device speech services provided by the OS, or
> > >> server-side speech synthesis/recognition.
> > >
> > > Again, it would help a lot of you could provide use cases and
> > > requirements. This helps both with designing an API, as well as
> > > evaluating if the use cases are common enough that a dedicated API is
> > > the best solution.
> > >
> > > / Jonas
> >
> > I'm mostly thinking about speech web apps for mobile devices. I think
> > that's where speech makes most sense as an input and output method,
> > because of the poor keyboards, small screens, and frequent hands/eyes
> > busy situations (e.g. while driving). Accessibility is the other big
> > reason for using speech.
> >
> > Some ideas for use cases:
> >
> > - Search by speaking a query
> > - Speech-to-speech translation
> > - Voice Dialing (could open a tel: URI to actually make the call)
> > - Dialog systems (e.g. the canonical pizza ordering system)
> > - Lightweight JavaScript browser extensions (e.g. Greasemonkey /
> > Chrome extensions) for using speech with any web site, e.g, for
> > accessibility.
> >
> > Requirements:
> >
> > - Web app developer side:
> >    - Allows both speech recognition and synthesis.
> >    - Easy to use API. Makes simple things easy and advanced things
> possible.
> >    - Doesn't require web app developer to develop / run his own speech
> > recognition / synthesis servers.
> >    - (Natural) language-neutral API.
> >    - Allows developer-defined application specific grammars / language
> models.
> >    - Allows multilingual applications.
> >    - Allows easy localization of speech apps.
> >
> > - Implementor side:
> >    - Easy enough to implement that it can get wide adoption in browsers.
> >    - Allows implementor to use either client-side or server-side
> > recognition and synthesis.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091203/777ea2f0/attachment.htm>

From kornel at geekhood.net  Thu Dec  3 05:31:41 2009
From: kornel at geekhood.net (=?UTF-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Thu, 3 Dec 2009 13:31:41 +0000
Subject: [whatwg] HTML5 video element - default to fallback in cases
	where UA can't play format
In-Reply-To: <op.u4c5pcz0sr6mfa@sisko>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
	<634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
	<op.u4c5pcz0sr6mfa@sisko>
Message-ID: <2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>

>> Can someone explain to me how this works, given Aryeh's response  
>> above? Surely if the iPhone can determine its capacity to be able  
>> to play a video file, other UAs could do likewise and fall back on  
>> the content accordingly as UAs with zero <video> support do?
>
> I know nothing about the iPhone, but any UA can know if it can play  
> a resource or not simply by trying and adjusting the UI as  
> appropriate. One *could* use the same hooks to display fallback  
> content in those cases, but it is a very bad idea. Apart from the  
> things Aryeh mention, because of how the resource selection  
> algorithm works, you can never know if there will be a playable  
> resource later, so there's no point where it's appropriate to show  
> the fallback content. The only remaining option is flip-flopping  
> between replaced content (video) and fallback content, which don't  
> want (especially considering that the fallback content is likely to  
> contain <object> for Flash or some other legacy fallback).

How about making end of selection algorithm explicit?

Something like video.imDoneWithSourcesEitherPlayOrShowFallback()  
method, which upon failure permanently locks <video> in fallback state  
(to avoid flip-flopping).

or a special source that, if selected, triggers fallback:

<video>
	<source src=file>
	<source fallback> (or <source src="#fallback">?)
</video>

-- 
regards, Kornel


From kit at iqmultimedia.com.au  Thu Dec  3 05:29:19 2009
From: kit at iqmultimedia.com.au (Kit Grose)
Date: Fri, 4 Dec 2009 00:29:19 +1100
Subject: [whatwg] HTML5 video element - default to fallback in
	cases	where UA can't play format
In-Reply-To: <2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
	<634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
	<op.u4c5pcz0sr6mfa@sisko>
	<2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
Message-ID: <ABD02030-CEBB-4B0F-AAEF-882BB71CF559@iqmultimedia.com.au>

It seems counterintuitive to me that having produced fallback content  
already, I still need to use Javascript to test for compatibility  
(even if I *did* generate two formats, there's obviously no guarantee  
IE9 won't come out requiring WMV or a similar issue with a different  
UA).

Are there any other elements in HTML that _require_ Javascript to  
provide a good UX?

?Kit

From philipj at opera.com  Thu Dec  3 06:00:15 2009
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Thu, 03 Dec 2009 15:00:15 +0100
Subject: [whatwg] HTML5 video element - default to fallback in cases
 where UA can't play format
In-Reply-To: <2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
	<634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
	<op.u4c5pcz0sr6mfa@sisko>
	<2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
Message-ID: <op.u4c7uptfsr6mfa@sisko>

On Thu, 03 Dec 2009 14:31:41 +0100, Kornel Lesi?ski <kornel at geekhood.net>  
wrote:

>>> Can someone explain to me how this works, given Aryeh's response  
>>> above? Surely if the iPhone can determine its capacity to be able to  
>>> play a video file, other UAs could do likewise and fall back on the  
>>> content accordingly as UAs with zero <video> support do?
>>
>> I know nothing about the iPhone, but any UA can know if it can play a  
>> resource or not simply by trying and adjusting the UI as appropriate.  
>> One *could* use the same hooks to display fallback content in those  
>> cases, but it is a very bad idea. Apart from the things Aryeh mention,  
>> because of how the resource selection algorithm works, you can never  
>> know if there will be a playable resource later, so there's no point  
>> where it's appropriate to show the fallback content. The only remaining  
>> option is flip-flopping between replaced content (video) and fallback  
>> content, which don't want (especially considering that the fallback  
>> content is likely to contain <object> for Flash or some other legacy  
>> fallback).
>
> How about making end of selection algorithm explicit?
>
> Something like video.imDoneWithSourcesEitherPlayOrShowFallback() method,  
> which upon failure permanently locks <video> in fallback state (to avoid  
> flip-flopping).
>
> or a special source that, if selected, triggers fallback:
>
> <video>
> 	<source src=file>
> 	<source fallback> (or <source src="#fallback">?)
> </video>
>

This has been proposed before, it is technically possible, but I don't  
particularly support it because it adds complexity for very little gain.  
Is the only problem we are trying to solve falling back to some legacy  
markup when the video format isn't supported? Given that there are only 2  
relevant formats so far, that doesn't seem like a problem worthwhile  
solving.

-- 
Philip J?genstedt
Core Developer
Opera Software

From philipj at opera.com  Thu Dec  3 06:13:29 2009
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Thu, 03 Dec 2009 15:13:29 +0100
Subject: [whatwg] HTML5 video element - default to fallback in cases
 where UA can't play format
In-Reply-To: <ABD02030-CEBB-4B0F-AAEF-882BB71CF559@iqmultimedia.com.au>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
	<634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
	<op.u4c5pcz0sr6mfa@sisko>
	<2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
	<ABD02030-CEBB-4B0F-AAEF-882BB71CF559@iqmultimedia.com.au>
Message-ID: <op.u4c8gra3sr6mfa@sisko>

On Thu, 03 Dec 2009 14:29:19 +0100, Kit Grose <kit at iqmultimedia.com.au>  
wrote:

> It seems counterintuitive to me that having produced fallback content
> already, I still need to use Javascript to test for compatibility
> (even if I *did* generate two formats, there's obviously no guarantee
> IE9 won't come out requiring WMV or a similar issue with a different
> UA).
>
> Are there any other elements in HTML that _require_ Javascript to
> provide a good UX?

What's wrong with using JavaScript to work around temporary problems? In  
the long term, is there a use case for allowing fallback content?

I'll freely admit that the most important reason I oppose this is because  
I don't want to implement it, because fallback behavior is a mess (see  
<object>). If there is any other browser implementor that thinks fallback  
is a good idea, it might be worth discussing.

-- 
Philip J?genstedt
Core Developer
Opera Software

From kit at iqmultimedia.com.au  Thu Dec  3 06:17:04 2009
From: kit at iqmultimedia.com.au (Kit Grose)
Date: Fri, 4 Dec 2009 01:17:04 +1100
Subject: [whatwg] HTML5 video element - default to fallback in cases
 where UA can't play format
In-Reply-To: <op.u4c8gra3sr6mfa@sisko>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
	<634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
	<op.u4c5pcz0sr6mfa@sisko>
	<2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
	<ABD02030-CEBB-4B0F-AAEF-882BB71CF559@iqmultimedia.com.au>
	<op.u4c8gra3sr6mfa@sisko>
Message-ID: <8B4A2A8C-5083-4579-8AFB-C2E56BEB4D3A@iqmultimedia.com.au>

On 04/12/2009, at 1:13 AM, Philip J?genstedt wrote:
> I'll freely admit that the most important reason I oppose this is  
> because
> I don't want to implement it

And I'll admit that the main reason I support it is selfish on my part  
too :).

Basically I don't want to be producing OGG files (given that I already  
have many H.264 videos available for use that were previously played  
in Flash or QT Player), and the general feeling I'm getting  
(anecdotally) is that FF users are increasingly opting to install  
NoScript.

In practice, that means I'm actually using the <noscript> tag again,  
which makes me feel incredibly dirty.

?Kit

From michaelaarontaylor at gmail.com  Thu Dec  3 06:31:18 2009
From: michaelaarontaylor at gmail.com (Mike Taylor)
Date: Thu, 3 Dec 2009 09:31:18 -0500
Subject: [whatwg] value content attribute of <input>
In-Reply-To: <20091203154535.BED9.C8DE7135@html5.jp>
References: <20091203154535.BED9.C8DE7135@html5.jp>
Message-ID: <7e56b1e10912030631n7a0feccejf6f394bf7393894f@mail.gmail.com>

It's not clear to me that every possible attribute is intended to be in that
table. Autofocus, for example, is missing as well.

However, the first time I read through that table I did do a double-take.

Mike T.

On Thu, Dec 3, 2009 at 1:48 AM, Futomi Hatano <info at html5.jp> wrote:

> Hi all
>
> Could you please see the section in the spec?
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element
>
> There is a table which includes summarizes which of content attributes, IDL
> attributes, methods, and events apply to each state.
> Is the value content attribute needed to include to the table, isn't it?
>
> --
> Futomi Hatano
> www.html5.jp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091203/a8ac1628/attachment.htm>

From oliver at apple.com  Thu Dec  3 08:21:20 2009
From: oliver at apple.com (Oliver Hunt)
Date: Thu, 3 Dec 2009 08:21:20 -0800
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com>
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com>
	<63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com>
	<1259778203.7253.3.camel@nasgul.local>
	<1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com>
	<63df84f0912021420p77637c9atd022b1ac0e904478@mail.gmail.com>
	<1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com>
Message-ID: <59E47AB0-BBEB-4B64-9F20-01BB275FB38F@apple.com>


On Dec 3, 2009, at 4:06 AM, Bjorn Bringert wrote:

> On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert <bringert at google.com> wrote:
>>> I agree that being able to capture and upload audio to a server would
>>> be useful for a lot of applications, and it could be used to do speech
>>> recognition. However, for a web app developer who just wants to
>>> develop an application that uses speech input and/or output, it
>>> doesn't seem very convenient, since it requires server-side
>>> infrastructure that is very costly to develop and run. A
>>> speech-specific API in the browser gives browser implementors the
>>> option to use on-device speech services provided by the OS, or
>>> server-side speech synthesis/recognition.
>> 
>> Again, it would help a lot of you could provide use cases and
>> requirements. This helps both with designing an API, as well as
>> evaluating if the use cases are common enough that a dedicated API is
>> the best solution.
>> 
>> / Jonas
> 
> I'm mostly thinking about speech web apps for mobile devices. I think
> that's where speech makes most sense as an input and output method,
> because of the poor keyboards, small screens, and frequent hands/eyes
> busy situations (e.g. while driving). Accessibility is the other big
> reason for using speech.
Accessibility is already handle through ARIA and the host platforms accessibility features.

> 
> Some ideas for use cases:
> 
> - Search by speaking a query
> - Speech-to-speech translation
> - Voice Dialing (could open a tel: URI to actually make the call)
> - Dialog systems (e.g. the canonical pizza ordering system)
> - Lightweight JavaScript browser extensions (e.g. Greasemonkey /
> Chrome extensions) for using speech with any web site, e.g, for
> accessibility.

I am unsure why the site should be directly responsible for things like audio based accessibility.  What do you believe a site should be doing itself manually vs. the accessibility services provided by the host OS?

> 
> Requirements:
> 
> - Web app developer side:
>   - Allows both speech recognition and synthesis.
ARIA (in conjunction with the OS accessibility services) already provides the accessibility focused text to speech (unsure about recognition side)
> 
>   - Doesn't require web app developer to develop / run his own speech
> recognition / synthesis servers.
This would seem to be "use the OS services"
> 
> - Implementor side:
>   - Easy enough to implement that it can get wide adoption in browsers.
These services are not simple -- any implementation would seem to be a significant amount of work, especially if you want to a) actually be good at it and b) interact with the host OS's native accessibility features.

>   - Allows implementor to use either client-side or server-side
> recognition and synthesis.
I honestly have no idea what you mean by this.

--Oliver

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

From gmaxwell at gmail.com  Thu Dec  3 08:39:36 2009
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Thu, 3 Dec 2009 11:39:36 -0500
Subject: [whatwg] HTML5 video element - default to fallback in cases
	where UA can't play format
In-Reply-To: <8B4A2A8C-5083-4579-8AFB-C2E56BEB4D3A@iqmultimedia.com.au>
References: <72A454D9-A881-4D04-92FF-6AACBAD6EC69@iqmultimedia.com.au>
	<7c2a12e20910271910r5813edcepc10739de78fae4fa@mail.gmail.com>
	<634EB864-ECD9-4301-B95B-04E8CDD53E4D@iqmultimedia.com.au>
	<op.u4c5pcz0sr6mfa@sisko>
	<2D885D58-F9EF-4FAA-B2FE-6E1E66C69BBB@geekhood.net>
	<ABD02030-CEBB-4B0F-AAEF-882BB71CF559@iqmultimedia.com.au>
	<op.u4c8gra3sr6mfa@sisko>
	<8B4A2A8C-5083-4579-8AFB-C2E56BEB4D3A@iqmultimedia.com.au>
Message-ID: <e692861c0912030839k2e4dac2fm1db5800365526e46@mail.gmail.com>

2009/12/3 Kit Grose <kit at iqmultimedia.com.au>:
> On 04/12/2009, at 1:13 AM, Philip J?genstedt wrote:
>> I'll freely admit that the most important reason I oppose this is
>> because
>> I don't want to implement it
>
> And I'll admit that the main reason I support it is selfish on my part
> too :).
>
> Basically I don't want to be producing OGG files (given that I already
> have many H.264 videos available for use that were previously played
> in Flash or QT Player), and the general feeling I'm getting
> (anecdotally) is that FF users are increasingly opting to install
> NoScript.
>
> In practice, that means I'm actually using the <noscript> tag again,
> which makes me feel incredibly dirty.

If they are running noscript then why on earth would you expect
them to have flash enabled?  :)

(1) Flash presents a greater and less controllable privacy exposure
than Javascript does.

(2) Flash is more frequently blamed for obnoxious ads than JS.

(3) Without javascript support a great many flash sites simply don't
work because the copy-and-paste flash version probing used depends
on Javascript.

(4) Flash (and other plugins) are commonly 'known' to trigger firefox
crashes, not so for JS.


Perhaps I'm all wrong? but I don't think your suspicions pass a sniff
test. Someone should try measuring.

From jonas at sicking.cc  Thu Dec  3 08:48:21 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 3 Dec 2009 08:48:21 -0800
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com> 
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com> 
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com> 
	<63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com> 
	<1259778203.7253.3.camel@nasgul.local>
	<1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com> 
	<63df84f0912021420p77637c9atd022b1ac0e904478@mail.gmail.com> 
	<1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com>
Message-ID: <63df84f0912030848o6d3ec2c0q21bd950dfd84f61a@mail.gmail.com>

On Thu, Dec 3, 2009 at 4:06 AM, Bjorn Bringert <bringert at google.com> wrote:
> On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert <bringert at google.com> wrote:
>>> I agree that being able to capture and upload audio to a server would
>>> be useful for a lot of applications, and it could be used to do speech
>>> recognition. However, for a web app developer who just wants to
>>> develop an application that uses speech input and/or output, it
>>> doesn't seem very convenient, since it requires server-side
>>> infrastructure that is very costly to develop and run. A
>>> speech-specific API in the browser gives browser implementors the
>>> option to use on-device speech services provided by the OS, or
>>> server-side speech synthesis/recognition.
>>
>> Again, it would help a lot of you could provide use cases and
>> requirements. This helps both with designing an API, as well as
>> evaluating if the use cases are common enough that a dedicated API is
>> the best solution.
>>
>> / Jonas
>
> I'm mostly thinking about speech web apps for mobile devices. I think
> that's where speech makes most sense as an input and output method,
> because of the poor keyboards, small screens, and frequent hands/eyes
> busy situations (e.g. while driving). Accessibility is the other big
> reason for using speech.
>
> Some ideas for use cases:
>
> - Search by speaking a query
> - Speech-to-speech translation
> - Voice Dialing (could open a tel: URI to actually make the call)

<input type=search>, <input type=text> and <input type=tel> seems like
the correct solution for these. Nothing prevents UAs for allowing
speech rather than keyboard input into these (and I believe that most
do if you have AT tools installed).

> - Dialog systems (e.g. the canonical pizza ordering system)

I saw some pretty cool XHTML+Voice demos a few years ago that did
this. They didn't use speech-to-text scripting APIs though.

> - Lightweight JavaScript browser extensions (e.g. Greasemonkey /
> Chrome extensions) for using speech with any web site, e.g, for
> accessibility.

These would seem like APIs not exposed to webpages, but rather to
extensions. So WHATWG would be the wrong place to standardize them.
And I'm not convinced that this needs speech-to-text scripting APIs
either, but rather simply support for speech rather than keyboard as
text input.

/ Jonas

From fergus at google.com  Thu Dec  3 09:30:12 2009
From: fergus at google.com (Fergus Henderson)
Date: Thu, 3 Dec 2009 12:30:12 -0500
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <1259843522.5368.1.camel@nasgul.local>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com> 
	<f4cd80640912020855y56a46f53h6653cebc7ba7aef4@mail.gmail.com> 
	<1ac456d70912020917y7e401007gd6c19678a9825f8d@mail.gmail.com> 
	<63df84f0912021004u5710d7e6ga48c27e56f833a8c@mail.gmail.com> 
	<1259778203.7253.3.camel@nasgul.local>
	<1ac456d70912021117r59b5cd50nea19a08993858aa@mail.gmail.com> 
	<63df84f0912021420p77637c9atd022b1ac0e904478@mail.gmail.com> 
	<1ac456d70912030406t60ae6914rc84f699db3bc61b6@mail.gmail.com> 
	<1259843522.5368.1.camel@nasgul.local>
Message-ID: <5a76647a0912030930y141ce7cdp1b0619c60b781322@mail.gmail.com>

On Thu, Dec 3, 2009 at 7:32 AM, Diogo Resende <dresende at thinkdigital.pt>wrote:

> I agree 100%. Still, I think the access to the mic and the speech
> recognition could be separated.
>

While it would be possible to separate access to the microphone and speech
recognition, combining them allows the API to abstract away details of the
implementation that would otherwise have to be exposed, in particular the
audio encoding(s) used, and whether the audio is streamed to the recognizer
or sent in a single chunk.  If we don't provide general access to the
microphone, the speech recognition API can be simpler, implementors will
have more flexibility, and implementations can be simpler and smaller
because they won't have to deal with conversions between different audio
encodings.

So I'm in favour of not separating out access to the microphone, at least in
v1 of the API.

-- 
Fergus Henderson <fergus at google.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091203/d7fe4556/attachment.htm>

From ap at webkit.org  Thu Dec  3 09:50:04 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Thu, 03 Dec 2009 09:50:04 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
Message-ID: <9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>


On 02.12.2009, at 23:46, Fumitoshi Ukai (????) wrote:

> If server sends back handshake response and a data frame, and close  
> immediately, fast enough to run JavaScript on browser, how  
> readyState should be?


I'd expect it to work in the same way it works for XMLHttpRequest -  
e.g., in an onreadystate handler of XMLHttpRequest, readyState does  
not change due to background processing of incoming data.

> It seems WebKit/Mac does former, and Chromium does latter, so  
> LayoutTests/websocket/tests/simple.html would fail with Chromium.

For those not involved with WebKit development, the test is available  
at <http://trac.webkit.org/browser/trunk/LayoutTests/websocket/tests/script-tests/simple.js?rev=51615 
 >, and its expected results at <http://trac.webkit.org/browser/trunk/LayoutTests/websocket/tests/simple-expected.txt 
 >.

- WBR, Alexey Proskuryakov


From dresende at thinkdigital.pt  Thu Dec  3 11:31:53 2009
From: dresende at thinkdigital.pt (Diogo Resende)
Date: Thu, 3 Dec 2009 19:31:53 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <5a76647a0912030930y141ce7cdp1b0619c60b781322@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
Message-ID: <1259868713.5368.9.camel@nasgul.local>

I was not thinking of raw access to the mic. I was just thinking of a 2
step method to do it so you could just do 1 step :)

I was thinking of something like:

        1. Call Sound API and ask to record (maybe something like the
        geolocation on Firefox [1]).
        
        2. Pass it to text2speech or save or stream or whatever..

This way one could record audio and do something else like save/stream.
If other want to translate into text, just do the next step.

[1]: http://www.mozilla.com/en-US/firefox/geolocation/

-- 
Diogo Resende <dresende at thinkdigital.pt>
ThinkDigital

On Thu, 2009-12-03 at 12:30 -0500, Fergus Henderson wrote:
> On Thu, Dec 3, 2009 at 7:32 AM, Diogo Resende
> <dresende at thinkdigital.pt> wrote:
>         I agree 100%. Still, I think the access to the mic and the
>         speech
>         recognition could be separated.
> 
> While it would be possible to separate access to the microphone and
> speech recognition, combining them allows the API to abstract away
> details of the implementation that would otherwise have to be exposed,
> in particular the audio encoding(s) used, and whether the audio is
> streamed to the recognizer or sent in a single chunk.  If we don't
> provide general access to the microphone, the speech recognition API
> can be simpler, implementors will have more flexibility, and
> implementations can be simpler and smaller because they won't have to
> deal with conversions between different audio encodings.
> 
> So I'm in favour of not separating out access to the microphone, at
> least in v1 of the API.
> 
> -- 
> Fergus Henderson <fergus at google.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091203/5b351073/attachment.pgp>

From chuck at jumis.com  Thu Dec  3 12:21:28 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Thu, 03 Dec 2009 12:21:28 -0800
Subject: [whatwg] Canvas Composition Modes
Message-ID: <4B181DC8.1050504@jumis.com>

Hey List:

I was just following up to the composition thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023706.html

Where in the spec did this "more explicit" definition get added?

......

 From the thread, Ian's post.


> ... Safari and Chrome currently do bound composition to the shape, and
> always have, then surely it's not too late to spec that?

"The problem is in defining what this means, exactly. As Philip 
mentioned, other browsers do do what the spec says (Opera in particular 
does a very good job)... I've made this more explicit, though."

Did this issue get resolved with the Mozilla crew, and others?
Has the spec been updated to a point where it's not ambiguous. We're all
leaning toward the Safari-Chrome behavior.

-Charles






From ap at apple.com  Thu Dec  3 13:43:10 2009
From: ap at apple.com (Alexey Proskuryakov)
Date: Thu, 03 Dec 2009 13:43:10 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
Message-ID: <98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>


On 03.12.2009, at 9:50, Alexey Proskuryakov wrote:

>> If server sends back handshake response and a data frame, and close  
>> immediately, fast enough to run JavaScript on browser, how  
>> readyState should be?
>
> I'd expect it to work in the same way it works for XMLHttpRequest -  
> e.g., in an onreadystate handler of XMLHttpRequest, readyState does  
> not change due to background processing of incoming data.


On the other hand, it can't possibly work like XMLHttpRequest - for  
whatever reason, the Web Sockets spec says that events are posted  
asynchronously. Maybe I'm not the last an only one to get confused by  
this difference from XMLHttpRequest events.

In light of this, I think that the test in question is incorrect.

- WBR, Alexey Proskuryakov


From robert at ocallahan.org  Thu Dec  3 14:24:55 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 4 Dec 2009 11:24:55 +1300
Subject: [whatwg] Canvas Composition Modes
In-Reply-To: <4B181DC8.1050504@jumis.com>
References: <4B181DC8.1050504@jumis.com>
Message-ID: <11e306600912031424u399eac13y562b335333333863@mail.gmail.com>

On Fri, Dec 4, 2009 at 9:21 AM, Charles Pritchard <chuck at jumis.com> wrote:

> I was just following up to the composition thread:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023706.html
>
> Where in the spec did this "more explicit" definition get added?
>

http://www.whatwg.org/specs/web-apps/current-work/#drawing-model
"1. Render the shape or image onto an infinite transparent black bitmap,
creating image A..."
"6. Composite A within the clipping region over the current canvas bitmap
using the current composition operator."

Did this issue get resolved with the Mozilla crew, and others?
>

We will fix our implementation to conform to the spec. I wrote some patches,
expect it to be fixed in Firefox 3.7. (On Windows and X we're already
correct, except for 'copy' ... on Mac, less so.)

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091204/03a1aa58/attachment.htm>

From ian at hixie.ch  Thu Dec  3 15:38:11 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Dec 2009 23:38:11 +0000 (UTC)
Subject: [whatwg] US-ASCII vs. ASCII in Web Socket Protocol
In-Reply-To: <9124e09b0911052218y5106a2d4qcda01ff67577679b@mail.gmail.com>
References: <9124e09b0911052218y5106a2d4qcda01ff67577679b@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912032337580.15540@hixie.dreamhostps.com>

On Fri, 6 Nov 2009, Yuzo Fujishima wrote:
>
> I see both "US-ASCII" and "ASCII" are used in: 
> http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54
> 
> If they mean the same thing, one should be used consistently.
> 
> In the document, US-ASCII seems to mean encoding while ASCII mean 
> charset. Is this common? (I guess US-ASCII is commonly considered as an 
> alias for ASCII. http://en.wikipedia.org/wiki/ASCII#Aliases )

I've changed the spec to use "ASCII" consistently.

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

From ian at hixie.ch  Thu Dec  3 15:42:55 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Dec 2009 23:42:55 +0000 (UTC)
Subject: [whatwg] Web Socket Protocol: Handling of erroneous UTF-8 on
 the	server side?
In-Reply-To: <9124e09b0911052312s58fb1689va7fddad50265baae@mail.gmail.com>
References: <9124e09b0911052312s58fb1689va7fddad50265baae@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912032342040.15540@hixie.dreamhostps.com>

On Fri, 6 Nov 2009, Yuzo Fujishima wrote:
> 
> Section 4.4 of 
> http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54 specifies 
> how erroneous UTF-8 must be handled on the client side.
> 
> Does the same apply for the server side?

It does not; the server-side processing of these errors is undefined 
(since it can be defined at the subprotocol level). I've added a section 
explicitly stating this.

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

From ian at hixie.ch  Thu Dec  3 15:43:53 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Dec 2009 23:43:53 +0000 (UTC)
Subject: [whatwg] Web Socket Protocol: How Lenient Server Should Be in
 Handshake?
In-Reply-To: <9124e09b0911060039y2ac6fbbfgb2914e428390a8c7@mail.gmail.com>
References: <9124e09b0911060039y2ac6fbbfgb2914e428390a8c7@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912032343060.15540@hixie.dreamhostps.com>

On Fri, 6 Nov 2009, Yuzo Fujishima wrote:
> 
> As far as I can read from
> http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54#section-5.2
> the server should (or must?) accept requests starting with, say:
>    POST<SPACE>/some/resource<SPACE>HTTP/1.0
> or, even
>    <SPACE>/some/resource<SPACE>
> 
> Is a server expected to be this lenient?

The server is allowed to completely ignore the client side of the 
handshake, but may also apply as strict processing as desired. Yesterday I 
updated the server-side requirements to be clearer on this matter.

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

From ian at hixie.ch  Thu Dec  3 15:57:02 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Dec 2009 23:57:02 +0000 (UTC)
Subject: [whatwg] Web sockets and existing HTTP stacks
In-Reply-To: <557ae280911200711i5493e654k67c1f5f07336bfb9@mail.gmail.com>
References: <557ae280911171402v7546e5e7n93a1e57f87dc10e5@mail.gmail.com>
	<557ae280911200711i5493e654k67c1f5f07336bfb9@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912032347360.15540@hixie.dreamhostps.com>

On Tue, 17 Nov 2009, Christian Biesinger wrote:
> 
> Is it intentional that it is impossible to implement this spec over an 
> existing HTTP stack, as currently specified?

Only to the same extent that it is "intentional" that it's impossible to 
implement Telnet or SSH over an existing HTTP stack.


> In particular, due to the strict requirements on the headers to send, it 
> seems like you can't really implement it with an existing HTTP stack. On 
> the other hand, you really do want to reuse your HTTP implementation, 
> because otherwise you have to reimplement all your HTTP proxy 
> authentication, including NTLM, GSSAPI, etc. Obviously another problem 
> would be that the actual bidirectional communication might be hard to 
> fit into your HTTP implementation, but that might be easier to work 
> around.

Yeah, it's likely that the code reuse theoretically made possible by 
reusing the HTTP proxy and cookie infrastructure is more theoretical than 
practical in many cases. I had hoped that it would be easier.

I guess it might still be possible if the relevant code can be abstracted 
out somehow, but that might result in code that feels a little twisted.

It's not clear what to do about this; we could limit the proxy support to 
just SOCKS, but that seems suboptimal.


(Similar problems exist on the server-side if you try to use an HTTP stack 
to implement WebSocket, though on that side there is far less reason to do 
so, since there's no proxy code to reuse and the cookie code that could be 
reused is minimal and more easily abstractable. The problem only really 
exists in the more advanced case of sharing a port with an HTTP server. 
The complexity there is considered acceptable because few people should 
ever have to write that code, compared to the number of people writing a 
straight WebSocket server.)

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

From info at html5.jp  Thu Dec  3 16:05:00 2009
From: info at html5.jp (Futomi Hatano)
Date: Fri, 04 Dec 2009 09:05:00 +0900
Subject: [whatwg] value content attribute of <input>
In-Reply-To: <7e56b1e10912030631n7a0feccejf6f394bf7393894f@mail.gmail.com>
References: <20091203154535.BED9.C8DE7135@html5.jp>
	<7e56b1e10912030631n7a0feccejf6f394bf7393894f@mail.gmail.com>
Message-ID: <20091204085420.770C.C8DE7135@html5.jp>

On Thu, 3 Dec 2009 09:31:18 -0500
Mike Taylor <michaelaarontaylor at gmail.com> wrote:

> It's not clear to me that every possible attribute is intended to be in that
> table. Autofocus, for example, is missing as well.

Exactly.
The table seems to list attributes defined for only <input>.
Attributes common to form controls(autofocus, disabled, form, name, value) seem to be excluded.
I understand the purpose of the table.
Thanks for your insight.

--
Futomi Hatano
www.html5.jp


From ian at hixie.ch  Thu Dec  3 17:55:50 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Dec 2009 01:55:50 +0000 (UTC)
Subject: [whatwg] Web Sockets URL
In-Reply-To: <644ACF88-438C-4526-A544-FF513A1AE38B@webkit.org>
References: <644ACF88-438C-4526-A544-FF513A1AE38B@webkit.org>
Message-ID: <Pine.LNX.4.62.0912040151230.15540@hixie.dreamhostps.com>

On Wed, 2 Dec 2009, Alexey Proskuryakov wrote:
>
> Currently, the Web Sockets API spec says that the WebSocket.URL 
> attribute must just return a value that was passed to the WebSocket 
> constructor. This doesn't match how many other url accessors work, and 
> consequentially, it doesn't match what currently happens in WebKit.
> 
> I think it makes more sense to return a resolved URL - e.g. (new
> WebSocket("ws://host/path/../")).URL would return "ws://host/".

I've changed the spec to say that the .URL attribute must return the same 
string as is actually used by the protocol spec (i.e. post-resolve). 
Whether this does "../" resolution will depend on what the IRI specs end 
up saying when we switch to relying on those.

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

From ian at hixie.ch  Thu Dec  3 18:07:57 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Dec 2009 02:07:57 +0000 (UTC)
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
Message-ID: <Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>

On Thu, 3 Dec 2009, Fumitoshi Ukai (??~\????~V~G?~U~O) wrote:
>
> I've question about thread to run Web Socket feedback from the protocol.
> 
> If server sends back handshake response and a data frame, and close 
> immediately, fast enough to run JavaScript on browser, how readyState 
> should be?
> 1) When client recognizes handshake response header, it changes readyState
> to OPEN  and queue a task to fire a simple event named "open".
> 2) Then client reads a data frame, and queue a task to fire a MessageEvent.
> 3) Then client recognizes the socket is closed, it changes readyState to
> CLOSED and queue a task to fire a simple event named "close".
> 
> I'm wondering this process should be done on the same thread of the
> JavaScript, or may be on the different thread.

It may be done on a different thread. (It doesn't _have_ to be done on a 
different thread; that would be indistinguishable from a slower network.)


> If it should run on the same thread,  1) would be processed after JavaScript
> code is processed. Thus, readyState is OPEN when it receives "open" event.
> However, if it may run on the different thread, 1)-3) might be processed
> before JavaScript code is processed.  So, readyState might be CLOSED when it
> receives "open" event.
> 
> Which is correct behavior?
> It seems WebKit/Mac does former, and Chromium does latter, so
> LayoutTests/websocket/tests/simple.html would fail with Chromium.

Both are correct. The test is incorrect in that it cannot predict what the 
readyState will be unless it has very strict timing relative to the 
server. (Such tests should exist, of course, but they are more complicated 
to write.)


On Thu, 3 Dec 2009, Alexey Proskuryakov wrote:
> 
> I'd expect it to work in the same way it works for XMLHttpRequest - 
> e.g., in an onreadystate handler of XMLHttpRequest, readyState does not 
> change due to background processing of incoming data.

On Thu, 3 Dec 2009, Alexey Proskuryakov wrote:
> 
> On the other hand, it can't possibly work like XMLHttpRequest - for 
> whatever reason, the Web Sockets spec says that events are posted 
> asynchronously. Maybe I'm not the last an only one to get confused by 
> this difference from XMLHttpRequest events.

I could change the spec to make the readyState attribute changes be 
queued along with the event dispatch, but then we'd have a situation 
whereby the "actual" state of the websocket object might not match the 
state returned by the attribute. Is that preferred?

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

From ukai at chromium.org  Thu Dec  3 22:05:08 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Fri, 4 Dec 2009 15:05:08 +0900
Subject: [whatwg] Web Sockets URL
In-Reply-To: <Pine.LNX.4.62.0912040151230.15540@hixie.dreamhostps.com>
References: <644ACF88-438C-4526-A544-FF513A1AE38B@webkit.org> 
	<Pine.LNX.4.62.0912040151230.15540@hixie.dreamhostps.com>
Message-ID: <de17d48e0912032205k7dd49d26q8364f3eb36e51ce7@mail.gmail.com>

On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 2 Dec 2009, Alexey Proskuryakov wrote:
> >
> > Currently, the Web Sockets API spec says that the WebSocket.URL
> > attribute must just return a value that was passed to the WebSocket
> > constructor. This doesn't match how many other url accessors work, and
> > consequentially, it doesn't match what currently happens in WebKit.
> >
> > I think it makes more sense to return a resolved URL - e.g. (new
> > WebSocket("ws://host/path/../")).URL would return "ws://host/".
>
> I've changed the spec to say that the .URL attribute must return the same
> string as is actually used by the protocol spec (i.e. post-resolve).
> Whether this does "../" resolution will depend on what the IRI specs end
> up saying when we switch to relying on those.
>

Should (new WebSocket("ws://host/path#frag")).URL be "ws://host/path" rather
than "ws://host/path#frag" ?
It seems "Resolving Web addresses" will drop fragment component according
to http://www.w3.org/html/wg/href/draft.html,
but I'd like to confirm it.

-- 
ukai


> --
> 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/20091204/c6e318b7/attachment.htm>

From ian at hixie.ch  Fri Dec  4 03:38:18 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Dec 2009 11:38:18 +0000 (UTC)
Subject: [whatwg] Web Sockets URL
In-Reply-To: <de17d48e0912032205k7dd49d26q8364f3eb36e51ce7@mail.gmail.com>
References: <644ACF88-438C-4526-A544-FF513A1AE38B@webkit.org> 
	<Pine.LNX.4.62.0912040151230.15540@hixie.dreamhostps.com>
	<de17d48e0912032205k7dd49d26q8364f3eb36e51ce7@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912041004180.32245@hixie.dreamhostps.com>

On Fri, 4 Dec 2009, Fumitoshi Ukai (??~\????~V~G?~U~O) wrote:
> On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 2 Dec 2009, Alexey Proskuryakov wrote:
> > >
> > > Currently, the Web Sockets API spec says that the WebSocket.URL 
> > > attribute must just return a value that was passed to the WebSocket 
> > > constructor. This doesn't match how many other url accessors work, 
> > > and consequentially, it doesn't match what currently happens in 
> > > WebKit.
> > >
> > > I think it makes more sense to return a resolved URL - e.g. (new 
> > > WebSocket("ws://host/path/../")).URL would return "ws://host/".
> >
> > I've changed the spec to say that the .URL attribute must return the 
> > same string as is actually used by the protocol spec (i.e. 
> > post-resolve). Whether this does "../" resolution will depend on what 
> > the IRI specs end up saying when we switch to relying on those.
> 
> Should (new WebSocket("ws://host/path#frag")).URL be "ws://host/path" 
> rather than "ws://host/path#frag" ? It seems "Resolving Web addresses" 
> will drop fragment component according to 
> http://www.w3.org/html/wg/href/draft.html, but I'd like to confirm it.

I hadn't considered #fragment components. I've changed the spec to say 
that the constructor will throw an exception if one is present. ws: and 
wss: URLs can't have fragment identifiers in this version of the protocol.

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

From annevk at opera.com  Fri Dec  4 04:12:01 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 04 Dec 2009 13:12:01 +0100
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
Message-ID: <op.u4exibm164w2qv@annevk-t60>

On Thu, 03 Dec 2009 22:43:10 +0100, Alexey Proskuryakov <ap at apple.com>  
wrote:
> On the other hand, it can't possibly work like XMLHttpRequest - for  
> whatever reason, the Web Sockets spec says that events are posted  
> asynchronously. Maybe I'm not the last an only one to get confused by  
> this difference from XMLHttpRequest events.

XMLHttpRequest network events are "asynchronous" too.


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

From webmartians at verizon.net  Fri Dec  4 04:52:12 2009
From: webmartians at verizon.net (WeBMartians)
Date: Fri, 04 Dec 2009 07:52:12 -0500
Subject: [whatwg] US-ASCII vs. ASCII in Web Socket Protocol
In-Reply-To: <Pine.LNX.4.62.0912032337580.15540@hixie.dreamhostps.com>
References: <9124e09b0911052218y5106a2d4qcda01ff67577679b@mail.gmail.com>
	<Pine.LNX.4.62.0912032337580.15540@hixie.dreamhostps.com>
Message-ID: <4B1905FC.1000205@verizon.net>

Hmmm... Maybe it would be better to say ISO-646US rather than ASCII. 
There is a lot of impreciseness about the very low value characters 
(less than 0x20 space) in the ASCII "specifications." The same can be 
said about the higher end.
===
Ian Hickson wrote:
> On Fri, 6 Nov 2009, Yuzo Fujishima wrote:
>   
>> I see both "US-ASCII" and "ASCII" are used in: 
>> http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54
>>
>> If they mean the same thing, one should be used consistently.
>>
>> In the document, US-ASCII seems to mean encoding while ASCII mean 
>> charset. Is this common? (I guess US-ASCII is commonly considered as an 
>> alias for ASCII. http://en.wikipedia.org/wiki/ASCII#Aliases )
>>     
>
> I've changed the spec to use "ASCII" consistently.
>
> Cheers,
>   


From Olli.Pettay at helsinki.fi  Fri Dec  4 06:51:22 2009
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Fri, 04 Dec 2009 16:51:22 +0200
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <6e608abf0912021650h52d6c6f2ha44d8559f181c3e8@mail.gmail.com>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>	<op.u4br8tck2q99of@id-c0981>
	<6e608abf0912021650h52d6c6f2ha44d8559f181c3e8@mail.gmail.com>
Message-ID: <4B1921EA.3000009@helsinki.fi>

Indeed the API should be something significantly simpler than X+V.
Microsoft has (had?) support for SALT. That API is pretty simple and
provides speech recognition and TTS.
The API could be probably even simpler than SALT.
IIRC, there was an extension for Firefox to support SALT (well, there 
was also an extension to support X+V).

If the platform/OS provides ASR and TTS, adding a JS API for it should
be pretty simple. X+V tries to handle some logic using VoiceXML FIA, but
I think it would be more web-like to give pure JS API (similar to SALT).
Integrating visual and voice input could be done in scripts. I'd assume
there would be some script libraries to handle multimodal input 
integration - especially if there will be touch and gestures events too 
etc. (Classic multimodal map applications will become possible in web.)

But this all is something which should be possibly designed in or with 
W3C multimodal working group. I know their current architecture is way 
more complex, but X+X, SALT and even Multimodal-CSS has been discussed 
in that working group.


-Olli



On 12/3/09 2:50 AM, Dave Burke wrote:
> We're envisaging a simpler programmatic API that looks familiar to the
> modern Web developer but one which avoids the legacy of dialog system
> languages.
>
> Dave
>
> On Wed, Dec 2, 2009 at 7:25 PM, Jo?o Eiras <joaoe at opera.com
> <mailto:joaoe at opera.com>> wrote:
>
>     On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert
>     <bringert at google.com <mailto:bringert at google.com>> wrote:
>
>         We've been watching our colleagues build native apps that use speech
>         recognition and speech synthesis, and would like to have JavaScript
>         APIs that let us do the same in web apps. We are thinking about
>         creating a lightweight and implementation-independent API that lets
>         web apps use speech services. Is anyone else interested in that?
>
>         Bjorn Bringert, David Singleton, Gummi Hafsteinsson
>
>
>     This exists already, but only Opera supports it, although there are
>     problems with the library we use for speech recognition.
>
>     http://www.w3.org/TR/xhtml+voice/
>     http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/
>
>     Would be nice to revive that specification and get vendor buy-in.
>
>
>
>     --
>
>     Jo?o Eiras
>     Core Developer, Opera Software ASA, http://www.opera.com/
>
>


From parasyte at kodewerx.org  Fri Dec  4 09:30:44 2009
From: parasyte at kodewerx.org (Jason Oster)
Date: Fri, 04 Dec 2009 10:30:44 -0700
Subject: [whatwg] Canvas pixel manipulation and performance
In-Reply-To: <4C20FD7E-0A26-4BBC-A058-6BE7D3B6391A@kodewerx.org>
References: <5E9E6D0D-8E6B-469A-AA7D-8CAD8FE54B91@kodewerx.org>	<9DFACC0E-2E02-46C5-8A5C-63ACD3E2C84B@kodewerx.org>	<4B12021C.6010809@mit.edu>	<26B35BF2-C577-4C99-9143-CBAD9350F22B@kodewerx.org>	<4B12D3A9.5040607@mit.edu>	<61E0B1B4-0DB1-44BB-B01C-36FF4A68A530@kodewerx.org>	<4B12E027.7060401@mit.edu>
	<4C20FD7E-0A26-4BBC-A058-6BE7D3B6391A@kodewerx.org>
Message-ID: <4B194744.2050601@kodewerx.org>

I guess this suggestion to access the full pixel data in a single array 
element has fallen by the wayside.  Are there any direct objections to 
including additional API to allow this kind of behavior?  It seems most 
developers believe it would be unnecessary, but I haven't heard much in 
the way of reasoning (technical nor personal).

I cannot comment on the "typical uses" of accessing pixel data from 
script; if it is [in general] more important to have each of the R,G,B,A 
components separated for script access, or not.  But for cases involving 
indexed palettes, having the ability to directly treat each pixel as a 
single property is very much desired.

It is not going to provide a huge boost in performance.  At worst, it 
will help make code cleaner.  But at best, it will do that and 
[slightly?] reduce the performance penalty of reading/writing 3 
superfluous (in my eyes) array accesses.  The only negative aspect I can 
think of with additional API functions is the introduction of new 
developer confusion; "Which one do I use?"

Thanks for listening,
Jay

From ap at webkit.org  Fri Dec  4 09:52:08 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 04 Dec 2009 09:52:08 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <op.u4exibm164w2qv@annevk-t60>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<op.u4exibm164w2qv@annevk-t60>
Message-ID: <640BBD67-35D5-4648-98F7-B512F3D5BCF3@webkit.org>


On 04.12.2009, at 4:12, Anne van Kesteren wrote:

>> On the other hand, it can't possibly work like XMLHttpRequest - for  
>> whatever reason, the Web Sockets spec says that events are posted  
>> asynchronously. Maybe I'm not the last an only one to get confused  
>> by this difference from XMLHttpRequest events.
>
> XMLHttpRequest network events are "asynchronous" too.


Looks like the spec says so now. Does any browser post XMLHttpRequest  
events asynchronously? This change in the spec is not harmless, as it  
seems to make readystatechange event pretty much useless.

- WBR, Alexey Proskuryakov


From ap at webkit.org  Fri Dec  4 10:07:32 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 04 Dec 2009 10:07:32 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
Message-ID: <3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>


On 03.12.2009, at 18:07, Ian Hickson wrote:

> I could change the spec to make the readyState attribute changes be
> queued along with the event dispatch,

I do not understand why the events are queued, to begin with.  
Synchronous dispatch seems more useful to authors, as it gives more  
guarantees about connection state when handling the event.  
Implementations have always dealt with the necessary book-keeping to  
present asynchronous networking events in a synchronous manner, and I  
don't think think it's been a problem.

An implementation that keeps parts of WebSocket logic in a different  
thread or process will need to queue readyState event changes as you  
describe, but that will be an implementation detail.

> but then we'd have a situation
> whereby the "actual" state of the websocket object might not match the
> state returned by the attribute.


This doesn't sounds like an issue to me. The "actual" state is always  
out of sync, because client and server have different ideas of actual  
state. So does an Ethernet controller, OS interrupt handler, low level  
OS networking code, etc. The only state that matters client-side is  
what JavaScript code sees, and all the intermediaries must (and do)  
act as if that were the real thing.

- WBR, Alexey Proskuryakov


From ap at webkit.org  Fri Dec  4 14:01:04 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 04 Dec 2009 14:01:04 -0800
Subject: [whatwg] Application cache updating synchronicity
Message-ID: <919BBBB0-8657-4F61-A917-F7E70FAFFFF3@webkit.org>

Recently, a new step was prepended to the application cache update  
algorithm:

"1. Optionally, wait until the permission to start the application  
cache download process has been obtained from the user and until the  
user agent is confident that the network is available. This could  
include doing nothing until the user explicitly opts-in to caching the  
site, or could involve prompting the user for permission. The  
algorithm might never get past this point. (This step is particularly  
intended to be used by user agents running on severely space- 
constrained devices or in highly privacy-sensitive environments)."

It's not clear if it's supposed to synchronous or not. The "doing  
nothing" clause suggests that page loading can continue normally. On  
the other hand, the algorithm says that asynchronous processing only  
begins after step 2, which runs "atomically".

- WBR, Alexey Proskuryakov


From michaeln at google.com  Fri Dec  4 14:24:53 2009
From: michaeln at google.com (Michael Nordman)
Date: Fri, 4 Dec 2009 14:24:53 -0800
Subject: [whatwg] Application cache updating synchronicity
In-Reply-To: <919BBBB0-8657-4F61-A917-F7E70FAFFFF3@webkit.org>
References: <919BBBB0-8657-4F61-A917-F7E70FAFFFF3@webkit.org>
Message-ID: <fa2eab050912041424i3d809c80y74931a74c604f633@mail.gmail.com>

My interpretation of this is that "atomically" is not to be read as
"synchronously" with regard to <html> tag parsing
(which ultimately initiates the update algorithm). Otherwise step 1 could
leave a blank page on the screen indefinitely (which is not the intent
afaict).

A clarification in the spec would help.

Even in the absence of async user-interactions alluded to by step 1,
allowing for async'ness at this point is beneficial since initial page
loading can make progress w/o having to consult the appcache prior to
getting past the <html> tag.

On Fri, Dec 4, 2009 at 2:01 PM, Alexey Proskuryakov <ap at webkit.org> wrote:

> Recently, a new step was prepended to the application cache update
> algorithm:
>
> "1. Optionally, wait until the permission to start the application cache
> download process has been obtained from the user and until the user agent is
> confident that the network is available. This could include doing nothing
> until the user explicitly opts-in to caching the site, or could involve
> prompting the user for permission. The algorithm might never get past this
> point. (This step is particularly intended to be used by user agents running
> on severely space-constrained devices or in highly privacy-sensitive
> environments)."
>
> It's not clear if it's supposed to synchronous or not. The "doing nothing"
> clause suggests that page loading can continue normally. On the other hand,
> the algorithm says that asynchronous processing only begins after step 2,
> which runs "atomically".
>
> - WBR, Alexey Proskuryakov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091204/0574871e/attachment.htm>

From jonas at sicking.cc  Fri Dec  4 14:30:02 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 4 Dec 2009 14:30:02 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <640BBD67-35D5-4648-98F7-B512F3D5BCF3@webkit.org>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com> 
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com> 
	<op.u4exibm164w2qv@annevk-t60>
	<640BBD67-35D5-4648-98F7-B512F3D5BCF3@webkit.org>
Message-ID: <63df84f0912041430v45d55edek674eeec7a67663d6@mail.gmail.com>

On Fri, Dec 4, 2009 at 9:52 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> On 04.12.2009, at 4:12, Anne van Kesteren wrote:
>
>>> On the other hand, it can't possibly work like XMLHttpRequest - for
>>> whatever reason, the Web Sockets spec says that events are posted
>>> asynchronously. Maybe I'm not the last an only one to get confused by this
>>> difference from XMLHttpRequest events.
>>
>> XMLHttpRequest network events are "asynchronous" too.
>
>
> Looks like the spec says so now. Does any browser post XMLHttpRequest events
> asynchronously? This change in the spec is not harmless, as it seems to make
> readystatechange event pretty much useless.

Depends which events we are talking about. Events that are fired as a
result of network activity is inheritly asynchronous since network
events arrive asynchronously. For example "progress" events or "load"
events.

Other events must be synchronous, for example the "readystatechange"
event that is fired during the call to XMLHttpRequest.open, or the
"loadstart" event fired from XMLHttpRequest.send must be fired
synchronously.

However for the events that are fired as a result of network activity,
I see no reason to fire these events asynchronously from that code.
I.e. when a network request is finished, XMLHttpRequest takes several
actions:

* Sets readystate to 4
* Fires "readystatechange"
* Fires "load"
* Fires "loadend"
* Makes responseXML non-null

I see no reason to make these events be fired asynchronously *from the
code that takes all these actions*. In other words, I think the
XMLHttpRequest implementation should look something like:

XMLHttpRequest::OnRequestDone(status) {
  if (status != success) {
    ... error handling ...
    return;
  }

  if (isXMLContentType(contentType)) {
    responseXML = parseAsXML(responseText);
  }

  readystate = 4;
  synchronousDispatch("readystatechange");
  synchronousDispatch("load");
  synchronousDispatch("loadend");
}


Another way to look at it is that I think the following code:

xhr = new XMLHttpRequest;
timerId = setInterval(function() { if(xhr.responseXML)
alert(xhr.responseXML); }, 0);
xhr.open(...);
xhr.send();
xhr.onloadend = function() {
  cancelInterval(timerId);
}

should never ever fire the alert.

The whole purpose of firing events asynchronously is to aid
implementations so that they don't need to have a deep callstack when
the event fires, but instead can ensure to be in a stable state when
firing the event. However if the code in question is already started
asynchronously, such as as a result of a network event, then there is
no reason not to fire synchronously.

Firing events asynchronously always introduces hassles. Typically that
conditions change between when the event was scheduled to be fired,
and when the event actually fires. Many times this means that you have
to keep track of the task that will fire the event and under certain
conditions cancel it if what the event indicates is no longer true.
Thus I think we should as a general rule try to fire synchronously
when this doesn't risk destabilizing implementations.

/ Jonas

From whatwg at adambarth.com  Fri Dec  4 14:57:40 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 4 Dec 2009 14:57:40 -0800
Subject: [whatwg] <form method="DELETE"> and 307 redirects
Message-ID: <7789133a0912041457m3cf02e5erbe96eba5034d443@mail.gmail.com>

The spec lets sites submit forms with PUT or DELETE methods to their
origin server.  What happens if the server responds with a 307
redirect to a foreign origin?  Based on my reading of the fetch
algorithm, the browser will issue a PUT or DELETE request
(respectively) to the foreign origin.  It seems like we want to
generate a network error instead.

Adam

From ap at webkit.org  Fri Dec  4 15:06:35 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 04 Dec 2009 15:06:35 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <63df84f0912041430v45d55edek674eeec7a67663d6@mail.gmail.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<op.u4exibm164w2qv@annevk-t60>
	<640BBD67-35D5-4648-98F7-B512F3D5BCF3@webkit.org>
	<63df84f0912041430v45d55edek674eeec7a67663d6@mail.gmail.com>
Message-ID: <7EABE377-F7DD-4F9B-B216-F751B7DDA014@webkit.org>


On 04.12.2009, at 14:30, Jonas Sicking wrote:

> However for the events that are fired as a result of network activity,
> I see no reason to fire these events asynchronously from that code.


Sounds like we're in complete agreement here. I've missed the change  
from sync to async dispatch when it was made in XHR specs (both v1 and  
v2), and I think that it should be reverted.

- WBR, Alexey Proskuryakov


From kbr at google.com  Fri Dec  4 17:10:01 2009
From: kbr at google.com (Kenneth Russell)
Date: Fri, 4 Dec 2009 17:10:01 -0800
Subject: [whatwg] Canvas pixel manipulation and performance
In-Reply-To: <4B194744.2050601@kodewerx.org>
References: <5E9E6D0D-8E6B-469A-AA7D-8CAD8FE54B91@kodewerx.org>
	<9DFACC0E-2E02-46C5-8A5C-63ACD3E2C84B@kodewerx.org>
	<4B12021C.6010809@mit.edu>
	<26B35BF2-C577-4C99-9143-CBAD9350F22B@kodewerx.org>
	<4B12D3A9.5040607@mit.edu>
	<61E0B1B4-0DB1-44BB-B01C-36FF4A68A530@kodewerx.org>
	<4B12E027.7060401@mit.edu>
	<4C20FD7E-0A26-4BBC-A058-6BE7D3B6391A@kodewerx.org>
	<4B194744.2050601@kodewerx.org>
Message-ID: <921bb10912041710s227c2279l5027c0d454d43a42@mail.gmail.com>

On Fri, Dec 4, 2009 at 9:30 AM, Jason Oster <parasyte at kodewerx.org> wrote:
> I guess this suggestion to access the full pixel data in a single array
> element has fallen by the wayside. ?Are there any direct objections to
> including additional API to allow this kind of behavior? ?It seems most
> developers believe it would be unnecessary, but I haven't heard much in the
> way of reasoning (technical nor personal).
>
> I cannot comment on the "typical uses" of accessing pixel data from script;
> if it is [in general] more important to have each of the R,G,B,A components
> separated for script access, or not. ?But for cases involving indexed
> palettes, having the ability to directly treat each pixel as a single
> property is very much desired.
>
> It is not going to provide a huge boost in performance. ?At worst, it will
> help make code cleaner. ?But at best, it will do that and [slightly?] reduce
> the performance penalty of reading/writing 3 superfluous (in my eyes) array
> accesses. ?The only negative aspect I can think of with additional API
> functions is the introduction of new developer confusion; "Which one do I
> use?"

I think you'd get more traction if you had performance measurements;
minimally, profiles showing that this is hot in your current
application. Ideally, you could do a prototype in one of the browsers
supporting WebGL which exposes the ImageData's backing store as a
WebGLUnsignedIntArray. If this showed a significant speedup it would
provide strong motivation.

-Ken

From parasyte at kodewerx.org  Fri Dec  4 17:30:49 2009
From: parasyte at kodewerx.org (Jason Oster)
Date: Fri, 4 Dec 2009 18:30:49 -0700
Subject: [whatwg] Canvas pixel manipulation and performance
In-Reply-To: <921bb10912041710s227c2279l5027c0d454d43a42@mail.gmail.com>
References: <5E9E6D0D-8E6B-469A-AA7D-8CAD8FE54B91@kodewerx.org>
	<9DFACC0E-2E02-46C5-8A5C-63ACD3E2C84B@kodewerx.org>
	<4B12021C.6010809@mit.edu>
	<26B35BF2-C577-4C99-9143-CBAD9350F22B@kodewerx.org>
	<4B12D3A9.5040607@mit.edu>
	<61E0B1B4-0DB1-44BB-B01C-36FF4A68A530@kodewerx.org>
	<4B12E027.7060401@mit.edu>
	<4C20FD7E-0A26-4BBC-A058-6BE7D3B6391A@kodewerx.org>
	<4B194744.2050601@kodewerx.org>
	<921bb10912041710s227c2279l5027c0d454d43a42@mail.gmail.com>
Message-ID: <1107884C-B82B-4026-AAB3-3EEF00F27EA8@kodewerx.org>

On Dec 4, 2009, at 6:10 PM, Kenneth Russell wrote:
> I think you'd get more traction if you had performance measurements;
> minimally, profiles showing that this is hot in your current
> application. Ideally, you could do a prototype in one of the browsers
> supporting WebGL which exposes the ImageData's backing store as a
> WebGLUnsignedIntArray. If this showed a significant speedup it would
> provide strong motivation.
My current application isn't necessarily the best test bed.  I'll see what I can do to prototype it with some minimal test cases, though.  Thanks for the suggestion.

Jay

From fbuchinger at gmail.com  Sat Dec  5 04:24:36 2009
From: fbuchinger at gmail.com (Franz Buchinger)
Date: Sat, 5 Dec 2009 13:24:36 +0100
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality from a
	worker
Message-ID: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>

Gears introduced the concept of an "offscreen canvas" that doesn't draw
anything in the browser window, but can be used to manipulate images in a
web worker.

I used this functionality to implement a "resize-before-upload" feature in
my photo gallery uploader. Now I'm trying to port my uploader to HTML5 but
there seems no way to delegate the scaling work to a HTML5 web worker.
Surely I could use the DOM canvas to scale down the photos in the main
"browser thread", but this means that the UI gets blocked during this
process.

If the user chooses more than a few multi-megapixel photos, the
CPU-intensive downscaling will likely freeze the browser and trigger a
script abortion warning.

Are there plans to introduce an "offscreen canvas" in html5? If not, which
workarounds are possible?

kind regards,

Franz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091205/dfc2b925/attachment-0001.htm>

From onesadcookie at gmail.com  Sat Dec  5 17:19:59 2009
From: onesadcookie at gmail.com (Keith Bauer)
Date: Sat, 5 Dec 2009 17:19:59 -0800
Subject: [whatwg] Audio Panning
Message-ID: <f28257050912051719v1922810ciea2c8fafa8731687@mail.gmail.com>

It looks in the current draft spec as if audio is not pannable, and
from Googling it looks like this was at one point considered, but I
can't find an explanation as to what happened between then and now.

Obviously panning is problematic for stereo audio, but with Canvas and
WebGL making browser games more possible, having the ability to pan at
least mono audio seems like a worthwhile addition.

Or is WebGL to be followed shortly by WebAL ;)

-Keith

From ap at webkit.org  Sat Dec  5 23:43:50 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Sat, 05 Dec 2009 23:43:50 -0800
Subject: [whatwg] [hybi]  Web sockets and existing HTTP stacks
In-Reply-To: <Pine.LNX.4.62.0912032347360.15540@hixie.dreamhostps.com>
References: <557ae280911171402v7546e5e7n93a1e57f87dc10e5@mail.gmail.com>
	<557ae280911200711i5493e654k67c1f5f07336bfb9@mail.gmail.com>
	<Pine.LNX.4.62.0912032347360.15540@hixie.dreamhostps.com>
Message-ID: <B348F42F-FB99-450A-ABD9-B74B37A1F997@webkit.org>


03.12.2009, ? 15:57, Ian Hickson ???????(?):

> Yeah, it's likely that the code reuse theoretically made possible by 
> reusing the HTTP proxy and cookie infrastructure is more theoretical than 
> practical in many cases. I had hoped that it would be easier.
> 
> I guess it might still be possible if the relevant code can be abstracted 
> out somehow, but that might result in code that feels a little twisted.


FWIW, we got a quite reasonable amount of code reuse with HTTP cookie and proxy support. This is mostly because our networking layer already had support for establishing streaming connections over proxies, but the point stands, as the actual implementation is shared.

- WBR, Alexey Proskuryakov


From ukai at chromium.org  Sun Dec  6 18:29:49 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Mon, 7 Dec 2009 11:29:49 +0900
Subject: [whatwg] Web Sockets URL
In-Reply-To: <Pine.LNX.4.62.0912041004180.32245@hixie.dreamhostps.com>
References: <644ACF88-438C-4526-A544-FF513A1AE38B@webkit.org> 
	<Pine.LNX.4.62.0912040151230.15540@hixie.dreamhostps.com> 
	<de17d48e0912032205k7dd49d26q8364f3eb36e51ce7@mail.gmail.com> 
	<Pine.LNX.4.62.0912041004180.32245@hixie.dreamhostps.com>
Message-ID: <de17d48e0912061829m64c29f47sa799b09bf512451d@mail.gmail.com>

On Fri, Dec 4, 2009 at 8:38 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 4 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:
> > On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Wed, 2 Dec 2009, Alexey Proskuryakov wrote:
> > > >
> > > > Currently, the Web Sockets API spec says that the WebSocket.URL
> > > > attribute must just return a value that was passed to the WebSocket
> > > > constructor. This doesn't match how many other url accessors work,
> > > > and consequentially, it doesn't match what currently happens in
> > > > WebKit.
> > > >
> > > > I think it makes more sense to return a resolved URL - e.g. (new
> > > > WebSocket("ws://host/path/../")).URL would return "ws://host/".
> > >
> > > I've changed the spec to say that the .URL attribute must return the
> > > same string as is actually used by the protocol spec (i.e.
> > > post-resolve). Whether this does "../" resolution will depend on what
> > > the IRI specs end up saying when we switch to relying on those.
> >
> > Should (new WebSocket("ws://host/path#frag")).URL be "ws://host/path"
> > rather than "ws://host/path#frag" ? It seems "Resolving Web addresses"
> > will drop fragment component according to
> > http://www.w3.org/html/wg/href/draft.html, but I'd like to confirm it.
>
> I hadn't considered #fragment components. I've changed the spec to say
> that the constructor will throw an exception if one is present. ws: and
> wss: URLs can't have fragment identifiers in this version of the protocol.
>

Ok.  I'll fix WebKit to follow the spec.
Thanks!
-- 
ukai


>
> --
> 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/20091207/9099dd58/attachment.htm>

From ukai at chromium.org  Sun Dec  6 20:58:06 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Mon, 7 Dec 2009 13:58:06 +0900
Subject: [whatwg] WebSocket sub protocol name.
Message-ID: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com>

Hi,

At 1.130 of "The Web Socket API", it adds the sub-protocol name must be an
ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR)
characters in it.
But "The Web Socket protocol" 3.1 Parsing Web Socket URLs, says
   1.   If /protocol/ is specified but is either the empty string or
        contains characters that are not in the range U+0021 to U+007E,
        then fail this algorithm.

Alghough I think it should not be a part of "Parsing Web Socket URLs", but
the /protocol/ here is talking about sub-protocol name in Web Socket
constructor, right?
I'm wondering why "The Web Socket API" has loose definition about
sub-protocol name.  If sub-protocol name contains a character less than
U+0021, it fails and throw a SYNTAX_ERR exception ?

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

From sigbjorn.finne at gmail.com  Sun Dec  6 22:18:53 2009
From: sigbjorn.finne at gmail.com (Sigbjorn Finne)
Date: Mon, 07 Dec 2009 07:18:53 +0100
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality
 from a worker
In-Reply-To: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>
Message-ID: <4B1C9E4D.1010901@gmail.com>

On 12/5/2009 13:24, Franz Buchinger wrote:
> Gears introduced the concept of an "offscreen canvas" that doesn't draw
> anything in the browser window, but can be used to manipulate images in a
> web worker.
>
> I used this functionality to implement a "resize-before-upload" feature in
> my photo gallery uploader. Now I'm trying to port my uploader to HTML5 but
> there seems no way to delegate the scaling work to a HTML5 web worker.
> Surely I could use the DOM canvas to scale down the photos in the main
> "browser thread", but this means that the UI gets blocked during this
> process.
>
> If the user chooses more than a few multi-megapixel photos, the
> CPU-intensive downscaling will likely freeze the browser and trigger a
> script abortion warning.
>
> Are there plans to introduce an "offscreen canvas" in html5? If not, which
> workarounds are possible?
>   
Hi Franz,

ImageData is cloneable via postMessage(), so you could perform some
forms of image processing that way.

--sigbjorn <sof at opera.com>


From ian at hixie.ch  Sun Dec  6 22:21:04 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Dec 2009 06:21:04 +0000 (UTC)
Subject: [whatwg] [hybi] WebSocket sub protocol name.
In-Reply-To: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>

On Mon, 7 Dec 2009, Fumitoshi Ukai (??~\????~V~G?~U~O) wrote:
> 
> At 1.130 of "The Web Socket API", it adds the sub-protocol name must be an
> ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR)
> characters in it.
> But "The Web Socket protocol" 3.1 Parsing Web Socket URLs, says
>    1.   If /protocol/ is specified but is either the empty string or
>         contains characters that are not in the range U+0021 to U+007E,
>         then fail this algorithm.

Woops, that step is a copy-and-paste mistake from a past version. My 
apologies. I've removed that sentence; it should not have been present. 
Control characters are allowed (though using them would be silly).

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

From oliver at apple.com  Sun Dec  6 22:34:46 2009
From: oliver at apple.com (Oliver Hunt)
Date: Sun, 6 Dec 2009 22:34:46 -0800
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality
	from a worker
In-Reply-To: <4B1C9E4D.1010901@gmail.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>
	<4B1C9E4D.1010901@gmail.com>
Message-ID: <9B0D216A-F551-4EDD-9D12-790C5881B952@apple.com>


On Dec 6, 2009, at 10:18 PM, Sigbjorn Finne wrote:

> On 12/5/2009 13:24, Franz Buchinger wrote:
>> Gears introduced the concept of an "offscreen canvas" that doesn't draw
>> anything in the browser window, but can be used to manipulate images in a
>> web worker.
>> 
>> I used this functionality to implement a "resize-before-upload" feature in
>> my photo gallery uploader. Now I'm trying to port my uploader to HTML5 but
>> there seems no way to delegate the scaling work to a HTML5 web worker.
>> Surely I could use the DOM canvas to scale down the photos in the main
>> "browser thread", but this means that the UI gets blocked during this
>> process.
>> 
>> If the user chooses more than a few multi-megapixel photos, the
>> CPU-intensive downscaling will likely freeze the browser and trigger a
>> script abortion warning.
>> 
>> Are there plans to introduce an "offscreen canvas" in html5? If not, which
>> workarounds are possible?
>> 
> Hi Franz,
> 
> ImageData is cloneable via postMessage(), so you could perform some
> forms of image processing that way.

I think the problem is that you lose more or less all native image processing support -- all you have is raw pixels which is fine if you're doing pure pixel manipulation, but unhelpful in many other cases.  Eg. in this case you have to implement your own image scaling logic in JS rather than relying in the (presumably) heavily optimised browser implementation.

That said I'm not sure whether we should really be trying to spec such a feature until we've had more time to see how workers are used in the wild.

> 
> --sigbjorn <sof at opera.com>
> 
--Oliver

From ukai at chromium.org  Sun Dec  6 22:41:15 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Mon, 7 Dec 2009 15:41:15 +0900
Subject: [whatwg] [hybi] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
Message-ID: <de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com>

On Mon, Dec 7, 2009 at 3:21 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 7 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:
> >
> > At 1.130 of "The Web Socket API", it adds the sub-protocol name must be
> an
> > ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR)
> > characters in it.
> > But "The Web Socket protocol" 3.1 Parsing Web Socket URLs, says
> >    1.   If /protocol/ is specified but is either the empty string or
> >         contains characters that are not in the range U+0021 to U+007E,
> >         then fail this algorithm.
>
> Woops, that step is a copy-and-paste mistake from a past version. My
> apologies. I've removed that sentence; it should not have been present.
>

Thanks for fixing.


> Control characters are allowed (though using them would be silly).
>

Why are control characters (except LF and CR) allowed?

-- 
ukai


> --
> 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/20091207/e4848048/attachment.htm>

From ian at hixie.ch  Sun Dec  6 23:26:52 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Dec 2009 07:26:52 +0000 (UTC)
Subject: [whatwg] [hybi] WebSocket sub protocol name.
In-Reply-To: <de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>

On Mon, 7 Dec 2009, Fumitoshi Ukai (??~\????~V~G?~U~O) wrote:
> On Mon, Dec 7, 2009 at 3:21 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 7 Dec 2009, Fumitoshi Ukai (???~\??????~V~G???U~O) wrote:
> > >
> > > At 1.130 of "The Web Socket API", it adds the sub-protocol name must 
> > > be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE 
> > > RETURN (CR) characters in it.
> > > But "The Web Socket protocol" 3.1 Parsing Web Socket URLs, says
> > >    1.   If /protocol/ is specified but is either the empty string or
> > >         contains characters that are not in the range U+0021 to U+007E,
> > >         then fail this algorithm.
> >
> > Woops, that step is a copy-and-paste mistake from a past version. My 
> > apologies. I've removed that sentence; it should not have been 
> > present.
> 
> Thanks for fixing.
> 
> > Control characters are allowed (though using them would be silly).
> 
> Why are control characters (except LF and CR) allowed?

There doesn't seem to be a good reason to exclude them, and excluding them 
would lead to a more complicated processing model.

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

From julian.reschke at gmx.de  Sun Dec  6 23:31:01 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 07 Dec 2009 08:31:01 +0100
Subject: [whatwg] [hybi]   WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com>
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com>
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
Message-ID: <4B1CAF35.40404@gmx.de>

Ian Hickson wrote:
> ...
>>> Control characters are allowed (though using them would be silly).
>> Why are control characters (except LF and CR) allowed?
> 
> There doesn't seem to be a good reason to exclude them, and excluding them 
> would lead to a more complicated processing model.
> ...

There isn't a good reason to disallow control characters in a *name*????

Best regards, Julian

From ukai at chromium.org  Sun Dec  6 23:40:02 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Mon, 7 Dec 2009 16:40:02 +0900
Subject: [whatwg] [hybi] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
Message-ID: <de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com>

On Mon, Dec 7, 2009 at 4:26 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 7 Dec 2009, Fumitoshi Ukai (??~\??~V~G?~U~O) wrote:
> > On Mon, Dec 7, 2009 at 3:21 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Mon, 7 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:
> > > >
> > > > At 1.130 of "The Web Socket API", it adds the sub-protocol name must
> > > > be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE
> > > > RETURN (CR) characters in it.
> > > > But "The Web Socket protocol" 3.1 Parsing Web Socket URLs, says
> > > >    1.   If /protocol/ is specified but is either the empty string or
> > > >         contains characters that are not in the range U+0021 to
> U+007E,
> > > >         then fail this algorithm.
> > >
> > > Woops, that step is a copy-and-paste mistake from a past version. My
> > > apologies. I've removed that sentence; it should not have been
> > > present.
> >
> > Thanks for fixing.
> >
> > > Control characters are allowed (though using them would be silly).
> >
> > Why are control characters (except LF and CR) allowed?
>
> There doesn't seem to be a good reason to exclude them, and excluding them
> would lead to a more complicated processing model.


In HTTP, field-content is TEXT or  combinations of token, separators, and
quoted-string. TEXT, or token, separators excludes CTLs.
So, we must use quoted-string in WebSocket-Protocol: if protocol contains
CTLs?

And, why is it limited to ASCII instead of UTF-8?

-- 
ukai


> --
> 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/20091207/824603a7/attachment.htm>

From ian at hixie.ch  Mon Dec  7 00:05:42 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Dec 2009 08:05:42 +0000 (UTC)
Subject: [whatwg] WebSocket sub protocol name.
In-Reply-To: <de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>


On Mon, 7 Dec 2009, Fumitoshi Ukai (??~\????~V~G?~U~O) wrote:
> > > >
> > > > Control characters are allowed (though using them would be silly).
> > >
> > > Why are control characters (except LF and CR) allowed?
> >
> > There doesn't seem to be a good reason to exclude them, and excluding 
> > them would lead to a more complicated processing model.
> 
> In HTTP, field-content is TEXT or combinations of token, separators, and 
> quoted-string. TEXT, or token, separators excludes CTLs. So, we must use 
> quoted-string in WebSocket-Protocol: if protocol contains CTLs?

Oh, I forgot that HTTP had the no-CTL restriction. Good point. I've 
updated the spec to be consistent with this.


> And, why is it limited to ASCII instead of UTF-8?

Because the HTTP working group refuse to allow UTF-8 in HTTP headers for 
reasons that I don't really understand, and the handshake is supposed to 
be valid HTTP.


On Mon, 7 Dec 2009, Julian Reschke wrote:
> 
> There isn't a good reason to disallow control characters in a *name*????

Not as far as I can tell, no... what would a good reason be?

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

From julian.reschke at gmx.de  Mon Dec  7 00:45:56 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 07 Dec 2009 09:45:56 +0100
Subject: [whatwg] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com>
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com>
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com>
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
Message-ID: <4B1CC0C4.6050700@gmx.de>

Ian Hickson wrote:
> ...
>> And, why is it limited to ASCII instead of UTF-8?
> 
> Because the HTTP working group refuse to allow UTF-8 in HTTP headers for 
> reasons that I don't really understand, and the handshake is supposed to 
> be valid HTTP.
> ...

A change of the default encoding would be incompatible with HTTP/1.1.

> On Mon, 7 Dec 2009, Julian Reschke wrote:
>> There isn't a good reason to disallow control characters in a *name*????
> 
> Not as far as I can tell, no... what would a good reason be?

Consistency with every other single spec on the planet with respect to 
names?

Best regards, Julian

From ukai at chromium.org  Mon Dec  7 02:07:56 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Mon, 7 Dec 2009 19:07:56 +0900
Subject: [whatwg] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com> 
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
Message-ID: <de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com>

On Mon, Dec 7, 2009 at 5:05 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> On Mon, 7 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:
> > > > >
> > > > > Control characters are allowed (though using them would be silly).
> > > >
> > > > Why are control characters (except LF and CR) allowed?
> > >
> > > There doesn't seem to be a good reason to exclude them, and excluding
> > > them would lead to a more complicated processing model.
> >
> > In HTTP, field-content is TEXT or combinations of token, separators, and
> > quoted-string. TEXT, or token, separators excludes CTLs. So, we must use
> > quoted-string in WebSocket-Protocol: if protocol contains CTLs?
>
> Oh, I forgot that HTTP had the no-CTL restriction. Good point. I've
> updated the spec to be consistent with this.
>

In "The Web Sockets API", could you fix the following statement?
  The second, protocol, if present, specifies a sub-protocol that the server
must support for the connection to be successful. The sub-protocol name must
be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN
(CR) characters in it.

IIRC, in old spec draft, protocol should not be an empty string, but current
spec draft accepts it?



>
> > And, why is it limited to ASCII instead of UTF-8?
>
> Because the HTTP working group refuse to allow UTF-8 in HTTP headers for
> reasons that I don't really understand, and the handshake is supposed to
> be valid HTTP.
>

Hmm, then it should be mentioned in The Web Socket protocol 1.2 Protocol
overview?
It looks websocket message accept UTF-8 in handshake message.

-- 
ukai


>
> On Mon, 7 Dec 2009, Julian Reschke wrote:
> >
> > There isn't a good reason to disallow control characters in a *name*????
>
> Not as far as I can tell, no... what would a good reason be?
>
> --
> 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/20091207/7b87b8c3/attachment.htm>

From ian at hixie.ch  Mon Dec  7 02:25:09 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Dec 2009 10:25:09 +0000 (UTC)
Subject: [whatwg] WebSocket sub protocol name.
In-Reply-To: <de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com> 
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
	<de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com>

On Mon, 7 Dec 2009, Fumitoshi Ukai (??~\????~V~G?~U~O) wrote:
> On Mon, Dec 7, 2009 at 5:05 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 7 Dec 2009, Fumitoshi Ukai (???~\??????~V~G???U~O) wrote:
> > > > > >
> > > > > > Control characters are allowed (though using them would be 
> > > > > > silly).
> > > > >
> > > > > Why are control characters (except LF and CR) allowed?
> > > >
> > > > There doesn't seem to be a good reason to exclude them, and 
> > > > excluding them would lead to a more complicated processing model.
> > >
> > > In HTTP, field-content is TEXT or combinations of token, separators, 
> > > and quoted-string. TEXT, or token, separators excludes CTLs. So, we 
> > > must use quoted-string in WebSocket-Protocol: if protocol contains 
> > > CTLs?
> >
> > Oh, I forgot that HTTP had the no-CTL restriction. Good point. I've 
> > updated the spec to be consistent with this.
> 
> In "The Web Sockets API", could you fix the following statement?
>   The second, protocol, if present, specifies a sub-protocol that the server
> must support for the connection to be successful. The sub-protocol name must
> be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN
> (CR) characters in it.

Fixed, thanks.


> IIRC, in old spec draft, protocol should not be an empty string, but 
> current spec draft accepts it?

Man, I'm just incompetent today. Sorry about that. Fixed.


> > > And, why is it limited to ASCII instead of UTF-8?
> >
> > Because the HTTP working group refuse to allow UTF-8 in HTTP headers 
> > for reasons that I don't really understand, and the handshake is 
> > supposed to be valid HTTP.
> 
> Hmm, then it should be mentioned in The Web Socket protocol 1.2 Protocol 
> overview? It looks websocket message accept UTF-8 in handshake message.

There should be no way to _send_ UTF-8 in the handshake at this point, 
given the requirements in the spec, but once you _receive_ the handshake, 
it's no longer HTTP, it's just WebSocket, so you can use UTF-8 fine. (In 
practice it doesn't mean much, since there's nothing in the 
server-to-client handshake other than the client-to-server handshake, so 
if there ever was UTF-8 in the server-to-client handshake, it would either 
be ignored, or the connection would be dropped, depending on where exactly 
the UTF-8 was found.)

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

From simonp at opera.com  Mon Dec  7 07:37:34 2009
From: simonp at opera.com (Simon Pieters)
Date: Mon, 07 Dec 2009 16:37:34 +0100
Subject: [whatwg] Interface objects defined in Web Workers outside workers
Message-ID: <op.u4kq0w0oidj3kv@zcorpandell.linkoping.osa>

It's not clear from the Web Workers spec which interface objects and  
constructors should be available to the non-worker context. Worker and  
SharedWorker obviously should be available, but what about AbstractWorker  
and the others? I think Worker, SharedWorker and ErrorEvent should  
probably be available, but the others not.

-- 
Simon Pieters
Opera Software

From simonp at opera.com  Mon Dec  7 07:49:32 2009
From: simonp at opera.com (Simon Pieters)
Date: Mon, 07 Dec 2009 16:49:32 +0100
Subject: [whatwg] Inconsistent naming for interfaces in workers
Message-ID: <op.u4krkunjidj3kv@zcorpandell.linkoping.osa>

The Navigator and WorkerLocation interfaces in workers have inconsistent  
naming. Please rename the Navigator interface to WorkerNavigator.

-- 
Simon Pieters
Opera Software

From nzakas at yahoo-inc.com  Mon Dec  7 10:51:19 2009
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Mon, 7 Dec 2009 10:51:19 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>

Hi,

 

In a recent investigation into capacity issues, I found that there are
several instances where the browser will make a second to the page based
on resolving empty-string URLs in the several tags. I tested four
instances: <img src="">, <link href="">, <script src="">, and <iframe
src="">. Across major browsers today, the behavior is vastly different:

 

* Internet Explorer 8

  - Make a request for: <img src=""> 

  - Does not make a request for: <link href="">, <script src="">,
<iframe src="">

* Firefox 3

  - Make a request for: <img src="">, <link href="">, <script src=""> 

  - Does not make a request for: < <iframe src="">.

* Firefox 3.5

  - Make a request for: <link href="">, <script src=""> 

  - Does not make a request for: <img src="">,  <iframe src="">

* Safari 4

  - Make a request for:<img src="">,  <link href="">, <script src=""> 

  - Does not make a request for: <iframe src="">

* Chrome 3 (same as Safari)

  - Make a request for:<img src="">,  <link href="">, <script src=""> 

  - Does not make a request for: <iframe src="">

* Opera 10

  - Make a request for: (none) 

  - Does not make a request for: <img src="">,  <link href="">, <script
src="">, <iframe src="">

 

Presently, HTML5 does provide guidance on the correct behavior for <img
src=""> in section 4.8.2, indicating that Firefox 3.5's and Opera 10's
behavior in this regard is correct:

 

"If the base URI of the element is the same as the document's address,
then the src attribute's value must not be the empty string."

 

This seems like it should also apply to the other elements that download
resources automatically. All browsers seem to be in agreement over the
behavior of <iframe src=""> despite a lack of guidance in any HTML spec,
and I'd assume that they will soon all be in agreement over <img
src="">, per the HTML5 spec. It would be nice to formalize this behavior
so that we can get all browsers to act in consistently in these
confusing cases.

 

My opinion is that Opera is the only browser currently doing this in a
reasonable manner, in that it makes a lot of sense to me that an
empty-string URL for an element that automatically downloads a resource
should be considered invalid and ignored. My hypothesis is that these
patterns are most frequently indications of errors rather than an
intentional use of this little-known behavior, and as a result, sending
another request is an unexpected and unwelcome result. For high-volume
web sites, a single mistaken inclusion of one of these patterns
immediately doubles page views, which can introduce capacity issues
(which I've needed to investigate at least twice in the past three
years).

 

I'm interested in what others' opinions on this may be, as this seems
like an important area in which to gain consistency.

 

-Nicholas

 

______________________________________________

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

Morpheus: "My beliefs do not require them to."

 

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

From Simetrical+w3c at gmail.com  Mon Dec  7 11:44:29 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 7 Dec 2009 14:44:29 -0500
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>

On Mon, Dec 7, 2009 at 1:51 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Presently, HTML5 does provide guidance on the correct behavior for <img
> src=??> in section 4.8.2, indicating that Firefox 3.5?s and Opera 10?s
> behavior in this regard is correct:
>
> ?If the base URI of the element is the same as the document?s address, then
> the src attribute?s value must not be the empty string.?

That says that if it's the empty string, the document is invalid.  It
doesn't say what the UA has to do.  The relevant part is:

[[
Unless . . . the element's src attribute has a value that is an
ignored self-reference, then, when an img is created with a src
attribute, and whenever the src attribute is set subsequently, the
user agent must resolve the value of that attribute, relative to the
element, and if that is successful must then fetch that resource. . .
.

The src attribute's value is an ignored self-reference if its value is
the empty string, and the base URI of the element is the same as the
document's address.
]]

This implies user agents don't need to resolve the src or fetch the
element if the src is empty (unless the base URI is non-default).  I
don't think they're prohibited from doing so, since there's no
detectable difference to their user-visible output -- likewise they
might fetch resources speculatively even if not explicitly required
to.  It's kind of pointless, though.

The other cases seem to make no specific exception for an empty URL,
so as far as I can tell, the UA must fetch them as usual -- although
of course it might have a valid copy in the cache.

This is clearly not a good idea for <iframe>, since otherwise <iframe
src=""> is an instant infinite loop on a typical page.  The same goes
for a URL that consists only of a fragment.  In fact, a quick test in
the browsers I had handy (Firefox 3.5 and Opera 9.22) suggests that
there are more elaborate protections against recursion here.  Try
saving these two files in the same directory with the names
"test1.html" and "test2.html", and viewing test1.html in a web
browser:

<!doctype html>
<p>1</p>
<iframe src=test2.html>

<!doctype html>
<p>2</p>
<iframe src=test1.html>

Neither browser I tested with has an infinite loop here, although they
terminate at different steps: Firefox displays each page only once
(visible text is 1 2), while Opera displays test1.html twice (1 2 1).
Is this covered by the spec anywhere?

I'm not sure it makes a difference whether <script src=""></script> or
<link rel=stylesheet href=""> does anything special.  It seems simpler
to just leave them as-is, so they fetch the resource again (or
retrieve it from cache if possible) and then probably throw it out as
invalid (since it's HTML and not CSS/JS/etc.).

> I?m interested in what others? opinions on this may be, as this seems like
> an important area in which to gain consistency.

Why?  It seems like fairly unlikely markup.  Consistency is good, but
I wouldn't call this point "important".

From nzakas at yahoo-inc.com  Mon Dec  7 12:05:08 2009
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Mon, 7 Dec 2009 12:05:08 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>

Thanks for the references, this helps my understanding a lot.

The reason I think this is important is because the "just fetch the
resource again" behavior is inherently destructive and unexpected. When
one of these appears on a page, page views double. This isn't a problem
if it's your personal blog, but for high-volume web sites such as
Yahoo!, Google, and Facebook, a 100% increase in traffic causes a lot of
problems. From conversations with engineers at other companies, it seems
that we've all fallen victim to this behavior at one time or another.

I think one would argue that <img src=""> is unlikely markup as well,
yet the spec currently provides guidance around this case. Wouldn't it
make sense to be consistent across tags that act in a similar fashion?

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

-----Original Message-----
From: simetrical at gmail.com [mailto:simetrical at gmail.com] On Behalf Of
Aryeh Gregor
Sent: Monday, December 07, 2009 11:44 AM
To: Nicholas Zakas
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Mon, Dec 7, 2009 at 1:51 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
wrote:
> Presently, HTML5 does provide guidance on the correct behavior for
<img
> src=""> in section 4.8.2, indicating that Firefox 3.5's and Opera 10's
> behavior in this regard is correct:
>
> "If the base URI of the element is the same as the document's address,
then
> the src attribute's value must not be the empty string."

That says that if it's the empty string, the document is invalid.  It
doesn't say what the UA has to do.  The relevant part is:

[[
Unless . . . the element's src attribute has a value that is an
ignored self-reference, then, when an img is created with a src
attribute, and whenever the src attribute is set subsequently, the
user agent must resolve the value of that attribute, relative to the
element, and if that is successful must then fetch that resource. . .
.

The src attribute's value is an ignored self-reference if its value is
the empty string, and the base URI of the element is the same as the
document's address.
]]

This implies user agents don't need to resolve the src or fetch the
element if the src is empty (unless the base URI is non-default).  I
don't think they're prohibited from doing so, since there's no
detectable difference to their user-visible output -- likewise they
might fetch resources speculatively even if not explicitly required
to.  It's kind of pointless, though.

The other cases seem to make no specific exception for an empty URL,
so as far as I can tell, the UA must fetch them as usual -- although
of course it might have a valid copy in the cache.

This is clearly not a good idea for <iframe>, since otherwise <iframe
src=""> is an instant infinite loop on a typical page.  The same goes
for a URL that consists only of a fragment.  In fact, a quick test in
the browsers I had handy (Firefox 3.5 and Opera 9.22) suggests that
there are more elaborate protections against recursion here.  Try
saving these two files in the same directory with the names
"test1.html" and "test2.html", and viewing test1.html in a web
browser:

<!doctype html>
<p>1</p>
<iframe src=test2.html>

<!doctype html>
<p>2</p>
<iframe src=test1.html>

Neither browser I tested with has an infinite loop here, although they
terminate at different steps: Firefox displays each page only once
(visible text is 1 2), while Opera displays test1.html twice (1 2 1).
Is this covered by the spec anywhere?

I'm not sure it makes a difference whether <script src=""></script> or
<link rel=stylesheet href=""> does anything special.  It seems simpler
to just leave them as-is, so they fetch the resource again (or
retrieve it from cache if possible) and then probably throw it out as
invalid (since it's HTML and not CSS/JS/etc.).

> I'm interested in what others' opinions on this may be, as this seems
like
> an important area in which to gain consistency.

Why?  It seems like fairly unlikely markup.  Consistency is good, but
I wouldn't call this point "important".

From bruant at enseirb-matmeca.fr  Mon Dec  7 13:39:31 2009
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Mon, 07 Dec 2009 13:39:31 -0800
Subject: [whatwg] [WebWorkers] Maximum number of workers (was "About the
 delegation example")
Message-ID: <4B1D7613.8080508@enseirb-matmeca.fr>

David Bruant :
> "In the delegation example, the number of workers chosen is an arbitrary 
> 10. But, in a single-core processor, having only one worker will result 
> in more or less the same running time, because at the end, each worker 
> runs on the only core."
>   
Ian Hickson :
"That depends on the algorithm. If the algorithm uses a lot of data, then 
a single hardware thread might be able to run two workers in the same time 
as it runs one, with one worker waiting for data while the other runs 
code, and with the workers trading back and forth.

Personally I would recommend basing the number of workers on the number of 
shards that the input data is split into, and then relying on the UA to 
avoid thrashing. I would expect UAs to notice when a script spawns a 
bazillion workers, and have the UA run them in a staggered fashion, so as 
to not starve the system resources. This is almost certainly needed 
anyway, to prevent pages from DOSing the user's system."

=> Wouldn't it be preferable to have an implementation-dependant "maximum number of workers" and to raise a security exception when this number is reached ? Maximum per domain ? per document ?
Maybe a different maximum for shared and dedicated workers.

Any opinion on this ?

David


From Simetrical+w3c at gmail.com  Mon Dec  7 13:52:41 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 7 Dec 2009 16:52:41 -0500
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>

On Mon, Dec 7, 2009 at 3:05 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> The reason I think this is important is because the "just fetch the
> resource again" behavior is inherently destructive and unexpected. When
> one of these appears on a page, page views double. This isn't a problem
> if it's your personal blog, but for high-volume web sites such as
> Yahoo!, Google, and Facebook, a 100% increase in traffic causes a lot of
> problems. From conversations with engineers at other companies, it seems
> that we've all fallen victim to this behavior at one time or another.

Interesting point.  I've never had this happen to me myself, but I can
see how it might occur as a bug.  If this is the use-case, then the
spec can probably leave out src="#foo" and similar things that would
have an identical effect, because those would be much less likely to
happen as the result of a bug.

> I think one would argue that <img src=""> is unlikely markup as well,
> yet the spec currently provides guidance around this case. Wouldn't it
> make sense to be consistent across tags that act in a similar fashion?

I don't know why <img src=""> has a special exception.  It would be
possible to look through the svn log to see if there was a helpful
commit message, or maybe someone will remember.

From bruant at enseirb-matmeca.fr  Mon Dec  7 14:08:28 2009
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Mon, 07 Dec 2009 14:08:28 -0800
Subject: [whatwg] [Web workers] An attribute describing the "best"
 number of worker to invoke in a delegation use case
In-Reply-To: <Pine.LNX.4.62.0912010942380.1141@hixie.dreamhostps.com>
References: <4AFB7EB5.7010001@enseirb-matmeca.fr>
	<4AFB81E0.7000100@mit.edu>	<4AFC4AB5.7020606@enseirb-matmeca.fr>
	<4AFC66A7.2010404@mit.edu>	<4AFC72D1.9020904@enseirb-matmeca.fr>
	<4AFC7F8A.1050703@mit.edu>	<4AFCA74D.80905@enseirb-matmeca.fr>
	<4AFCA9DB.5000103@mit.edu>
	<Pine.LNX.4.62.0912010942380.1141@hixie.dreamhostps.com>
Message-ID: <4B1D7CDC.6050907@enseirb-matmeca.fr>

Ian Hickson a ?crit :
> On Wed, 11 Nov 2009, David Bruant wrote:
>   
>> This is a new proposal taking into account the feedback I recieved to 
>> the "[WebWorkers] About the delegation example" message.
>>
>> In the delegation example of the WebWorker spec, we can see this line :
>> "var num_workers = 10;"
>>
>> My concern is about the arbitrarity of the "10".
>>     
>
> I agree that it's suboptimal. However, I think realistically a good 
> implementation of parallel work would need some sort of dynamic 
> performance tuning, continuously slowly ramping up the number of workers 
> while it increases throughput, and when throughput decreases, switching to 
> reducing the number of workers until throughput increases again. That 
> would probably be too complicated to show in an example in the spec.
>   
=> As far as I know, if the running time is a decreasing function of the
number of workers (which seems to be a non-such-trivial assumption), the
best algorithm (on average, of course !) is to double the number of
workers until finding a barrier in the running time (find n such as the
max is between [2^n, 2^(n+1)[ ). Then, use a dichotomy algorithm in this
interval.

However, running this algorithm each time a UA comes in your website can
become to be costly.
I think that the spec should say something about "finding the correct
number of thread for your problem" and encourage authors to store their
value with the local storage and add a date to re-run the algorithm if
the value is old (more than two months ?)

>> My point is that this number may be available very easily. For example, 
>> in my dual-core, Linux, Firefox 3.5, the number is 2. Why spare an 
>> information that can be useful and reliable (more than measurement at 
>> least !) ?
>>     
>
> It's actually probably quite rarely 2. It depends on all kinds of factors, 
> like the kind of algorithm, what other programs are running, etc.
>
>
> I still haven't added this feature, as I do not believe the arguments 
> presented form a convincing case. However, if you are still interested in 
> persuing this feature, I encourage you to convince a browser vendor to 
> implement it, as discussed here:
>
>    http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>
> Cheers,
>   
I understand now that my proposition was not very realistic. However, I
think that something should be described in the spec to avoid arbitrary
choices of number of workers.

I'm convinced that with canvas and workers, we will see very soon fancy
web video games with AI. Authors of those games will want to use as many
computation power as possible for their AI, so the "best number of
workers" will be a value that they are interested in.

So, either an "hint" can be provided by the spec through the Navigator
object, either the spec could provide the above described method
(improve my description or ask me to improve it if you want) to find the
"best" number (according to a particular problem).

Thanks,

David

From atwilson at google.com  Mon Dec  7 14:57:28 2009
From: atwilson at google.com (Drew Wilson)
Date: Mon, 7 Dec 2009 14:57:28 -0800
Subject: [whatwg] [WebWorkers] Maximum number of workers (was "About the
	delegation example")
In-Reply-To: <4B1D7613.8080508@enseirb-matmeca.fr>
References: <4B1D7613.8080508@enseirb-matmeca.fr>
Message-ID: <f965ae410912071457p6ecd6a52mb352b211eb4da3b2@mail.gmail.com>

We discussed this previously (
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html) -
the consensus was that since the Worker APIs are inherently asynchronous,
user agents were free to impose limits on worker creation (and queue up new
creation requests when the limit has been hit), but the spec should be
silent on this issue.

FWIW, Chrome does this - we limit each tab to a maximum of 16 workers, with
an overall limit of 64 - the 17th worker creation request for a tab is
queued up until another worker exits to make room for it. Chrome currently
has the limitation that each worker runs in its own process - when we
address that limitation, we expect to adjust the limits accordingly.

-atw

On Mon, Dec 7, 2009 at 1:39 PM, David Bruant <bruant at enseirb-matmeca.fr>wrote:

> David Bruant :
> > "In the delegation example, the number of workers chosen is an arbitrary
> > 10. But, in a single-core processor, having only one worker will result
> > in more or less the same running time, because at the end, each worker
> > runs on the only core."
> >
> Ian Hickson :
> "That depends on the algorithm. If the algorithm uses a lot of data, then
> a single hardware thread might be able to run two workers in the same time
> as it runs one, with one worker waiting for data while the other runs
> code, and with the workers trading back and forth.
>
> Personally I would recommend basing the number of workers on the number of
> shards that the input data is split into, and then relying on the UA to
> avoid thrashing. I would expect UAs to notice when a script spawns a
> bazillion workers, and have the UA run them in a staggered fashion, so as
> to not starve the system resources. This is almost certainly needed
> anyway, to prevent pages from DOSing the user's system."
>
> => Wouldn't it be preferable to have an implementation-dependant "maximum
> number of workers" and to raise a security exception when this number is
> reached ? Maximum per domain ? per document ?
> Maybe a different maximum for shared and dedicated workers.
>
> Any opinion on this ?
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091207/c1a0031e/attachment.htm>

From gman at google.com  Mon Dec  7 16:32:36 2009
From: gman at google.com (Gregg Tavares)
Date: Mon, 7 Dec 2009 16:32:36 -0800
Subject: [whatwg] Passing mouse events through the transparent parts of a
	<canvas> tag
Message-ID: <de4bd3190912071632j4d054ef7h825f96c33e19e1e2@mail.gmail.com>

Excuse me if this has already been discussed

Has there been a proposal for allowing mouse events to go through a canvas
element where it is transparent to the element below?

As an example, assume you have a canvas element with a triangle rendered
into the top left corner so that half the canvas is opaque and half the
canvas is 100% transparent (Alpha = 0).  That canvas is zIndexed to be above
other HTML. It would be nice if it was possible to interact with the visible
html under the transparent part of the canvas but as it is now all browsers
treat the canvas as a rectangle and ignore its transparency so that if the
user attempts to interact with the clearly visible HTML nothing happens.

One solution that comes to mind is to add an option (css?) that tells the
browser "if alpha = 0 at the place the user clicks then pass the event
through to the element below"

As a CSS option this could really apply to any tag. <img> for example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091207/8fd031b7/attachment-0001.htm>

From bruant at enseirb-matmeca.fr  Mon Dec  7 16:38:03 2009
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Mon, 07 Dec 2009 16:38:03 -0800
Subject: [whatwg] [WebWorkers] Advocation to provide the DOM API to the
 workers
In-Reply-To: <Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com>
References: <4AFCC2A0.1030202@enseirb-matmeca.fr>
	<Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com>
Message-ID: <4B1D9FEB.8030808@enseirb-matmeca.fr>

> The reason WebWorkers don't have access to the DOM is concurrency. For
> example, to loop through a list of children I need to first read the
> number of childrens, then have a for loop which starts at 0 and ends
> at length-1. If you have two threads that can access the DOM
> concurrently, then one could change the number of children while the
> other was looping through the list, which would cause bugs in the
> program. The only way to fix this is to make the DOM a monitor or
> introduce semaphores, but then you would have to change the way the
> DOM is accessed in HTML5, breaking backwards compatibility, which is
> not a good idea.
>
> A better solution to your problem is to load fragments of the entire
> document using AJAX and then insert those fragments into the main
> document, when they are needed. You rarely need to see the entire
> document at once anyways.
>
> Marius Gundersen
>> One good way I have found would be to cut the whole page into several 
>> parts (one the server side, what is already done in the multi-page 
>> version) and to launch several workers. Each worker gets one part of the 
>> whole page in the background and could give it to the browsing context 
>> which will append the right part at the right place.
>>     
>
> As others have noted, the slowness turns out to not be parsing, but to be 
> a bunch of scripts that are doing various things such as adding the 
> sidebar annotations, setting up the <dfn> cross-references, and generating 
> the short table of contents.
>
> Plus, since browsers don't have thread-safe DOM implementations, we 
> actually can't expose the DOM in workers. Maybe one day. :-)
>   
> -- Ian Hickson
=> I'm sorry for the misunderstanding. I shouldn't have said "the DOM
API". To be as accurate as I can be I want to provide the
DOMImplementation interface
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-102161490) to the
workers. As I'm going to explain, the point is to be able to create a
document and then a documentFragment.

I will explain my point through another use case. (Sorry for the
confusion with the HTML5 one-page version.)

Let imagine that I want to build a single page with several non-HTML
sources of information. They can be in different formats (RSS, datas got
from XML-RPC requests, any other kind of XML file, JSON...). I suppose
that each source is a different JSON file with different structures
(different properties, different nestings). Each source needs a
particular treatment. As I said in my first e-mail, there are 3 mains
steps before visualizing my page fully loaded. For each source of
content, we have to :
(1) get the content
(2) transform it into a DOM tree (as a documentFragment or a string that
is the representation of a HTML fragment, for example)
(3) append this to the main document at the right place. (which triggers
graphical rendering)
This last step is either an appendChild or a ".innerHTML=" and must be
done in the main browsing context, there is no choice.


Let imagine that I want that one workers per source.
For the moment, WebWorkers can do the step (1) independently (thanks to
XMLHttpRequest).

When each workers receives its JSON string, this string must be
transformed into an HTML DOM tree (2) (let say a <table> for example).
Because none of the DOM core API is currently available to the
WebWorkers, we have two solutions to turn the JSON string received in
(1) into an HTML DOM tree :
(2.1) Send the JSON string (or the resulting object, whatever) to the
main document which will create a documentFragment, run through the JSON
object and append the <table>,<tbody>, <tr>s and <td>s and contents to
this fragment for all the sources.
(2.2) Each worker create a string which looks like "<table
id=blabla><tbody><tr class="blibli"><td>1</td><td>2</td></tr><tr
class="blibli"><td>3</td><td>37</td></tr></tbody></table>" with "+="
while running through the JSON object. Then send the string through
postMessage() and the main browsing context can do a
"rightPlace.innerHTML = e.data" (where e.data is the string).

(2.1) We have the document/documentFragment/Element/Node abstraction,
but we loose all the parallelism, because the browsing context is
handling all the sources of information (and creating a documentFragment
and all the appendings for each source)

(2.2) We have the parallelism, because each Worker handles a source.
However, we loose the DOM abstraction. I hope that I have made the
string ridiculously long enough to convince you that it is not a good
solution. For complicated examples, by experience, using += and
.innerHTML is always a source of error especially because of closing
tags. These problems don't occur when developing with the DOM abstraction.

My proposition is :
(2.3) Assuming that we have access to the DOMImplementation interface,
we can create an object implementing the document interface which is
DIFFERENT from the main document object and I insist on this point. I am
NOT proposing to provide an access to the main document (the one which
"created the workers").
Thanks to this document, we can create a different documentFragment in
each worker and do in a parallel way the documentFragment appendings
described in (2.1).
The receiving context could have the following code :
"onmessage_handler(e){
/* Some code to identify which worker it was and where its
documentFragment should be
** inserted in the document.
*/
rightPlace = some_function(e); // An element in the main document.
df = e.data; // this data is the documentFragment sent by the worker.
rightPlace.appendChild(df);
}"

postMessag-ing an element/document/documentFragment/Node can cause a
problem because of references to document that they contain (because a
worker must NOT have access to the main document and the main document
must NOT have access to a worker document either)
As far as I can see, there are only two potential problems to
postMessage such objects "from one document to another":
* From Node interface : ownerDocument.
For this, it can be decided that a when postMessage is called on a node,
this node and all the subtree are automatically .adoptNode-ed by the
main document (window.document) of the receiving context.

* From Node interface : parentNode.
When a node is postMessage-ed, if its parentNode is a reference to the a
node in the worker context (a document or documentFragment), we can
automatically do an importNode() from the main document
(window.document) on it. By the way, document-s and documentFragment-s
have no parent
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1060184317), so this
step is not even necessary for them.


This way, between the postMessage() context and the event.data (used
during onmessage handler) context, I have broken all the references (if
I have forgotten some, tell me, I can propose a solution for them too)
to a document living in a different and asynchronous running context. I
have described a safe means to send a
document/documentFragment/Element/Node from a worker to the main
browsing context. The other direction shouldn't be hard to get either.


I think that providing the DOMImplementation interface is a good way for
implementors to provide a light-weight DOM implementation (because the
DOM API needs for workers are not the same than for documents as we know
them now). I may be wrong.

Note :
With a DOMImplementation available, the document response entity body of
XMLHttpRequest has no reason to be null anymore.

Thanks for your time and your feedback,

David

From parasyte at kodewerx.org  Mon Dec  7 19:15:48 2009
From: parasyte at kodewerx.org (Jason Oster)
Date: Mon, 7 Dec 2009 20:15:48 -0700
Subject: [whatwg] Passing mouse events through the transparent parts of
	a <canvas> tag
In-Reply-To: <de4bd3190912071632j4d054ef7h825f96c33e19e1e2@mail.gmail.com>
References: <de4bd3190912071632j4d054ef7h825f96c33e19e1e2@mail.gmail.com>
Message-ID: <8721E8D7-4275-447A-9223-7EBE9F83FFE6@kodewerx.org>

On Dec 7, 2009, at 5:32 PM, Gregg Tavares wrote:

> Excuse me if this has already been discussed
> 
> Has there been a proposal for allowing mouse events to go through a canvas element where it is transparent to the element below? 
> 
> As an example, assume you have a canvas element with a triangle rendered into the top left corner so that half the canvas is opaque and half the canvas is 100% transparent (Alpha = 0).  That canvas is zIndexed to be above other HTML. It would be nice if it was possible to interact with the visible html under the transparent part of the canvas but as it is now all browsers treat the canvas as a rectangle and ignore its transparency so that if the user attempts to interact with the clearly visible HTML nothing happens.
> 
> One solution that comes to mind is to add an option (css?) that tells the browser "if alpha = 0 at the place the user clicks then pass the event through to the element below"
> 
> As a CSS option this could really apply to any tag. <img> for example.
The pointer-events CSS property was recently added to Firefox for web (HTML) content:  https://developer.mozilla.org/en/CSS/pointer-events

Although the current implementation only supports the values 'auto' and 'none' for web content, it seems like some of the SVG-only values could possibly be used for your example case.  Or at the very least, I expect the property could be extended with additional values specifically for similar use cases with web content.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091207/da50909e/attachment.htm>

From ukai at chromium.org  Mon Dec  7 21:17:18 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Tue, 8 Dec 2009 14:17:18 +0900
Subject: [whatwg] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com> 
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
	<de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com> 
	<Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com>
Message-ID: <de17d48e0912072117t34a358cbj4646d6d0f1b4b7c6@mail.gmail.com>

On Mon, Dec 7, 2009 at 7:25 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 7 Dec 2009, Fumitoshi Ukai (??~\??~V~G?~U~O) wrote:
> > On Mon, Dec 7, 2009 at 5:05 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Mon, 7 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:
> > > > > > >
> > > > > > > Control characters are allowed (though using them would be
> > > > > > > silly).
> > > > > >
> > > > > > Why are control characters (except LF and CR) allowed?
> > > > >
> > > > > There doesn't seem to be a good reason to exclude them, and
> > > > > excluding them would lead to a more complicated processing model.
> > > >
> > > > In HTTP, field-content is TEXT or combinations of token, separators,
> > > > and quoted-string. TEXT, or token, separators excludes CTLs. So, we
> > > > must use quoted-string in WebSocket-Protocol: if protocol contains
> > > > CTLs?
> > >
> > > Oh, I forgot that HTTP had the no-CTL restriction. Good point. I've
> > > updated the spec to be consistent with this.
> >
> > In "The Web Sockets API", could you fix the following statement?
> >   The second, protocol, if present, specifies a sub-protocol that the
> server
> > must support for the connection to be successful. The sub-protocol name
> must
> > be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE
> RETURN
> > (CR) characters in it.
>
> Fixed, thanks.
>
>
> > IIRC, in old spec draft, protocol should not be an empty string, but
> > current spec draft accepts it?
>
> Man, I'm just incompetent today. Sorry about that. Fixed.
>

Thanks!

protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ?
(e.g. new WebSocket("ws://example.com/", " "); )
It seems space is optional after colon in field of handshake message, how
can we distinguish U+0020 and U+0020 U+0020 ?


>
>
> > > > And, why is it limited to ASCII instead of UTF-8?
> > >
> > > Because the HTTP working group refuse to allow UTF-8 in HTTP headers
> > > for reasons that I don't really understand, and the handshake is
> > > supposed to be valid HTTP.
> >
> > Hmm, then it should be mentioned in The Web Socket protocol 1.2 Protocol
> > overview? It looks websocket message accept UTF-8 in handshake message.
>
> There should be no way to _send_ UTF-8 in the handshake at this point,
> given the requirements in the spec, but once you _receive_ the handshake,
> it's no longer HTTP, it's just WebSocket, so you can use UTF-8 fine. (In
> practice it doesn't mean much, since there's nothing in the
> server-to-client handshake other than the client-to-server handshake, so
> if there ever was UTF-8 in the server-to-client handshake, it would either
> be ignored, or the connection would be dropped, depending on where exactly
> the UTF-8 was found.)
>

Ok. I see.


>
> HTH,
> --
> 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/20091208/35c30b0b/attachment.htm>

From jonas at sicking.cc  Mon Dec  7 21:52:45 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 7 Dec 2009 21:52:45 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
References: <Acp3bkOSk8kXUIQQSB2tGoqsFKJlSg==>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <63df84f0912072152q246db70ej9cf5c928b225cee7@mail.gmail.com>

On Mon, Dec 7, 2009 at 10:51 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Hi,
>
>
>
> In a recent investigation into capacity issues, I found that there are
> several instances where the browser will make a second to the page based on
> resolving empty-string URLs in the several tags. I tested four instances:
> <img src=??>, <link href=??>, <script src=??>, and <iframe src=??>. Across
> major browsers today, the behavior is vastly different:
>
>
>
> * Internet Explorer 8
>
> ? - Make a request for: <img src=??>
>
> ? - Does not make a request for: <link href=??>, <script src=??>, <iframe
> src=??>
>
> * Firefox 3
>
> ? - Make a request for: <img src=??>, <link href=??>, <script src=??>
>
> ? - Does not make a request for: < <iframe src=??>.
>
> * Firefox 3.5
>
> ? - Make a request for: <link href=??>, <script src=??>
>
> ? - Does not make a request for: <img src=??>, ?<iframe src=??>
>
> * Safari 4
>
> ? - Make a request for:<img src=??>, ?<link href=??>, <script src=??>
>
> ? - Does not make a request for: <iframe src=??>
>
> * Chrome 3 (same as Safari)
>
> ? - Make a request for:<img src=??>, ?<link href=??>, <script src=??>
>
> ? - Does not make a request for: <iframe src=??>
>
> * Opera 10
>
> ? - Make a request for: (none)
>
> ? - Does not make a request for: <img src=??>, ?<link href=??>, <script
> src=??>, <iframe src=??>
>
>
>
> Presently, HTML5 does provide guidance on the correct behavior for <img
> src=??> in section 4.8.2, indicating that Firefox 3.5?s and Opera 10?s
> behavior in this regard is correct:
>
>
>
> ?If the base URI of the element is the same as the document?s address, then
> the src attribute?s value must not be the empty string.?
>
>
>
> This seems like it should also apply to the other elements that download
> resources automatically. All browsers seem to be in agreement over the
> behavior of <iframe src=??> despite a lack of guidance in any HTML spec, and
> I?d assume that they will soon all be in agreement over <img src=??>, per
> the HTML5 spec. It would be nice to formalize this behavior so that we can
> get all browsers to act in consistently in these confusing cases.
>
>
>
> My opinion is that Opera is the only browser currently doing this in a
> reasonable manner, in that it makes a lot of sense to me that an
> empty-string URL for an element that automatically downloads a resource
> should be considered invalid and ignored. My hypothesis is that these
> patterns are most frequently indications of errors rather than an
> intentional use of this little-known behavior, and as a result, sending
> another request is an unexpected and unwelcome result. For high-volume web
> sites, a single mistaken inclusion of one of these patterns immediately
> doubles page views, which can introduce capacity issues (which I?ve needed
> to investigate at least twice in the past three years).
>
>
>
> I?m interested in what others? opinions on this may be, as this seems like
> an important area in which to gain consistency.

Given that the concern is sites that accidentally leave a attribute
empty, wouldn't you want to prevent a request from going out even if
the base-uri is set? I.e. wouldn't you want to prevent a request from
going out for the current document:

foo.html:
<head><base src="bar.html">
<body><img src="">

It seems to me equally unlikely that someone would do that
intentionally expecting a request to be sent to "bar.html"?

/ Jonas

From jonas at sicking.cc  Mon Dec  7 22:03:23 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 7 Dec 2009 22:03:23 -0800
Subject: [whatwg] Passing mouse events through the transparent parts of
	a <canvas> tag
In-Reply-To: <8721E8D7-4275-447A-9223-7EBE9F83FFE6@kodewerx.org>
References: <de4bd3190912071632j4d054ef7h825f96c33e19e1e2@mail.gmail.com> 
	<8721E8D7-4275-447A-9223-7EBE9F83FFE6@kodewerx.org>
Message-ID: <63df84f0912072203m26fcc99ap1742547c2cace03e@mail.gmail.com>

On Mon, Dec 7, 2009 at 7:15 PM, Jason Oster <parasyte at kodewerx.org> wrote:
> On Dec 7, 2009, at 5:32 PM, Gregg Tavares wrote:
>
> Excuse me if this has already been discussed
>
> Has there been a proposal for allowing mouse events to go through a canvas
> element where it is transparent to the element below?
>
> As an example, assume you have a canvas element with a triangle rendered
> into the top left corner so that half the canvas is opaque and half the
> canvas is 100% transparent (Alpha = 0).? That canvas is zIndexed to be above
> other HTML. It would be nice if it was possible to interact with the visible
> html under the transparent part of the canvas but as it is now all browsers
> treat the canvas as a rectangle and ignore its transparency so that if the
> user attempts to interact with the clearly visible HTML nothing happens.
>
> One solution that comes to mind is to add an option (css?) that tells the
> browser "if alpha = 0 at the place the user clicks then pass the event
> through to the element below"
>
> As a CSS option this could really apply to any tag. <img> for example.
>
> The pointer-events CSS property was recently added to Firefox for web (HTML)
> content: ?https://developer.mozilla.org/en/CSS/pointer-events
> Although the current implementation only supports the values 'auto' and
> 'none' for web content, it seems like some of the SVG-only values could
> possibly be used for your example case. ?Or at the very least, I expect the
> property could be extended with additional values specifically for similar
> use cases with web content.

Indeed. We've talked about using this CSS property as a way to let
only the non-transparent parts of an image receive events.
Unfortunately if I recall correctly none of the currently defined
values of pointer-events fit that behavior, but the intent would be to
add one. In any case I think this CSS property is the way to add the
feature you want, and so the discussion is probably best had on the
www-style mailing list.

/ Jonas

From ian at hixie.ch  Mon Dec  7 23:59:10 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 8 Dec 2009 07:59:10 +0000 (UTC)
Subject: [whatwg] WebSocket sub protocol name.
In-Reply-To: <de17d48e0912072117t34a358cbj4646d6d0f1b4b7c6@mail.gmail.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com> 
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
	<de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com> 
	<Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com>
	<de17d48e0912072117t34a358cbj4646d6d0f1b4b7c6@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>

On Tue, 8 Dec 2009, Fumitoshi Ukai (??~\????~V~G?~U~O) wrote:
> 
> protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ?
> (e.g. new WebSocket("ws://example.com/", " "); )
> It seems space is optional after colon in field of handshake message, how
> can we distinguish U+0020 and U+0020 U+0020 ?

The space isn't optional (both the client and the server are required to 
send it before the subprotocol name), it's just that the client will 
handle a missing space gracefully. Maybe we should remove that "feature", 
and require that the space be present, closing the connection otherwise?
I don't feel strongly either way.

Anyway, the point is that "WebSocket-Protocol: " is the empty string, and 
"WebSocket-Protocol:  " is a one-space protocol name.

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

From ukai at chromium.org  Tue Dec  8 00:04:49 2009
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Tue, 8 Dec 2009 17:04:49 +0900
Subject: [whatwg] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com> 
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
	<de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com> 
	<Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com> 
	<de17d48e0912072117t34a358cbj4646d6d0f1b4b7c6@mail.gmail.com> 
	<Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>
Message-ID: <de17d48e0912080004p7f360a80xef09d0c64ad61078@mail.gmail.com>

On Tue, Dec 8, 2009 at 4:59 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 8 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:
> >
> > protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ?
> > (e.g. new WebSocket("ws://example.com/", " "); )
> > It seems space is optional after colon in field of handshake message, how
> > can we distinguish U+0020 and U+0020 U+0020 ?
>
> The space isn't optional (both the client and the server are required to
> send it before the subprotocol name), it's just that the client will
> handle a missing space gracefully. Maybe we should remove that "feature",
> and require that the space be present, closing the connection otherwise?
> I don't feel strongly either way.
>
> Anyway, the point is that "WebSocket-Protocol: " is the empty string, and
> "WebSocket-Protocol:  " is a one-space protocol name.
>

Thanks for clarifying this.

-- 
ukai


> --
> 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/20091208/2ac9e643/attachment.htm>

From yuzo at google.com  Tue Dec  8 00:06:57 2009
From: yuzo at google.com (Yuzo Fujishima)
Date: Tue, 8 Dec 2009 17:06:57 +0900
Subject: [whatwg] [hybi] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com> 
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
	<de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com> 
	<Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com> 
	<de17d48e0912072117t34a358cbj4646d6d0f1b4b7c6@mail.gmail.com> 
	<Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>
Message-ID: <9124e09b0912080006i2b34d213t631b794222f62ecb@mail.gmail.com>

On Tue, Dec 8, 2009 at 4:59 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 8 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:

>> protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ?
>> (e.g. new WebSocket("ws://example.com/", " "); )
>> It seems space is optional after colon in field of handshake message, how
>> can we distinguish U+0020 and U+0020 U+0020 ?

> The space isn't optional (both the client and the server are required to
> send it before the subprotocol name), it's just that the client will
> handle a missing space gracefully. Maybe we should remove that "feature",
> and require that the space be present, closing the connection otherwise?
> I don't feel strongly either way.

> Anyway, the point is that "WebSocket-Protocol: " is the empty string, and
> "WebSocket-Protocol: ?" is a one-space protocol name.

Hi, Ian, let me confirm one thing: Empty string is not allowed for
subprotocol, is it?

Yuzo


> --
> Ian Hickson ? ? ? ? ? ? ? U+1047E ? ? ? ? ? ? ? ?)\._.,--....,'``. ? ?fL
> http://ln.hixie.ch/ ? ? ? U+263A ? ? ? ? ? ? ? ?/, ? _.. \ ? _\ ?;`._ ,.
> Things that are impossible just take longer. ? `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> hybi at ietf.org
> https://www.ietf.org/mailman/listinfo/hybi




From julian.reschke at gmx.de  Tue Dec  8 00:25:54 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 08 Dec 2009 09:25:54 +0100
Subject: [whatwg] [hybi] WebSocket sub protocol name.
In-Reply-To: <Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com>
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com>
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com>
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>	<de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com>
	<Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com>	<de17d48e0912072117t34a358cbj4646d6d0f1b4b7c6@mail.gmail.com>
	<Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>
Message-ID: <4B1E0D92.3040406@gmx.de>

Ian Hickson wrote:
> On Tue, 8 Dec 2009, Fumitoshi Ukai (?~\??~V~G?~U~O) wrote:
>> protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ?
>> (e.g. new WebSocket("ws://example.com/", " "); )
>> It seems space is optional after colon in field of handshake message, how
>> can we distinguish U+0020 and U+0020 U+0020 ?
> 
> The space isn't optional (both the client and the server are required to 
> send it before the subprotocol name), it's just that the client will 
> handle a missing space gracefully. Maybe we should remove that "feature", 
> and require that the space be present, closing the connection otherwise?
> I don't feel strongly either way.
> 
> Anyway, the point is that "WebSocket-Protocol: " is the empty string, and 
> "WebSocket-Protocol:  " is a one-space protocol name.
> ...

Out of curiosity: why do you think it's wise to allow SP in protocol names?

BR, Julian

From ian at hixie.ch  Tue Dec  8 00:31:28 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 8 Dec 2009 08:31:28 +0000 (UTC)
Subject: [whatwg] [hybi] WebSocket sub protocol name.
In-Reply-To: <9124e09b0912080006i2b34d213t631b794222f62ecb@mail.gmail.com>
References: <de17d48e0912062058u72db7455x4e211cb05da19070@mail.gmail.com> 
	<Pine.LNX.4.62.0912070618170.5629@hixie.dreamhostps.com>
	<de17d48e0912062241q3001c6a9r955bb0e1577fc4d0@mail.gmail.com> 
	<Pine.LNX.4.62.0912070726010.5629@hixie.dreamhostps.com>
	<de17d48e0912062340x7d3eed42t4f1f9cf95d482610@mail.gmail.com> 
	<Pine.LNX.4.62.0912070756380.5629@hixie.dreamhostps.com>
	<de17d48e0912070207p15e54f4bv9d52716c514f596@mail.gmail.com> 
	<Pine.LNX.4.62.0912071015130.14026@hixie.dreamhostps.com> 
	<de17d48e0912072117t34a358cbj4646d6d0f1b4b7c6@mail.gmail.com> 
	<Pine.LNX.4.62.0912080753260.16061@hixie.dreamhostps.com>
	<9124e09b0912080006i2b34d213t631b794222f62ecb@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912080829360.16061@hixie.dreamhostps.com>

On Tue, 8 Dec 2009, Yuzo Fujishima wrote:
> On Tue, Dec 8, 2009 at 4:59 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 8 Dec 2009, Fumitoshi Ukai (?~\??~V~G?U~O) wrote:
> > > protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ?
> > > (e.g. new WebSocket("ws://example.com/", " "); )
> > > It seems space is optional after colon in field of handshake message, how
> > > can we distinguish U+0020 and U+0020 U+0020 ?
> > 
> > The space isn't optional (both the client and the server are required 
> > to send it before the subprotocol name), it's just that the client 
> > will handle a missing space gracefully. Maybe we should remove that 
> > "feature", and require that the space be present, closing the 
> > connection otherwise? I don't feel strongly either way.
> > 
> > Anyway, the point is that "WebSocket-Protocol: " is the empty string, 
> > and "WebSocket-Protocol: ?" is a one-space protocol name.
> 
> Hi, Ian, let me confirm one thing: Empty string is not allowed for 
> subprotocol, is it?

The API will throw if the string is empty. However, if no protocol was 
specified, and the server returns an empty WebSocket-Protocol, it's 
ignored (as would any other WebSocket-Protocol value sent by the server in 
that case).

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

From simonp at opera.com  Tue Dec  8 01:26:55 2009
From: simonp at opera.com (Simon Pieters)
Date: Tue, 08 Dec 2009 10:26:55 +0100
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
Message-ID: <op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>

On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> I don't know why <img src=""> has a special exception.  It would be
> possible to look through the svn log to see if there was a helpful
> commit message, or maybe someone will remember.

I seem to remember someone from Mozilla mentioned that they recently  
changed the behavior for img, so Hixie changed the spec for img.

-- 
Simon Pieters
Opera Software

From robert at ocallahan.org  Tue Dec  8 09:24:36 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 8 Dec 2009 09:24:36 -0800
Subject: [whatwg] Passing mouse events through the transparent parts of
	a <canvas> tag
In-Reply-To: <63df84f0912072203m26fcc99ap1742547c2cace03e@mail.gmail.com>
References: <de4bd3190912071632j4d054ef7h825f96c33e19e1e2@mail.gmail.com>
	<8721E8D7-4275-447A-9223-7EBE9F83FFE6@kodewerx.org>
	<63df84f0912072203m26fcc99ap1742547c2cace03e@mail.gmail.com>
Message-ID: <11e306600912080924q4de53004k59d652e374d0710c@mail.gmail.com>

On Mon, Dec 7, 2009 at 10:03 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> Indeed. We've talked about using this CSS property as a way to let
> only the non-transparent parts of an image receive events.
> Unfortunately if I recall correctly none of the currently defined
> values of pointer-events fit that behavior, but the intent would be to
> add one. In any case I think this CSS property is the way to add the
> feature you want, and so the discussion is probably best had on the
> www-style mailing list.
>

www-svg would be better, since it's an SVG property.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091208/bc95544e/attachment-0001.htm>

From jonas at sicking.cc  Tue Dec  8 09:26:22 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 8 Dec 2009 09:26:22 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com> 
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com> 
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
Message-ID: <63df84f0912080926l67307eafy84a4ffec2d7a47fa@mail.gmail.com>

On Tue, Dec 8, 2009 at 1:26 AM, Simon Pieters <simonp at opera.com> wrote:
> On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor <Simetrical+w3c at gmail.com>
> wrote:
>
>> I don't know why <img src=""> has a special exception. ?It would be
>> possible to look through the svn log to see if there was a helpful
>> commit message, or maybe someone will remember.
>
> I seem to remember someone from Mozilla mentioned that they recently changed
> the behavior for img, so Hixie changed the spec for img.

It turns out that <img src=""> is decently common on the web, and in
all cases we saw did *not* intend its literal interpretation (i.e.
display an image using the current baseuri).

So it was deemed as a worth while performance improvement to add code
to suppress the network fetch. For further details see:

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

/ Jonas

From nzakas at yahoo-inc.com  Tue Dec  8 09:36:49 2009
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Tue, 8 Dec 2009 09:36:49 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <63df84f0912072152q246db70ej9cf5c928b225cee7@mail.gmail.com>
References: <Acp3bkOSk8kXUIQQSB2tGoqsFKJlSg==><4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<63df84f0912072152q246db70ej9cf5c928b225cee7@mail.gmail.com>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CEE9@SNV-EXVS09.ds.corp.yahoo.com>

I'd agree with that, I've yet been able to find an example of someone intentionally including an empty-string URL in one of these tags. 

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

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: Monday, December 07, 2009 9:53 PM
To: Nicholas Zakas
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Mon, Dec 7, 2009 at 10:51 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Hi,
>
>
>
> In a recent investigation into capacity issues, I found that there are
> several instances where the browser will make a second to the page based on
> resolving empty-string URLs in the several tags. I tested four instances:
> <img src="">, <link href="">, <script src="">, and <iframe src="">. Across
> major browsers today, the behavior is vastly different:
>
>
>
> * Internet Explorer 8
>
> ? - Make a request for: <img src="">
>
> ? - Does not make a request for: <link href="">, <script src="">, <iframe
> src="">
>
> * Firefox 3
>
> ? - Make a request for: <img src="">, <link href="">, <script src="">
>
> ? - Does not make a request for: < <iframe src="">.
>
> * Firefox 3.5
>
> ? - Make a request for: <link href="">, <script src="">
>
> ? - Does not make a request for: <img src="">, ?<iframe src="">
>
> * Safari 4
>
> ? - Make a request for:<img src="">, ?<link href="">, <script src="">
>
> ? - Does not make a request for: <iframe src="">
>
> * Chrome 3 (same as Safari)
>
> ? - Make a request for:<img src="">, ?<link href="">, <script src="">
>
> ? - Does not make a request for: <iframe src="">
>
> * Opera 10
>
> ? - Make a request for: (none)
>
> ? - Does not make a request for: <img src="">, ?<link href="">, <script
> src="">, <iframe src="">
>
>
>
> Presently, HTML5 does provide guidance on the correct behavior for <img
> src=""> in section 4.8.2, indicating that Firefox 3.5's and Opera 10's
> behavior in this regard is correct:
>
>
>
> "If the base URI of the element is the same as the document's address, then
> the src attribute's value must not be the empty string."
>
>
>
> This seems like it should also apply to the other elements that download
> resources automatically. All browsers seem to be in agreement over the
> behavior of <iframe src=""> despite a lack of guidance in any HTML spec, and
> I'd assume that they will soon all be in agreement over <img src="">, per
> the HTML5 spec. It would be nice to formalize this behavior so that we can
> get all browsers to act in consistently in these confusing cases.
>
>
>
> My opinion is that Opera is the only browser currently doing this in a
> reasonable manner, in that it makes a lot of sense to me that an
> empty-string URL for an element that automatically downloads a resource
> should be considered invalid and ignored. My hypothesis is that these
> patterns are most frequently indications of errors rather than an
> intentional use of this little-known behavior, and as a result, sending
> another request is an unexpected and unwelcome result. For high-volume web
> sites, a single mistaken inclusion of one of these patterns immediately
> doubles page views, which can introduce capacity issues (which I've needed
> to investigate at least twice in the past three years).
>
>
>
> I'm interested in what others' opinions on this may be, as this seems like
> an important area in which to gain consistency.

Given that the concern is sites that accidentally leave a attribute
empty, wouldn't you want to prevent a request from going out even if
the base-uri is set? I.e. wouldn't you want to prevent a request from
going out for the current document:

foo.html:
<head><base src="bar.html">
<body><img src="">

It seems to me equally unlikely that someone would do that
intentionally expecting a request to be sent to "bar.html"?

/ Jonas

From nzakas at yahoo-inc.com  Tue Dec  8 09:42:33 2009
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Tue, 8 Dec 2009 09:42:33 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>

The change seems reasonable to me. It just seems that the same change
should be made in all cases that cause similar issues, making it the
rule of the spec instead of an exception for this one case. Does that
make sense?

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

-----Original Message-----
From: Simon Pieters [mailto:simonp at opera.com] 
Sent: Tuesday, December 08, 2009 1:27 AM
To: Aryeh Gregor; Nicholas Zakas
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> I don't know why <img src=""> has a special exception.  It would be
> possible to look through the svn log to see if there was a helpful
> commit message, or maybe someone will remember.

I seem to remember someone from Mozilla mentioned that they recently  
changed the behavior for img, so Hixie changed the spec for img.

-- 
Simon Pieters
Opera Software

From cevans at google.com  Tue Dec  8 11:04:23 2009
From: cevans at google.com (Chris Evans)
Date: Tue, 8 Dec 2009 11:04:23 -0800
Subject: [whatwg] Proposal for <iframe sandbox> related change to HTML5
	section 4.8.3
Message-ID: <ff1e8c3a0912081104v5be773bfl4f587af2e020ad96@mail.gmail.com>

Hello,

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."


This change makes sure the sandbox attribute protects the integrity as well
as confidentiality of the cookies. It also matches what was implemented in
WebKit.


Cheers
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091208/ed338fc6/attachment.htm>

From bnkuhn at gmail.com  Tue Dec  8 11:49:45 2009
From: bnkuhn at gmail.com (Brian Kuhn)
Date: Tue, 8 Dec 2009 11:49:45 -0800
Subject: [whatwg] boolean attributes in javascript
Message-ID: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>

How do I correctly set a boolean
attribute<http://dev.w3.org/html5/spec/Overview.html#boolean-attributes>on
a DOM element object in Javascript?

var script = document.createElement('script');

   1. script.async = true;        // makes the most sense, but appears go
   against the spec
   2. script.async = 'true';       // worse, but not bad, but also appears
   to go against the spec
   3. script.async = '';            // sets to empty string, but what does
   that really mean?
   4. script.async = 'async';   // sets async = async, which is weird
*and*verbose

And then you have the debate on setting the property directly versus using
setAttribute.  Any thoughts on that?


To me, boolean attributes seem to break the rule of least
surprise<http://en.wikipedia.org/wiki/Principle_of_least_astonishment>.
 I find it very hard to believe people will understand:
<script async="" src="..."></script>    or   <script async="async"
src="..."></script>

more than:
<script async="true" src="..."></script>

Thanks,
    Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091208/9c16ac4c/attachment.htm>

From jackalmage at gmail.com  Tue Dec  8 13:41:42 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 8 Dec 2009 15:41:42 -0600
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
Message-ID: <dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>

On Tue, Dec 8, 2009 at 1:49 PM, Brian Kuhn <bnkuhn at gmail.com> wrote:
> How do I correctly set a boolean attribute on a DOM element object in
> Javascript?
> var script = document.createElement('script');
>
> script.async = true; ? ? ? ?// makes the most sense, but appears go against
> the spec
> script.async = 'true'; ? ? ? // worse, but not bad, but also appears to go
> against the spec
> script.async = ''; ? ? ? ? ? ?// sets to empty string, but what does that
> really mean?
> script.async = 'async'; ? // sets async = async, which is weird and verbose
>
> And then you have the debate on setting the property directly versus using
> setAttribute. ?Any thoughts on that?
>
> To me, boolean attributes seem to break the rule of least surprise. ?I find
> it very hard to believe people will understand:
> <script async="" src="..."></script> ? ?or ? <script async="async"
> src="..."></script>
> more than:
> <script async="true" src="..."></script>

Setting an attribute foo to '' or 'foo' is the correct way.  To unset
it, remove the attribute entirely.

This is mostly unchangeable now, because it's how HTML and XHTML have
worked for a long time.  XHTML requires the longer foo="foo" form, and
in HTML writing an element like <bar foo> will give the element an
attribute "foo" with the value of the empty string.  Thus those are
the two proper ways to set it.  For compatibility reasons setting
*any* value on the attribute sets it (it's set or not based purely on
the presence or absence of the attribute itself, not the value of the
attribute), but it's invalid to set it to anything other than the two
values I just mentioned.

If authors are writing HTML, they can just do <script async src="?">.
Simple and easy.

~TJ

From bnkuhn at gmail.com  Tue Dec  8 13:48:21 2009
From: bnkuhn at gmail.com (Brian Kuhn)
Date: Tue, 8 Dec 2009 13:48:21 -0800
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com> 
	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
Message-ID: <335a812d0912081348r12727badl7d9467c48c6746b7@mail.gmail.com>

>  but it's invalid to set it to anything other than the two values I just
mentioned.

That's the part I'd like to see changed.  I understand that if it's present,
it's on.  So, why can't async="true" be valid?  I think all browser vendors
will implement it that way anyway.  They'd be crazy not to.

-Brian





On Tue, Dec 8, 2009 at 1:41 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Tue, Dec 8, 2009 at 1:49 PM, Brian Kuhn <bnkuhn at gmail.com> wrote:
> > How do I correctly set a boolean attribute on a DOM element object in
> > Javascript?
> > var script = document.createElement('script');
> >
> > script.async = true;        // makes the most sense, but appears go
> against
> > the spec
> > script.async = 'true';       // worse, but not bad, but also appears to
> go
> > against the spec
> > script.async = '';            // sets to empty string, but what does that
> > really mean?
> > script.async = 'async';   // sets async = async, which is weird and
> verbose
> >
> > And then you have the debate on setting the property directly versus
> using
> > setAttribute.  Any thoughts on that?
> >
> > To me, boolean attributes seem to break the rule of least surprise.  I
> find
> > it very hard to believe people will understand:
> > <script async="" src="..."></script>    or   <script async="async"
> > src="..."></script>
> > more than:
> > <script async="true" src="..."></script>
>
> Setting an attribute foo to '' or 'foo' is the correct way.  To unset
> it, remove the attribute entirely.
>
> This is mostly unchangeable now, because it's how HTML and XHTML have
> worked for a long time.  XHTML requires the longer foo="foo" form, and
> in HTML writing an element like <bar foo> will give the element an
> attribute "foo" with the value of the empty string.  Thus those are
> the two proper ways to set it.  For compatibility reasons setting
> *any* value on the attribute sets it (it's set or not based purely on
> the presence or absence of the attribute itself, not the value of the
> attribute), but it's invalid to set it to anything other than the two
> values I just mentioned.
>
> If authors are writing HTML, they can just do <script async src="?">.
> Simple and easy.
>
> ~TJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091208/3472b4e3/attachment.htm>

From jackalmage at gmail.com  Tue Dec  8 13:57:47 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 8 Dec 2009 15:57:47 -0600
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <335a812d0912081348r12727badl7d9467c48c6746b7@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
	<335a812d0912081348r12727badl7d9467c48c6746b7@mail.gmail.com>
Message-ID: <dd0fbad0912081357i47ae0046l7a5db218036b4984@mail.gmail.com>

On Tue, Dec 8, 2009 at 3:48 PM, Brian Kuhn <bnkuhn at gmail.com> wrote:
>>??but it's invalid to set it to anything other than the two?values I just
>> mentioned.
>
> That's the part I'd like to see changed. ?I understand that if it's present,
> it's on. ?So, why can't async="true" be valid? ?I think all browser vendors
> will implement it that way anyway. ?They'd be crazy not to.

Indeed, async="true" does set it to be on.  However, so does
async="false", async="off", async="no", and any other string you can
think of that might imply that it's turned off.  Setting it to *any*
value turns it on, so it's best to avoid values that would lead to
confusing results.  The two values that are currently valid are the
minimum necessary, and neither have antonyms that would confuse
people.

~TJ

From bnkuhn at gmail.com  Tue Dec  8 14:59:25 2009
From: bnkuhn at gmail.com (Brian Kuhn)
Date: Tue, 8 Dec 2009 14:59:25 -0800
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <335a812d0912081455k34581007ia53914e05ba6ea4c@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
	<335a812d0912081348r12727badl7d9467c48c6746b7@mail.gmail.com>
	<dd0fbad0912081357i47ae0046l7a5db218036b4984@mail.gmail.com>
	<335a812d0912081455k34581007ia53914e05ba6ea4c@mail.gmail.com>
Message-ID: <335a812d0912081459h2875f701q6af50f402453787e@mail.gmail.com>

I can accept that.  It's just a shame that true and false can't be supported
for something called a boolean attribute.

Anyone have any thoughts on setAttribute vs. setting the attribute
directly?  My test show that they both work.

Thanks,
     Brian

On Dec 8, 2009 1:57 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:

On Tue, Dec 8, 2009 at 3:48 PM, Brian Kuhn <bnkuhn at gmail.com> wrote: >>  but
it's invalid to set it ...
Indeed, async="true" does set it to be on.  However, so does
async="false", async="off", async="no", and any other string you can
think of that might imply that it's turned off.  Setting it to *any*
value turns it on, so it's best to avoid values that would lead to
confusing results.  The two values that are currently valid are the
minimum necessary, and neither have antonyms that would confuse
people.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091208/e54eb488/attachment.htm>

From dhtmlkitchen at gmail.com  Tue Dec  8 15:04:04 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 8 Dec 2009 15:04:04 -0800
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
Message-ID: <c9e12660912081504w4373b102if5bf09a534fee9ab@mail.gmail.com>

On Tue, Dec 8, 2009 at 1:41 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, Dec 8, 2009 at 1:49 PM, Brian Kuhn <bnkuhn at gmail.com> wrote:
>> How do I correctly set a boolean attribute on a DOM element object in
>> Javascript?
>> var script = document.createElement('script');
>>
>> script.async = true; ? ? ? ?// makes the most sense, but appears go against
>> the spec


HTML content attributes and dom properties are different things.

Like the majority of cases, DOM properties make sense here. The async
property is specified in HTML5, which copied the property from IE.

W3c specs use the term "attribute" to mean "dom property". DOM
properties are not HTML content attributes.

[...]

>
> Setting an attribute foo to '' or 'foo' is the correct way.

getAttribute/setAttribute is not any more correct than DOM properties
but it is less interoperable.

Some content attributes "reflect" object state, others do not. Which
attributes "reflect" varies between browsers and the attribute in
question.

Setting an attribute to the empty string may have the effect of
removing the attribute in some browsers.

Garrett

From jackalmage at gmail.com  Tue Dec  8 15:22:18 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 8 Dec 2009 17:22:18 -0600
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <c9e12660912081504w4373b102if5bf09a534fee9ab@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
	<c9e12660912081504w4373b102if5bf09a534fee9ab@mail.gmail.com>
Message-ID: <dd0fbad0912081522r2bec70cfya22b56447287ff9a@mail.gmail.com>

Some clarification is in order; I didn't answer fully and was
corrected elsewhere.

There are two distinct notions of attributes here.  The first, the
"content attribute", is what you're manipulating when you do
foo.setAttribute() or foo.getAttribute().  The second, the "IDL
attribute" (may be called "DOM attribute" or "property" in some
places) is what you're manipulating when you do foo.bar (where foo is
an element and bar is an attribute name).

The content attribute can exist or not; if it exists, it's considered
'on', and if it doesn't it's considered 'off'.  It's a string, and if
specified must be one of the two values I mentioned previously.

The IDL attribute is a boolean.  It's either true or false.  Setting
it to true will set the content attribute, and setting it to false
will remove the content attribute.

So "script.async=true" is valid and does what you would expect.
Similarly, "script.async=false" is valid and does what you would
expect.  "script.setAttribute('async','true')" is invalid, but still
makes the element async.  "script.setAttribute('async','false')" is
invalid, and also makes the element async, which is not what you would
naively expect.

If you want to get more confusing, "script.async='true'" makes the
element async, because in javascript non-empty strings evaluate as
true.  However, "script.async='false'" would also make it async, while
"script.async=''" doesn't.  You have to pay attention to what you're
actually dealing with.

~TJ

From derernst at gmx.ch  Tue Dec  8 15:25:32 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Wed, 09 Dec 2009 00:25:32 +0100
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <dd0fbad0912081357i47ae0046l7a5db218036b4984@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>	<335a812d0912081348r12727badl7d9467c48c6746b7@mail.gmail.com>
	<dd0fbad0912081357i47ae0046l7a5db218036b4984@mail.gmail.com>
Message-ID: <4B1EE06C.2000700@gmx.ch>

Tab Atkins Jr. schrieb:
> On Tue, Dec 8, 2009 at 3:48 PM, Brian Kuhn <bnkuhn at gmail.com> wrote:
>>>   but it's invalid to set it to anything other than the two values I just
>>> mentioned.
>> That's the part I'd like to see changed.  I understand that if it's present,
>> it's on.  So, why can't async="true" be valid?  I think all browser vendors
>> will implement it that way anyway.  They'd be crazy not to.
> 
> Indeed, async="true" does set it to be on.  However, so does
> async="false", async="off", async="no", and any other string you can
> think of that might imply that it's turned off.  Setting it to *any*
> value turns it on, so it's best to avoid values that would lead to
> confusing results.  The two values that are currently valid are the
> minimum necessary, and neither have antonyms that would confuse
> people.

If I understand things right, It looks to me like you talk about 
different things. I think the part of the spec that Brian linked to is 
about HTML, not Javascript (but a link to a section on the DOM handling 
of boolean attributes would be useful, however). I prefer the checked 
attribute as a commen example for boolean attributes:

HTML:
<input type="checkbox" name="box1">
<input type="checkbox" name="box2" checked>
(or: checked="checked", or checked="")

Javascript:
document.forms[0].elements["box1"].checked = false;
document.forms[0].elements["box2"].checked = true;

Or do I misunderstand the discussion?

From t.broyer at gmail.com  Tue Dec  8 15:27:34 2009
From: t.broyer at gmail.com (Thomas Broyer)
Date: Wed, 9 Dec 2009 00:27:34 +0100
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
Message-ID: <a9699fd20912081527t24f45271wa6a3b1b749e6c40a@mail.gmail.com>

On Tue, Dec 8, 2009 at 8:49 PM, Brian Kuhn <bnkuhn at gmail.com> wrote:
> How do I correctly set a boolean attribute on a DOM element object in
> Javascript?
> var script = document.createElement('script');
>
> script.async = true; ? ? ? ?// makes the most sense, but appears go against
> the spec
> script.async = 'true'; ? ? ? // worse, but not bad, but also appears to go
> against the spec
> script.async = ''; ? ? ? ? ? ?// sets to empty string, but what does that
> really mean?
> script.async = 'async'; ? // sets async = async, which is weird and verbose

The WebIDL snippet in [1] defines the property as being of type
'boolean', and WebIDL defines how it is to be bound in ECMAScript [2],
which in turn defers to ECMAScript for the ToBoolean conversion [3]
(?9.2 in both ES3 and ES5, which have identical behavior)
So you'd do script.async=true.
script.async = 'true' would also work, but script.async = 'false'
would actually set it to true, as well as script.async = 'async'.
script.async = '' would set it to false.

[1] http://dev.w3.org/html5/spec/Overview.html#script ("DOM interface")
[2] http://dev.w3.org/2006/webapi/WebIDL/#es-boolean
[3] http://www.ecma-international.org/memento/TC39-M.htm

> And then you have the debate on setting the property directly versus using
> setAttribute. ?Any thoughts on that?

Use properties, it's so easier!

> To me, boolean attributes seem to break the rule of least surprise. ?I find
> it very hard to believe people will understand:
> <script async="" src="..."></script> ? ?or ? <script async="async"
> src="..."></script>
> more than:
> <script async="true" src="..."></script>

Most people would simply srite <script src="..." async></script>

Boolean attributes work that way since very early versions of HTML,
because of a feature of SGML that allows the value to be omitted when
it's the same as the attribute name (I'm not an SGML expert, someone
correct me if I'm wrong; what I'm saying is that it's the way to go in
SGML):
   <input disabled>
   <input readonly>
   <img ismap>
   etc.

-- 
Thomas Broyer
/t?.ma.b?wa.je/

From dean.edwards at gmail.com  Tue Dec  8 16:49:12 2009
From: dean.edwards at gmail.com (Dean Edwards)
Date: Wed, 09 Dec 2009 00:49:12 +0000
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <c9e12660912081504w4373b102if5bf09a534fee9ab@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
	<c9e12660912081504w4373b102if5bf09a534fee9ab@mail.gmail.com>
Message-ID: <4B1EF408.8030301@gmail.com>

On 08/12/2009 23:04, Garrett Smith wrote:
> Setting an attribute to the empty string may have the effect of
> removing the attribute in some browsers.

Which browsers/properties?

-dean

From dhtmlkitchen at gmail.com  Tue Dec  8 17:40:04 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 8 Dec 2009 17:40:04 -0800
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <4B1EF408.8030301@gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com>
	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com>
	<c9e12660912081504w4373b102if5bf09a534fee9ab@mail.gmail.com>
	<4B1EF408.8030301@gmail.com>
Message-ID: <c9e12660912081740s59adaf54obebf6e6f961e3e12@mail.gmail.com>

On Tue, Dec 8, 2009 at 4:49 PM, Dean Edwards <dean.edwards at gmail.com> wrote:
> On 08/12/2009 23:04, Garrett Smith wrote:
>>
>> Setting an attribute to the empty string may have the effect of
>> removing the attribute in some browsers.
>
> Which browsers/properties?
>

s/removing the attribute/setting a false value.

Try setting a 'checked' property of an input checkbox in IE.

<input type="checkbox" checked id="checkboxInput">

checkboxInput.setAttribute("checked", "");

will un-check a checkbox in IE.

The phenomenon is explained by two factors:
1) In IE < 8, attributes are properties (IE8 has some fixes)
2) Setting a boolean property to a non-boolean value may result in
boolean conversion.

From bnkuhn at gmail.com  Tue Dec  8 17:45:49 2009
From: bnkuhn at gmail.com (Brian Kuhn)
Date: Tue, 8 Dec 2009 17:45:49 -0800
Subject: [whatwg] boolean attributes in javascript
In-Reply-To: <dd0fbad0912081522r2bec70cfya22b56447287ff9a@mail.gmail.com>
References: <335a812d0912081149y5eed3119y5ac372b66859965a@mail.gmail.com> 
	<dd0fbad0912081341s3a8c892asdb20e0fef83567c1@mail.gmail.com> 
	<c9e12660912081504w4373b102if5bf09a534fee9ab@mail.gmail.com> 
	<dd0fbad0912081522r2bec70cfya22b56447287ff9a@mail.gmail.com>
Message-ID: <335a812d0912081745g33f1f1adk405a95bced8004d2@mail.gmail.com>

Thanks Tab, and everyone else.  This has been enlightening!


On Tue, Dec 8, 2009 at 3:22 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> Some clarification is in order; I didn't answer fully and was
> corrected elsewhere.
>
> There are two distinct notions of attributes here.  The first, the
> "content attribute", is what you're manipulating when you do
> foo.setAttribute() or foo.getAttribute().  The second, the "IDL
> attribute" (may be called "DOM attribute" or "property" in some
> places) is what you're manipulating when you do foo.bar (where foo is
> an element and bar is an attribute name).
>
> The content attribute can exist or not; if it exists, it's considered
> 'on', and if it doesn't it's considered 'off'.  It's a string, and if
> specified must be one of the two values I mentioned previously.
>
> The IDL attribute is a boolean.  It's either true or false.  Setting
> it to true will set the content attribute, and setting it to false
> will remove the content attribute.
>
> So "script.async=true" is valid and does what you would expect.
> Similarly, "script.async=false" is valid and does what you would
> expect.  "script.setAttribute('async','true')" is invalid, but still
> makes the element async.  "script.setAttribute('async','false')" is
> invalid, and also makes the element async, which is not what you would
> naively expect.
>
> If you want to get more confusing, "script.async='true'" makes the
> element async, because in javascript non-empty strings evaluate as
> true.  However, "script.async='false'" would also make it async, while
> "script.async=''" doesn't.  You have to pay attention to what you're
> actually dealing with.
>
> ~TJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091208/37461bce/attachment.htm>

From ian at hixie.ch  Wed Dec  9 04:39:17 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 12:39:17 +0000 (UTC)
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
Message-ID: <Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>


On Fri, 4 Dec 2009, Alexey Proskuryakov wrote:
> On 03.12.2009, at 18:07, Ian Hickson wrote:
> 
> > I could change the spec to make the readyState attribute changes be 
> > queued along with the event dispatch,
> 
> I do not understand why the events are queued, to begin with. 

How else would it work? We can't interrupt a running script to run an 
event dispatch, or fire an event in the middle of the HTML parser running, 
or fire an event while a plugin is doing sychronous DOM changes -- we 
always have to wait for the event loop's current running task to have 
finished. That's what queuing a task means.


> > but then we'd have a situation whereby the "actual" state of the 
> > websocket object might not match the state returned by the attribute.
> 
> This doesn't sounds like an issue to me. The "actual" state is always 
> out of sync, because client and server have different ideas of actual 
> state. So does an Ethernet controller, OS interrupt handler, low level 
> OS networking code, etc. The only state that matters client-side is what 
> JavaScript code sees, and all the intermediaries must (and do) act as if 
> that were the real thing.

I'm not talking about the state of the network, but about the state of the 
object itself. You would end up in situations where, for instance, sending 
would work fine, even though the state attribute said that you hadn't 
connected yet.

I suppose we could get around that by saying that the attribute _is_ the 
state, so even if the object thinks it has a connection, the send() would 
still fail until the first event has fired and the state has changed... 
Would that be acceptable?

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

From ian at hixie.ch  Wed Dec  9 06:56:43 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 14:56:43 +0000 (UTC)
Subject: [whatwg] Interface objects defined in Web Workers outside
	workers
In-Reply-To: <op.u4kq0w0oidj3kv@zcorpandell.linkoping.osa>
References: <op.u4kq0w0oidj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0912091430580.29336@hixie.dreamhostps.com>

On Mon, 7 Dec 2009, Simon Pieters wrote:
>
> It's not clear from the Web Workers spec which interface objects and 
> constructors should be available to the non-worker context. Worker and 
> SharedWorker obviously should be available, but what about 
> AbstractWorker and the others? I think Worker, SharedWorker and 
> ErrorEvent should probably be available, but the others not.

WebIDL says they're all always available. I've excluded the ones where 
that should not happen, and made AbstractWorker an editorial issue (by 
using [Supplemental] in a new fourth way... I hope we get a spec for that 
one day!).

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

From ian at hixie.ch  Wed Dec  9 07:02:40 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 15:02:40 +0000 (UTC)
Subject: [whatwg] Inconsistent naming for interfaces in workers
In-Reply-To: <op.u4krkunjidj3kv@zcorpandell.linkoping.osa>
References: <op.u4krkunjidj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0912091456500.29336@hixie.dreamhostps.com>

On Mon, 7 Dec 2009, Simon Pieters wrote:
>
> The Navigator and WorkerLocation interfaces in workers have inconsistent 
> naming. Please rename the Navigator interface to WorkerNavigator.

WorkerLocation was a mistake; it was supposed to be Location, for 
consistency with Window. But I guess it's better to use unique names, so 
that we avoid having clashes and confusion everywhere. Done.

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

From ian at hixie.ch  Wed Dec  9 07:28:56 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 15:28:56 +0000 (UTC)
Subject: [whatwg] Number of workers (various threads)
In-Reply-To: <4B1D9FEB.8030808@enseirb-matmeca.fr>
References: <4AFCC2A0.1030202@enseirb-matmeca.fr>
	<Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com>
	<4B1D9FEB.8030808@enseirb-matmeca.fr>
Message-ID: <Pine.LNX.4.62.0912091503590.29336@hixie.dreamhostps.com>

On Mon, 7 Dec 2009, David Bruant wrote:
> Ian Hickson:
> > David Bruant:
> > > In the delegation example, the number of workers chosen is an 
> > > arbitrary 10. But, in a single-core processor, having only one 
> > > worker will result in more or less the same running time, because at 
> > > the end, each worker runs on the only core."
> >
> > That depends on the algorithm. If the algorithm uses a lot of data, 
> > then a single hardware thread might be able to run two workers in the 
> > same time as it runs one, with one worker waiting for data while the 
> > other runs code, and with the workers trading back and forth.
> > 
> > Personally I would recommend basing the number of workers on the number 
> > of shards that the input data is split into, and then relying on the UA 
> > to avoid thrashing. I would expect UAs to notice when a script spawns a 
> > bazillion workers, and have the UA run them in a staggered fashion, so 
> > as to not starve the system resources. This is almost certainly needed 
> > anyway, to prevent pages from DOSing the user's system."
> 
> Wouldn't it be preferable to have an implementation-dependant "maximum 
> number of workers" and to raise a security exception when this number is 
> reached ? Maximum per domain ? per document ?

On Mon, 7 Dec 2009, Drew Wilson wrote:
>
> We discussed this previously ( 
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html) 
> - the consensus was that since the Worker APIs are inherently 
> asynchronous, user agents were free to impose limits on worker creation 
> (and queue up new creation requests when the limit has been hit), but 
> the spec should be silent on this issue.
> 
> FWIW, Chrome does this - we limit each tab to a maximum of 16 workers, 
> with an overall limit of 64 - the 17th worker creation request for a tab 
> is queued up until another worker exits to make room for it. Chrome 
> currently has the limitation that each worker runs in its own process - 
> when we address that limitation, we expect to adjust the limits 
> accordingly.

I agree with Drew that it is better not to have hard limits. I don't 
really see the benefit of hard limits. Sometimes, workers aren't used for 
splitting a high-CPU task into many shards, they're used for splitting 
logically unrelated tasks into separate code units. This case is frankly 
likely to be more common, in fact. And in this case, I don't see why you'd 
want to limit it to the same limit as if the system was under heavy load.


On Mon, 7 Dec 2009, David Bruant wrote:
> Ian Hickson wrote:
> > On Wed, 11 Nov 2009, David Bruant wrote:
> >>
> >> My concern is about the arbitrarity of the "10".
> >
> > I agree that it's suboptimal. However, I think realistically a good 
> > implementation of parallel work would need some sort of dynamic 
> > performance tuning, continuously slowly ramping up the number of workers 
> > while it increases throughput, and when throughput decreases, switching to 
> > reducing the number of workers until throughput increases again. That 
> > would probably be too complicated to show in an example in the spec.
> 
> As far as I know, if the running time is a decreasing function of the
> number of workers (which seems to be a non-such-trivial assumption), the
> best algorithm (on average, of course !) is to double the number of
> workers until finding a barrier in the running time (find n such as the
> max is between [2^n, 2^(n+1)[ ). Then, use a dichotomy algorithm in this
> interval.
> 
> However, running this algorithm each time a UA comes in your website can
> become to be costly.

Sure. You'd want to remember where you left off, and start from there, as 
an optimisation.


> I think that the spec should say something about "finding the correct 
> number of thread for your problem" and encourage authors to store their 
> value with the local storage and add a date to re-run the algorithm if 
> the value is old (more than two months ?)

I think this kind of low-level advice is best left to best-practices 
guides and tutorials. I haven't added it to the spec. I'm concerned that 
it's still early days for this API and so we shouldn't be making hard and 
fast recommendations that may turn out to be wrong.


> >> My point is that this number may be available very easily. For 
> >> example, in my dual-core, Linux, Firefox 3.5, the number is 2. Why 
> >> spare an information that can be useful and reliable (more than 
> >> measurement at least !) ?
> >
> > It's actually probably quite rarely 2. It depends on all kinds of 
> > factors, like the kind of algorithm, what other programs are running, 
> > etc.
> >
> > I still haven't added this feature, as I do not believe the arguments 
> > presented form a convincing case. However, if you are still interested 
> > in persuing this feature, I encourage you to convince a browser vendor 
> > to implement it, as discussed here:
> >    
> > http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>
> I understand now that my proposition was not very realistic. However, I 
> think that something should be described in the spec to avoid arbitrary 
> choices of number of workers.
> 
> I'm convinced that with canvas and workers, we will see very soon fancy 
> web video games with AI. Authors of those games will want to use as many 
> computation power as possible for their AI, so the "best number of 
> workers" will be a value that they are interested in.
> 
> So, either an "hint" can be provided by the spec through the Navigator 
> object, either the spec could provide the above described method 
> (improve my description or ask me to improve it if you want) to find the 
> "best" number (according to a particular problem).

Until we know what to recommend, it's probably too early to add something 
to the spec. Specs tend to have a little more weight than we might want to 
give to a recommendation right now. I would suggest writing tutorials and 
best practices guides and seeing what experiences we get from that.


On Mon, 7 Dec 2009, David Bruant wrote:
> >
> > Plus, since browsers don't have thread-safe DOM implementations, we 
> > actually can't expose the DOM in workers. Maybe one day. :-)
>
> I'm sorry for the misunderstanding. I shouldn't have said "the DOM API". 
> To be as accurate as I can be I want to provide the DOMImplementation 
> interface (http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-102161490) 
> to the workers. As I'm going to explain, the point is to be able to 
> create a document and then a documentFragment.

Since browsers don't have thread-safe DOM implementations, that's 
basically a non-starter. It doesn't matter that we aren't offering access 
to the same DOM in pages and workers; the actual innards of the DOM 
implementations aren't thread safe.

As soon as browsers are able to implement this, I'm sure it will be added 
to the spec.

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

From ian at hixie.ch  Wed Dec  9 09:01:30 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 17:01:30 +0000 (UTC)
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <4AE85ABE.6090507@mit.edu>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
Message-ID: <Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>

On Wed, 28 Oct 2009, tali garsiel wrote:
> 
> This is a quote from Section 4.2 of the spec:
> 
> "A style sheet in the context of the Document of an HTML parser or XML 
> parser is said to be a style sheet blocking scripts if the element was 
> created by that Document's parser, and the element is either a style 
> element or a link element that was an external resource link that 
> contributes to the styling processing model when the element was created 
> by the parser, and the element's style sheet was enabled when the 
> element was created by the parser, and the element's style sheet ready 
> flag is not yet set, and, the last time the event loop reached step 1, 
> the element was in that Document"
> 
> And the section about parsing - the "<script>" tag says that before 
> executing a script the parser must:
> 
> 3. Spin the event loop until there is no style sheet blocking scripts 
> and the script's "ready to be parser-executed" flag is set.
> 
> I have two questions:
> 
> 1. As far as I know, Firefox and Webkit have a "stall on demand" 
> behavior, where a stylesheet blocks a script only if the script asks 
> from style information. According to the spec the style sheet always 
> blocks a script, am I right?
> 
> 2. Can you clarify the condition - "the element's style sheet was 
> enabled when the element was created by the parser, and the element's 
> style sheet ready flag is not yet set, and, the last time the event loop 
> reached step 1, the element was in that Document"
> 
> Does it mean the style sheet blocks scripts only if it's currently being 
> parsed?

On Wed, 28 Oct 2009, Boris Zbarsky wrote:
> On 10/28/09 2:59 AM, tali garsiel wrote:
> > 1. As far as I know, Firefox and Webkit have a "stall on demand" 
> > behavior, where a stylesheet blocks a script only if the script asks 
> > from style information.
> 
> You know wrong, sorry.  Firefox has the behavior the spec describes; 
> webkit blocks the parser completely on stylesheets (the behavior Firefox 
> used to have).  Last I checked, at least.
> 
> > 2. Can you clarify the condition - "the element's style sheet was 
> > enabled when the element was created by the parser, and the element's 
> > style sheet ready flag is not yet set, and, the last time the event 
> > loop reached step 1, the element was in that Document"
> 
> The parts of that condition basically mean:
> 
> 1)  When the element was created by the parser, it was in the then-enabled
> stylesheet set (i.e. not an alternate stylesheet).
> 2)  The stylesheet, or one of its @import descendants, is still loading.
> 3)  The stylesheet linking element is still in the document (so the stylesheet
> still applies).

Thanks Boris.

Tali, does this answer your question to your satisfaction?

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

From ian at hixie.ch  Wed Dec  9 09:08:29 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 17:08:29 +0000 (UTC)
Subject: [whatwg] Canvas.cloneNode()
In-Reply-To: <op.u3ewoee01ejg13@sandra-svwliu01>
References: <fdd21a0e0910300903y23bcbfe2u7efa11796e81767a@mail.gmail.com>
	<op.u3ewoee01ejg13@sandra-svwliu01>
Message-ID: <Pine.LNX.4.62.0912091707060.29336@hixie.dreamhostps.com>

On Fri, 30 Oct 2009, OmegaJunior wrote:
> 
> Since Last Call was announced and I just ran into this problem, hereby 
> this question:
> 
> If an image is drawn on a Canvas element, and subsequently the 
> javascript function cloneNode(true) is executed for that element, should 
> the clone include a copy of the source canvas image, or should it show 
> an empty space?
> 
> From my perspective (the web author), I'd prefer to have the canvas 
> image included when executing (the deep) cloneNode(true), and excluded 
> it when using (the shallow) cloneNode(false).

The cloneNode() method just clones the node, not the node's state, so the 
bitmap isn't copied. You can easily draw one bitmap onto the other, 
though, using drawImage().


On Sat, 14 Nov 2009, Michael A. Puls II wrote:
> 
> I think it'd be cool if the clone showed the image. But, I'm pretty sure 
> cloneNode(true) is just supposed to create a new canvas element with the 
> same attributes and childNodes as the original. It's not supposed to 
> copy everything that's going on with the element being copied.
> 
> There are some exceptions with state for certain elements. Perhaps that 
> can happen with canvas too.

I'd rather keep these exceptions to an absolute minimum. cloneNode() is 
part of the DOM Core API, and it would be bad for nodes to clone 
differently based on whether it's an HTML-aware UA implementing the DOM 
Core API or not.

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

From ian at hixie.ch  Wed Dec  9 09:25:23 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 17:25:23 +0000 (UTC)
Subject: [whatwg] <model/>: A 3D Equivalent to <img/>
In-Reply-To: <d7e38f950911021919t40cf4626w1331696e0a05d9b4@mail.gmail.com>
References: <BAY118-W39D211EF9A33AD0B1F6448BCB20@phx.gbl>
	<d7e38f950911021919t40cf4626w1331696e0a05d9b4@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912091719180.29336@hixie.dreamhostps.com>

On Fri, 30 Oct 2009, Brian Blakely wrote:
>
> To ensure HTML remains semantic as the web makes its gradual transition 
> to 3D rich interfaces and content, I am submitting a proposal for 
> WHATWG's consideration.

I encourage you to follow the suggestions given in the FAQ on how to 
proposed new features:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

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

From ap at webkit.org  Wed Dec  9 09:32:19 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Wed, 09 Dec 2009 09:32:19 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>
Message-ID: <F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>


On 09.12.2009, at 4:39, Ian Hickson wrote:

>>> I could change the spec to make the readyState attribute changes be
>>> queued along with the event dispatch,
>>
>> I do not understand why the events are queued, to begin with.
>
> How else would it work? We can't interrupt a running script to run an
> event dispatch, or fire an event in the middle of the HTML parser  
> running,
> or fire an event while a plugin is doing sychronous DOM changes -- we
> always have to wait for the event loop's current running task to have
> finished. That's what queuing a task means.

This is only an issue if WebSocket handling is performed in some other  
thread of execution (and even then, it's not really an issue). But I  
don't think that's the best way to think about it.

Data from network is only processed as an event loop task, so it's  
possible and desirable to dispatch events right away. Both single- 
process and multi-process implementations I know of do so - and even  
if some future implementation wants to run WebSocket code on a  
different thread, they can easily implement synchronous event dispatch  
by posting an event and waiting for it to be processed.

This is no different from how XMLHttpRequest works - browser engines  
do not need to queue tasks for onreadystate events, and do not - those  
are dispatched right away.

>>> but then we'd have a situation whereby the "actual" state of the
>>> websocket object might not match the state returned by the  
>>> attribute.
>>
>> This doesn't sounds like an issue to me. The "actual" state is always
>> out of sync, because client and server have different ideas of actual
>> state. So does an Ethernet controller, OS interrupt handler, low  
>> level
>> OS networking code, etc. The only state that matters client-side is  
>> what
>> JavaScript code sees, and all the intermediaries must (and do) act  
>> as if
>> that were the real thing.
>
> I'm not talking about the state of the network, but about the state  
> of the
> object itself. You would end up in situations where, for instance,  
> sending
> would work fine, even though the state attribute said that you hadn't
> connected yet.
>
> I suppose we could get around that by saying that the attribute _is_  
> the
> state, so even if the object thinks it has a connection, the send()  
> would
> still fail until the first event has fired and the state has  
> changed...
> Would that be acceptable?


I don't understand what this means.

- WBR, Alexey Proskuryakov


From ian at hixie.ch  Wed Dec  9 09:34:08 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 17:34:08 +0000 (UTC)
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
Message-ID: <Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>

On Wed, 9 Dec 2009, Alexey Proskuryakov wrote:
> 
> Data from network is only processed as an event loop task

I do not believe this is accurate. It certainly isn't what is specced.

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

From ian at hixie.ch  Wed Dec  9 09:42:25 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 17:42:25 +0000 (UTC)
Subject: [whatwg] <a onlyreplace>
In-Reply-To: <989aa6910910312100v5e20d125y998162d5ca85bffe@mail.gmail.com>
References: <989aa6910910312100v5e20d125y998162d5ca85bffe@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912091741270.29336@hixie.dreamhostps.com>

On Sat, 31 Oct 2009, Rowan Nairn wrote:
> 
> I want to provide an animated page transition that doesn't break the 
> back button or the URL bar and degrades gracefully in non-javascript 
> UAs.  You can see an example of this at http://mrtaggy.com/ .  This is a 
> site I launched last year that uses animations to show transitions 
> between search result pages. Leaving aside whether you like this 
> particular set of animations, I think you'll probably a agree that 
> animations are used well in many applications to help users keep track 
> of change.  It would be nice if this was easy to do on the web.

This seems like a presentation-level feature -- I'd recommend raising this 
with the CSS working group. It might make sense to provide the CSS 
transition module with a hook for page transitions as well as the 
transitions it does now, for instance.

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

From jonas at sicking.cc  Wed Dec  9 09:47:21 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 9 Dec 2009 09:47:21 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com> 
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com> 
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com> 
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com> 
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>
Message-ID: <63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com>

On Wed, Dec 9, 2009 at 9:34 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 9 Dec 2009, Alexey Proskuryakov wrote:
>>
>> Data from network is only processed as an event loop task
>
> I do not believe this is accurate. It certainly isn't what is specced.

In XMLHttpRequest this is certainly accurate. You will never see
.responseText changing in the middle of an execution thread, it's
always changed in response of a task run from the event loop. This
task can (and IMO should) synchronously fire the 'progress' event
(within the usual limitations of never firing that event more often
than every 50ms).

/ Jonas

From anewpage.media at gmail.com  Wed Dec  9 09:49:13 2009
From: anewpage.media at gmail.com (Brian Blakely)
Date: Wed, 9 Dec 2009 12:49:13 -0500
Subject: [whatwg] <model/>: A 3D Equivalent to <img/>
In-Reply-To: <Pine.LNX.4.62.0912091719180.29336@hixie.dreamhostps.com>
References: <BAY118-W39D211EF9A33AD0B1F6448BCB20@phx.gbl>
	<d7e38f950911021919t40cf4626w1331696e0a05d9b4@mail.gmail.com> 
	<Pine.LNX.4.62.0912091719180.29336@hixie.dreamhostps.com>
Message-ID: <d7e38f950912090949q104531fcp9be712f88b675bd6@mail.gmail.com>

Thank you Ian.  My next step is to create a website that will allow authors
to discuss a presentation explaining <model/>, then to contact the Mozilla
and Webkit groups.  This should take place over the next couple of weeks,
and I will report back to WHATWG with updates.

-Brian

On Wed, Dec 9, 2009 at 12:25 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 30 Oct 2009, Brian Blakely wrote:
> >
> > To ensure HTML remains semantic as the web makes its gradual transition
> > to 3D rich interfaces and content, I am submitting a proposal for
> > WHATWG's consideration.
>
> I encourage you to follow the suggestions given in the FAQ on how to
> proposed new features:
>
>
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>
> Cheers,
> --
> 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/20091209/31654eb0/attachment.htm>

From ian at hixie.ch  Wed Dec  9 09:53:38 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 17:53:38 +0000 (UTC)
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com> 
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com> 
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com> 
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>
	<63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>

On Wed, 9 Dec 2009, Jonas Sicking wrote:
> On Wed, Dec 9, 2009 at 9:34 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 9 Dec 2009, Alexey Proskuryakov wrote:
> >>
> >> Data from network is only processed as an event loop task
> >
> > I do not believe this is accurate. It certainly isn't what is specced.
> 
> In XMLHttpRequest this is certainly accurate. You will never see
> .responseText changing in the middle of an execution thread, it's
> always changed in response of a task run from the event loop.

Sure. From the spec's point of view, a task is queued by the background 
network thread to update the responseText attribute. (I haven't checked if 
that's how Anne actually specced it, but something to that effect is 
needed, otherwise you can see the attribute changing from under you in a 
running script.)

I'm absolutely fine with changing WebSocket to change readyState as part 
of the same task that dispatches the event, but we can't just say there's 
no task, that makes no sense.

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

From jonas at sicking.cc  Wed Dec  9 10:06:04 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 9 Dec 2009 10:06:04 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com> 
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com> 
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com> 
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com> 
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com> 
	<63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com> 
	<Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>
Message-ID: <63df84f0912091006w4dbae18fp685b13f4402c38ba@mail.gmail.com>

On Wed, Dec 9, 2009 at 9:53 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 9 Dec 2009, Jonas Sicking wrote:
>> On Wed, Dec 9, 2009 at 9:34 AM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Wed, 9 Dec 2009, Alexey Proskuryakov wrote:
>> >>
>> >> Data from network is only processed as an event loop task
>> >
>> > I do not believe this is accurate. It certainly isn't what is specced.
>>
>> In XMLHttpRequest this is certainly accurate. You will never see
>> .responseText changing in the middle of an execution thread, it's
>> always changed in response of a task run from the event loop.
>
> Sure. From the spec's point of view, a task is queued by the background
> network thread to update the responseText attribute. (I haven't checked if
> that's how Anne actually specced it, but something to that effect is
> needed, otherwise you can see the attribute changing from under you in a
> running script.)
>
> I'm absolutely fine with changing WebSocket to change readyState as part
> of the same task that dispatches the event

Yes, that is what I think the spec should say.

/ Jonas

From ian at hixie.ch  Wed Dec  9 10:07:26 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 18:07:26 +0000 (UTC)
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <63df84f0912091006w4dbae18fp685b13f4402c38ba@mail.gmail.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com> 
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com> 
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com> 
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com> 
	<63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com> 
	<Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>
	<63df84f0912091006w4dbae18fp685b13f4402c38ba@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912091807070.16061@hixie.dreamhostps.com>

On Wed, 9 Dec 2009, Jonas Sicking wrote:
> >
> > I'm absolutely fine with changing WebSocket to change readyState as 
> > part of the same task that dispatches the event
> 
> Yes, that is what I think the spec should say.

Done.

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

From ap at webkit.org  Wed Dec  9 10:23:08 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Wed, 09 Dec 2009 10:23:08 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <Pine.LNX.4.62.0912091807070.16061@hixie.dreamhostps.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>
	<63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com>
	<Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>
	<63df84f0912091006w4dbae18fp685b13f4402c38ba@mail.gmail.com>
	<Pine.LNX.4.62.0912091807070.16061@hixie.dreamhostps.com>
Message-ID: <95E3D00E-40E0-40C3-AC49-B2F3E3D8154D@webkit.org>


On 09.12.2009, at 10:07, Ian Hickson wrote:

>>> I'm absolutely fine with changing WebSocket to change readyState as
>>> part of the same task that dispatches the event
>>
>> Yes, that is what I think the spec should say.
>
> Done.

With the updated text, there is a race condition between closing a  
socket and removing all data that was received. The spec says "When a  
user agent is to close the Web Socket connection, it must drop all  
subsequent data from the server" - but with the current spec text, you  
can get message events after you call close() from onopen handler.

- WBR, Alexey Proskuryakov



From ian at hixie.ch  Wed Dec  9 10:40:41 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 18:40:41 +0000 (UTC)
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <95E3D00E-40E0-40C3-AC49-B2F3E3D8154D@webkit.org>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>
	<63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com>
	<Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>
	<63df84f0912091006w4dbae18fp685b13f4402c38ba@mail.gmail.com>
	<Pine.LNX.4.62.0912091807070.16061@hixie.dreamhostps.com>
	<95E3D00E-40E0-40C3-AC49-B2F3E3D8154D@webkit.org>
Message-ID: <Pine.LNX.4.62.0912091839570.16061@hixie.dreamhostps.com>

On Wed, 9 Dec 2009, Alexey Proskuryakov wrote:
> On 09.12.2009, at 10:07, Ian Hickson wrote:
> > > > 
> > > > I'm absolutely fine with changing WebSocket to change readyState 
> > > > as part of the same task that dispatches the event
> > > 
> > > Yes, that is what I think the spec should say.
> > 
> > Done.
> 
> With the updated text, there is a race condition between closing a 
> socket and removing all data that was received. The spec says "When a 
> user agent is to close the Web Socket connection, it must drop all 
> subsequent data from the server" - but with the current spec text, you 
> can get message events after you call close() from onopen handler.

Fixed. This also makes readyState change to CLOSED as soon as you call 
close() (the 'close' event is still queued, though, it doesn't fire 
synchronously during the close() call).

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

From ap at webkit.org  Wed Dec  9 10:44:56 2009
From: ap at webkit.org (Alexey Proskuryakov)
Date: Wed, 09 Dec 2009 10:44:56 -0800
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <Pine.LNX.4.62.0912091807070.16061@hixie.dreamhostps.com>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>
	<63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com>
	<Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>
	<63df84f0912091006w4dbae18fp685b13f4402c38ba@mail.gmail.com>
	<Pine.LNX.4.62.0912091807070.16061@hixie.dreamhostps.com>
Message-ID: <E4EC4CDC-F53D-4D53-B4DC-145750DF6611@webkit.org>


On 09.12.2009, at 10:07, Ian Hickson wrote:

>>> I'm absolutely fine with changing WebSocket to change readyState as
>>> part of the same task that dispatches the event
>>
>> Yes, that is what I think the spec should say.
>
> Done.


As discussed on IRC, this leaves us with a race condition between  
close() and queued messages. The spec says that once close() is  
invoked, incoming data should be dropped, but queued tasks to dispatch  
message event will still be coming.

This race condition can of course be fixed without much difficulty. It  
may be more difficult to similarly rearrange XHR specs.

I find it unfortunate that where the spec says "queue a task", most  
(or all) implementations will perform those actions immediately. This  
may be indistinguishable from JavaScript client code, but it will be a  
source of confusion for developers.

- WBR, Alexey Proskuryakov


From bruant at enseirb-matmeca.fr  Wed Dec  9 10:46:20 2009
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Wed, 09 Dec 2009 10:46:20 -0800
Subject: [whatwg] providing a DOM API to workers without a thread-safe DOM
 implementation
In-Reply-To: <Pine.LNX.4.62.0912091503590.29336@hixie.dreamhostps.com>
References: <4AFCC2A0.1030202@enseirb-matmeca.fr>	<Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com>	<4B1D9FEB.8030808@enseirb-matmeca.fr>
	<Pine.LNX.4.62.0912091503590.29336@hixie.dreamhostps.com>
Message-ID: <4B1FF07C.6090808@enseirb.fr>


> On Mon, 7 Dec 2009, David Bruant wrote:
>    
>>> Plus, since browsers don't have thread-safe DOM implementations, we
>>> actually can't expose the DOM in workers. Maybe one day. :-)
>>>        
>> I'm sorry for the misunderstanding. I shouldn't have said "the DOM API".
>> To be as accurate as I can be I want to provide the DOMImplementation
>> interface (http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-102161490)
>> to the workers. As I'm going to explain, the point is to be able to
>> create a document and then a documentFragment.
>>      
> Since browsers don't have thread-safe DOM implementations, that's
> basically a non-starter. It doesn't matter that we aren't offering access
> to the same DOM in pages and workers; the actual innards of the DOM
> implementations aren't thread safe.
>
> As soon as browsers are able to implement this, I'm sure it will be added
> to the spec.
>    
=> The point of my "Re: [whatwg] [WebWorkers] Advocation to provide the 
DOM API to the workers" e-mail of the December 7th was to prove that we 
don't even need a thread-safe implementation.

The requirement is just to have 2 implementations (which can be the 
same, but it would be a "coincidence") one for the main browsing 
context, the other for workers. Then, I'm describing a way to 
communicate (through postMessage and the onmessage handler) which allow 
to send and recieve DOM objects (Node/Element/Document/DocumentFragment) 
in a safe way (basically, by breaking the references to DOM objects 
coming from another implementation and I think that I have enumerated 
all of them and found a proper solution for each).

I think that what I describe can be implemented without a thread-safe 
implementation (so, it could be already implemented today).

David

From ian at hixie.ch  Wed Dec  9 10:51:36 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 18:51:36 +0000 (UTC)
Subject: [whatwg] Thread to run Web Socket feedback from the protocol ?
In-Reply-To: <E4EC4CDC-F53D-4D53-B4DC-145750DF6611@webkit.org>
References: <de17d48e0912022346g7a5d8f95l46668c8af47e5867@mail.gmail.com>
	<9A358674-F4AE-4504-8092-FF45190A4F11@webkit.org>
	<98070607-5D02-4AF5-9606-D9C780A1A991@apple.com>
	<Pine.LNX.4.62.0912040202110.15540@hixie.dreamhostps.com>
	<3E06B198-38B2-4BDA-9012-F45995EDDDE9@webkit.org>
	<Pine.LNX.4.62.0912091230050.29336@hixie.dreamhostps.com>
	<F8DE3F76-A621-445A-8FE8-CB023F9C1555@webkit.org>
	<Pine.LNX.4.62.0912091733130.16061@hixie.dreamhostps.com>
	<63df84f0912090947x6a699933oc2fd206a4e4a6174@mail.gmail.com>
	<Pine.LNX.4.62.0912091751450.16061@hixie.dreamhostps.com>
	<63df84f0912091006w4dbae18fp685b13f4402c38ba@mail.gmail.com>
	<Pine.LNX.4.62.0912091807070.16061@hixie.dreamhostps.com>
	<E4EC4CDC-F53D-4D53-B4DC-145750DF6611@webkit.org>
Message-ID: <Pine.LNX.4.62.0912091847440.16061@hixie.dreamhostps.com>

On Wed, 9 Dec 2009, Alexey Proskuryakov wrote:
> On 09.12.2009, at 10:07, Ian Hickson wrote:
> > > > 
> > > > I'm absolutely fine with changing WebSocket to change readyState 
> > > > as part of the same task that dispatches the event
> > > 
> > > Yes, that is what I think the spec should say.
> > 
> > Done.
> 
> As discussed on IRC, this leaves us with a race condition between 
> close() and queued messages. The spec says that once close() is invoked, 
> incoming data should be dropped, but queued tasks to dispatch message 
> event will still be coming.
> 
> This race condition can of course be fixed without much difficulty.

I believe it has been fixed, as per my last e-mail.


> It may be more difficult to similarly rearrange XHR specs.

I'm happy to work with Anne to address this as necessary.


> I find it unfortunate that where the spec says "queue a task", most (or 
> all) implementations will perform those actions immediately. This may be 
> indistinguishable from JavaScript client code, but it will be a source 
> of confusion for developers.

I disagree with your interpretation. Wherever the spec says "queue a 
task", this can be interpreted as meaning a message posted by a network 
thread to the main UI event loop, for UAs where this makes sense. However, 
there are many other UA implementation strategies where explicitly saying 
this would be even further from the actual implementation. I think it is 
inadvisable for specs to be defining things that are not black-box 
testable.

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

From ian at hixie.ch  Wed Dec  9 10:55:21 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Dec 2009 18:55:21 +0000 (UTC)
Subject: [whatwg] providing a DOM API to workers without a thread-safe
 DOM implementation
In-Reply-To: <4B1FF07C.6090808@enseirb.fr>
References: <4AFCC2A0.1030202@enseirb-matmeca.fr>
	<Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com>
	<4B1D9FEB.8030808@enseirb-matmeca.fr>
	<Pine.LNX.4.62.0912091503590.29336@hixie.dreamhostps.com>
	<4B1FF07C.6090808@enseirb.fr>
Message-ID: <Pine.LNX.4.62.0912091851470.16061@hixie.dreamhostps.com>

On Wed, 9 Dec 2009, David Bruant wrote:
> Ian wrote:
> >
> > Since browsers don't have thread-safe DOM implementations, that's 
> > basically a non-starter. It doesn't matter that we aren't offering 
> > access to the same DOM in pages and workers; the actual innards of the 
> > DOM implementations aren't thread safe.
> > 
> > As soon as browsers are able to implement this, I'm sure it will be 
> > added to the spec.
>
> The point of my "Re: [whatwg] [WebWorkers] Advocation to provide the DOM 
> API to the workers" e-mail of the December 7th was to prove that we 
> don't even need a thread-safe implementation.

When I am referring to thread safety here I don't mean that it's not 
possible for a single DOM tree to be accessed from two threads. I mean 
that it's not possible for two DOM nodes from completely unrelated trees 
to exist on two threads, because the DOM implementations make use of 
global state (e.g. global atoms, memory pools) that are not written such 
that they can be accessed from code in multiple threads (e.g. because the 
memory allocator doesn't use locks to ensure that the memory pool is only 
mutated by one thread at once).


> The requirement is just to have 2 implementations (which can be the 
> same, but it would be a "coincidence") one for the main browsing 
> context, the other for workers.

Whether it's a second implementation or one implementation that is made 
thread-safe, UAs don't currently have it. As soon as they do, we'll be 
able to add DOM APIs to workers.


> Then, I'm describing a way to communicate (through postMessage and the 
> onmessage handler) which allow to send and recieve DOM objects 
> (Node/Element/Document/DocumentFragment) in a safe way (basically, by 
> breaking the references to DOM objects coming from another 
> implementation and I think that I have enumerated all of them and found 
> a proper solution for each).

This is not the problem.

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

From nzakas at yahoo-inc.com  Wed Dec  9 12:14:00 2009
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Wed, 9 Dec 2009 12:14:00 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com><7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com><4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com><7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com><op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>

Just curious if anyone knows why <img src=""> is the exception in the
spec, rather than having the same behavior for all elements that
download resources on page load? As far as I can tell, the spec would
currently allow self-referencing downloads for the following elements:

* <iframe>
* <embed>
* <object>
* <video>
* <audio>
* <source>

Can the self-reference <img> exception become the rule and apply to all
of these tags the same way?

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

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Nicholas Zakas
Sent: Tuesday, December 08, 2009 9:43 AM
To: Simon Pieters; Aryeh Gregor
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

The change seems reasonable to me. It just seems that the same change
should be made in all cases that cause similar issues, making it the
rule of the spec instead of an exception for this one case. Does that
make sense?

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

-----Original Message-----
From: Simon Pieters [mailto:simonp at opera.com] 
Sent: Tuesday, December 08, 2009 1:27 AM
To: Aryeh Gregor; Nicholas Zakas
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Mon, 07 Dec 2009 22:52:41 +0100, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> I don't know why <img src=""> has a special exception.  It would be
> possible to look through the svn log to see if there was a helpful
> commit message, or maybe someone will remember.

I seem to remember someone from Mozilla mentioned that they recently  
changed the behavior for img, so Hixie changed the spec for img.

-- 
Simon Pieters
Opera Software

From t_garsiel at hotmail.com  Wed Dec  9 13:42:29 2009
From: t_garsiel at hotmail.com (tali garsiel)
Date: Wed, 9 Dec 2009 21:42:29 +0000
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>,
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
Message-ID: <BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>


Well, not completely.Regarding the first question- Webkit guys told me (on their IRC channel) that the don't block the parser and only block scripts that request visual information, so I'm still  confused.

> Date: Wed, 9 Dec 2009 17:01:30 +0000
> From: ian at hixie.ch
> To: t_garsiel at hotmail.com; bzbarsky at MIT.EDU
> CC: whatwg at whatwg.org
> Subject: Re: [whatwg] style sheet blocking scripts
> 
> On Wed, 28 Oct 2009, tali garsiel wrote:
> > 
> > This is a quote from Section 4.2 of the spec:
> > 
> > "A style sheet in the context of the Document of an HTML parser or XML 
> > parser is said to be a style sheet blocking scripts if the element was 
> > created by that Document's parser, and the element is either a style 
> > element or a link element that was an external resource link that 
> > contributes to the styling processing model when the element was created 
> > by the parser, and the element's style sheet was enabled when the 
> > element was created by the parser, and the element's style sheet ready 
> > flag is not yet set, and, the last time the event loop reached step 1, 
> > the element was in that Document"
> > 
> > And the section about parsing - the "<script>" tag says that before 
> > executing a script the parser must:
> > 
> > 3. Spin the event loop until there is no style sheet blocking scripts 
> > and the script's "ready to be parser-executed" flag is set.
> > 
> > I have two questions:
> > 
> > 1. As far as I know, Firefox and Webkit have a "stall on demand" 
> > behavior, where a stylesheet blocks a script only if the script asks 
> > from style information. According to the spec the style sheet always 
> > blocks a script, am I right?
> > 
> > 2. Can you clarify the condition - "the element's style sheet was 
> > enabled when the element was created by the parser, and the element's 
> > style sheet ready flag is not yet set, and, the last time the event loop 
> > reached step 1, the element was in that Document"
> > 
> > Does it mean the style sheet blocks scripts only if it's currently being 
> > parsed?
> 
> On Wed, 28 Oct 2009, Boris Zbarsky wrote:
> > On 10/28/09 2:59 AM, tali garsiel wrote:
> > > 1. As far as I know, Firefox and Webkit have a "stall on demand" 
> > > behavior, where a stylesheet blocks a script only if the script asks 
> > > from style information.
> > 
> > You know wrong, sorry.  Firefox has the behavior the spec describes; 
> > webkit blocks the parser completely on stylesheets (the behavior Firefox 
> > used to have).  Last I checked, at least.
> > 
> > > 2. Can you clarify the condition - "the element's style sheet was 
> > > enabled when the element was created by the parser, and the element's 
> > > style sheet ready flag is not yet set, and, the last time the event 
> > > loop reached step 1, the element was in that Document"
> > 
> > The parts of that condition basically mean:
> > 
> > 1)  When the element was created by the parser, it was in the then-enabled
> > stylesheet set (i.e. not an alternate stylesheet).
> > 2)  The stylesheet, or one of its @import descendants, is still loading.
> > 3)  The stylesheet linking element is still in the document (so the stylesheet
> > still applies).
> 
> Thanks Boris.
> 
> Tali, does this answer your question to your satisfaction?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
 		 	   		  
_________________________________________________________________
Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091209/1b55220e/attachment.htm>

From jamesr at google.com  Wed Dec  9 14:10:29 2009
From: jamesr at google.com (James Robinson)
Date: Wed, 9 Dec 2009 14:10:29 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
Message-ID: <ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>

2009/12/9 tali garsiel <t_garsiel at hotmail.com>

>  Well, not completely.
> Regarding the first question- Webkit guys told me (on their IRC channel)
> that the don't block the parser and only block scripts that request visual
> information, so I'm still  confused.
>

Here's my understanding of the implementation inside WebKit currently:
During parsing, WebKit does not block the parser on stylesheet loads, but
does block external scripts from running until previously-encountered
stylesheets have loaded.  WebKit does not suspend script execution on
requests for visual information if stylesheets have not loaded (for example
for inline scripts or in the case of stylesheets added dynamically after
parsing has completed).  WebKit does suspend parsing of the document on
script loads, but has a speculative preloader to attempt to start fetches
for resources past the <script> tag.

- James




>
> > Date: Wed, 9 Dec 2009 17:01:30 +0000
> > From: ian at hixie.ch
> > To: t_garsiel at hotmail.com; bzbarsky at MIT.EDU
> > CC: whatwg at whatwg.org
> > Subject: Re: [whatwg] style sheet blocking scripts
>
> >
> > On Wed, 28 Oct 2009, tali garsiel wrote:
> > >
> > > This is a quote from Section 4.2 of the spec:
> > >
> > > "A style sheet in the context of the Document of an HTML parser or XML
> > > parser is said to be a style sheet blocking scripts if the element was
> > > created by that Document's parser, and the element is either a style
> > > element or a link element that was an external resource link that
> > > contributes to the styling processing model when the element was c
> reated
> > > by the parser, and the element's style sheet was enabled when the
> > > element was created by the parser, and the element's style sheet ready
> > > flag is not yet set, and, the last time the event loop reached step 1,
> > > the element was in that Document"
> > >
> > > And the section about parsing - the "<script>" tag says that before
> > > executing a script the parser must:
> > >
> > > 3. Spin the event loop until there is no style sheet blocking scripts
> > > and the script's "ready to be parser-executed" flag is set.
> > >
> > > I have two questions:
> > >
> > > 1. As far as I know, Firefox and Webkit have a "stall on demand"
> > > behavior, where a stylesheet blocks a script only if the script asks
> > > from style information. According to the spec the style sheet always
> > > blocks a script, am I right?
> > >
> > > 2. Can you clarify the condition - "the element's style sheet was
> > > enabled when the element was created by the parser, and the element's
> > > style sheet ready flag is not yet set, and, the last time the event
> loop
> > > reached step 1, the element was in that Document"
> > >
> > > Does it mean the style sheet blocks scripts only if it's currently
> being
> > > parsed?
> >
> > On Wed, 28 Oct 2009, Boris Zbarsky wrote:
> > > On 10/28/09 2:59 AM, tali garsiel wrote:
> > > > 1. As far as I know, Firefox and Webkit have a "stall on demand"
> > > > behavior, where a stylesheet blocks a script only if the script asks
> > > > from style information.
> > >
> > > You know wrong, sorry. Firefox has the behavior the spec describes;
> > > webkit blocks the parser completely on stylesheets (the behavior
> Firefox
> > > used to have). Last I chec ked, at least.
>
> > >
> > > > 2. Can you clarify the condition - "the element's style sheet was
> > > > enabled when the element was created by the parser, and the element's
>
> > > > style sheet ready flag is not yet set, and, the last time the event
> > > > loop reached step 1, the element was in that Document"
> > >
> > > The parts of that condition basically mean:
> > >
> > > 1) When the element was created by the parser, it was in the
> then-enabled
> > > stylesheet set (i.e. not an alternate stylesheet).
> > > 2) The stylesheet, or one of its @import descendants, is still loading.
> > > 3) The stylesheet linking element is still in the document (so the
> stylesheet
> > > still applies).
> >
> > Thanks Boris.
> >
> > Tali, does this answer your question to your satisfaction?
> >
> > --
> > Ian Hickson U+1047E )\._.,--....,'``. fL
> > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
> ------------------------------
> Windows Live Hotmail: Your friends can get your Facebook updates, right
> from Hotmail?.<http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091209/e66429d3/attachment.htm>

From jonas at sicking.cc  Wed Dec  9 14:53:37 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 9 Dec 2009 14:53:37 -0800
Subject: [whatwg] providing a DOM API to workers without a thread-safe
	DOM implementation
In-Reply-To: <Pine.LNX.4.62.0912091851470.16061@hixie.dreamhostps.com>
References: <4AFCC2A0.1030202@enseirb-matmeca.fr>
	<Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com> 
	<4B1D9FEB.8030808@enseirb-matmeca.fr>
	<Pine.LNX.4.62.0912091503590.29336@hixie.dreamhostps.com> 
	<4B1FF07C.6090808@enseirb.fr>
	<Pine.LNX.4.62.0912091851470.16061@hixie.dreamhostps.com>
Message-ID: <63df84f0912091453v57a38adq49a0889a9718daca@mail.gmail.com>

On Wed, Dec 9, 2009 at 10:55 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 9 Dec 2009, David Bruant wrote:
>> Ian wrote:
>> >
>> > Since browsers don't have thread-safe DOM implementations, that's
>> > basically a non-starter. It doesn't matter that we aren't offering
>> > access to the same DOM in pages and workers; the actual innards of the
>> > DOM implementations aren't thread safe.
>> >
>> > As soon as browsers are able to implement this, I'm sure it will be
>> > added to the spec.
>>
>> The point of my "Re: [whatwg] [WebWorkers] Advocation to provide the DOM
>> API to the workers" e-mail of the December 7th was to prove that we
>> don't even need a thread-safe implementation.
>
> When I am referring to thread safety here I don't mean that it's not
> possible for a single DOM tree to be accessed from two threads. I mean
> that it's not possible for two DOM nodes from completely unrelated trees
> to exist on two threads, because the DOM implementations make use of
> global state (e.g. global atoms, memory pools) that are not written such
> that they can be accessed from code in multiple threads (e.g. because the
> memory allocator doesn't use locks to ensure that the memory pool is only
> mutated by one thread at once).

I can only speak for the gecko implementation, but what Ian says here
is completely true.

Behind the scenes there is lots of global data structures that we
can't access from any other thread than the main thread. Thus we can't
currently implement the DOM on any worker threads, even if any given
node only ever lives on a single thread.

We couldn't for example use the event dispatch code, or the
XMLHttpRequest code directly in the worker thread. For events we
basically duplicated the event dispatch code (or rather, we wrote
another, much simpler, version to be used in workers). For
XMLHttpRequest we end up proxying lots of information to the main
thread where the majority of the code is run.

/ Jonas

From jonas at sicking.cc  Wed Dec  9 14:55:53 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 9 Dec 2009 14:55:53 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com> 
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com> 
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <63df84f0912091455y92b62bdl32328e0e08744802@mail.gmail.com>

On Wed, Dec 9, 2009 at 12:14 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Just curious if anyone knows why <img src=""> is the exception in the
> spec, rather than having the same behavior for all elements that
> download resources on page load? As far as I can tell, the spec would
> currently allow self-referencing downloads for the following elements:
>
> * <iframe>
> * <embed>
> * <object>
> * <video>
> * <audio>
> * <source>

As stated. If the other browser vendors are ok with it, I'm ok with
making the empty string mean "don't load" in all these cases. I.e.
treat an empty src/href attribute the same way as an absence of the
attribute (except for <script> which still wouldn't treat it as an
inline script).

/ Jonas

From jonas at sicking.cc  Wed Dec  9 14:57:56 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 9 Dec 2009 14:57:56 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu> 
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com> 
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
Message-ID: <63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>

On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com> wrote:
> 2009/12/9 tali garsiel <t_garsiel at hotmail.com>
>>
>> Well, not completely.
>> Regarding the first question- Webkit guys told me (on their IRC channel)
>> that the don't block the parser and only block scripts that request visual
>> information, so I'm still ?confused.
>
> Here's my understanding of the implementation inside WebKit currently:
> During parsing, WebKit does not block the parser on stylesheet loads, but
> does block external scripts from running until previously-encountered
> stylesheets have loaded. ?WebKit does not suspend script execution on
> requests for visual information if stylesheets have not loaded (for example
> for inline scripts or in the case of stylesheets added dynamically after
> parsing has completed). ?WebKit does suspend parsing of the document on
> script loads, but has a speculative preloader to attempt to start fetches
> for resources past the <script> tag.

Why does webkit treat external scripts different from inline scripts
here? I.e. why is an inline script allowed to run even if there are
pending stylesheet loads, but external scripts not? That seems
inconsistent and confusing.

Is this considered a bug or desired behavior?

/ Jonas

From jamesr at google.com  Wed Dec  9 15:06:00 2009
From: jamesr at google.com (James Robinson)
Date: Wed, 9 Dec 2009 15:06:00 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>
Message-ID: <ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>

On Wed, Dec 9, 2009 at 2:57 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com> wrote:
> > 2009/12/9 tali garsiel <t_garsiel at hotmail.com>
> >>
> >> Well, not completely.
> >> Regarding the first question- Webkit guys told me (on their IRC channel)
> >> that the don't block the parser and only block scripts that request
> visual
> >> information, so I'm still  confused.
> >
> > Here's my understanding of the implementation inside WebKit currently:
> > During parsing, WebKit does not block the parser on stylesheet loads, but
> > does block external scripts from running until previously-encountered
> > stylesheets have loaded.  WebKit does not suspend script execution on
> > requests for visual information if stylesheets have not loaded (for
> example
> > for inline scripts or in the case of stylesheets added dynamically after
> > parsing has completed).  WebKit does suspend parsing of the document on
> > script loads, but has a speculative preloader to attempt to start fetches
> > for resources past the <script> tag.
>
> Why does webkit treat external scripts different from inline scripts
> here? I.e. why is an inline script allowed to run even if there are
> pending stylesheet loads, but external scripts not? That seems
> inconsistent and confusing.
>
> Is this considered a bug or desired behavior?
>

The former:
http://trac.webkit.org/browser/trunk/WebCore/html/HTMLTokenizer.cpp#L2017

<http://trac.webkit.org/browser/trunk/WebCore/html/HTMLTokenizer.cpp#L2017>I'm
not sure how much this matters in practice.  In theory, this is unobservable
to the page unless it queries the loaded stylesheets directly or a property
derived from layout both of which should suspend script execution.

- James


>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091209/8cf4fa8c/attachment.htm>

From bzbarsky at MIT.EDU  Wed Dec  9 15:18:35 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 09 Dec 2009 15:18:35 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>	<4AE85ABE.6090507@mit.edu>	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>
	<ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>
Message-ID: <4B20304B.7010108@mit.edu>

On 12/9/09 3:06 PM, James Robinson wrote:
>     On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com
>     <mailto:jamesr at google.com>> wrote:
>> WebKit does not suspend script execution on requests for visual information if stylesheets have not loaded

> In theory, this is unobservable to the page unless it queries the loaded stylesheets
> directly or a property derived from layout both of which should suspend
> script execution.

I'm having a hard time reconciling the above two claims.

-Boris

From jonas at sicking.cc  Wed Dec  9 15:18:51 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 9 Dec 2009 15:18:51 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu> 
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com> 
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com> 
	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com> 
	<ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>
Message-ID: <63df84f0912091518l4f0223c6h9c1c4a685eadf916@mail.gmail.com>

On Wed, Dec 9, 2009 at 3:06 PM, James Robinson <jamesr at google.com> wrote:
> On Wed, Dec 9, 2009 at 2:57 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com> wrote:
>> > 2009/12/9 tali garsiel <t_garsiel at hotmail.com>
>> >>
>> >> Well, not completely.
>> >> Regarding the first question- Webkit guys told me (on their IRC
>> >> channel)
>> >> that the don't block the parser and only block scripts that request
>> >> visual
>> >> information, so I'm still ?confused.
>> >
>> > Here's my understanding of the implementation inside WebKit currently:
>> > During parsing, WebKit does not block the parser on stylesheet loads,
>> > but
>> > does block external scripts from running until previously-encountered
>> > stylesheets have loaded. ?WebKit does not suspend script execution on
>> > requests for visual information if stylesheets have not loaded (for
>> > example
>> > for inline scripts or in the case of stylesheets added dynamically after
>> > parsing has completed). ?WebKit does suspend parsing of the document on
>> > script loads, but has a speculative preloader to attempt to start
>> > fetches
>> > for resources past the <script> tag.
>>
>> Why does webkit treat external scripts different from inline scripts
>> here? I.e. why is an inline script allowed to run even if there are
>> pending stylesheet loads, but external scripts not? That seems
>> inconsistent and confusing.
>>
>> Is this considered a bug or desired behavior?
>
> The
> former:?http://trac.webkit.org/browser/trunk/WebCore/html/HTMLTokenizer.cpp#L2017
> I'm not sure how much this matters in practice. ?In theory, this is
> unobservable to the page unless it queries the loaded stylesheets directly
> or a property derived from layout both of which should suspend script
> execution.

Why is this more "in theory" for inline scripts than for external scripts?

/ Jonas

From jonas at sicking.cc  Wed Dec  9 15:19:38 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 9 Dec 2009 15:19:38 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <63df84f0912091518l4f0223c6h9c1c4a685eadf916@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu> 
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com> 
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com> 
	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com> 
	<ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com> 
	<63df84f0912091518l4f0223c6h9c1c4a685eadf916@mail.gmail.com>
Message-ID: <63df84f0912091519g1319bb21j6d26ecd4f5b379a9@mail.gmail.com>

On Wed, Dec 9, 2009 at 3:18 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Wed, Dec 9, 2009 at 3:06 PM, James Robinson <jamesr at google.com> wrote:
>> On Wed, Dec 9, 2009 at 2:57 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>
>>> On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com> wrote:
>>> > 2009/12/9 tali garsiel <t_garsiel at hotmail.com>
>>> >>
>>> >> Well, not completely.
>>> >> Regarding the first question- Webkit guys told me (on their IRC
>>> >> channel)
>>> >> that the don't block the parser and only block scripts that request
>>> >> visual
>>> >> information, so I'm still ?confused.
>>> >
>>> > Here's my understanding of the implementation inside WebKit currently:
>>> > During parsing, WebKit does not block the parser on stylesheet loads,
>>> > but
>>> > does block external scripts from running until previously-encountered
>>> > stylesheets have loaded. ?WebKit does not suspend script execution on
>>> > requests for visual information if stylesheets have not loaded (for
>>> > example
>>> > for inline scripts or in the case of stylesheets added dynamically after
>>> > parsing has completed). ?WebKit does suspend parsing of the document on
>>> > script loads, but has a speculative preloader to attempt to start
>>> > fetches
>>> > for resources past the <script> tag.
>>>
>>> Why does webkit treat external scripts different from inline scripts
>>> here? I.e. why is an inline script allowed to run even if there are
>>> pending stylesheet loads, but external scripts not? That seems
>>> inconsistent and confusing.
>>>
>>> Is this considered a bug or desired behavior?
>>
>> The
>> former:?http://trac.webkit.org/browser/trunk/WebCore/html/HTMLTokenizer.cpp#L2017
>> I'm not sure how much this matters in practice. ?In theory, this is
>> unobservable to the page unless it queries the loaded stylesheets directly
>> or a property derived from layout both of which should suspend script
>> execution.
>
> Why is this more "in theory" for inline scripts than for external scripts?

Or rather, why is this more unobservable for inline scripts than for
external scripts?

/ Jonas

From jamesr at google.com  Wed Dec  9 15:53:18 2009
From: jamesr at google.com (James Robinson)
Date: Wed, 9 Dec 2009 15:53:18 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <4B20304B.7010108@mit.edu>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>
	<ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>
	<4B20304B.7010108@mit.edu>
Message-ID: <ad1a0c1e0912091553r51bcfde2jf13e3cb6e89b4dfd@mail.gmail.com>

On Wed, Dec 9, 2009 at 3:18 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 12/9/09 3:06 PM, James Robinson wrote:
>
>>    On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com
>>    <mailto:jamesr at google.com>> wrote:
>>
>>> WebKit does not suspend script execution on requests for visual
>>> information if stylesheets have not loaded
>>>
>>
>  In theory, this is unobservable to the page unless it queries the loaded
>> stylesheets
>> directly or a property derived from layout both of which should suspend
>> script execution.
>>
>
> I'm having a hard time reconciling the above two claims.
>

Hence the "in theory".  If WebKit did suspend script execution on requests
for information that pending stylesheets might influence, then theory would
match practice.  It currently does not (which I believe is contrary to what
the spec says).  I'm curious if this actually negatively impacts anyone in
the wild, as suspending script execution in the middle of a block to wait
for a network load is generally not ideal.

- James


> -Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091209/b3bfcb8b/attachment-0001.htm>

From jamesr at google.com  Wed Dec  9 15:59:07 2009
From: jamesr at google.com (James Robinson)
Date: Wed, 9 Dec 2009 15:59:07 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <63df84f0912091519g1319bb21j6d26ecd4f5b379a9@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>
	<ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>
	<63df84f0912091518l4f0223c6h9c1c4a685eadf916@mail.gmail.com>
	<63df84f0912091519g1319bb21j6d26ecd4f5b379a9@mail.gmail.com>
Message-ID: <ad1a0c1e0912091559p5184756bjad485afad81c80a0@mail.gmail.com>

On Wed, Dec 9, 2009 at 3:19 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Dec 9, 2009 at 3:18 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> > On Wed, Dec 9, 2009 at 3:06 PM, James Robinson <jamesr at google.com>
> wrote:
> >> On Wed, Dec 9, 2009 at 2:57 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>>
> >>> On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com>
> wrote:
> >>> > 2009/12/9 tali garsiel <t_garsiel at hotmail.com>
> >>> >>
> >>> >> Well, not completely.
> >>> >> Regarding the first question- Webkit guys told me (on their IRC
> >>> >> channel)
> >>> >> that the don't block the parser and only block scripts that request
> >>> >> visual
> >>> >> information, so I'm still  confused.
> >>> >
> >>> > Here's my understanding of the implementation inside WebKit
> currently:
> >>> > During parsing, WebKit does not block the parser on stylesheet loads,
> >>> > but
> >>> > does block external scripts from running until previously-encountered
> >>> > stylesheets have loaded.  WebKit does not suspend script execution on
> >>> > requests for visual information if stylesheets have not loaded (for
> >>> > example
> >>> > for inline scripts or in the case of stylesheets added dynamically
> after
> >>> > parsing has completed).  WebKit does suspend parsing of the document
> on
> >>> > script loads, but has a speculative preloader to attempt to start
> >>> > fetches
> >>> > for resources past the <script> tag.
> >>>
> >>> Why does webkit treat external scripts different from inline scripts
> >>> here? I.e. why is an inline script allowed to run even if there are
> >>> pending stylesheet loads, but external scripts not? That seems
> >>> inconsistent and confusing.
> >>>
> >>> Is this considered a bug or desired behavior?
> >>
> >> The
> >> former:
> http://trac.webkit.org/browser/trunk/WebCore/html/HTMLTokenizer.cpp#L2017
> >> I'm not sure how much this matters in practice.  In theory, this is
> >> unobservable to the page unless it queries the loaded stylesheets
> directly
> >> or a property derived from layout both of which should suspend script
> >> execution.
> >
> > Why is this more "in theory" for inline scripts than for external
> scripts?
>
> Or rather, why is this more unobservable for inline scripts than for
> external scripts?
>

You're right, there's no real difference in the observability of this
behavior for inline vs external scripts.

- James


>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091209/78a7b8be/attachment.htm>

From bzbarsky at MIT.EDU  Wed Dec  9 16:02:57 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 09 Dec 2009 16:02:57 -0800
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <ad1a0c1e0912091553r51bcfde2jf13e3cb6e89b4dfd@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>	
	<4AE85ABE.6090507@mit.edu>	
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>	
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>	
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>	
	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>	
	<ad1a0c1e0912091506j424b8e3dxa0885e5ab9d2b3e1@mail.gmail.com>	
	<4B20304B.7010108@mit.edu>
	<ad1a0c1e0912091553r51bcfde2jf13e3cb6e89b4dfd@mail.gmail.com>
Message-ID: <4B203AB1.4080200@mit.edu>

On 12/9/09 3:53 PM, James Robinson wrote:
> Hence the "in theory".  If WebKit did suspend script execution on
> requests for information that pending stylesheets might influence, then
> theory would match practice.  It currently does not (which I believe is
> contrary to what the spec says).  I'm curious if this actually
> negatively impacts anyone in the wild, as suspending script execution in
> the middle of a block to wait for a network load is generally not ideal.

Sure.  The Gecko behavior is to not run the inline script until the 
stylesheets have loaded, just like webkit (and Gecko) does for 
non-inline scripts.

Any inline script that asks for layout information is affected, right? 
Good question on how much this is a problem in practice.  I don't have 
data on that....

-Boris

From bruant at enseirb-matmeca.fr  Wed Dec  9 16:29:47 2009
From: bruant at enseirb-matmeca.fr (David Bruant)
Date: Wed, 09 Dec 2009 16:29:47 -0800
Subject: [whatwg] providing a DOM API to workers without a thread-safe
 DOM implementation
In-Reply-To: <63df84f0912091453v57a38adq49a0889a9718daca@mail.gmail.com>
References: <4AFCC2A0.1030202@enseirb-matmeca.fr>	<Pine.LNX.4.62.0912020155410.1141@hixie.dreamhostps.com>
	<4B1D9FEB.8030808@enseirb-matmeca.fr>	<Pine.LNX.4.62.0912091503590.29336@hixie.dreamhostps.com>
	<4B1FF07C.6090808@enseirb.fr>	<Pine.LNX.4.62.0912091851470.16061@hixie.dreamhostps.com>
	<63df84f0912091453v57a38adq49a0889a9718daca@mail.gmail.com>
Message-ID: <4B2040FB.2010002@enseirb.fr>

Le 09/12/2009 14:53, Jonas Sicking a ?crit :
> On Wed, Dec 9, 2009 at 10:55 AM, Ian Hickson<ian at hixie.ch>  wrote:
>    
>> On Wed, 9 Dec 2009, David Bruant wrote:
>>      
>>> Ian wrote:
>>>        
>>>> Since browsers don't have thread-safe DOM implementations, that's
>>>> basically a non-starter. It doesn't matter that we aren't offering
>>>> access to the same DOM in pages and workers; the actual innards of the
>>>> DOM implementations aren't thread safe.
>>>>
>>>> As soon as browsers are able to implement this, I'm sure it will be
>>>> added to the spec.
>>>>          
>>> The point of my "Re: [whatwg] [WebWorkers] Advocation to provide the DOM
>>> API to the workers" e-mail of the December 7th was to prove that we
>>> don't even need a thread-safe implementation.
>>>        
>> When I am referring to thread safety here I don't mean that it's not
>> possible for a single DOM tree to be accessed from two threads. I mean
>> that it's not possible for two DOM nodes from completely unrelated trees
>> to exist on two threads, because the DOM implementations make use of
>> global state (e.g. global atoms, memory pools) that are not written such
>> that they can be accessed from code in multiple threads (e.g. because the
>> memory allocator doesn't use locks to ensure that the memory pool is only
>> mutated by one thread at once).
>>      
> I can only speak for the gecko implementation, but what Ian says here
> is completely true.
>
> Behind the scenes there is lots of global data structures that we
> can't access from any other thread than the main thread. Thus we can't
> currently implement the DOM on any worker threads, even if any given
> node only ever lives on a single thread.
>
> We couldn't for example use the event dispatch code, or the
> XMLHttpRequest code directly in the worker thread. For events we
> basically duplicated the event dispatch code (or rather, we wrote
> another, much simpler, version to be used in workers). For
> XMLHttpRequest we end up proxying lots of information to the main
> thread where the majority of the code is run.
>
> / Jonas
>    
Thanks to your two answers, it makes sense now that breaking some 
references here and there didn't solve the problem.

I stop now my proposition.

Thank you for your feedback,

David

From fbuchinger at gmail.com  Thu Dec 10 00:45:19 2009
From: fbuchinger at gmail.com (Franz Buchinger)
Date: Thu, 10 Dec 2009 09:45:19 +0100
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality
	from a worker
In-Reply-To: <4B1C9E4D.1010901@gmail.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>
	<4B1C9E4D.1010901@gmail.com>
Message-ID: <a07b86220912100045l7ce698c5sdada653744c1684b@mail.gmail.com>

Hi Sigbjorn,

Does this mean that I have to implement my own image scaling method in
Javascript when using web workers, instead of using the scale() method of
CanvasRenderingContext2D?

If so, I'd have to manually iterate over all pixels of the image, perform
some nearest-neighbour calculation and create a new ImageData Object with
the result...
This will be magnitudes sloooooooooower than scale() :(

I'd really appreciate if the "scale-images-before-upload" use case would be
considered better in the HTML5 spec. After all, images are the most
frequently uploaded file type and it has always been a hassle for users to
scale down their multi-megapixel photos manually before uploading them. Now
that we have the chance to solve this issue with pure-browser techniques, we
stop half-way.

Franz

2009/12/7 Sigbjorn Finne <sigbjorn.finne at gmail.com>

> On 12/5/2009 13:24, Franz Buchinger wrote:
> > Gears introduced the concept of an "offscreen canvas" that doesn't draw
> > anything in the browser window, but can be used to manipulate images in a
> > web worker.
> >
> > I used this functionality to implement a "resize-before-upload" feature
> in
> > my photo gallery uploader. Now I'm trying to port my uploader to HTML5
> but
> > there seems no way to delegate the scaling work to a HTML5 web worker.
> > Surely I could use the DOM canvas to scale down the photos in the main
> > "browser thread", but this means that the UI gets blocked during this
> > process.
> >
> > If the user chooses more than a few multi-megapixel photos, the
> > CPU-intensive downscaling will likely freeze the browser and trigger a
> > script abortion warning.
> >
> > Are there plans to introduce an "offscreen canvas" in html5? If not,
> which
> > workarounds are possible?
> >
> Hi Franz,
>
> ImageData is cloneable via postMessage(), so you could perform some
> forms of image processing that way.
>
> --sigbjorn <sof at opera.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/b92af70f/attachment.htm>

From annevk at opera.com  Thu Dec 10 01:55:40 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 10 Dec 2009 10:55:40 +0100
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <op.u4pu6zqx64w2qv@anne-van-kesterens-macbook.local>

On Wed, 09 Dec 2009 21:14:00 +0100, Nicholas Zakas <nzakas at yahoo-inc.com>  
wrote:
> Can the self-reference <img> exception become the rule and apply to all
> of these tags the same way?

If we'd also apply it to APIs that would be annoying actually. We have a  
bunch of Web Workers tests that rely on this working fine.

What is wrong with having this work as is?


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

From hugh.guiney at gmail.com  Thu Dec 10 02:09:17 2009
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Thu, 10 Dec 2009 05:09:17 -0500
Subject: [whatwg] Use cases for the time element
In-Reply-To: <6D551565-4233-40C3-A951-7CAE509497E9@adactio.com>
References: <7AFE3B8F-C3F0-4683-A18F-1BD72161E357@adactio.com> 
	<72DBCF6F-4BB0-432D-843B-68B28A3FDD9A@iki.fi>
	<4B0FEBB0.4010708@lachy.id.au> 
	<6D551565-4233-40C3-A951-7CAE509497E9@adactio.com>
Message-ID: <2a1386f80912100209o219b7dcet91b7e60648cc41ff@mail.gmail.com>

I concur 100%.

Additionally, I don't understand why the time element is allowed to specify
an arbitrary hour, but not an arbitrary month or year.

My own use case involves marking up years of publication for documents I
have created, to be displayed in an online resume that can be sorted by
date. I do not necessarily have the original timestamps for every file, yet
I can recall the years in which they were published. In this case, the year
"2005", for instance, is semantically distinct from the numeral "2005", and
though the difference can be inferred from context by a human it can not by
a machine, hence why things like <time>2005</time>, or <time
datetime="2005">4 years ago</time> would be useful here. But under the
current specification, these uses are invalid, meaning I'd only be able to
specify exact dates with meaningful language, as in <time
datetime="2005-01-01">2005</time>, and hack around it for inexact dates with
non-semantics like <span class="datetime">2005</span>.

This use case (which has nothing to do with calendars) would certainly not
be unique to me, as I'm sure there are many events well-within the Gregorian
calendar that have inexact dates, such as the dates of deceased family
members for whom incomplete records were kept during the time of their death
<http://people.mnhs.org/dci/faq.cfm#17>. Rather than just presented
textually, the results could be marked up in HTML and extracted using an
API, browser add-on, or other software that reads the metadata and returns
something useful to the user, such as an automatically-generated
genealogical entry file that can be imported into a family tree program?much
in the way the Operator Toolbar extension for Firefox currently reads hCards
and automatically generates contact entry files that can be imported into
e-mail programs.

The way I see it, if we can mark up abbreviations without having to expand
them fully, or even at all (<abbr>XSLT</abbr>, <abbr title="XSL
Transformations>XSLT</abbr>, and <abbr title="eXtensible Stylesheet Language
Transformations>XSLT</abbr>, or even <abbr title="cat">XSLT</abbr> are all
valid) we should be able to mark up datetimes without having to expand them
fully.

But don't take my word for it. I'm sure these articles have been mentioned
here before, but Eric Meyer <
http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/> and PPK <
http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html> have
also voiced support for a less-restrictive <time> (Hixie has at least seen
the former <
http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/#comment-475378>,
though there was no further discussion with him about the issue there.)

If these issues have already been discussed, please point me in the right
direction so that I can better understand the decision to phrase the spec
this way.

Thank you,
Hugh

On Sat, Nov 28, 2009 at 7:11 AM, Jeremy Keith <jeremy at adactio.com> wrote:

> We seem to be straying behind the bikeshed a little bit here. My point
> wasn't to point out problems with the examples given in "common idioms
> without dedicated elements"
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#conversations
>
> The real problem is the definition of the <time> element itself:
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element
>
> This sentence:
>
> "This element is intended as a way to encode modern dates and times in a
> machine-readable way so that user agents can offer to add them to the user's
> calendar."
>
> ...should be changed to:
> "This element is intended as a way to encode modern dates and times in a
> machine-readable way."
>
> The overly-restrictive clause at the end canonises a single use case as the
> only usage of the element. The fact that there examples elsewhere in the
> spec that contradict this definition highlights the problem, but the issue
> isn't with those examples; it's with the definition of <time>.
>
> HTH,
>
>
> Jeremy
>
> --
> Jeremy Keith
>
> a d a c t i o
>
> http://adactio.com/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/a6ed1d81/attachment-0001.htm>

From ian at hixie.ch  Thu Dec 10 04:17:44 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 10 Dec 2009 12:17:44 +0000 (UTC)
Subject: [whatwg] Typo in 4.4.10
In-Reply-To: <4AE035C3-0704-45AA-B967-3E1E50184AF8@cookwood.com>
References: <4AE035C3-0704-45AA-B967-3E1E50184AF8@cookwood.com>
Message-ID: <Pine.LNX.4.62.0912101216500.29336@hixie.dreamhostps.com>

On Mon, 2 Nov 2009, Elizabeth Castro wrote:
>
> The third to last word in this line:
> 
> > If node has an ancestor element that is a article element
> 
> should be "an"

Fixed, thanks.

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

From ian at hixie.ch  Thu Dec 10 05:29:54 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 10 Dec 2009 13:29:54 +0000 (UTC)
Subject: [whatwg] Adding a src attribute to all elements
In-Reply-To: <1257300326.16740.7.camel@cgrymala-desktop>
References: <1257300326.16740.7.camel@cgrymala-desktop>
Message-ID: <Pine.LNX.4.62.0912101328160.29336@hixie.dreamhostps.com>

On Tue, 3 Nov 2009, Curtiss Grymala wrote:
>
> I would like to propose that a src attribute be added to the spec for 
> all HTML elements. The content of the file referenced in the src 
> attribute would then replace the contents of the element that contains 
> the src attribute. The src attribute would then be interpreted 
> differently, depending on the type of file referenced in that src 
> attribute.

What's the use case?


> For instance, if I create a level 1 header that looks like:
> <h1 src="/example.png">This is a header</h1>
> The text "This is a header" would be replaced with the image that's
> located at /example.png. However, if /example.png returns a 404 error,
> the text would be displayed instead.

This seems like a presentational concern, and thus should be handled by 
CSS. And indeed, it is; CSS3 has a 'content' property for this.


> If, however, I create a div that looks like:
> <div src="/example.txt">This is some other text</div>
> The text content of /example.txt would replace the text "This is some
> other text" within the div that I created. Again, though,
> if /example.txt returned a 404 error, then "This is some other text"
> would show up inside the div instead.

Isn't <object> adequate for this? As in:

   <object src="/example.txt">This is some other text</object>

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

From jackalmage at gmail.com  Thu Dec 10 06:06:04 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 10 Dec 2009 08:06:04 -0600
Subject: [whatwg] Use cases for the time element
In-Reply-To: <2a1386f80912100209o219b7dcet91b7e60648cc41ff@mail.gmail.com>
References: <7AFE3B8F-C3F0-4683-A18F-1BD72161E357@adactio.com> 
	<72DBCF6F-4BB0-432D-843B-68B28A3FDD9A@iki.fi>
	<4B0FEBB0.4010708@lachy.id.au> 
	<6D551565-4233-40C3-A951-7CAE509497E9@adactio.com>
	<2a1386f80912100209o219b7dcet91b7e60648cc41ff@mail.gmail.com>
Message-ID: <dd0fbad0912100606y77fc414exa25fcf7809516bfa@mail.gmail.com>

On Thu, Dec 10, 2009 at 4:09 AM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> My own use case involves marking up years of publication for documents I
> have created, to be displayed in an online resume that can be sorted by
> date. I do not necessarily have the original timestamps for every file, yet
> I can recall the years in which they were published. In this case, the year
> "2005", for instance, is semantically distinct from the numeral "2005", and
> though the difference can be inferred from context by a human it can not by
> a machine, hence why things like <time>2005</time>, or <time
> datetime="2005">4 years ago</time> would be useful here. But under the
> current specification, these uses are invalid, meaning I'd only be able to
> specify exact dates with meaningful language, as in <time
> datetime="2005-01-01">2005</time>, and hack around it for inexact dates with
> non-semantics like <span class="datetime">2005</span>.

Are you planning on using the information in <time> to *do* the
sorting?  That is, when someone chooses "sort by date", do you have
scripting that searches in each section for a <time> and extracts the
date to determine where in the order it should go?


> The way I see it, if we can mark up abbreviations without having to expand
> them fully, or even at all (<abbr>XSLT</abbr>, <abbr title="XSL
> Transformations>XSLT</abbr>, and <abbr title="eXtensible Stylesheet Language
> Transformations>XSLT</abbr>, or even <abbr title="cat">XSLT</abbr> are all
> valid) we should be able to mark up datetimes without having to expand them
> fully.

Fairness isn't a justification for putting anything in the spec,
fortunately.  Each piece of the spec has to justify itself.


> But don't take my word for it. I'm sure these articles have been mentioned
> here before, but Eric Meyer
> <http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/> and PPK
> <http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html> have
> also voiced support for a less-restrictive <time> (Hixie has at least seen
> the former
> <http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/#comment-475378>,
> though there was no further discussion with him about the issue there.)

I agree with Meyer on the first one.  That's a useful case.  In
addition, <time>'s usefulness in Microdata is somewhat impaired by its
inability to mark up months or years.  These are by far the most
common 'fuzzy dates' that one would have to mark up for embedded
metadata.  Their lack means that vocabularies need to structure
themselves to take two dates per real 'date', to allow such fuzziness,
which means that date *ranges* would need *four* dates specified.
That's just silly.

However, the second one isn't quite an argument for expanding time.
It's an outlining of, *if* we decide that we want <time> to be useful
for *all* dates, how we should go about doing it.  ppk recognizes that
such an approach may not be what the spec wants.

~TJ

From ian at hixie.ch  Thu Dec 10 06:48:55 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 10 Dec 2009 14:48:55 +0000 (UTC)
Subject: [whatwg] <object> behavior
In-Reply-To: <op.u2zuggti1ejg13@sandra-svwliu01>
References: <4A7ACFB1.8030808@ado.is-a-geek.net> <4A7AE539.6020406@mit.edu>
	<Pine.LNX.4.62.0908140155380.6420@hixie.dreamhostps.com>
	<4A85320D.2060102@ado.is-a-geek.net>
	<Pine.LNX.4.62.0908242325300.13789@hixie.dreamhostps.com>
	<4A93A385.5020005@ado.is-a-geek.net>
	<Pine.LNX.4.62.0908310906470.6775@hixie.dreamhostps.com>
	<4A9BCF43.1080206@mit.edu>
	<Pine.LNX.4.62.0909020152530.6775@hixie.dreamhostps.com>
	<4AA4053B.8080107@mit.edu>
	<Pine.LNX.4.62.0909132154440.14605@hixie.dreamhostps.com>
	<4AAE3A22.3070300@mit.edu> <op.u0f250wi1ejg13@sandra-svwliu01>
	<4AB37A7C.3010009@mit.edu> <op.u0gh6jv01ejg13@sandra-svwliu01>
	<4AB3D4DB.7070502@mit.edu> <op.u0g406uw1ejg13@sandra-svwliu01>
	<4AB67927.9080209@mit.edu> <op.u0lq8npj1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0910160621020.25383@hixie.dreamhostps.com>
	<op.u2zuggti1ejg13@sandra-svwliu01>
Message-ID: <Pine.LNX.4.62.0912101445380.29336@hixie.dreamhostps.com>

On Fri, 6 Nov 2009, Michael A. Puls II wrote:
> > > 
> > > O.K., so put simply, HTML5 should explicitly mention that the css 
> > > display property for <object>, <embed> (and <applet> in the handling 
> > > section) has absolutely no effect on plug-in instantiation and 
> > > destroying and has absolutely no effect on @src and @data resource 
> > > fetching.
> > > 
> > > HTML5 could also be extra clear by example that display: none 
> > > doesn't destroy, or prevent the creation of, the plug-in instance 
> > > and that changing the display value doesn't destroy the instance.
> > > 
> > > Lastly, HTML5 could briefly mention that what the plug-in does when 
> > > its window/area is not displayed because of display: none, is 
> > > plug-in and plug-in API dependent.
> > 
> > I've added a note to this effect.
> 
> Also see <https://bugzilla.mozilla.org/show_bug.cgi?id=90268#c68>. 
> Should probably add a note in the spec that the css overflow and 
> position properties don't affect instantiation/destroying etc. (might as 
> well add visibility too). And, after that, it'd probably be best to note 
> that css in general doesn't affect instantiation/destroying (to avoid 
> having to keep on adding CSS properties to the list)
> 
> Something like this:
> 
> Note: The above algorithm is independent of CSS. For example, it runs 
> even if the element is hidden or out-of-view because of the 'display', 
> 'position', 'visibility' and 'overflow' properties.
> 
> Further, changing the value of any CSS property does not cause the above 
> algorithm to run again on the element. For example, changing the 
> element's 'display' property from 'inline-block' to 'none' does not 
> destroy the loaded resource.

Fair enough. Done something like the above.

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

From ian at hixie.ch  Thu Dec 10 07:01:59 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 10 Dec 2009 15:01:59 +0000 (UTC)
Subject: [whatwg] Proposal: Extension to the base element
In-Reply-To: <9301ed6b0911091225m362c529awa2387fd4365d6fb6@mail.gmail.com>
References: <9301ed6b0911091225m362c529awa2387fd4365d6fb6@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912101458540.29336@hixie.dreamhostps.com>

On Mon, 9 Nov 2009, Fabian Freiburg wrote:
> 
> The "base" element is very helpful. Trouble is that it affects all 
> relative links and "src" attributes. Especially for the "src" attributes 
> it would be very useful if it could define a context or media type to 
> which it belongs. With this it would be possible to define a "base" URI 
> fore. g.  images, javascripts or stylesheets. Furthermore it would be 
> very easy to use a CDN for serving static media files. There are 
> probably some more advantages.

It's not exactly clear to me what problem this is solving. Isn't giving 
absolute URLs pretty straight-forward?

It seems that anyone who is using a CDN wouldn't have any trouble just 
generating the absolute URLs dynamically using server-side scripting or 
templating, making this unnecessary on the client.


Note that in general the process for proposing new features is as 
described here:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

Should you wish to persue this idea, I recommend following the steps 
described above.

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

From shadow2531 at gmail.com  Thu Dec 10 07:34:48 2009
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Thu, 10 Dec 2009 10:34:48 -0500
Subject: [whatwg] Canvas.cloneNode()
In-Reply-To: <Pine.LNX.4.62.0912091707060.29336@hixie.dreamhostps.com>
References: <fdd21a0e0910300903y23bcbfe2u7efa11796e81767a@mail.gmail.com>
	<op.u3ewoee01ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0912091707060.29336@hixie.dreamhostps.com>
Message-ID: <op.u4qav8j81ejg13@sandra-svwliu01>

On Wed, 09 Dec 2009 12:08:29 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 30 Oct 2009, OmegaJunior wrote:
>>
>> Since Last Call was announced and I just ran into this problem, hereby
>> this question:
>>
>> If an image is drawn on a Canvas element, and subsequently the
>> javascript function cloneNode(true) is executed for that element, should
>> the clone include a copy of the source canvas image, or should it show
>> an empty space?
>>
>> From my perspective (the web author), I'd prefer to have the canvas
>> image included when executing (the deep) cloneNode(true), and excluded
>> it when using (the shallow) cloneNode(false).
>
> The cloneNode() method just clones the node, not the node's state, so the
> bitmap isn't copied. You can easily draw one bitmap onto the other,
> though, using drawImage().
>
>
> On Sat, 14 Nov 2009, Michael A. Puls II wrote:
>>
>> I think it'd be cool if the clone showed the image. But, I'm pretty sure
>> cloneNode(true) is just supposed to create a new canvas element with the
>> same attributes and childNodes as the original. It's not supposed to
>> copy everything that's going on with the element being copied.
>>
>> There are some exceptions with state for certain elements. Perhaps that
>> can happen with canvas too.
>
> I'd rather keep these exceptions to an absolute minimum. cloneNode() is
> part of the DOM Core API, and it would be bad for nodes to clone
> differently based on whether it's an HTML-aware UA implementing the DOM
> Core API or not.

Thanks.

I don't know canvas stuff that well. What's the proper way to patch  
cloneNode to do a full copy?

I think something like the following, but maybe you know better.

(function() {
     var oldCloneNode = HTMLCanvasElement.prototype.cloneNode;
     HTMLCanvasElement.prototype.cloneNode = function(deep) {
         var copy = oldCloneNode.call(this, deep);
         var copy_ctx = copy.getContext("2d");
         copy_ctx.drawImage(this, 0, 0, this.width, this.height);
         return copy;
     };
})();

-- 
Michael

From ian at hixie.ch  Thu Dec 10 07:38:32 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 10 Dec 2009 15:38:32 +0000 (UTC)
Subject: [whatwg] Canvas.cloneNode()
In-Reply-To: <op.u4qav8j81ejg13@sandra-svwliu01>
References: <fdd21a0e0910300903y23bcbfe2u7efa11796e81767a@mail.gmail.com>
	<op.u3ewoee01ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0912091707060.29336@hixie.dreamhostps.com>
	<op.u4qav8j81ejg13@sandra-svwliu01>
Message-ID: <Pine.LNX.4.62.0912101537580.16061@hixie.dreamhostps.com>

On Thu, 10 Dec 2009, Michael A. Puls II wrote:
> 
> I don't know canvas stuff that well. What's the proper way to patch cloneNode
> to do a full copy?
> 
> I think something like the following, but maybe you know better.
> 
> (function() {
>     var oldCloneNode = HTMLCanvasElement.prototype.cloneNode;
>     HTMLCanvasElement.prototype.cloneNode = function(deep) {
>         var copy = oldCloneNode.call(this, deep);
>         var copy_ctx = copy.getContext("2d");
>         copy_ctx.drawImage(this, 0, 0, this.width, this.height);
>         return copy;
>     };
> })();

Looks right to me, though generally I would discourage this style of 
programming as it makes it quite hard for people to maintain unless they 
are very familiar with the codebase.

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

From shadow2531 at gmail.com  Thu Dec 10 09:15:10 2009
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Thu, 10 Dec 2009 12:15:10 -0500
Subject: [whatwg] Canvas.cloneNode()
In-Reply-To: <Pine.LNX.4.62.0912101537580.16061@hixie.dreamhostps.com>
References: <fdd21a0e0910300903y23bcbfe2u7efa11796e81767a@mail.gmail.com>
	<op.u3ewoee01ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0912091707060.29336@hixie.dreamhostps.com>
	<op.u4qav8j81ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0912101537580.16061@hixie.dreamhostps.com>
Message-ID: <op.u4qfjkbc1ejg13@sandra-svwliu01>

On Thu, 10 Dec 2009 10:38:32 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 10 Dec 2009, Michael A. Puls II wrote:
>>
>> I don't know canvas stuff that well. What's the proper way to patch  
>> cloneNode
>> to do a full copy?
>>
>> I think something like the following, but maybe you know better.
>>
>> (function() {
>>     var oldCloneNode = HTMLCanvasElement.prototype.cloneNode;
>>     HTMLCanvasElement.prototype.cloneNode = function(deep) {
>>         var copy = oldCloneNode.call(this, deep);
>>         var copy_ctx = copy.getContext("2d");
>>         copy_ctx.drawImage(this, 0, 0, this.width, this.height);
>>         return copy;
>>     };
>> })();
>
> Looks right to me, though generally I would discourage this style of
> programming as it makes it quite hard for people to maintain unless they
> are very familiar with the codebase.

OK. Thanks

-- 
Michael

From shadow2531 at gmail.com  Thu Dec 10 09:18:50 2009
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Thu, 10 Dec 2009 12:18:50 -0500
Subject: [whatwg] <object> behavior
In-Reply-To: <Pine.LNX.4.62.0912101445380.29336@hixie.dreamhostps.com>
References: <4A7ACFB1.8030808@ado.is-a-geek.net>
	<4A85320D.2060102@ado.is-a-geek.net>
	<Pine.LNX.4.62.0908242325300.13789@hixie.dreamhostps.com>
	<4A93A385.5020005@ado.is-a-geek.net>
	<Pine.LNX.4.62.0908310906470.6775@hixie.dreamhostps.com>
	<4A9BCF43.1080206@mit.edu>
	<Pine.LNX.4.62.0909020152530.6775@hixie.dreamhostps.com>
	<4AA4053B.8080107@mit.edu>
	<Pine.LNX.4.62.0909132154440.14605@hixie.dreamhostps.com>
	<4AAE3A22.3070300@mit.edu> <op.u0f250wi1ejg13@sandra-svwliu01>
	<4AB37A7C.3010009@mit.edu> <op.u0gh6jv01ejg13@sandra-svwliu01>
	<4AB3D4DB.7070502@mit.edu> <op.u0g406uw1ejg13@sandra-svwliu01>
	<4AB67927.9080209@mit.edu> <op.u0lq8npj1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0910160621020.25383@hixie.dreamhostps.com>
	<op.u2zuggti1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0912101445380.29336@hixie.dreamhostps.com>
Message-ID: <op.u4qfpogl1ejg13@sandra-svwliu01>

On Thu, 10 Dec 2009 09:48:55 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 6 Nov 2009, Michael A. Puls II wrote:
>> > >
>> > > O.K., so put simply, HTML5 should explicitly mention that the css
>> > > display property for <object>, <embed> (and <applet> in the handling
>> > > section) has absolutely no effect on plug-in instantiation and
>> > > destroying and has absolutely no effect on @src and @data resource
>> > > fetching.
>> > >
>> > > HTML5 could also be extra clear by example that display: none
>> > > doesn't destroy, or prevent the creation of, the plug-in instance
>> > > and that changing the display value doesn't destroy the instance.
>> > >
>> > > Lastly, HTML5 could briefly mention that what the plug-in does when
>> > > its window/area is not displayed because of display: none, is
>> > > plug-in and plug-in API dependent.
>> >
>> > I've added a note to this effect.
>>
>> Also see <https://bugzilla.mozilla.org/show_bug.cgi?id=90268#c68>.
>> Should probably add a note in the spec that the css overflow and
>> position properties don't affect instantiation/destroying etc. (might as
>> well add visibility too). And, after that, it'd probably be best to note
>> that css in general doesn't affect instantiation/destroying (to avoid
>> having to keep on adding CSS properties to the list)
>>
>> Something like this:
>>
>> Note: The above algorithm is independent of CSS. For example, it runs
>> even if the element is hidden or out-of-view because of the 'display',
>> 'position', 'visibility' and 'overflow' properties.
>>
>> Further, changing the value of any CSS property does not cause the above
>> algorithm to run again on the element. For example, changing the
>> element's 'display' property from 'inline-block' to 'none' does not
>> destroy the loaded resource.
>
> Fair enough. Done something like the above.

That'll work. Could you make the change for <embed> and <applet> too when  
you have time?

Thanks

-- 
Michael

From hugh.guiney at gmail.com  Thu Dec 10 09:52:06 2009
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Thu, 10 Dec 2009 12:52:06 -0500
Subject: [whatwg] Use cases for the time element
In-Reply-To: <dd0fbad0912100606y77fc414exa25fcf7809516bfa@mail.gmail.com>
References: <7AFE3B8F-C3F0-4683-A18F-1BD72161E357@adactio.com> 
	<72DBCF6F-4BB0-432D-843B-68B28A3FDD9A@iki.fi>
	<4B0FEBB0.4010708@lachy.id.au> 
	<6D551565-4233-40C3-A951-7CAE509497E9@adactio.com>
	<2a1386f80912100209o219b7dcet91b7e60648cc41ff@mail.gmail.com> 
	<dd0fbad0912100606y77fc414exa25fcf7809516bfa@mail.gmail.com>
Message-ID: <2a1386f80912100952p74ca481bh3b942bd37b960387@mail.gmail.com>

On Thu, Dec 10, 2009 at 9:06 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> Are you planning on using the information in <time> to *do* the
> sorting? ?That is, when someone chooses "sort by date", do you have
> scripting that searches in each section for a <time> and extracts the
> date to determine where in the order it should go?

Yes, ideally I would like to store all of my data as XHTML+XML. Though
I suppose I could describe that data with an arbitrary vocabulary
server-side, sort on that, and transform the result into HTML, it
makes the script much smaller and easier to write if there's a common
syntax in place.

> Fairness isn't a justification for putting anything in the spec,
> fortunately. ?Each piece of the spec has to justify itself.

It just seems to me that *requiring* this sort of specificity (rather
than simply allowing it) is contrary to the typically rather
permissive nature of HTML. If we don't even need to close our tags,
why do we need to specify whole dates? As far as I know, there hasn't
ever been an element that made validation fail because of a malformed
microsyntax; why start now? ISO 8601 (which has been footnoted by the
W3C since 1997) allows for several levels of granularity, up to the
year. What is it that necessitates this particular level of
granularity (aside from adding dates to calendars, which is only one
use case)?

> I agree with Meyer on the first one. ?That's a useful case. ?In
> addition, <time>'s usefulness in Microdata is somewhat impaired by its
> inability to mark up months or years. ?These are by far the most
> common 'fuzzy dates' that one would have to mark up for embedded
> metadata. ?Their lack means that vocabularies need to structure
> themselves to take two dates per real 'date', to allow such fuzziness,
> which means that date *ranges* would need *four* dates specified.
> That's just silly.

I agree.

> However, the second one isn't quite an argument for expanding time.
> It's an outlining of, *if* we decide that we want <time> to be useful
> for *all* dates, how we should go about doing it. ?ppk recognizes that
> such an approach may not be what the spec wants.

I realize that, but the fact that he was able to write that much on
the topic just strengthens the argument that <time> has far more use
cases than it's been allotted, and as such, its current definition
needs to be addressed, be it in that capacity or smaller.

From hyatt at apple.com  Thu Dec 10 10:13:56 2009
From: hyatt at apple.com (David Hyatt)
Date: Thu, 10 Dec 2009 12:13:56 -0600
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
Message-ID: <227A5C31-1338-411F-B8BC-75F2A59D502A@apple.com>

This is false.  WebKit will block the parser when it encounters an external script if there are pending stylesheet loads.  However we have a speculative preloader that will continue to parse and load resources beyond that script (but the real parser will be blocked).

dave

On Dec 9, 2009, at 3:42 PM, tali garsiel wrote:

> Well, not completely.
> Regarding the first question- Webkit guys told me (on their IRC channel) that the don't block the parser and only block scripts that request visual information, so I'm still  confused.
> 
> > Date: Wed, 9 Dec 2009 17:01:30 +0000
> > From: ian at hixie.ch
> > To: t_garsiel at hotmail.com; bzbarsky at MIT.EDU
> > CC: whatwg at whatwg.org
> > Subject: Re: [whatwg] style sheet blocking scripts
> > 
> > On Wed, 28 Oct 2009, tali garsiel wrote:
> > > 
> > > This is a quote from Section 4.2 of the spec:
> > > 
> > > "A style sheet in the context of the Document of an HTML parser or XML 
> > > parser is said to be a style sheet blocking scripts if the element was 
> > > created by that Document's parser, and the element is either a style 
> > > element or a link element that was an external resource link that 
> > > contributes to the styling processing model when the element was c reated 
> > > by the parser, and the element's style sheet was enabled when the 
> > > element was created by the parser, and the element's style sheet ready 
> > > flag is not yet set, and, the last time the event loop reached step 1, 
> > > the element was in that Document"
> > > 
> > > And the section about parsing - the "<script>" tag says that before 
> > > executing a script the parser must:
> > > 
> > > 3. Spin the event loop until there is no style sheet blocking scripts 
> > > and the script's "ready to be parser-executed" flag is set.
> > > 
> > > I have two questions:
> > > 
> > > 1. As far as I know, Firefox and Webkit have a "stall on demand" 
> > > behavior, where a stylesheet blocks a script only if the script asks 
> > > from style information. According to the spec the style sheet always 
> > > blocks a script, am I right?
> > > 
> > > 2. Can you clarify the condition - "the element's style sheet was 
> > > enabled when the element was created by the parser, and the element's 
> > > style sheet ready flag is not yet set, and, the last time the event loop 
> > > reached step 1, the element was in that Document"
> > > 
> > > Does it mean the style sheet blocks scripts only if it's currently being 
> > > parsed?
> > 
> > On Wed, 28 Oct 2009, Boris Zbarsky wrote:
> > > On 10/28/09 2:59 AM, tali garsiel wrote:
> > > > 1. As far as I know, Firefox and Webkit have a "stall on demand" 
> > > > behavior, where a stylesheet blocks a script only if the script asks 
> > > > from style information.
> > > 
> > > You know wrong, sorry. Firefox has the behavior the spec describes; 
> > > webkit blocks the parser completely on stylesheets (the behavior Firefox 
> > > used to have). Last I chec ked, at least.
> > > 
> > > > 2. Can you clarify the condition - "the element's style sheet was 
> > > > enabled when the element was created by the parser, and the element's 
> > > > style sheet ready flag is not yet set, and, the last time the event 
> > > > loop reached step 1, the element was in that Document"
> > > 
> > > The parts of that condition basically mean:
> > > 
> > > 1) When the element was created by the parser, it was in the then-enabled
> > > stylesheet set (i.e. not an alternate stylesheet).
> > > 2) The stylesheet, or one of its @import descendants, is still loading.
> > > 3) The stylesheet linking element is still in the document (so the stylesheet
> > > still applies).
> > 
> > Thanks Boris.
> > 
> > Tali, does this answer your question to your satisfaction?
> > 
> > -- 
> > Ian Hickson U+1047E )\._.,--....,'``. fL
> > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
> 
> Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?.

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

From hyatt at apple.com  Thu Dec 10 10:15:50 2009
From: hyatt at apple.com (David Hyatt)
Date: Thu, 10 Dec 2009 12:15:50 -0600
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
Message-ID: <6FE5CDAD-39AC-43BE-B805-6185F35F5EC9@apple.com>


On Dec 9, 2009, at 4:10 PM, James Robinson wrote:

> 2009/12/9 tali garsiel <t_garsiel at hotmail.com>
> Well, not completely.
> Regarding the first question- Webkit guys told me (on their IRC channel) that the don't block the parser and only block scripts that request visual information, so I'm still  confused.
> 
> Here's my understanding of the implementation inside WebKit currently:
> During parsing, WebKit does not block the parser on stylesheet loads, but does block external scripts from running until previously-encountered stylesheets have loaded.  WebKit does not suspend script execution on requests for visual information if stylesheets have not loaded (for example for inline scripts or in the case of stylesheets added dynamically after parsing has completed).  WebKit does suspend parsing of the document on script loads, but has a speculative preloader to attempt to start fetches for resources past the <script> tag.
> 
> - James
> 

This is accurate, although I'd add that we consider it a bug that we don't yet block the parser for inline scripts in addition to external scripts.

dave

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

From hyatt at apple.com  Thu Dec 10 10:16:19 2009
From: hyatt at apple.com (David Hyatt)
Date: Thu, 10 Dec 2009 12:16:19 -0600
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>
	<4AE85ABE.6090507@mit.edu>
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>
	<63df84f0912091457y6953b8een42149ae68a72ed37@mail.gmail.com>
Message-ID: <D6FF1C74-22FB-445B-B671-68D59A9EDE28@apple.com>

It is considered a bug.

On Dec 9, 2009, at 4:57 PM, Jonas Sicking wrote:

> On Wed, Dec 9, 2009 at 2:10 PM, James Robinson <jamesr at google.com> wrote:
>> 2009/12/9 tali garsiel <t_garsiel at hotmail.com>
>>> 
>>> Well, not completely.
>>> Regarding the first question- Webkit guys told me (on their IRC channel)
>>> that the don't block the parser and only block scripts that request visual
>>> information, so I'm still  confused.
>> 
>> Here's my understanding of the implementation inside WebKit currently:
>> During parsing, WebKit does not block the parser on stylesheet loads, but
>> does block external scripts from running until previously-encountered
>> stylesheets have loaded.  WebKit does not suspend script execution on
>> requests for visual information if stylesheets have not loaded (for example
>> for inline scripts or in the case of stylesheets added dynamically after
>> parsing has completed).  WebKit does suspend parsing of the document on
>> script loads, but has a speculative preloader to attempt to start fetches
>> for resources past the <script> tag.
> 
> Why does webkit treat external scripts different from inline scripts
> here? I.e. why is an inline script allowed to run even if there are
> pending stylesheet loads, but external scripts not? That seems
> inconsistent and confusing.
> 
> Is this considered a bug or desired behavior?
> 
> / Jonas


From jackalmage at gmail.com  Thu Dec 10 10:17:40 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 10 Dec 2009 12:17:40 -0600
Subject: [whatwg] Use cases for the time element
In-Reply-To: <2a1386f80912100952p74ca481bh3b942bd37b960387@mail.gmail.com>
References: <7AFE3B8F-C3F0-4683-A18F-1BD72161E357@adactio.com> 
	<72DBCF6F-4BB0-432D-843B-68B28A3FDD9A@iki.fi>
	<4B0FEBB0.4010708@lachy.id.au> 
	<6D551565-4233-40C3-A951-7CAE509497E9@adactio.com>
	<2a1386f80912100209o219b7dcet91b7e60648cc41ff@mail.gmail.com> 
	<dd0fbad0912100606y77fc414exa25fcf7809516bfa@mail.gmail.com> 
	<2a1386f80912100952p74ca481bh3b942bd37b960387@mail.gmail.com>
Message-ID: <dd0fbad0912101017v172f5ffaq710d4bf4c629edfb@mail.gmail.com>

On Thu, Dec 10, 2009 at 11:52 AM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> On Thu, Dec 10, 2009 at 9:06 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> However, the second one isn't quite an argument for expanding time.
>> It's an outlining of, *if* we decide that we want <time> to be useful
>> for *all* dates, how we should go about doing it. ?ppk recognizes that
>> such an approach may not be what the spec wants.
>
> I realize that, but the fact that he was able to write that much on
> the topic just strengthens the argument that <time> has far more use
> cases than it's been allotted, and as such, its current definition
> needs to be addressed, be it in that capacity or smaller.

Well, no, he had to write that much because historical dates are
really quite messed up, and it's *very* non-trivial to represent them
'correctly'.  That doesn't mean that <time> should really be that
complex, just that *if* <time> wants to address those cases it'll need
that level of complexity.

~TJ

From nzakas at yahoo-inc.com  Thu Dec 10 10:22:59 2009
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Thu, 10 Dec 2009 10:22:59 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <63df84f0912091455y92b62bdl32328e0e08744802@mail.gmail.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
	<63df84f0912091455y92b62bdl32328e0e08744802@mail.gmail.com>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B5@SNV-EXVS09.ds.corp.yahoo.com>

Sweet, so how can we get this done? :)

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

-----Original Message-----
From: Jonas Sicking [mailto:jonas at sicking.cc] 
Sent: Wednesday, December 09, 2009 2:56 PM
To: Nicholas Zakas
Cc: Simon Pieters; Aryeh Gregor; whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Wed, Dec 9, 2009 at 12:14 PM, Nicholas Zakas <nzakas at yahoo-inc.com>
wrote:
> Just curious if anyone knows why <img src=""> is the exception in the
> spec, rather than having the same behavior for all elements that
> download resources on page load? As far as I can tell, the spec would
> currently allow self-referencing downloads for the following elements:
>
> * <iframe>
> * <embed>
> * <object>
> * <video>
> * <audio>
> * <source>

As stated. If the other browser vendors are ok with it, I'm ok with
making the empty string mean "don't load" in all these cases. I.e.
treat an empty src/href attribute the same way as an absence of the
attribute (except for <script> which still wouldn't treat it as an
inline script).

/ Jonas

From nzakas at yahoo-inc.com  Thu Dec 10 10:22:43 2009
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Thu, 10 Dec 2009 10:22:43 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <op.u4pu6zqx64w2qv@anne-van-kesterens-macbook.local>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u4pu6zqx64w2qv@anne-van-kesterens-macbook.local>
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B3@SNV-EXVS09.ds.corp.yahoo.com>

I'd be happy to make the compromise that this applies to markup but not
to JavaScript APIs. 

It's the "automatic download" that makes this problematic, as it
silently doubles the number of requests to the server, which as I've
said in previous emails, is a huge problem for high-volume sites. Opera
already doesn't make a request in all of these cases, so I'm guessing
that Web Workers is an exception?

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

-----Original Message-----
From: Anne van Kesteren [mailto:annevk at opera.com] 
Sent: Thursday, December 10, 2009 1:56 AM
To: Nicholas Zakas; Simon Pieters; Aryeh Gregor
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Wed, 09 Dec 2009 21:14:00 +0100, Nicholas Zakas
<nzakas at yahoo-inc.com>  
wrote:
> Can the self-reference <img> exception become the rule and apply to
all
> of these tags the same way?

If we'd also apply it to APIs that would be annoying actually. We have a

bunch of Web Workers tests that rely on this working fine.

What is wrong with having this work as is?


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

From jonas at sicking.cc  Thu Dec 10 10:47:10 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 10 Dec 2009 10:47:10 -0800
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B5@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com> 
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com> 
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
	<63df84f0912091455y92b62bdl32328e0e08744802@mail.gmail.com> 
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B5@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <63df84f0912101047u218f559v2c3af7be5f7d9c82@mail.gmail.com>

On Thu, Dec 10, 2009 at 10:22 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Sweet, so how can we get this done? :)

Just gotta convince the other browser vendors that this is a good idea ;)

/ Jonas

From simonp at opera.com  Thu Dec 10 10:56:54 2009
From: simonp at opera.com (Simon Pieters)
Date: Thu, 10 Dec 2009 19:56:54 +0100
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B3@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u4pu6zqx64w2qv@anne-van-kesterens-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B3@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <op.u4qj84k0idj3kv@simon-pieterss-macbook.local>

On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas <nzakas at yahoo-inc.com>  
wrote:

> I'd be happy to make the compromise that this applies to markup but not
> to JavaScript APIs.

I think it shouldn't apply to markup that doesn't download things  
automatically; in particular <a href=""> should work.

What about URLs in CSS and SVG?

-- 
Simon Pieters
Opera Software

From t_garsiel at hotmail.com  Thu Dec 10 12:47:38 2009
From: t_garsiel at hotmail.com (tali garsiel)
Date: Thu, 10 Dec 2009 20:47:38 +0000
Subject: [whatwg] style sheet blocking scripts
In-Reply-To: <6FE5CDAD-39AC-43BE-B805-6185F35F5EC9@apple.com>
References: <BAY117-W28009A67F3600230034B8783B80@phx.gbl>,
	<4AE85ABE.6090507@mit.edu>,
	<Pine.LNX.4.62.0912091700220.29336@hixie.dreamhostps.com>,
	<BAY117-W13F34FD2FE8AE4CFF37154838E0@phx.gbl>,
	<ad1a0c1e0912091410s2144530dw474a18198fc38f1@mail.gmail.com>,
	<6FE5CDAD-39AC-43BE-B805-6185F35F5EC9@apple.com>
Message-ID: <BAY117-W35DEEA64A5F6D1E38FAC28838D0@phx.gbl>


I understand now. Thank you for your answers.

From: hyatt at apple.com
Date: Thu, 10 Dec 2009 12:15:50 -0600
To: jamesr at google.com
CC: whatwg at whatwg.org; bzbarsky at mit.edu; ian at hixie.ch; t_garsiel at hotmail.com
Subject: Re: [whatwg] style sheet blocking scripts




On Dec 9, 2009, at 4:10 PM, James Robinson wrote:2009/12/9 tali garsiel <t_garsiel at hotmail.com>






Well, not completely.Regarding the first question- Webkit guys told me (on their IRC channel) that the don't block the parser and only block scripts that request visual information, so I'm still  confused.


Here's my understanding of the implementation inside WebKit currently:During parsing, WebKit does not block the parser on stylesheet loads, but does block external scripts from running until previously-encountered stylesheets have loaded.  WebKit does not suspend script execution on requests for visual information if stylesheets have not loaded (for example for inline scripts or in the case of stylesheets added dynamically after parsing has completed).  WebKit does suspend parsing of the document on script loads, but has a speculative preloader to attempt to start fetches for resources past the <script> tag.

- James

This is accurate, although I'd add that we consider it a bug that we don't yet block the parser for inline scripts in addition to external scripts.
dave
 		 	   		  
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you?re up to on Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/24560596/attachment.htm>

From simonp at opera.com  Thu Dec 10 13:10:23 2009
From: simonp at opera.com (Simon Pieters)
Date: Thu, 10 Dec 2009 22:10:23 +0100
Subject: [whatwg] wording bug in web workers
Message-ID: <op.u4qqflwjidj3kv@simon-pieterss-macbook.local>

Web Workers says in the SharedWorker constructor algorithm:

"Otherwise, if name is the empty string and there exists a  
SharedWorkerGlobalScope object whose closing flag is false, and whose  
location attribute is exactly equal to scriptURL, then let worker global  
scope be that SharedWorkerGlobalScope object."

The location attribute is an object implementing WorkerLocation, which is  
not a URL, so with a literal interpretation it will never be equal to  
scriptURL. I guess it should say something like "whose location attribute  
represents an absolute URL that is exactly equal to scriptURL" instead.

-- 
Simon Pieters
Opera Software

From oliver at apple.com  Thu Dec 10 13:36:45 2009
From: oliver at apple.com (Oliver Hunt)
Date: Thu, 10 Dec 2009 13:36:45 -0800
Subject: [whatwg] "offscreen canvas" /Access to canvas
	functionality	from a worker
In-Reply-To: <a07b86220912100045l7ce698c5sdada653744c1684b@mail.gmail.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>
	<4B1C9E4D.1010901@gmail.com>
	<a07b86220912100045l7ce698c5sdada653744c1684b@mail.gmail.com>
Message-ID: <BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>

Ideally if we were to have a graphics context in a worker we'd want it to be the standard CanvasRenderingContext2D, the only real problem is that CanvasRenderingContext2D references the parent canvas element which clearly won't fly in a worker.

I've been thinking of creating something like a WorkerCanvas which is basically a DOM-less CanvasRenderingContext2D, so you can do

var canvas = new WorkerCanvas(width, height);
canvas.putImageData(myData);

I have a vague desire to allow a ImageData to be provided as a backing store, but then you may hit perf or consistency issues on UAs that use premultiplied alpha backing stores.

Additionally there's the question of origin tainting -- is it possible to taint the origin in a worker? you don;t have image elements, you can't xhr unsafely to other origins, but maybe i'm missing something?

--Oliver

On Dec 10, 2009, at 12:45 AM, Franz Buchinger wrote:

> Hi Sigbjorn,
> 
> Does this mean that I have to implement my own image scaling method in Javascript when using web workers, instead of using the scale() method of CanvasRenderingContext2D?
> 
> If so, I'd have to manually iterate over all pixels of the image, perform some nearest-neighbour calculation and create a new ImageData Object with the result...  
> This will be magnitudes sloooooooooower than scale() :(
> 
> I'd really appreciate if the "scale-images-before-upload" use case would be considered better in the HTML5 spec. After all, images are the most frequently uploaded file type and it has always been a hassle for users to scale down their multi-megapixel photos manually before uploading them. Now that we have the chance to solve this issue with pure-browser techniques, we stop half-way. 
> 
> Franz
> 
> 2009/12/7 Sigbjorn Finne <sigbjorn.finne at gmail.com>
> On 12/5/2009 13:24, Franz Buchinger wrote:
> > Gears introduced the concept of an "offscreen canvas" that doesn't draw
> > anything in the browser window, but can be used to manipulate images in a
> > web worker.
> >
> > I used this functionality to implement a "resize-before-upload" feature in
> > my photo gallery uploader. Now I'm trying to port my uploader to HTML5 but
> > there seems no way to delegate the scaling work to a HTML5 web worker.
> > Surely I could use the DOM canvas to scale down the photos in the main
> > "browser thread", but this means that the UI gets blocked during this
> > process.
> >
> > If the user chooses more than a few multi-megapixel photos, the
> > CPU-intensive downscaling will likely freeze the browser and trigger a
> > script abortion warning.
> >
> > Are there plans to introduce an "offscreen canvas" in html5? If not, which
> > workarounds are possible?
> >
> Hi Franz,
> 
> ImageData is cloneable via postMessage(), so you could perform some
> forms of image processing that way.
> 
> --sigbjorn <sof at opera.com>
> 
> 

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

From dimich at google.com  Thu Dec 10 14:12:10 2009
From: dimich at google.com (Dmitry Titov)
Date: Thu, 10 Dec 2009 14:12:10 -0800
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality
	from a worker
In-Reply-To: <BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>
	<4B1C9E4D.1010901@gmail.com>
	<a07b86220912100045l7ce698c5sdada653744c1684b@mail.gmail.com>
	<BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>
Message-ID: <28040fc60912101412o4a19883aq5725c83d86d7b7c9@mail.gmail.com>

On Thu, Dec 10, 2009 at 1:36 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> Additionally there's the question of origin tainting -- is it possible to
> taint the origin in a worker? you don;t have image elements, you can't xhr
> unsafely to other origins, but maybe i'm missing something?
>

Is origin tainting relevant here because we want to make sure the image
being processed before upload does not get sent to malicious site by
the compromised worker script? It seems UA should taint the connected
documents once worker gets tainted.

There is importScript that can go cross-origin, just like <script> tag.
Going to http or different origin should trigger 'mixed content' indication
in UA for all pages connected to worker. XHR is SOP but there are bad SSL
certs. Normally the workers XHR would silently fail if received a bad SSL
cert response, but if the user previously replied "trust the site anyways"
on the scary dialog while visiting the site, I think the access from worker
then goes through with bad cert, since user already 'approved' it for the
whole origin.

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/1ab37fc4/attachment.htm>

From westonruter at gmail.com  Thu Dec 10 16:54:00 2009
From: westonruter at gmail.com (Weston Ruter)
Date: Thu, 10 Dec 2009 16:54:00 -0800
Subject: [whatwg] Text-To-Speech (TTS) Web API for JavaScript
Message-ID: <fb8299e10912101654p4a03fa77n574eb1349027501@mail.gmail.com>

I've been working on a web app which reads text in a web page, highlighting
each word as it is read. For this to be possible, a Text-To-Speech API is
needed which is able to:
(1) generate the speech audio from some text, and
(2) include the time indicies for when each of the words in the text is
spoken.

Microsoft has its Sapi.SpVoice API via ActiveXObject which does (1) but not
(2) apparently. There are web services (usable in conjunction with HTML5
Audio) which also do (1) such as the iSpeech
API<http://www.ispeech.org/api> and
Google Translate's TTS <
http://translate.google.com/translate_tts?q=Hello%2C+World&tl=en>, but none
that I have found which do (2). In any case, web services
aren't preferable since they require that the audio be transferred over the
network which could take a significant amount of time.

Is anyone aware of any work done to develop a standard TTS API for the Web?
Operating systems already have this functionality built-in, and it's a shame
that web apps can't make use of it. If Google Gears were alive, it would've
been a good place to prototype this, but alas?

Thanks,
Weston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/8a739240/attachment.htm>

From Olli.Pettay at helsinki.fi  Thu Dec 10 17:42:46 2009
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 10 Dec 2009 17:42:46 -0800
Subject: [whatwg] Text-To-Speech (TTS) Web API for JavaScript
In-Reply-To: <fb8299e10912101654p4a03fa77n574eb1349027501@mail.gmail.com>
References: <fb8299e10912101654p4a03fa77n574eb1349027501@mail.gmail.com>
Message-ID: <4B21A396.4060300@helsinki.fi>

On 12/10/09 4:54 PM, Weston Ruter wrote:
> I've been working on a web app which reads text in a web page,
> highlighting each word as it is read. For this to be possible, a
> Text-To-Speech API is needed which is able to:
> (1) generate the speech audio from some text, and
> (2) include the time indicies for when each of the words in the text is
> spoken.
>
> Microsoft has its Sapi.SpVoice API via ActiveXObject which does (1) but
> not (2) apparently. There are web services (usable in conjunction with
> HTML5 Audio) which also do (1) such as the iSpeech API
> <http://www.ispeech.org/api> and Google Translate's TTS
> <http://translate.google.com/translate_tts?q=Hello%2C+World&tl=en
> <http://translate.google.com/translate_tts?q=Hello%2C+World&tl=en>>, but
> none that I have found which do (2). In any case, web services
> aren't preferable since they require that the audio be transferred over
> the network which could take a significant amount of time.
>
> Is anyone aware of any work done to develop a standard TTS API for the
> Web? Operating systems already have this functionality built-in, and
> it's a shame that web apps can't make use of it. If Google Gears were
> alive, it would've been a good place to prototype this, but alas?


You probably want to ask W3C multimodal working group.
There are specifications like XHTML+Voice and SALT
(neither really W3C specifications) and (old) proposals like
MMI-CSS.


-Olli

From ifette at google.com  Thu Dec 10 19:23:48 2009
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 10 Dec 2009 19:23:48 -0800
Subject: [whatwg] Uploading directories of files
Message-ID: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>

USE CASE:
Many sites allow you to upload multiple files, often images. HTML5 allows
this via <input type="file" multiple>. This works well when your files are
all in one folder, but it may often be the case that files are spread across
sub-folders, and in this case you have to do multiple transactions (or
multiple <input type=file multiple> tags, which is just awkward) to upload
your files.

PROPOSAL: Allow a UA to recursively select and upload a directory of files.
How the UA chooses to modify the file picker dialog is outside the scope of
this spec, but for the sake of argument, assume that the UA lets you pick a
folder and say "upload all". Allow the UA to upload the files in the folder,
with the subdirectories included in the filename with a directory separator.

E.g. assume I have:

C:\users\ian\a\b\1.jpg
C:\users\ian\a\b\2.jpg
C:\users\ian\a\c\3.jpg

If the user chooses "a", the UA should be allowed to send all three files
with filenames:

"a/b/1.jpg"
"a/b/2.jpg"
"a/c/3.jpg"

as it would for the existing <input type=file multiple> implementation, with
the addition of the directories and path separators (not full path, just the
directory the user chose and sub-paths.)

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/955a6f9a/attachment.htm>

From jonas at sicking.cc  Thu Dec 10 21:29:51 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 10 Dec 2009 21:29:51 -0800
Subject: [whatwg] Uploading directories of files
In-Reply-To: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
Message-ID: <63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>

2009/12/10 Ian Fette (????????) <ifette at google.com>:
> USE CASE:
> Many sites allow you to upload multiple files, often images. HTML5 allows
> this via <input type="file" multiple>. This works well when your files are
> all in one folder, but it may often be the case that files are spread across
> sub-folders, and in this case you have to do multiple transactions (or
> multiple <input type=file multiple> tags, which is just awkward) to upload
> your files.
> PROPOSAL: Allow a UA to recursively select and upload a directory of files.
> How the UA chooses to modify the file picker dialog is outside the scope of
> this spec, but for the sake of argument, assume that the UA lets you pick a
> folder and say "upload all". Allow the UA to upload the files in the folder,
> with the subdirectories included in the filename with a directory separator.
> E.g. assume I have:
> C:\users\ian\a\b\1.jpg
> C:\users\ian\a\b\2.jpg
> C:\users\ian\a\c\3.jpg
> If the user chooses "a", the UA should be allowed to send all three files
> with filenames:
> "a/b/1.jpg"
> "a/b/2.jpg"
> "a/c/3.jpg"
> as it would for the existing <input type=file multiple> implementation, with
> the addition of the directories and path separators (not full path, just the
> directory the user chose and sub-paths.)
> Thoughts?

I don't think there is anything in the spec preventing you from doing
this right now. The fact that only files in the same folder can be
selected is a limitation in the implementation, not a limitation in
the spec.

The spec does require that only the leaf name, without any paths, are
submitted. Is that a problem?

I guess I'd be ok with changing the spec to allow more of the path to
be exposed. However that would mean that there is a mismatch between
what name is submitted and what name you'd get from
input.files[n].name.

/ Jonas

From ifette at google.com  Thu Dec 10 22:16:44 2009
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Thu, 10 Dec 2009 22:16:44 -0800
Subject: [whatwg] Uploading directories of files
In-Reply-To: <63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
Message-ID: <bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>

2009/12/10 Jonas Sicking <jonas at sicking.cc>

> 2009/12/10 Ian Fette (????????) <ifette at google.com>:
> > USE CASE:
> > Many sites allow you to upload multiple files, often images. HTML5 allows
> > this via <input type="file" multiple>. This works well when your files
> are
> > all in one folder, but it may often be the case that files are spread
> across
> > sub-folders, and in this case you have to do multiple transactions (or
> > multiple <input type=file multiple> tags, which is just awkward) to
> upload
> > your files.
> > PROPOSAL: Allow a UA to recursively select and upload a directory of
> files.
> > How the UA chooses to modify the file picker dialog is outside the scope
> of
> > this spec, but for the sake of argument, assume that the UA lets you pick
> a
> > folder and say "upload all". Allow the UA to upload the files in the
> folder,
> > with the subdirectories included in the filename with a directory
> separator.
> > E.g. assume I have:
> > C:\users\ian\a\b\1.jpg
> > C:\users\ian\a\b\2.jpg
> > C:\users\ian\a\c\3.jpg
> > If the user chooses "a", the UA should be allowed to send all three files
> > with filenames:
> > "a/b/1.jpg"
> > "a/b/2.jpg"
> > "a/c/3.jpg"
> > as it would for the existing <input type=file multiple> implementation,
> with
> > the addition of the directories and path separators (not full path, just
> the
> > directory the user chose and sub-paths.)
> > Thoughts?
>
> I don't think there is anything in the spec preventing you from doing
> this right now. The fact that only files in the same folder can be
> selected is a limitation in the implementation, not a limitation in
> the spec.
>
> The spec does require that only the leaf name, without any paths, are
> submitted. Is that a problem?
>

Perhaps not a show stopper, but I think it's sub-optimal. E.g. if I am using
a client application, I can point it to my "My Photos" directory and it can
infer some album structure from how I've organized my photos. It would be
nice if a web photo app could do the same.


>
> I guess I'd be ok with changing the spec to allow more of the path to
> be exposed. However that would mean that there is a mismatch between
> what name is submitted and what name you'd get from
> input.files[n].name.
>
>
I think that the notion of allowing more of the path to be exposed and
reconciling that with .name is where the problem lies, and would like to
figure out if we could resolve that. I think that there is a case to be made
for including the paths -- e.g. if I'm uploading photos to flickr, picasa,
or facebook, I may have already organized them locally, there's no reason
that I shouldn't be able to maintain that structure when I upload to the web
application. The question is then how that gets reconciled with
input.files[n].name -- I would think it preferable if .name also were
allowed to contain that extra information -- currently we say "The name of
the file. There are numerous file name variations on different systems; this
is merely the name of the file, without path information." [1]. I guess I
would propose that be changed to "The name of the file. There are numerous
file name variations on different systems; this is merely the name of the
file. If the user agent allows for files from multiple directories to be
selected and included in a single FileList, path information may be included
to distinguish between the files, provided that such path information SHOULD
NOT include information about any path components that are common to all of
the Files in the FileList."


Again, open to suggestions of how this could be accomplished in a better
way.

[1] http://www.w3.org/TR/FileAPI/#dfn-name

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

From jonas at sicking.cc  Thu Dec 10 22:31:40 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 10 Dec 2009 22:31:40 -0800
Subject: [whatwg] Uploading directories of files
In-Reply-To: <bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com> 
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com> 
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
Message-ID: <63df84f0912102231r3c5e8383pfad4bfb306a23d25@mail.gmail.com>

2009/12/10 Ian Fette (????????) <ifette at google.com>:
>> I guess I'd be ok with changing the spec to allow more of the path to
>> be exposed. However that would mean that there is a mismatch between
>> what name is submitted and what name you'd get from
>> input.files[n].name.
>>
>
> I think that the notion of allowing more of the path to be exposed and
> reconciling that with .name is where the problem lies, and would like to
> figure out if we could resolve that. I think that there is a case to be made
> for including the paths -- e.g. if I'm uploading photos to flickr, picasa,
> or facebook, I may have already organized them locally, there's no reason
> that I shouldn't be able to maintain that structure when I upload to the web
> application. The question is then how that gets reconciled with
> input.files[n].name -- I would think it preferable if .name also were
> allowed to contain that extra information -- currently we say "The name of
> the file. There are numerous file name variations on different systems; this
> is merely the name of the file, without path information." [1]. I guess I
> would propose that be changed to "The name of the file. There are numerous
> file name variations on different systems; this is merely the name of the
> file. If the user agent allows for files from multiple directories to be
> selected and included in a single FileList, path information may be included
> to distinguish between the files, provided that such path information SHOULD
> NOT include information about any path components that are common to all of
> the Files in the FileList."

If we're going to expose a full or partial path, then I think we
should do that separately from the .name property. I'd rather keep the
.name strictly be the leaf name.

/ Jonas

/ Jonas

From annevk at opera.com  Thu Dec 10 23:33:51 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 11 Dec 2009 08:33:51 +0100
Subject: [whatwg] Inconsistent behavior for empty-string URLs
In-Reply-To: <4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B3@SNV-EXVS09.ds.corp.yahoo.com>
References: <4E45EC6AD219FD47AD1BC06E4EE3845D0420CDBC@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071144yf994ea8tde81a6bb46e52a28@mail.gmail.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CDE7@SNV-EXVS09.ds.corp.yahoo.com>
	<7c2a12e20912071352v3b816071ubc99852ccf08cac8@mail.gmail.com>
	<op.u4l4i5aaidj3kv@simon-pieterss-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420CEEB@SNV-EXVS09.ds.corp.yahoo.com>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D01E@SNV-EXVS09.ds.corp.yahoo.com>
	<op.u4pu6zqx64w2qv@anne-van-kesterens-macbook.local>
	<4E45EC6AD219FD47AD1BC06E4EE3845D0420D0B3@SNV-EXVS09.ds.corp.yahoo.com>
Message-ID: <op.u4rjapok64w2qv@anne-van-kesterens-macbook.local>

On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas <nzakas at yahoo-inc.com>  
wrote:
> It's the "automatic download" that makes this problematic, as it
> silently doubles the number of requests to the server, which as I've
> said in previous emails, is a huge problem for high-volume sites. Opera
> already doesn't make a request in all of these cases, so I'm guessing
> that Web Workers is an exception?

It only doubles the load if you have crappy markup (or server setup,  
depending on your goals). Not sure why we are not loading the resource.  
That'd be a bug per the current specification.


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

From annevk at opera.com  Thu Dec 10 23:53:55 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 11 Dec 2009 08:53:55 +0100
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality
 from a worker
In-Reply-To: <BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com>
	<4B1C9E4D.1010901@gmail.com>
	<a07b86220912100045l7ce698c5sdada653744c1684b@mail.gmail.com>
	<BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>
Message-ID: <op.u4rj75yo64w2qv@anne-van-kesterens-macbook.local>

On Thu, 10 Dec 2009 22:36:45 +0100, Oliver Hunt <oliver at apple.com> wrote:
> Ideally if we were to have a graphics context in a worker we'd want it  
> to be the standard CanvasRenderingContext2D, the only real problem is  
> that CanvasRenderingContext2D references the parent canvas element which  
> clearly won't fly in a worker.

I think the solution to that is to just as with Navigator be more creative  
with IDL interfaces. The methods that take HTMLImageElement or  
HTMLVideoElement similarly should be excluded from the  
CanvasRenderingContext2D exposed within Web Workers.


> I've been thinking of creating something like a WorkerCanvas which is  
> basically a DOM-less CanvasRenderingContext2D, so you can do
>
> var canvas = new WorkerCanvas(width, height);
> canvas.putImageData(myData);

Something like that sounds good, though shouldn't putImageData() be on the  
2D context you can get via WorkerCanvas?


> I have a vague desire to allow a ImageData to be provided as a backing  
> store, but then you may hit perf or consistency issues on UAs that use  
> premultiplied alpha backing stores.
>
> Additionally there's the question of origin tainting -- is it possible  
> to taint the origin in a worker? you don;t have image elements, you  
> can't xhr unsafely to other origins, but maybe i'm missing something?

<canvas> can only be tainted by unsafe <img> or <video> elements. Neither  
is applicable, so no.


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

From derernst at gmx.ch  Fri Dec 11 00:13:52 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Fri, 11 Dec 2009 09:13:52 +0100
Subject: [whatwg] Uploading directories of files
In-Reply-To: <bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
Message-ID: <4B21FF40.30201@gmx.ch>

Ian Fette (????????) schrieb:
> I would think it preferable if 
> .name also were allowed to contain that extra information -- currently 
> we say "The name of the file. There are numerous file name variations on 
> different systems; this is merely the name of the file, without path 
> information." [1]. I guess I would propose that be changed to "The name 
> of the file. There are numerous file name variations on different 
> systems; this is merely the name of the file. If the user agent allows 
> for files from multiple directories to be selected and included in a 
> single FileList, path information may be included to distinguish between 
> the files, provided that such path information SHOULD NOT include 
> information about any path components that are common to all of the 
> Files in the FileList." 

If I understand you correctly, this would lead to differences in file 
names based on the UA, and even based on the folder that the user 
actually chose to upload. See your example:

C:\users\ian\a\b\1.jpg
C:\users\ian\a\b\2.jpg
C:\users\ian\a\c\3.jpg

1. The user anually selects files 1.jpg and 2.jpg in directory b. The 
resulting filename of the first file is "1.jpg".

2. Tho other day the user does an update, but this time selects 
directory b and does "upload all". Resulting filename: "b/1.jpg".

3. For the next update the user wants to easily upload all 3 files, 
which results in: "a/b/1.jpg".

4. Then the same action is done from another computer with a different 
UA, the file might again be named "1.jpg".

I have no idea how to handle such inconsistent behaviour on the server 
side (except adding extra code to flatten all uploaded directory 
structures before handling). I assume that HTTP upload should be kept 
simple, and more complex upload tasks should be handled with specialized 
applications, such as RadUpload[1].

[1] http://www.radinks.com

From annevk at opera.com  Fri Dec 11 00:17:55 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 11 Dec 2009 09:17:55 +0100
Subject: [whatwg] Uploading directories of files
In-Reply-To: <4B21FF40.30201@gmx.ch>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
	<4B21FF40.30201@gmx.ch>
Message-ID: <op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>

On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst <derernst at gmx.ch> wrote:
> I have no idea how to handle such inconsistent behaviour on the server  
> side (except adding extra code to flatten all uploaded directory  
> structures before handling). I assume that HTTP upload should be kept  
> simple, and more complex upload tasks should be handled with specialized  
> applications, such as RadUpload[1].
>
> [1] http://www.radinks.com

I don't think we want to rely on the availability of Java on the end  
user's platform (or the availability of any other plug-in for that matter).


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

From derernst at gmx.ch  Fri Dec 11 00:33:06 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Fri, 11 Dec 2009 09:33:06 +0100
Subject: [whatwg] Uploading directories of files
In-Reply-To: <op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>	<4B21FF40.30201@gmx.ch>
	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>
Message-ID: <4B2203C2.9070501@gmx.ch>

Anne van Kesteren schrieb:
> On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst <derernst at gmx.ch> wrote:
>> I have no idea how to handle such inconsistent behaviour on the server 
>> side (except adding extra code to flatten all uploaded directory 
>> structures before handling). I assume that HTTP upload should be kept 
>> simple, and more complex upload tasks should be handled with 
>> specialized applications, such as RadUpload[1].
>>
>> [1] http://www.radinks.com
> 
> I don't think we want to rely on the availability of Java on the end 
> user's platform (or the availability of any other plug-in for that matter).

I did not mean including it into HTML5 or an UA. Just leaving 
specialized upload tasks out of the standard, assuming that developers 
will work with applications that they think are useful for their tasks 
(and that rely on technologies they believe are avaliable at their 
target audience).

From annevk at opera.com  Fri Dec 11 00:47:34 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 11 Dec 2009 09:47:34 +0100
Subject: [whatwg] Uploading directories of files
In-Reply-To: <4B2203C2.9070501@gmx.ch>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
	<4B21FF40.30201@gmx.ch>
	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>
	<4B2203C2.9070501@gmx.ch>
Message-ID: <op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>

On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst <derernst at gmx.ch> wrote:
> Anne van Kesteren schrieb:
>> On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst <derernst at gmx.ch>  
>> wrote:
>>> I have no idea how to handle such inconsistent behaviour on the server  
>>> side (except adding extra code to flatten all uploaded directory  
>>> structures before handling). I assume that HTTP upload should be kept  
>>> simple, and more complex upload tasks should be handled with  
>>> specialized applications, such as RadUpload[1].
>>>
>>> [1] http://www.radinks.com
>>
>> I don't think we want to rely on the availability of Java on the end  
>> user's platform (or the availability of any other plug-in for that  
>> matter).
>
> I did not mean including it into HTML5 or an UA. Just leaving  
> specialized upload tasks out of the standard, assuming that developers  
> will work with applications that they think are useful for their tasks  
> (and that rely on technologies they believe are avaliable at their  
> target audience).

And I mean that if it is important to application developers we should  
make it available as a feature and not endorse some plug-in dependency.


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

From jonas at sicking.cc  Fri Dec 11 00:49:42 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 11 Dec 2009 00:49:42 -0800
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality
	from a worker
In-Reply-To: <BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com> 
	<4B1C9E4D.1010901@gmail.com>
	<a07b86220912100045l7ce698c5sdada653744c1684b@mail.gmail.com> 
	<BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>
Message-ID: <63df84f0912110049y2ac5ae1fr628906630ad4d667@mail.gmail.com>

On Thu, Dec 10, 2009 at 1:36 PM, Oliver Hunt <oliver at apple.com> wrote:
> Ideally if we were to have a graphics context in a worker we'd want it to be
> the standard CanvasRenderingContext2D, the only real problem is that
> CanvasRenderingContext2D references the parent canvas element which clearly
> won't fly in a worker.
> I've been thinking of creating something like a WorkerCanvas which is
> basically a DOM-less CanvasRenderingContext2D, so you can do
> var canvas = new WorkerCanvas(width, height);
> canvas.putImageData(myData);

Do you really need all of CanvasRenderingContext2D? I.e. do you really
need things like spline drawing, pattern filling, and text?

My concern weather the libraries backing CanvasRenderingContext2D are
generally threadsafe?

The use case brought up at the beginning of this thread was about
scaling. It would be dramatically easier to implement just a few
things like transformations, cropping and encoding/decoding, than to
implement all of CanvasRenderingContext2D off the main thread.

/ Jonas

From jorlow at chromium.org  Fri Dec 11 02:17:26 2009
From: jorlow at chromium.org (Jeremy Orlow)
Date: Fri, 11 Dec 2009 02:17:26 -0800
Subject: [whatwg] Uploading directories of files
In-Reply-To: <op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com> 
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com> 
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com> 
	<4B21FF40.30201@gmx.ch>
	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local> 
	<4B2203C2.9070501@gmx.ch>
	<op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>
Message-ID: <5dd9e5c50912110217u35fe4222l3a4b529398d93b02@mail.gmail.com>

On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren <annevk at opera.com>wrote:

> On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst <derernst at gmx.ch> wrote:
>
>> Anne van Kesteren schrieb:
>>
>>> On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst <derernst at gmx.ch>
>>> wrote:
>>>
>>>> I have no idea how to handle such inconsistent behaviour on the server
>>>> side (except adding extra code to flatten all uploaded directory structures
>>>> before handling). I assume that HTTP upload should be kept simple, and more
>>>> complex upload tasks should be handled with specialized applications, such
>>>> as RadUpload[1].
>>>>
>>>> [1] http://www.radinks.com
>>>>
>>>
>>> I don't think we want to rely on the availability of Java on the end
>>> user's platform (or the availability of any other plug-in for that matter).
>>>
>>
>> I did not mean including it into HTML5 or an UA. Just leaving specialized
>> upload tasks out of the standard, assuming that developers will work with
>> applications that they think are useful for their tasks (and that rely on
>> technologies they believe are avaliable at their target audience).
>>
>
> And I mean that if it is important to application developers we should make
> it available as a feature and not endorse some plug-in dependency.


I (and I think most of us) strongly agree.  That's the whole point of
standardization.  :-)

Personally, I don't think the case Markus pointed out is at all a show
stopper.  In the case of images, the server could easily recognize and
reconcile duplicates (by hashing them and looking for duplicate hashes or
something).  If the image has been tweaked some in the mean time, the EXIF
data can help.  And so on....this seems like the type of thing clever
developers can work around.

But regardless.....I don't think you could argue that having _some_ path
information is worse than _none_, right?

I also agree with Jonas that if some path information is added, it might be
better to create a new property (other than .name) for it.

And, with or without that extra property, I think what Ian's suggesting
would be useful to users.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091211/3e191cf4/attachment.htm>

From derernst at gmx.ch  Fri Dec 11 02:20:53 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Fri, 11 Dec 2009 11:20:53 +0100
Subject: [whatwg] Uploading directories of files
In-Reply-To: <op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>	<4B21FF40.30201@gmx.ch>	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>	<4B2203C2.9070501@gmx.ch>
	<op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>
Message-ID: <4B221D05.1080307@gmx.ch>

Anne van Kesteren schrieb:
> On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst <derernst at gmx.ch> wrote:
>> Anne van Kesteren schrieb:
>>> On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst <derernst at gmx.ch> 
>>> wrote:
>>>> I have no idea how to handle such inconsistent behaviour on the 
>>>> server side (except adding extra code to flatten all uploaded 
>>>> directory structures before handling). I assume that HTTP upload 
>>>> should be kept simple, and more complex upload tasks should be 
>>>> handled with specialized applications, such as RadUpload[1].
>>>>
>>>> [1] http://www.radinks.com
>>>
>>> I don't think we want to rely on the availability of Java on the end 
>>> user's platform (or the availability of any other plug-in for that 
>>> matter).
>>
>> I did not mean including it into HTML5 or an UA. Just leaving 
>> specialized upload tasks out of the standard, assuming that developers 
>> will work with applications that they think are useful for their tasks 
>> (and that rely on technologies they believe are avaliable at their 
>> target audience).
> 
> And I mean that if it is important to application developers we should 
> make it available as a feature and not endorse some plug-in dependency.

Ok.

Jonas Sicking schrieb:
 > If we're going to expose a full or partial path, then I think we
 > should do that separately from the .name property. I'd rather keep the
 > .name strictly be the leaf name.

I support this point. I assume that changing the name property would 
break backwards compatibility, as server-side applications (at least the 
ones I wrote) rely on the current behaviour.

There is an other aspect in Ians proposal - avoiding file name 
conflicts, when e.g. /a/1.jpg and /b/1.jpg are uploaded. This can be 
handled by the UA, for example by displaying an error message, allowing 
to rename the conflicting files before upload.

From derernst at gmx.ch  Fri Dec 11 02:30:19 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Fri, 11 Dec 2009 11:30:19 +0100
Subject: [whatwg] Uploading directories of files
In-Reply-To: <5dd9e5c50912110217u35fe4222l3a4b529398d93b02@mail.gmail.com>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
	<4B21FF40.30201@gmx.ch>	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>
	<4B2203C2.9070501@gmx.ch>	<op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>
	<5dd9e5c50912110217u35fe4222l3a4b529398d93b02@mail.gmail.com>
Message-ID: <4B221F3B.6070907@gmx.ch>

Jeremy Orlow schrieb:
> On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren <annevk at opera.com 

>     And I mean that if it is important to application developers we
>     should make it available as a feature and not endorse some plug-in
>     dependency.
> 
> 
> I (and I think most of us) strongly agree.  That's the whole point of 
> standardization.  :-)
> 
> Personally, I don't think the case Markus pointed out is at all a show 
> stopper.  In the case of images, the server could easily recognize and 
> reconcile duplicates (by hashing them and looking for duplicate hashes 
> or something).  If the image has been tweaked some in the mean time, the 
> EXIF data can help.  And so on....this seems like the type of thing 
> clever developers can work around.
> 
> But regardless.....I don't think you could argue that having _some_ path 
> information is worse than _none_, right?
> 
> I also agree with Jonas that if some path information is added, it might 
> be better to create a new property (other than .name) for it.
> 
> And, with or without that extra property, I think what Ian's suggesting 
> would be useful to users.

Yes I see Anne's and your points. Anyway I don't see yet how to get 
_useful_ path information, as the same file can be posted as /a/b/1.jpg, 
and at the next occasion as 1.jpg or /b/1.jpg, just based on where in 
the upload dialog you did make the start point.

Relying on information contained in the uploaded file does not seem to 
make sense to me, as you might want to upload a new file with the same 
name in order to replace the old one.

From jorlow at chromium.org  Fri Dec 11 02:30:23 2009
From: jorlow at chromium.org (Jeremy Orlow)
Date: Fri, 11 Dec 2009 02:30:23 -0800
Subject: [whatwg] "offscreen canvas" /Access to canvas functionality
	from a worker
In-Reply-To: <63df84f0912110049y2ac5ae1fr628906630ad4d667@mail.gmail.com>
References: <a07b86220912050424g7fbca502lc77be237cabc3a08@mail.gmail.com> 
	<4B1C9E4D.1010901@gmail.com>
	<a07b86220912100045l7ce698c5sdada653744c1684b@mail.gmail.com> 
	<BA353DD6-1DA3-4242-B0EA-8DEADB2E0888@apple.com>
	<63df84f0912110049y2ac5ae1fr628906630ad4d667@mail.gmail.com>
Message-ID: <5dd9e5c50912110230n3c0eb0cet3f2d39588041ea5a@mail.gmail.com>

On Fri, Dec 11, 2009 at 12:49 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Thu, Dec 10, 2009 at 1:36 PM, Oliver Hunt <oliver at apple.com> wrote:
> > Ideally if we were to have a graphics context in a worker we'd want it to
> be
> > the standard CanvasRenderingContext2D, the only real problem is that
> > CanvasRenderingContext2D references the parent canvas element which
> clearly
> > won't fly in a worker.
> > I've been thinking of creating something like a WorkerCanvas which is
> > basically a DOM-less CanvasRenderingContext2D, so you can do
> > var canvas = new WorkerCanvas(width, height);
> > canvas.putImageData(myData);
>
> Do you really need all of CanvasRenderingContext2D? I.e. do you really
> need things like spline drawing, pattern filling, and text?
>
> My concern weather the libraries backing CanvasRenderingContext2D are
> generally threadsafe?
>

CanvasRenderingContext2Ds would never need to be shared between threads
because they're "cloned" when passed...so is your concern that the libraries
are only meant to ever be used from one thread?  Maybe I'm being naive, but
it would surprise me if that turned out to be an issue.


> The use case brought up at the beginning of this thread was about
> scaling. It would be dramatically easier to implement just a few
> things like transformations, cropping and encoding/decoding, than to
> implement all of CanvasRenderingContext2D off the main thread.
>

Resizing images was just one use.  I could easily imagine apps wanting to
generate more complex images on background threads without needing to
implement things like spline drawing, pattern filling, and text themselves.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091211/20ad9f98/attachment.htm>

From jorlow at chromium.org  Fri Dec 11 02:33:23 2009
From: jorlow at chromium.org (Jeremy Orlow)
Date: Fri, 11 Dec 2009 02:33:23 -0800
Subject: [whatwg] Uploading directories of files
In-Reply-To: <4B221F3B.6070907@gmx.ch>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com> 
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com> 
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com> 
	<4B21FF40.30201@gmx.ch>
	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local> 
	<4B2203C2.9070501@gmx.ch>
	<op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local> 
	<5dd9e5c50912110217u35fe4222l3a4b529398d93b02@mail.gmail.com> 
	<4B221F3B.6070907@gmx.ch>
Message-ID: <5dd9e5c50912110233n615383del99d7f110ee57131@mail.gmail.com>

On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst <derernst at gmx.ch> wrote:

> Jeremy Orlow schrieb:
>
>  On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren <annevk at opera.com
>>
>
>     And I mean that if it is important to application developers we
>>    should make it available as a feature and not endorse some plug-in
>>    dependency.
>>
>>
>> I (and I think most of us) strongly agree.  That's the whole point of
>> standardization.  :-)
>>
>> Personally, I don't think the case Markus pointed out is at all a show
>> stopper.  In the case of images, the server could easily recognize and
>> reconcile duplicates (by hashing them and looking for duplicate hashes or
>> something).  If the image has been tweaked some in the mean time, the EXIF
>> data can help.  And so on....this seems like the type of thing clever
>> developers can work around.
>>
>> But regardless.....I don't think you could argue that having _some_ path
>> information is worse than _none_, right?
>>
>> I also agree with Jonas that if some path information is added, it might
>> be better to create a new property (other than .name) for it.
>>
>> And, with or without that extra property, I think what Ian's suggesting
>> would be useful to users.
>>
>
> Yes I see Anne's and your points. Anyway I don't see yet how to get
> _useful_ path information, as the same file can be posted as /a/b/1.jpg, and
> at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload
> dialog you did make the start point.
>
> Relying on information contained in the uploaded file does not seem to make
> sense to me, as you might want to upload a new file with the same name in
> order to replace the old one.
>

The information in the path could be seen as a hint that may or may not be
provided.  I feel like it'd be difficult security wise to guarantee that the
hint will be there and/or consistent from upload to upload.  But, once
again, some hint is better than none, right?  If you as a web developer
don't think it's useful, you can ignore it, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091211/eacd0470/attachment.htm>

From ian at hixie.ch  Fri Dec 11 02:41:22 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 11 Dec 2009 10:41:22 +0000 (UTC)
Subject: [whatwg] Text-To-Speech (TTS) Web API for JavaScript
In-Reply-To: <fb8299e10912101654p4a03fa77n574eb1349027501@mail.gmail.com>
References: <fb8299e10912101654p4a03fa77n574eb1349027501@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912111040060.16061@hixie.dreamhostps.com>

On Thu, 10 Dec 2009, Weston Ruter wrote:
>
> I've been working on a web app which reads text in a web page, highlighting
> each word as it is read. For this to be possible, a Text-To-Speech API is
> needed which is able to:
> (1) generate the speech audio from some text, and
> (2) include the time indicies for when each of the words in the text is
> spoken.
> 
> Microsoft has its Sapi.SpVoice API via ActiveXObject which does (1) but not
> (2) apparently. There are web services (usable in conjunction with HTML5
> Audio) which also do (1) such as the iSpeech
> API<http://www.ispeech.org/api> and
> Google Translate's TTS <
> http://translate.google.com/translate_tts?q=Hello%2C+World&tl=en>, but none
> that I have found which do (2). In any case, web services
> aren't preferable since they require that the audio be transferred over the
> network which could take a significant amount of time.
> 
> Is anyone aware of any work done to develop a standard TTS API for the Web?
> Operating systems already have this functionality built-in, and it's a shame
> that web apps can't make use of it. If Google Gears were alive, it would've
> been a good place to prototype this, but alas?

In addition to the suggestions made by Olli, you may also wish to read 
this thread, which includes some other people interested in this topic:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/thread.html#24281

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

From ian at hixie.ch  Fri Dec 11 05:43:43 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 11 Dec 2009 13:43:43 +0000 (UTC)
Subject: [whatwg] Psuedo classes based on DOM Events
In-Reply-To: <ea56cd6c0612042318m7474dfe2i96bed2431c365f00@mail.gmail.com>
References: <ea56cd6c0612042318m7474dfe2i96bed2431c365f00@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0912111341580.29336@hixie.dreamhostps.com>

On Tue, 5 Dec 2006, Rohan Prabhu wrote:
>
> i was just wondering, that in the Web Controls 1.0 specifications, in
> the psuedo classes specifications, could it be that the psuedo classes
> could also be the DOM Events which would modify the style information
> attached to it. Like for ex:
> 
> #objectid:onmouseup
> #objectid:onmousedown
> #objectid:onmouseover
> #objectid:onmouseout
> #objectid:onkeypress
> 
> etc...
> 
> just a idea from the silly mind of mine :D .. but do give ur comments on 
> that..

Based on the direction that the Web standards world has gone in since you 
wrote your question, I think it's likely that the Web Controls spec isn't 
going to go anywhere. Instead, I expect XBL2 and ARIA will provide the 
bulk of the features. The effect you describe will probably just be 
handled by regular script, possibly in conjunction with CSS features like 
the new CSS transition draft.

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

From bringert at google.com  Fri Dec 11 06:05:00 2009
From: bringert at google.com (Bjorn Bringert)
Date: Fri, 11 Dec 2009 14:05:00 +0000
Subject: [whatwg] Web API for speech recognition and synthesis
In-Reply-To: <4B1921EA.3000009@helsinki.fi>
References: <1ac456d70912020332m11cf5a3fv5a2449399e0b339e@mail.gmail.com>
	<op.u4br8tck2q99of@id-c0981>
	<6e608abf0912021650h52d6c6f2ha44d8559f181c3e8@mail.gmail.com>
	<4B1921EA.3000009@helsinki.fi>
Message-ID: <1ac456d70912110605i5fdc3f31wfd0370dc26b745f@mail.gmail.com>

Thanks for the discussion - cool to see more interest today also
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024453.html)

I've hacked up a proof-of-concept JavaScript API for speech
recognition and synthesis. It adds a navigator.speech object with
these functions:

void listen(ListenCallback callback, ListenOptions options);
void speak(DOMString text, SpeakCallback callback, SpeakOptions options);

The implementation uses an NPAPI plugin for the Android browser that
wraps the existing Android speech APIs. The code is available at
http://code.google.com/p/speech-api-browser-plugin/

There are some simple demo apps in
http://code.google.com/p/speech-api-browser-plugin/source/browse/trunk/android-plugin/demos/
including:

- English to Spanish speech-to-speech translation
- Google search by speaking a query
- The obligatory pizza ordering system
- A phone number dialer

Comments appreciated!

/Bjorn

On Fri, Dec 4, 2009 at 2:51 PM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:
> Indeed the API should be something significantly simpler than X+V.
> Microsoft has (had?) support for SALT. That API is pretty simple and
> provides speech recognition and TTS.
> The API could be probably even simpler than SALT.
> IIRC, there was an extension for Firefox to support SALT (well, there was
> also an extension to support X+V).
>
> If the platform/OS provides ASR and TTS, adding a JS API for it should
> be pretty simple. X+V tries to handle some logic using VoiceXML FIA, but
> I think it would be more web-like to give pure JS API (similar to SALT).
> Integrating visual and voice input could be done in scripts. I'd assume
> there would be some script libraries to handle multimodal input integration
> - especially if there will be touch and gestures events too etc. (Classic
> multimodal map applications will become possible in web.)
>
> But this all is something which should be possibly designed in or with W3C
> multimodal working group. I know their current architecture is way more
> complex, but X+X, SALT and even Multimodal-CSS has been discussed in that
> working group.
>
>
> -Olli
>
>
>
> On 12/3/09 2:50 AM, Dave Burke wrote:
>>
>> We're envisaging a simpler programmatic API that looks familiar to the
>> modern Web developer but one which avoids the legacy of dialog system
>> languages.
>>
>> Dave
>>
>> On Wed, Dec 2, 2009 at 7:25 PM, Jo?o Eiras <joaoe at opera.com
>> <mailto:joaoe at opera.com>> wrote:
>>
>> ? ?On Wed, 02 Dec 2009 12:32:07 +0100, Bjorn Bringert
>> ? ?<bringert at google.com <mailto:bringert at google.com>> wrote:
>>
>> ? ? ? ?We've been watching our colleagues build native apps that use
>> speech
>> ? ? ? ?recognition and speech synthesis, and would like to have JavaScript
>> ? ? ? ?APIs that let us do the same in web apps. We are thinking about
>> ? ? ? ?creating a lightweight and implementation-independent API that lets
>> ? ? ? ?web apps use speech services. Is anyone else interested in that?
>>
>> ? ? ? ?Bjorn Bringert, David Singleton, Gummi Hafsteinsson
>>
>>
>> ? ?This exists already, but only Opera supports it, although there are
>> ? ?problems with the library we use for speech recognition.
>>
>> ? ?http://www.w3.org/TR/xhtml+voice/
>>
>> ?http://dev.opera.com/articles/view/add-voice-interactivity-to-your-site/
>>
>> ? ?Would be nice to revive that specification and get vendor buy-in.
>>
>>
>>
>> ? ?--
>>
>> ? ?Jo?o Eiras
>> ? ?Core Developer, Opera Software ASA, http://www.opera.com/
>>
>>
>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

From ifette at google.com  Fri Dec 11 06:24:37 2009
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 11 Dec 2009 06:24:37 -0800
Subject: [whatwg] Uploading directories of files
In-Reply-To: <5dd9e5c50912110233n615383del99d7f110ee57131@mail.gmail.com>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
	<4B21FF40.30201@gmx.ch>
	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>
	<4B2203C2.9070501@gmx.ch>
	<op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>
	<5dd9e5c50912110217u35fe4222l3a4b529398d93b02@mail.gmail.com>
	<4B221F3B.6070907@gmx.ch>
	<5dd9e5c50912110233n615383del99d7f110ee57131@mail.gmail.com>
Message-ID: <bbeaa26f0912110624k4becfaa2s4bc85e0372befbd@mail.gmail.com>

Ok, I sense resistance to putting it in .name. What about .path, undefined
in most cases except where there is an upload including files from multiple
directories, in which case .path contains the path less any path components
common to all 3 (sorry, it's early morning and I can't write well before
having coffee).

e.g.

input.files[0].name="1.jpg"
input.files[0].path="a/b"
input.files[1].name="2.jpg"
input.files[1].path="a/b"
input.files[2].name="3.jpg"
input.files[2].path="a/c"

(Need to figure out the exact wording, as "a" is common to all 3 but if
you're uploading the entire directory "a", it may make sense to include that
in the path -- but I don't feel quite as strongly about that -- subfolders
are certainly more important IMO.)

2009/12/11 Jeremy Orlow <jorlow at chromium.org>

> On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst <derernst at gmx.ch> wrote:
>
>> Jeremy Orlow schrieb:
>>
>>  On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren <annevk at opera.com
>>>
>>
>>     And I mean that if it is important to application developers we
>>>    should make it available as a feature and not endorse some plug-in
>>>    dependency.
>>>
>>>
>>> I (and I think most of us) strongly agree.  That's the whole point of
>>> standardization.  :-)
>>>
>>> Personally, I don't think the case Markus pointed out is at all a show
>>> stopper.  In the case of images, the server could easily recognize and
>>> reconcile duplicates (by hashing them and looking for duplicate hashes or
>>> something).  If the image has been tweaked some in the mean time, the EXIF
>>> data can help.  And so on....this seems like the type of thing clever
>>> developers can work around.
>>>
>>> But regardless.....I don't think you could argue that having _some_ path
>>> information is worse than _none_, right?
>>>
>>> I also agree with Jonas that if some path information is added, it might
>>> be better to create a new property (other than .name) for it.
>>>
>>> And, with or without that extra property, I think what Ian's suggesting
>>> would be useful to users.
>>>
>>
>> Yes I see Anne's and your points. Anyway I don't see yet how to get
>> _useful_ path information, as the same file can be posted as /a/b/1.jpg, and
>> at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload
>> dialog you did make the start point.
>>
>> Relying on information contained in the uploaded file does not seem to
>> make sense to me, as you might want to upload a new file with the same name
>> in order to replace the old one.
>>
>
> The information in the path could be seen as a hint that may or may not be
> provided.  I feel like it'd be difficult security wise to guarantee that the
> hint will be there and/or consistent from upload to upload.  But, once
> again, some hint is better than none, right?  If you as a web developer
> don't think it's useful, you can ignore it, right?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091211/ad246972/attachment-0001.htm>

From annevk at opera.com  Fri Dec 11 06:28:35 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 11 Dec 2009 15:28:35 +0100
Subject: [whatwg] Uploading directories of files
In-Reply-To: <bbeaa26f0912110624k4becfaa2s4bc85e0372befbd@mail.gmail.com>
References: <bbeaa26f0912101923n35ac0e4ds3f0c425ab55fded2@mail.gmail.com>
	<63df84f0912102129h5a5c377qcbe632eaa3c8f1a3@mail.gmail.com>
	<bbeaa26f0912102216t5433d36cnb6d6df348333eae1@mail.gmail.com>
	<4B21FF40.30201@gmx.ch>
	<op.u4rlb5t864w2qv@anne-van-kesterens-macbook.local>
	<4B2203C2.9070501@gmx.ch>
	<op.u4rmpkqt64w2qv@anne-van-kesterens-macbook.local>
	<5dd9e5c50912110217u35fe4222l3a4b529398d93b02@mail.gmail.com>
	<4B221F3B.6070907@gmx.ch>
	<5dd9e5c50912110233n615383del99d7f110ee57131@mail.gmail.com>
	<bbeaa26f0912110624k4becfaa2s4bc85e0372befbd@mail.gmail.com>
Message-ID: <op.u4r2hxu464w2qv@anne-van-kesterens-macbook.local>

On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (????????)  
<ifette at g