From emoller at opera.com  Tue Jun  1 03:12:54 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Tue, 01 Jun 2010 12:12:54 +0200
Subject: [whatwg] WebSockets: UDP
Message-ID: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>

The use case I'd like to address in this post is Real-time client/server  
games.

The majority of the on-line games of today use a client/server model over  
UDP and we should try to give game developers the tools they require to  
create browser based games. For many simpler games a TCP based protocol is  
exactly what's needed but for most real-time games a UDP based protocol is  
a requirement. Games typically send small updates to its server at 20-30Hz  
over UDP and can with the help of entity interpolation and if required  
entity extrapolation cope well with intermittent packet loss. When a  
packet loss occur in a TCP based protocol the entire stream of data is  
held up until the packet is resent meaning a game would have to revert to  
entity extrapolation possibly over several seconds, leading to an  
unacceptable gameplay experience.

It seems to me the WebSocket interface can be easily modified to cope with  
UDP sockets (a wsd: scheme perhaps?) and it sounds like a good idea to  
leverage the work already done for WebSockets in terms of interface and  
framing.

The most important distinction between ws: and wsd: is that messages sent  
by send() in wsd: need not be acknowledged by the peer nor be resent. To  
keep the interface the same to the largest possible extent I'd suggest  
implementing a simple reliable 3-way handshake over UDP, keep-alive  
messages (and timeouts) and reliable close frames. If these are  
implemented right the interface in it's entirety could be kept. Only one  
new readonly attribute long maxMessageSize could be introduced to describe  
the min path MTU (perhaps only valid once in connected mode, or perhaps  
set to 0 or 576 initially and updated once in connected mode). This  
attribute could also be useful to expose in ws: and wss: but in that case  
be set to the internal limit of the browser / server.

The actual content of the handshake for wsd: can be vastly simplified  
compared to that of ws: as there's no need to be http compliant. It could  
contain just a magic identifier and length encoded strings for origin,  
location and protocol.

To minimize the work needed on the spec the data framing of wsd: can be  
kept identical to that of ws:, though I'd expect game developers would  
choose whatever the binary framing will be once the spec is done.

I'd be very interested to hear peoples opinion on this.

-- 
Erik M?ller
Core Developer
Opera Software

From svartman95 at gmail.com  Tue Jun  1 04:09:57 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 1 Jun 2010 11:09:57 +0000
Subject: [whatwg] audio and video: volume and muted as content
	attributes?
In-Reply-To: <AANLkTimlhYXmzS7UJxsUAcaj90Dufk3aDvpej3uo16zZ@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com>
	<4c0420c9.d345d80a.5c04.ffffd9f9@mx.google.com>
	<AANLkTimlhYXmzS7UJxsUAcaj90Dufk3aDvpej3uo16zZ@mail.gmail.com>
Message-ID: <AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f@mail.gmail.com>

On 5/31/10, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> On Tue, Jun 1, 2010 at 6:48 AM, bjartur <svartman95 at gmail.com> wrote:
>>>I just came across a curious situation in the spec: IIUC, it seems the
>>>@volume and @muted attributes are only IDL attributes and not content
>>>attributes. This means that an author who is creating an audio-visual
>>>Webpage has to use JavaScript to turn down (or up) the loudness of
>>>their media elements or mute them rather than just being able to
>>>specify this through content attributes.
>>>If you want to control the volume for the user after the page loads
>>>then yes, you'll need JavaScript.
>>>I've searched the archives and didn't find a discussion or reasons for
>>>this. Apologies if this has been discussed before.
>>>
>>>I am guessing the reasons for not having them as content attributes is
>>>that anything that requires muting of audio-visual content is assumed
>>> to need JavaScript anyway.
>>
>> Exactly.
>>
>>>However, if I have multiple videos on a page, all on autoplay, it
>>>would be nice to turn off the sound of all of them without JavaScript.
>>>With all the new CSS3 functionality, I can, for example, build a
>>>spinning cube of video elements that are on autoplay or a marquee of
>>>videos on autoplay - all of which would require muting the videos to
>>>be bearable. If we added @muted to the content attributes, it would be
>>>easy to set the muted state without having to write any JavaScript.
>>
>> If you need the audio to be muted you should use CSS. If you need to
>> control volume dynamically you need scripting.
>
> I am not aware of a CSS property for media elements that lets you
> control the muted state. Can you link me to a specification?
Well, http://www.w3.org/TR/CSS2/aural.html defines volume and
play-during. Play-during can stop, autoplay and repeat sounds.
It's not obvious to me how this will apply to elements that represent
audiovisual content but volume: silent; unambiguously mutes content.
Decorating audio (such as background music in games or videos)
seem to be even more easily styled for some reason. Multiple
soundtracks can be muxed and assigned different loudness.
Also @media aural {display: none;} can be used on audio elements
but I haven't read the specs properly so I don't know if that would hide
an <video> element when inside of an @media aural clause.

CSS 3 aural is still to be done so more capabilities may be suggested.

>> Well, you have a point. That can be done by increasing the volume
>> of the soundtrack itself, metedata (like embedded volume metadata in
>> MPEG files) and should be possible in CSS. Adding it to HTML as well
>> seems redundant.
>
> Are you saying that a Web author needs to edit the media resource in
> order to change the default volume setting for the resource? I think
> that's a bit of a stretch. Also, if you have a pointer to how this can
> be done in CSS, that would be highly appreciated.
Not necessarily, just pointing out that it would be a good idea to fix the
soundtrack if it's broken. CSS is perfect for these kind of things so I
recommend extending that rather than HTML.

-- 
kv,
  - Bjartur

From kornel at geekhood.net  Tue Jun  1 04:24:24 2010
From: kornel at geekhood.net (Kornel Lesinski)
Date: Tue, 1 Jun 2010 12:24:24 +0100
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net>

On 1 Jun 2010, at 11:12, Erik M?ller wrote:

> The use case I'd like to address in this post is Real-time client/server games.
> 
> The majority of the on-line games of today use a client/server model over UDP and we should try to give game developers the tools they require to create browser based games. For many simpler games a TCP based protocol is exactly what's needed but for most real-time games a UDP based protocol is a requirement. Games typically send small updates to its server at 20-30Hz over UDP and can with the help of entity interpolation and if required entity extrapolation cope well with intermittent packet loss. When a packet loss occur in a TCP based protocol the entire stream of data is held up until the packet is resent meaning a game would have to revert to entity extrapolation possibly over several seconds, leading to an unacceptable gameplay experience.
> 
> It seems to me the WebSocket interface can be easily modified to cope with UDP sockets (a wsd: scheme perhaps?) and it sounds like a good idea to leverage the work already done for WebSockets in terms of interface and framing.
> 
> The most important distinction between ws: and wsd: is that messages sent by send() in wsd: need not be acknowledged by the peer nor be resent. To keep the interface the same to the largest possible extent I'd suggest implementing a simple reliable 3-way handshake over UDP, keep-alive messages (and timeouts) and reliable close frames. If these are implemented right the interface in it's entirety could be kept. Only one new readonly attribute long maxMessageSize could be introduced to describe the min path MTU (perhaps only valid once in connected mode, or perhaps set to 0 or 576 initially and updated once in connected mode). This attribute could also be useful to expose in ws: and wss: but in that case be set to the internal limit of the browser / server.

SCTP would be ideal for this. It's connection-oriented, but supports multistreaming (can deliver messages out of order, without head of line blocking).

http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

-- 
regards, Kornel


From excors+whatwg at gmail.com  Tue Jun  1 04:34:51 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 1 Jun 2010 12:34:51 +0100
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>

On Tue, Jun 1, 2010 at 11:12 AM, Erik M?ller <emoller at opera.com> wrote:
> The use case I'd like to address in this post is Real-time client/server
> games.
>
> The majority of the on-line games of today use a client/server model over
> UDP and we should try to give game developers the tools they require to
> create browser based games. For many simpler games a TCP based protocol is
> exactly what's needed but for most real-time games a UDP based protocol is a
> requirement. [...]
>
> It seems to me the WebSocket interface can be easily modified to cope with
> UDP sockets [...]

As far as I'm aware, games use UDP because they can't use TCP (since
packet loss shouldn't stall the entire stream) and there's no
alternative but UDP. (And also because peer-to-peer usually requires
NAT punchthrough, which is much more reliable with UDP than with TCP).
They don't use UDP because it's a good match for their requirements,
it's just the only choice that doesn't make their requirements
impossible.

There are lots of features that seem very commonly desired in games: a
mixture of reliable and unreliable and reliable-but-unordered channels
(movement updates can be safely dropped but chat messages must never
be), automatic fragmentation of large messages, automatic aggregation
of small messages, flow control to avoid overloading the network,
compression, etc. And there's lots of libraries that build on top of
UDP to implement protocols halfway towards TCP in order to provide
those features:
http://msdn.microsoft.com/en-us/library/bb153248(VS.85).aspx,
http://opentnl.sourceforge.net/doxydocs/fundamentals.html,
http://www.jenkinssoftware.com/raknet/manual/introduction.html,
http://enet.bespin.org/Features.html, etc.

UDP sockets seem like a pretty inadequate solution for the use case of
realtime games - everyone would have to write their own higher-level
networking libraries (probably poorly and incompatibly) in JS to
provide the features that they really want. Browsers would lose the
ability to provide much security, e.g. flow control to prevent
intentional/accidental DOS attacks on the user's network, since they
would be too far removed from the application level to understand what
they should buffer or drop or notify the application about.

I think it'd be much more useful to provide a level of abstraction
similar to those game networking libraries - at least the ability to
send reliable and unreliable sequenced and unreliable unsequenced
messages over the same connection, with automatic
aggregation/fragmentation so you don't have to care about packet
sizes, and dynamic flow control for reliable messages and maybe some
static rate limit for unreliable messages. The API shouldn't expose
details of UDP (you could implement exactly the same API over TCP,
with better reliability but worse latency, or over any other protocols
that become well supported in the network).

-- 
Philip Taylor
excors at gmail.com

From silviapfeiffer1 at gmail.com  Tue Jun  1 04:41:38 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 1 Jun 2010 21:41:38 +1000
Subject: [whatwg] audio and video: volume and muted as content
	attributes?
In-Reply-To: <AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com> 
	<4c0420c9.d345d80a.5c04.ffffd9f9@mx.google.com>
	<AANLkTimlhYXmzS7UJxsUAcaj90Dufk3aDvpej3uo16zZ@mail.gmail.com> 
	<AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f@mail.gmail.com>
Message-ID: <AANLkTil5v_uAdUazNB2k5JjXxST-POvGeZSwyJB4Yxwk@mail.gmail.com>

On Tue, Jun 1, 2010 at 9:09 PM, Bjartur Thorlacius <svartman95 at gmail.com> wrote:
> On 5/31/10, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
>> On Tue, Jun 1, 2010 at 6:48 AM, bjartur <svartman95 at gmail.com> wrote:
>>>>I just came across a curious situation in the spec: IIUC, it seems the
>>>>@volume and @muted attributes are only IDL attributes and not content
>>>>attributes. This means that an author who is creating an audio-visual
>>>>Webpage has to use JavaScript to turn down (or up) the loudness of
>>>>their media elements or mute them rather than just being able to
>>>>specify this through content attributes.
>>>>If you want to control the volume for the user after the page loads
>>>>then yes, you'll need JavaScript.
>>>>I've searched the archives and didn't find a discussion or reasons for
>>>>this. Apologies if this has been discussed before.
>>>>
>>>>I am guessing the reasons for not having them as content attributes is
>>>>that anything that requires muting of audio-visual content is assumed
>>>> to need JavaScript anyway.
>>>
>>> Exactly.
>>>
>>>>However, if I have multiple videos on a page, all on autoplay, it
>>>>would be nice to turn off the sound of all of them without JavaScript.
>>>>With all the new CSS3 functionality, I can, for example, build a
>>>>spinning cube of video elements that are on autoplay or a marquee of
>>>>videos on autoplay - all of which would require muting the videos to
>>>>be bearable. If we added @muted to the content attributes, it would be
>>>>easy to set the muted state without having to write any JavaScript.
>>>
>>> If you need the audio to be muted you should use CSS. If you need to
>>> control volume dynamically you need scripting.
>>
>> I am not aware of a CSS property for media elements that lets you
>> control the muted state. Can you link me to a specification?
>
> Well, http://www.w3.org/TR/CSS2/aural.html defines volume and
> play-during.

Interesting.

> Play-during can stop, autoplay and repeat sounds.
> It's not obvious to me how this will apply to elements that represent
> audiovisual content but volume: silent; unambiguously mutes content.
> Decorating audio (such as background music in games or videos)
> seem to be even more easily styled for some reason. Multiple
> soundtracks can be muxed and assigned different loudness.
> Also @media aural {display: none;} can be used on audio elements
> but I haven't read the specs properly so I don't know if that would hide
> an <video> element when inside of an @media aural clause.
>
> CSS 3 aural is still to be done so more capabilities may be suggested.
>
>>> Well, you have a point. That can be done by increasing the volume
>>> of the soundtrack itself, metedata (like embedded volume metadata in
>>> MPEG files) and should be possible in CSS. Adding it to HTML as well
>>> seems redundant.
>>
>> Are you saying that a Web author needs to edit the media resource in
>> order to change the default volume setting for the resource? I think
>> that's a bit of a stretch. Also, if you have a pointer to how this can
>> be done in CSS, that would be highly appreciated.
> Not necessarily, just pointing out that it would be a good idea to fix the
> soundtrack if it's broken. CSS is perfect for these kind of things so I
> recommend extending that rather than HTML.

Has there been any discussion about implementing support for CSS2
aural in Web browsers? Until such a time - and in fact independently
of that - I still think turning the existing volume and muted IDL
attributes into content attributes would be a nice and simple
solution. Introducing a whole CSS aural control section will take lots
longer IMHO. Also, it won't hurt to have both - we do that for width
and height, too.

Cheers,
Silvia.

From lachlan.hunt at lachy.id.au  Tue Jun  1 04:42:22 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 01 Jun 2010 13:42:22 +0200
Subject: [whatwg] audio and video: volume and muted as
	content	attributes?
In-Reply-To: <AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com>	<4c0420c9.d345d80a.5c04.ffffd9f9@mx.google.com>	<AANLkTimlhYXmzS7UJxsUAcaj90Dufk3aDvpej3uo16zZ@mail.gmail.com>
	<AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f@mail.gmail.com>
Message-ID: <4C04F21E.4020101@lachy.id.au>

On 2010-06-01 13:09, Bjartur Thorlacius wrote:
> On 5/31/10, Silvia Pfeiffer<silviapfeiffer1 at gmail.com>  wrote:
>> I am not aware of a CSS property for media elements that lets you
>> control the muted state. Can you link me to a specification?
>
> Well, http://www.w3.org/TR/CSS2/aural.html defines volume and
> play-during. Play-during can stop, autoplay and repeat sounds.
> It's not obvious to me how this will apply to elements that represent
> audiovisual content but volume: silent; unambiguously mutes content.

Those properties were designed for aural browsers using speech synthesis 
to read the content of a page, not to control multimedia in a page 
itself.  Also, attempting to hijack those properties for use with 
multimedia content could create difficulties as you would have to define 
how the HTMLMediaElement's volume and muted properties interact with 
those CSS properties, if at all.

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

From emoller at opera.com  Tue Jun  1 06:00:50 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Tue, 01 Jun 2010 15:00:50 +0200
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
Message-ID: <op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>

On Tue, 01 Jun 2010 13:34:51 +0200, Philip Taylor  
<excors+whatwg at gmail.com> wrote:

> On Tue, Jun 1, 2010 at 11:12 AM, Erik M?ller <emoller at opera.com> wrote:
>> The use case I'd like to address in this post is Real-time client/server
>> games.
>>
>> The majority of the on-line games of today use a client/server model  
>> over
>> UDP and we should try to give game developers the tools they require to
>> create browser based games. For many simpler games a TCP based protocol  
>> is
>> exactly what's needed but for most real-time games a UDP based protocol  
>> is a
>> requirement. [...]
>>
>> It seems to me the WebSocket interface can be easily modified to cope  
>> with
>> UDP sockets [...]
>
> As far as I'm aware, games use UDP because they can't use TCP (since
> packet loss shouldn't stall the entire stream) and there's no
> alternative but UDP. (And also because peer-to-peer usually requires
> NAT punchthrough, which is much more reliable with UDP than with TCP).
> They don't use UDP because it's a good match for their requirements,
> it's just the only choice that doesn't make their requirements
> impossible.
>
> There are lots of features that seem very commonly desired in games: a
> mixture of reliable and unreliable and reliable-but-unordered channels
> (movement updates can be safely dropped but chat messages must never
> be), automatic fragmentation of large messages, automatic aggregation
> of small messages, flow control to avoid overloading the network,
> compression, etc. And there's lots of libraries that build on top of
> UDP to implement protocols halfway towards TCP in order to provide
> those features:
> http://msdn.microsoft.com/en-us/library/bb153248(VS.85).aspx,
> http://opentnl.sourceforge.net/doxydocs/fundamentals.html,
> http://www.jenkinssoftware.com/raknet/manual/introduction.html,
> http://enet.bespin.org/Features.html, etc.
>
> UDP sockets seem like a pretty inadequate solution for the use case of
> realtime games - everyone would have to write their own higher-level
> networking libraries (probably poorly and incompatibly) in JS to
> provide the features that they really want. Browsers would lose the
> ability to provide much security, e.g. flow control to prevent
> intentional/accidental DOS attacks on the user's network, since they
> would be too far removed from the application level to understand what
> they should buffer or drop or notify the application about.
>
> I think it'd be much more useful to provide a level of abstraction
> similar to those game networking libraries - at least the ability to
> send reliable and unreliable sequenced and unreliable unsequenced
> messages over the same connection, with automatic
> aggregation/fragmentation so you don't have to care about packet
> sizes, and dynamic flow control for reliable messages and maybe some
> static rate limit for unreliable messages. The API shouldn't expose
> details of UDP (you could implement exactly the same API over TCP,
> with better reliability but worse latency, or over any other protocols
> that become well supported in the network).
>

I've never heard any gamedevs complain how poorly UDP matches their needs  
so I'm not so sure about that, but you may be right it would be better to  
have a higher level abstraction. If we are indeed targeting the game  
developing community we should ask for their feedback rather than guessing  
what they prefer. I will grep my linked-in account for game-devs tonight  
and see if I can gather some feedback.

I suspect they prefer to be "empowered with UDP" rather than "boxed into a  
high level protocol that doesn't fit their needs" but I may be wrong.  
Those who have the knowledge, time and desire to implement their own  
reliable channels/flow control/security over UDP would be free to do so,  
those who couldn't care less can always use ws: or wss: for their reliable  
traffic and just use UDP where necessary.

So the question to the gamedevs will be, and please make suggestions for  
changes and I'll do an email round tonight:

If browser and server vendors agree on and standardize a socket based  
network interface to be used for real-time games running in the browsers,  
at what level would you prefer the interface to be?
(Note that an interface for communicating reliably via TCP and TLS are  
already implemented.)
- A low-level interface similar to a plain UDP socket
- A medium-level interface allowing for reliable and unreliable channels,  
automatically compressed data, flow control, data priority etc
- A high-level interface with "ghosted entities"

Oh, and I guess we should continue this discussion on the HyBi list... my  
fault for not posting there in the first place.

-- 
Erik M?ller
Core Developer
Opera Software

From bzbarsky at MIT.EDU  Tue Jun  1 07:46:42 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 01 Jun 2010 10:46:42 -0400
Subject: [whatwg] audio and video: volume and muted as
	content	attributes?
In-Reply-To: <AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com>	<4c0420c9.d345d80a.5c04.ffffd9f9@mx.google.com>	<AANLkTimlhYXmzS7UJxsUAcaj90Dufk3aDvpej3uo16zZ@mail.gmail.com>
	<AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f@mail.gmail.com>
Message-ID: <4C051D52.5040801@mit.edu>

On 6/1/10 7:09 AM, Bjartur Thorlacius wrote:
> Also @media aural {display: none;} can be used on audio elements
> but I haven't read the specs properly so I don't know if that would hide
> an<video>  element when inside of an @media aural clause.

You seem to be somewhat confused about the way "media" are used in CSS.

A "medium" is a property of the way the entire document is being 
presented.  Typical values one runs into with desktop web browsers are 
"screen" and "print".  The spec you link to is for the "aural" and 
"speech" media.

So in particular, rules inside "@media aural {}" will get ignored in all 
desktop browsers.  (Your example has a declaration directly inside 
@media, which is just a parse error, but I assume you meant putting an 
actual rule that assigns display:none to a particular element in the 
@media rule).

But more to the point, since the aural properties only apply to "aural" 
and "speech" media it would require a pretty major CSS spec change to 
make them mean anything in the "screen" medium, which is what you're 
proposing.

-Boris


From mike at belshe.com  Tue Jun  1 08:34:15 2010
From: mike at belshe.com (Mike Belshe)
Date: Tue, 1 Jun 2010 08:34:15 -0700
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net>
Message-ID: <AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com>

On Tue, Jun 1, 2010 at 4:24 AM, Kornel Lesinski <kornel at geekhood.net> wrote:

> On 1 Jun 2010, at 11:12, Erik M?ller wrote:
>
> > The use case I'd like to address in this post is Real-time client/server
> games.
> >
> > The majority of the on-line games of today use a client/server model over
> UDP and we should try to give game developers the tools they require to
> create browser based games. For many simpler games a TCP based protocol is
> exactly what's needed but for most real-time games a UDP based protocol is a
> requirement. Games typically send small updates to its server at 20-30Hz
> over UDP and can with the help of entity interpolation and if required
> entity extrapolation cope well with intermittent packet loss. When a packet
> loss occur in a TCP based protocol the entire stream of data is held up
> until the packet is resent meaning a game would have to revert to entity
> extrapolation possibly over several seconds, leading to an unacceptable
> gameplay experience.
> >
> > It seems to me the WebSocket interface can be easily modified to cope
> with UDP sockets (a wsd: scheme perhaps?) and it sounds like a good idea to
> leverage the work already done for WebSockets in terms of interface and
> framing.
> >
> > The most important distinction between ws: and wsd: is that messages sent
> by send() in wsd: need not be acknowledged by the peer nor be resent. To
> keep the interface the same to the largest possible extent I'd suggest
> implementing a simple reliable 3-way handshake over UDP, keep-alive messages
> (and timeouts) and reliable close frames. If these are implemented right the
> interface in it's entirety could be kept. Only one new readonly attribute
> long maxMessageSize could be introduced to describe the min path MTU
> (perhaps only valid once in connected mode, or perhaps set to 0 or 576
> initially and updated once in connected mode). This attribute could also be
> useful to expose in ws: and wss: but in that case be set to the internal
> limit of the browser / server.
>
> SCTP would be ideal for this. It's connection-oriented, but supports
> multistreaming (can deliver messages out of order, without head of line
> blocking).
>
> http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol


FYI:   SCTP is effectively non-deployable on the internet today due to NAT.

+1 on finding ways to enable UDP.  It's a key missing component to the web
platform.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100601/e3a940b7/attachment-0001.htm>

From jat at google.com  Tue Jun  1 08:52:35 2010
From: jat at google.com (John Tamplin)
Date: Tue, 1 Jun 2010 11:52:35 -0400
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net> 
	<AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com>
Message-ID: <AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com>

On Tue, Jun 1, 2010 at 11:34 AM, Mike Belshe <mike at belshe.com> wrote:

> FYI:   SCTP is effectively non-deployable on the internet today due to NAT.
>
> +1 on finding ways to enable UDP.  It's a key missing component to the web
> platform.
>

But there is so much infrastructure that would have to be enabled to use UDP
from a web app.  How would proxies be handled?  Even if specs were written
and implementations available, how many years would it be before corporate
proxies/firewalls supported WebSocket over UDP?

I am all for finding a way to get datagram communication from a web app, but
I think it will take a long time and shouldn't hold up current WebSocket
work.

-- 
John A. Tamplin
Software Engineer (GWT), Google
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100601/704c4515/attachment.htm>

From mike at belshe.com  Tue Jun  1 09:45:51 2010
From: mike at belshe.com (Mike Belshe)
Date: Tue, 1 Jun 2010 09:45:51 -0700
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net>
	<AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com>
	<AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com>
Message-ID: <AANLkTimqKeShKPpV0NHprXuiTh--zZtpz-HpiCunWXCU@mail.gmail.com>

On Tue, Jun 1, 2010 at 8:52 AM, John Tamplin <jat at google.com> wrote:

> On Tue, Jun 1, 2010 at 11:34 AM, Mike Belshe <mike at belshe.com> wrote:
>
>> FYI:   SCTP is effectively non-deployable on the internet today due to
>> NAT.
>>
>> +1 on finding ways to enable UDP.  It's a key missing component to the web
>> platform.
>>
>
> But there is so much infrastructure that would have to be enabled to use
> UDP from a web app.  How would proxies be handled?  Even if specs were
> written and implementations available, how many years would it be before
> corporate proxies/firewalls supported WebSocket over UDP?


Agree - nobody said it would be trivial.  There are so many games
successfully doing it today that it is clearly viable.  For games in
particular, they have had to document to their users how to configure their
home routers, and that has been successful too.  If you talk with game
writers - there are a class of games where UDP is just better (e.g. those
communicating real-time, interactive position and other info).  If we can
enable that through the web platform, that is good.


>
> I am all for finding a way to get datagram communication from a web app,
> but I think it will take a long time and shouldn't hold up current WebSocket
> work.
>

Agree-  no need to stall existing work.

Mike


>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100601/a14a95e0/attachment.htm>

From emoller at opera.com  Tue Jun  1 12:08:15 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Tue, 01 Jun 2010 21:08:15 +0200
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTimqKeShKPpV0NHprXuiTh--zZtpz-HpiCunWXCU@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net>
	<AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com>
	<AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com>
	<AANLkTimqKeShKPpV0NHprXuiTh--zZtpz-HpiCunWXCU@mail.gmail.com>
Message-ID: <op.vdmx310ar4mipi@emoller-pc.gothenburg.osa>

On Tue, 01 Jun 2010 18:45:51 +0200, Mike Belshe <mike at belshe.com> wrote:

> On Tue, Jun 1, 2010 at 8:52 AM, John Tamplin <jat at google.com> wrote:
>
>> On Tue, Jun 1, 2010 at 11:34 AM, Mike Belshe <mike at belshe.com> wrote:
>>
>>> FYI:   SCTP is effectively non-deployable on the internet today due to
>>> NAT.
>>>
>>> +1 on finding ways to enable UDP.  It's a key missing component to the  
>>> web
>>> platform.
>>>
>>
>> But there is so much infrastructure that would have to be enabled to use
>> UDP from a web app.  How would proxies be handled?  Even if specs were
>> written and implementations available, how many years would it be before
>> corporate proxies/firewalls supported WebSocket over UDP?
>
>
> Agree - nobody said it would be trivial.  There are so many games
> successfully doing it today that it is clearly viable.  For games in
> particular, they have had to document to their users how to configure  
> their
> home routers, and that has been successful too.  If you talk with game
> writers - there are a class of games where UDP is just better (e.g. those
> communicating real-time, interactive position and other info).  If we can
> enable that through the web platform, that is good.
>
>
>>
>> I am all for finding a way to get datagram communication from a web app,
>> but I think it will take a long time and shouldn't hold up current  
>> WebSocket
>> work.
>>
>
> Agree-  no need to stall existing work.
>
> Mike
>
>
>>
>> --
>> John A. Tamplin
>> Software Engineer (GWT), Google
>>

I don't think proxies and firewalls are going to be a major problem, like  
Mike said, the myriad of UDP games out there seem to do just fine in the  
real world. Sure, there will be corporate firewalls and proxies blocking  
employees from fragging their colleagues when the boss is in a meeting,  
but I guess they're partly put there to prevent just that so we probably  
shouldn't try to combat it.
If we were talking about peer-to-peer UDP it'd be a whole new ballgame,  
but that's why I specifically said the use-case was for client/server  
games, I don't think we should attempt peer-to-peer before WebSockets is  
all done and shipped.

I fully agree any discussions on UDP (or other protocol) shouldn't stall  
the existing work, but right now there seems to be very little activity  
anyways.

-- 
Erik M?ller
Core Developer
Opera Software

From excors+whatwg at gmail.com  Tue Jun  1 12:14:33 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Tue, 1 Jun 2010 20:14:33 +0100
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>

On Tue, Jun 1, 2010 at 2:00 PM, Erik M?ller <emoller at opera.com> wrote:
> [...]
> I've never heard any gamedevs complain how poorly UDP matches their needs so
> I'm not so sure about that, but you may be right it would be better to have
> a higher level abstraction. If we are indeed targeting the game developing
> community we should ask for their feedback rather than guessing what they
> prefer. I will grep my linked-in account for game-devs tonight and see if I
> can gather some feedback.

More feedback is certainly good, though I think the libraries I
mentioned (DirectPlay/OpenTNL/RakNet/ENet (there's probably more)) are
useful as an indicator of common real needs (as opposed to edge-case
or merely perceived needs) - they've been used by quite a few games
and they seem to have largely converged on a core set of features, so
that's better than just guessing.

I guess many commercial games write their own instead of reusing
third-party libraries, and I guess they often reimplement very similar
concepts to these, but it would be good to have more reliable
information about that.

> I suspect they prefer to be "empowered with UDP" rather than "boxed into a
> high level protocol that doesn't fit their needs" but I may be wrong.

If you put it like that, I don't see why anybody would not want to be
empowered :-)

But that's not the choice, since they could never really have UDP -
the protocol will perhaps have to be Origin-based, connection-oriented
(to exchange Origin information etc), with complex packet headers so
you can't trick it into talking to a DNS server, with rate limiting in
the browser to prevent DOS attacks, restricted to client-server (no
peer-to-peer since you probably can't run a socket server in the
browser), etc.

Once you've got all that, a simple UDP-socket-like API might not be
the most natural or efficient way to implement a higher-level
partially-reliable protocol - the application couldn't cooperate with
the low-level network buffering to prioritise certain messages, it
couldn't use the packet headers that have already been added on top of
UDP, it would have to send acks from a script callback which may add
some latency after a packet is received from the network, etc. So I
think there's some tradeoffs and it's not a question of one low-level
protocol vs one strictly more restrictive higher-level protocol.

> So the question to the gamedevs will be, and please make suggestions for
> changes and I'll do an email round tonight:
>
> If browser and server vendors agree on and standardize a socket based
> network interface to be used for real-time games running in the browsers, at
> what level would you prefer the interface to be?
> (Note that an interface for communicating reliably via TCP and TLS are
> already implemented.)
> - A low-level interface similar to a plain UDP socket
> - A medium-level interface allowing for reliable and unreliable channels,
> automatically compressed data, flow control, data priority etc
> - A high-level interface with "ghosted entities"

That first option sounds like you're offering something very much like
a plain UDP socket (and I guess anyone who's willing to write their
own high-level wrapper (which is only hundreds or thousands of lines
of code and not a big deal for a complex game) would prefer that since
they want as much power as possible), but (as above) I think that's
misleading - it's really a UDP interface on top of a protocol that has
some quite different characteristics to UDP. So I think the question
should be clearer that the protocol will necessarily include various
features and restrictions on top of UDP, and the choice is whether it
includes the minimal set of features needed for security and hides
them behind a UDP-like interface or whether it includes higher-level
features and exposes them in a higher-level interface.

-- 
Philip Taylor
excors at gmail.com

From emoller at opera.com  Tue Jun  1 13:02:05 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Tue, 01 Jun 2010 22:02:05 +0200
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
Message-ID: <op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>

On Tue, 01 Jun 2010 21:14:33 +0200, Philip Taylor  
<excors+whatwg at gmail.com> wrote:

> More feedback is certainly good, though I think the libraries I
> mentioned (DirectPlay/OpenTNL/RakNet/ENet (there's probably more)) are
> useful as an indicator of common real needs (as opposed to edge-case
> or merely perceived needs) - they've been used by quite a few games
> and they seem to have largely converged on a core set of features, so
> that's better than just guessing.
>
> I guess many commercial games write their own instead of reusing
> third-party libraries, and I guess they often reimplement very similar
> concepts to these, but it would be good to have more reliable
> information about that.
>

I was hoping to be able to avoid looking at what the interfaces of a high  
vs low level option would look like this early on in the discussions, but  
perhaps we need to do just that; look at Torque, RakNet etc and find a  
least common denominator and see what the reactions would be to such an  
interface. Game companies are pretty restrictive about what they discuss,  
but I think I know enough game devs to at least get some good feedback on  
what would be required to make it work well with their engine/game.

>> I suspect they prefer to be "empowered with UDP" rather than "boxed  
>> into a
>> high level protocol that doesn't fit their needs" but I may be wrong.
>
> If you put it like that, I don't see why anybody would not want to be
> empowered :-)

Yeah I wouldn't put it like that when asking :) I'm really not trying to  
sell my view, I just like to see real browser gaming in a not too distant  
future.

>
> But that's not the choice, since they could never really have UDP -
> the protocol will perhaps have to be Origin-based, connection-oriented
> (to exchange Origin information etc), with complex packet headers so
> you can't trick it into talking to a DNS server, with rate limiting in
> the browser to prevent DOS attacks, restricted to client-server (no
> peer-to-peer since you probably can't run a socket server in the
> browser), etc.
[...]
>
> That first option sounds like you're offering something very much like
> a plain UDP socket (and I guess anyone who's willing to write their
> own high-level wrapper (which is only hundreds or thousands of lines
> of code and not a big deal for a complex game) would prefer that since
> they want as much power as possible), but (as above) I think that's
> misleading - it's really a UDP interface on top of a protocol that has
> some quite different characteristics to UDP. So I think the question
> should be clearer that the protocol will necessarily include various
> features and restrictions on top of UDP, and the choice is whether it
> includes the minimal set of features needed for security and hides
> them behind a UDP-like interface or whether it includes higher-level
> features and exposes them in a higher-level interface.

So, what would the minimal set of limitations be to make a "UDP WebSocket"  
browser-safe?

-No listen sockets
-No multicast
-Reliable handshake with origin info
-Automatic keep-alives
-Reliable close handshake
-Socket is bound to one address for the duration of its lifetime
-Sockets open sequentially (like current DOS protection in WebSockets)
-Cap on number of open sockets per server and total per user agent


-- 
Erik M?ller
Core Developer
Opera Software

From svartman95 at gmail.com  Tue Jun  1 15:14:49 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 01 Jun 2010 22:14:49 +0000
Subject: [whatwg] audio and video: volume and muted as
	content	attributes?
Message-ID: <4c058668.5cebd80a.089e.2129@mx.google.com>

References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu at mail.gmail.com> 
	<4c0420c9.d345d80a.5c04.ffffd9f9 at mx.google.com> <AANLkTimlhYXmzS7UJxsUAcaj90Dufk3aDvpej3uo16zZ at mail.gmail.com> 
	<AANLkTin3iq_ahIWWUWam6hevnsS1rXAl17g3zj9YnN9f at mail.gmail.com>
>Bjartur Thorlacius <svartman95 at gmail.com> wrote:
>> Play-during can stop, autoplay and repeat sounds.
>> It's not obvious to me how this will apply to elements that represent
>> audiovisual content but volume: silent; unambiguously mutes content.
>> Decorating audio (such as background music in games or videos)
>> seem to be even more easily styled for some reason. Multiple
>> soundtracks can be muxed and assigned different loudness.
>> Also @media aural {display: none;} can be used on audio elements
>> but I haven't read the specs properly so I don't know if that would hide
>> an <video> element when inside of an @media aural clause.
>>
>> CSS 3 aural has still to be done so more capabilities may be suggested.
>>
>Has there been any discussion about implementing support for CSS2
>aural in Web browsers? Until such a time - and in fact independently
>of that - I still think turning the existing volume and muted IDL
>attributes into content attributes would be a nice and simple
>solution. Introducing a whole CSS aural control section will take lots
>longer IMHO. Also, it won't hurt to have both - we do that for width
>and height, too.
It seems much more "The Right Way"(tm) to do such things in CSS.
Browsers don't have to conform to the whole aural specification nor
the speech module of CSS 3. I think CSS 3 will have seperate speech
and aural modules which would solve the problem entirely. Note also
that CSS 2 aural allows styling of cues. As there's a workaround
implementation time isn't the number one priority.
There's need for the capability so saying that it shouldn't be
implemented because of lack of discussion seems weird.
Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
>On 2010-06-01 13:09, Bjartur Thorlacius wrote:
>> On 5/31/10, Silvia Pfeiffer <silviapfeiffer1 at gmail.com>  wrote:
>>> I am not aware of a CSS property for media elements that lets you
>>> control the muted state. Can you link me to a specification?
>>
>> Well, http://www.w3.org/TR/CSS2/aural.html defines volume and
>> play-during. Play-during can stop, autoplay and repeat sounds.
>> It's not obvious to me how this will apply to elements that represent
>> audiovisual content but volume: silent; unambiguously mutes content.
>
>Those properties were designed for aural browsers using speech synthesis 
>to read the content of a page, not to control multimedia in a page 
>itself.
Well, sounds are to speech/text as images are to (written) text.
You can float both paragraphs and images because to CSS they're just boxes.
I don't see a reason not to allow authors to control the volume of sound
if they can do so with speech.

As for play-during it's so general that it might be included in interactive
visual media as well.
>Also, attempting to hijack those properties for use with 
>multimedia content could create difficulties as you would have to define 
>how the HTMLMediaElement's volume and muted properties interact with 
>those CSS properties, if at all.
How's it done for other visual/behavioral content attributes in HTML?
Align, color and in fact most of the attributes of <font> have similiar
problems.

From jsalsman at gmail.com  Tue Jun  1 15:34:17 2010
From: jsalsman at gmail.com (James Salsman)
Date: Tue, 1 Jun 2010 15:34:17 -0700
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net>
	<AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com>
	<AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com>
Message-ID: <AANLkTinviwOMk1-LAkzv9Kp-c8qqTJs4Heqjbo2SXAgC@mail.gmail.com>

I agree UDP sockets are a legitimate, useful option, with applications
far beyond games.  In most cases TCP is fine, but adaptive bit-rate
vocoders, for example, can use packet loss as an adaptation parameter,
and chose only to retransmit some of the more essential packets in
cases of congestion.  I am not suggesting that javascript applications
should implement adaptive bit-rate vocoding (until a fast
cross-platform javascript signal processing library is developed, if
then) but there are reasons that a web application might want to send
both reliable and unreliable traffic; most all of them having to do
with adapting to bandwith constraints.

On Tue, Jun 1, 2010 at 8:52 AM, John Tamplin <jat at google.com> wrote:
>
>... How would proxies be handled?

UDP is supposed to never be buffered, not even by proxies. Proxies are
supposed to simply forward UDP without logging.  Lots of them don't
forward any UDP, and alot of them probably log the traffic.

>?Even if specs were written and implementations available, how many years
> would it be before corporate proxies/firewalls supported WebSocket over UDP?

Maybe UDP adoption would follow adoption of SIP and RTP.  Has anyone
measured the current rate of UDP transmission availability from the
typical corporate client host?

On Tue, Jun 1, 2010 at 1:02 PM, Erik M?ller <emoller at opera.com> wrote:
>....
> what would the minimal set of limitations be to make a "UDP WebSocket" browser-safe?
>
> -No listen sockets

For outgoing-from-client UDP, client-initiated TCP streams for
incoming responses and packet acknowledgment may be maximally
NAT-safe.

> -No multicast

People will eventually ask for it, but forwarding to it through
servers known to be free from NATs is preferable.

> -Reliable handshake with origin info

Nothing about UDP is reliable, you just send packets and hope they get there.

> -Automatic keep-alives

You mean on the incoming-to-client TCP channel in the opposite
direction from the UDP traffic?

> -Reliable close handshake

Can we use REST/HTTP/HTTPS persistent connections for this?

> -Socket is bound to one address for the duration of its lifetime

That sounds reasonable, but clients do change IP addresses now and
then, so maybe there should be some anticipation of this possibility?

> -Sockets open sequentially (like current DOS protection in WebSockets)

Do you mean their sequence numbers should be strictly increasing
incrementally until they roll over?

> -Cap on number of open sockets per server and total per user agent

There was some discussion that people rarely check for the error
condition when such caps are exausted, so I'm not sure whether that
should be the same as the system cap, or some fraction, or dozens, or
a developer configuration parameter.

From mark.frohnmayer at gmail.com  Tue Jun  1 16:07:48 2010
From: mark.frohnmayer at gmail.com (Mark Frohnmayer)
Date: Tue, 1 Jun 2010 16:07:48 -0700
Subject: [whatwg] [hybi]  WebSockets: UDP
In-Reply-To: <op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> 
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> 
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com>

On Tue, Jun 1, 2010 at 1:02 PM, Erik M?ller <emoller at opera.com> wrote:
>
> I was hoping to be able to avoid looking at what the interfaces of a high vs
> low level option would look like this early on in the discussions, but
> perhaps we need to do just that; look at Torque, RakNet etc and find a least
> common denominator and see what the reactions would be to such an interface.
> Game companies are pretty restrictive about what they discuss, but I think I
> know enough game devs to at least get some good feedback on what would be
> required to make it work well with their engine/game.

Glad to see this discussion rolling!  For what it's worth, the Torque
Sockets design effort was to take a stab at answering this question --
what is the least-common-denominator "webby" API/protocol that's
sufficiently useful to be a common foundation for real time games.  I
did the first stab at porting OpenTNL (now tnl2) atop it; from my
reading of the RTP protocol that should easily layer as well, but it
would be worth getting the perspective of some other high-level
network stack folks (RakNet, etc).

>
>>> I suspect they prefer to be "empowered with UDP" rather than "boxed into
>>> a
>>> high level protocol that doesn't fit their needs" but I may be wrong.
>>
>> If you put it like that, I don't see why anybody would not want to be
>> empowered :-)
>
> Yeah I wouldn't put it like that when asking :) I'm really not trying to
> sell my view, I just like to see real browser gaming in a not too distant
> future.

Hmm... given the number of different approaches to higher-level game
networking I'd hate to see a high-level straightjacket where a
well-conceived low level API could easily support all of the existing
solutions out there.  The more complex the API the larger the attack
surface at the trusted level and the more difficulty in getting
existing stakeholders (game and browser makers) on board.

>
> So, what would the minimal set of limitations be to make a "UDP WebSocket"
> browser-safe?
>
> -No listen sockets

Only feedback here would be I think p2p should be looked at in this
pass -- many client/server game instances are peers from the
perspective of the hosting service (XBox Live, Quake, Half-Life,
Battle.net) -- forcing all game traffic to pass through the hosting
domain is a severe constraint.  My question -- what does a "webby" p2p
solution look like regarding Origin restrictions, etc?

> -No multicast

> -Reliable handshake with origin info
> -Automatic keep-alives
> -Reliable close handshake

While we're at it, I'd add key exchange, encryption and client puzzles
to reduce connection depletion/CPU depletion attacks to the handshake.
 The protocol you seem to be aiming for isn't UDP -- rather it's more
like an connected, unreliable packet stream between hosts.

> -Socket is bound to one address for the duration of its lifetime
> -Sockets open sequentially (like current DOS protection in WebSockets)
> -Cap on number of open sockets per server and total per user agent

A single UDP socket can host multiple connections (indexed by packet
source address), so even a modest limit on actual number of sockets
wouldn't be a big impediment.

I'd also advocate for packet delivery notification to be a part of the
API -- with a known success or failure status on packet delivery many
of the higher level data transmission policies become trivial, and
should be essentially zero overhead at the protocol level.  Without
notification the higher level code has to do manual packet
acknowledgement as Phil mentioned.

Regards,
Mark

From shess at google.com  Tue Jun  1 16:34:05 2010
From: shess at google.com (Scott Hess)
Date: Tue, 1 Jun 2010 16:34:05 -0700
Subject: [whatwg] [hybi] WebSockets: UDP
In-Reply-To: <AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com>
Message-ID: <AANLkTinsp1rOYr4tLYpfgilqnelhRqQB9gUDHrUOxTrB@mail.gmail.com>

On Tue, Jun 1, 2010 at 4:07 PM, Mark Frohnmayer
<mark.frohnmayer at gmail.com> wrote:
> On Tue, Jun 1, 2010 at 1:02 PM, Erik M?ller <emoller at opera.com> wrote:
>> So, what would the minimal set of limitations be to make a "UDP WebSocket"
>> browser-safe?
>>
>> -No listen sockets
>
> Only feedback here would be I think p2p should be looked at in this
> pass -- many client/server game instances are peers from the
> perspective of the hosting service (XBox Live, Quake, Half-Life,
> Battle.net) -- forcing all game traffic to pass through the hosting
> domain is a severe constraint. ?My question -- what does a "webby" p2p
> solution look like regarding Origin restrictions, etc?

Unix domain sockets allow you to pass file descriptors between
processes.  It might be interesting to pass a WebSocket endpoint
across a WebSocket.  If the clients can punch through NATs, it becomes
a direct peer-to-peer connection, otherwise it gets proxied through
the server.  Probably makes implementations excessively complicated,
though.  UDP-style would be easier (no need to worry about data
received by the server after it initiates pushing the endpoint to the
other client - just drop it on the floor).

-scott

From mark.frohnmayer at gmail.com  Tue Jun  1 17:12:15 2010
From: mark.frohnmayer at gmail.com (Mark Frohnmayer)
Date: Tue, 1 Jun 2010 17:12:15 -0700
Subject: [whatwg] [hybi]  WebSockets: UDP
In-Reply-To: <218FD9A5-77A9-499C-8170-38621354C988@surrey.ac.uk>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> 
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> 
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com> 
	<218FD9A5-77A9-499C-8170-38621354C988@surrey.ac.uk>
Message-ID: <AANLkTilNGZN64H7GerLtDcnHURAry6Ja0IF4MAT8D7IY@mail.gmail.com>

On Tue, Jun 1, 2010 at 4:35 PM,  <L.Wood at surrey.ac.uk> wrote:
> On 2 Jun 2010, at 00:07, Mark Frohnmayer wrote:
>> A single UDP socket can host multiple connections (indexed by packet
>> source address), so even a modest limit on actual number of sockets
>> wouldn't be a big impediment.
>
> Um, NAT?

You would want to index by the NAT'd address.  In the case of peer
introduction and connection a third party is needed to provide the
external send-to address.

Is that what you were asking?

Regards,
Mark

From ben.garney at gmail.com  Tue Jun  1 17:24:36 2010
From: ben.garney at gmail.com (Ben Garney)
Date: Tue, 1 Jun 2010 17:24:36 -0700
Subject: [whatwg] [hybi] WebSockets: UDP
In-Reply-To: <AANLkTilNGZN64H7GerLtDcnHURAry6Ja0IF4MAT8D7IY@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> 
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> 
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com> 
	<218FD9A5-77A9-499C-8170-38621354C988@surrey.ac.uk>
	<AANLkTilNGZN64H7GerLtDcnHURAry6Ja0IF4MAT8D7IY@mail.gmail.com>
Message-ID: <AANLkTikd2OhNZLsV4jLkwd0-oAmrJM9b2_T6m-caBlEh@mail.gmail.com>

On Tue, Jun 1, 2010 at 5:12 PM, Mark Frohnmayer
<mark.frohnmayer at gmail.com>wrote:

> On Tue, Jun 1, 2010 at 4:35 PM,  <L.Wood at surrey.ac.uk> wrote:
> > On 2 Jun 2010, at 00:07, Mark Frohnmayer wrote:
> >> A single UDP socket can host multiple connections (indexed by packet
> >> source address), so even a modest limit on actual number of sockets
> >> wouldn't be a big impediment.
> >
> > Um, NAT?
>
> You would want to index by the NAT'd address.  In the case of peer
> introduction and connection a third party is needed to provide the
> external send-to address.
>
>
In some cases you need to use UPNP to NAT, but in general the 3rd
party connection facilitator will help. The UPNP is mostly needed so that
clients can _host_, which is not the goal here.

If we assume a public, carefully set up UDP host, then nearly anyone can
connect if UDP is allowed at all. No NAT is required in this case. And I
think this is the common case, since we are not trying to run service hosts
in the browser at this time.

If you have any sort of connection identifier (typically port will be
different even if IP is not), then you can multiplex by that.

(Also, hi! This is my first post. I'm Ben Garney, I worked at PushButton
Labs on Flash game technology (www.pushbuttonengine.com,
www.pushbuttonlabs.com). Naturally, seeing browser capabilities expand
either by plugin or native capabilities is exciting. Before I worked at PBL
I worked with Mark at GarageGames on networking technology, among other
things.)

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100601/5e9fe5b5/attachment.htm>

From julian.reschke at gmx.de  Tue Jun  1 22:23:12 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 02 Jun 2010 07:23:12 +0200
Subject: [whatwg] ISSUE-86,
 Re: hixie: Remove the HTML-to-Atom mapping definition from the W3C
 version of the spec. (whatwg r5100)
In-Reply-To: <20100602042010.512582BCC3@toro.w3.mag.keio.ac.jp>
References: <20100602042010.512582BCC3@toro.w3.mag.keio.ac.jp>
Message-ID: <4C05EAC0.3020506@gmx.de>

Hi Ian,

thanks for the removal.

I notice that you kept the text in the WHATWG version of the spec.

Various problems have been reported with respect to the mapping, notably

   <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7806>

and

   <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546>

and in the Working Group discussions around

   <http://www.w3.org/html/wg/tracker/issues/86>

Please consider them raised (and still open) as per the WHATWG issue 
tracking rules.

Best regards, Julian


On 02.06.2010 06:20, poot wrote:
> hixie: Remove the HTML-to-Atom mapping definition from the W3C version
> of the spec. (whatwg r5100)
>
> http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.4095&r2=1.4096&f=h
> http://html5.org/tools/web-apps-tracker?from=5099&to=5100
>
> ===================================================================
> RCS file: /sources/public/html5/spec/Overview.html,v
> retrieving revision 1.4095
> retrieving revision 1.4096
> diff -u -d -r1.4095 -r1.4096
> --- Overview.html	1 Jun 2010 04:26:11 -0000	1.4095
> +++ Overview.html	2 Jun 2010 04:19:31 -0000	1.4096
> @@ -287,7 +287,7 @@
>
>      <h1>HTML5</h1>
>      <h2 class="no-num no-toc" id="a-vocabulary-and-associated-apis-for-html-and-xhtml">A vocabulary and associated APIs for HTML and XHTML</h2>
> -<h2 class="no-num no-toc" id="editor-s-draft-1-june-2010">Editor's Draft 1 June 2010</h2>
> +<h2 class="no-num no-toc" id="editor-s-draft-2-june-2010">Editor's Draft 2 June 2010</h2>
>      <dl><dt>Latest Published Version:</dt>
>       <dd><a href="http://www.w3.org/TR/html5/">http://www.w3.org/TR/html5/</a></dd>
>       <dt>Latest Editor's Draft:</dt>
> @@ -390,7 +390,7 @@
>     Group</a>  is the W3C working group responsible for this
>     specification's progress along the W3C Recommendation
>     track.
> -  This specification is the 1 June 2010 Editor's Draft.
> +  This specification is the 2 June 2010 Editor's Draft.
>     </p><!-- UNDER NO CIRCUMSTANCES IS THE PRECEDING PARAGRAPH TO BE REMOVED OR EDITED WITHOUT TALKING TO IAN FIRST --><!-- relationship to other work (required) --><p>The contents of this specification are also part of<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">a
>     specification</a>  published by the<a href="http://www.whatwg.org/">WHATWG</a>, which is available under a
>     license that permits reuse of the specification text.</p><!-- UNDER NO CIRCUMSTANCES IS THE FOLLOWING PARAGRAPH TO BE REMOVED OR EDITED WITHOUT TALKING TO IAN FIRST --><!-- required patent boilerplate --><p>This document was produced by a group operating under the<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
> @@ -867,9 +867,7 @@
>       <ol>
>        <li><a href="#selectors"><span class="secno">4.14.1</span>Case-sensitivity</a></li>
>        <li><a href="#pseudo-classes"><span class="secno">4.14.2</span>Pseudo-classes</a></ol></li>
> -<li><a href="#converting-html-to-other-formats"><span class="secno">4.15</span>Converting HTML to other formats</a>
> -<ol>
> -<li><a href="#atom"><span class="secno">4.15.1</span>Atom</a></ol></ol></li>
> +<li><a href="#converting-html-to-other-formats"><span class="secno">4.15</span>Converting HTML to other formats</a></ol></li>
>    <li><a href="#browsers"><span class="secno">5</span>Loading Web pages</a>
>     <ol>
>      <li><a href="#windows"><span class="secno">5.1</span>Browsing contexts</a>
> @@ -40034,457 +40032,6 @@
>     <h3 id="converting-html-to-other-formats"><span class="secno">4.15</span>Converting HTML to other formats</h3><p class="XXX annotation"><b>Status:</b><i>Last call for comments</i></p>
>
>
> -<h4 id="atom"><span class="secno">4.15.1</span>Atom</h4><p class="XXX annotation"><b>Status:</b><i>Last call for comments.</i><span><a href="http://www.w3.org/html/wg/tracker/issues/86">ISSUE-86</a>  (atom-id-stability) blocks progress to Last Call</span></p>
> -
> -<p>Given a<code><a href="#document">Document</a></code>  <var title="">source</var>, a user
> -  agent may run the following algorithm to<dfn id="extracting-atom" title="extracting
> -  Atom">extract an Atom feed</dfn>. This is not the only algorithm
> -  that can be used for this purpose; for instance, a user agent might
> -  instead use the hAtom algorithm.<a href="#refsHATOM">[HATOM]</a></p>
> -
> -<ol><li><p>If the<code><a href="#document">Document</a></code>  <var title="">source</var>  does
> -   not contain any<code><a href="#the-article-element">article</a></code>  elements, then return nothing
> -   and abort these steps. This algorithm can only be used with
> -   documents that contain distinct articles.</p>
> -
> -<li><p>Let<var title="">R</var>  be an empty<a href="#xml-documents" title="XML
> -   documents">XML</a>  <code><a href="#document">Document</a></code>  object whose<a href="#the-document-s-address" title="the document's address">address</a>  is user-agent
> -   defined.</li>
> -
> -<li><p>Append a<code title="">feed</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>  to<var title="">R</var>.</li>
> -
> -<li>
> -
> -<p>For each<code><a href="#meta">meta</a></code>  element with a<code title="attr-meta-name"><a href="#attr-meta-name">name</a></code>  attribute and a<code title="attr-meta-content"><a href="#attr-meta-content">content</a></code>  attribute and whose<code title="attr-meta-name"><a href="#attr-meta-name">name</a></code>  attribute's value is<code title="meta-author"><a href="#meta-author">author</a></code>, run the following substeps:</p>
> -
> -<ol><li><p>Append an<code title="">author</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>  to the root element of<var title="">R</var>.</li>
> -
> -<li><p>Append a<code title="">name</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>  to the element created in the
> -     previous step.</p>
> -
> -<li><p>Append a text node whose data is the value of the
> -<code><a href="#meta">meta</a></code>  element's<code title="attr-meta-content"><a href="#attr-meta-content">content</a></code>  attribute to the element
> -     created in the previous step.</li>
> -
> -</ol><!-- could use vCards instead, and get<atom:email>  and<atom:uri>
> -    elements out of this instead of just<atom:name>  --></li>
> -
> -<li>
> -
> -<p>If there is a<code><a href="#the-link-element">link</a></code>  element whose<code title="attr-link-rel"><a href="#attr-link-rel">rel</a></code>  attribute's value includes the
> -    keyword<code title="rel-icon"><a href="#rel-icon">icon</a></code>, and that element also
> -    has an<code title="attr-link-href"><a href="#attr-link-href">href</a></code>  attribute whose
> -    value successfully<a href="#resolve-a-url" title="resolve a url">resolves</a>
> -    relative to the<code><a href="#the-link-element">link</a></code>  element, then append an<code title="">icon</code>  element in the<a href="#atom-namespace">Atom namespace</a>  to
> -    the root element of<var title="">R</var>  whose contents is a text
> -    node with its data set to the<a href="#absolute-url">absolute URL</a>  resulting
> -    from<a href="#resolve-a-url" title="resolve a url">resolving</a>  the value of the
> -<code title="attr-link-href"><a href="#attr-link-href">href</a></code>  attribute.</p>
> -
> -<!-- could check ratio, could check type... -->
> -
> -</li>
> -
> -<li>
> -
> -<p>Append an<code title="">id</code>  element in the<a href="#atom-namespace">Atom
> -    namespace</a>  to the root element of<var title="">R</var>
> -    whose contents is a text node with its data set to<a href="#the-document-s-current-address">the
> -    document's current address</a>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>Optionally: Let<var title="">x</var>  be a<code title="">link</code>  element in the<a href="#atom-namespace">Atom
> -    namespace</a>. Add a<code title="">rel</code>  attribute whose
> -    value is the string "<code title="">self</code>" to<var title="">x</var>. Append a text node with its data set to the
> -    (user-agent-defined)<a href="#the-document-s-address" title="the document's
> -    address">address</a>  of<var title="">R</var>  to<var title="">x</var>. Append<var title="">x</var>  to the root element
> -    of<var title="">R</var>.</p>
> -
> -<p class="note">This step would be skipped when the document<var title="">R</var>  has no convenient<a href="#the-document-s-address" title="the document's
> -    address">address</a>. The presence of the<code title="">rel="self"</code>  link is a "should"-level requirement in
> -    the Atom specification.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>Let<var title="">x</var>  be a<code title="">link</code>
> -    element in the<a href="#atom-namespace">Atom namespace</a>. Add a<code title="">rel</code>  attribute whose value is the string "<code title="">alternate</code>" to<var title="">x</var>. If the
> -    document being converted is an<a href="#html-documents" title="HTML documents">HTML
> -    document</a>, add a<code title="">type</code>  attribute whose
> -    value is the string "<code><a href="#text-html">text/html</a></code>" to<var title="">x</var>. Otherwise, the document being converted is an
> -<a href="#xml-documents" title="XML documents">XML document</a>; add a<code title="">type</code>  attribute whose value is the string
> -    "<code><a href="#application-xhtml-xml">application/xhtml+xml</a></code>" to<var title="">x</var>. Append a text node with its data set to
> -<a href="#the-document-s-current-address">the document's current address</a>  to<var title="">x</var>. Append<var title="">x</var>  to the root element
> -    of<var title="">R</var>.</p>
> -
> -</li>
> -
> -<li><p>Let<var title="">subheading text</var>  be the empty
> -   string.</li>
> -
> -<li><p>Let<var title="">heading</var>  be the first element of
> -<a href="#heading-content">heading content</a>  whose nearest ancestor of
> -<a href="#sectioning-content">sectioning content</a>  is<a href="#the-body-element">the body
> -   element</a>, if any, or null if there is none.</li>
> -
> -<li>
> -
> -<p>Take the appropriate action from the following list, as
> -    determined by the type of the<var title="">heading</var>
> -    element:</p>
> -
> -<dl><dt>If<var title="">heading</var>  is null</dt>
> -
> -<dd>
> -
> -<p>Let<var title="">heading text</var>  be the
> -<code><a href="#textcontent">textContent</a></code>  of<a href="#the-title-element">the<code>title</code>
> -      element</a>, if there is one, or the empty string
> -      otherwise.</p>
> -
> -</dd>
> -
> -<dt>If<var title="">heading</var>  is a<code><a href="#the-hgroup-element">hgroup</a></code>  element</dt>
> -
> -<dd>
> -
> -<p>If<var title="">heading</var>  contains no child
> -<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>&ndash;<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h6</a></code>  elements, let<var title="">heading text</var>  be the empty string.</p>
> -
> -<p>Otherwise, let<var title="">headings list</var>  be a list of
> -      all the<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>&ndash;<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h6</a></code>  element children
> -      of<var title="">heading</var>, sorted first by descending
> -<a href="#rank">rank</a>  and then in<a href="#tree-order">tree order</a>  (so
> -<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>s first, then<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h2</a></code>s, etc, with each
> -      group in the order they appear in the document). Then, let<var title="">heading text</var>  be the<code><a href="#textcontent">textContent</a></code>  of
> -      the first entry in<var title="">headings list</var>, and if
> -      there are multiple entries, let<var title="">subheading
> -      text</var>  be the<code><a href="#textcontent">textContent</a></code>  of the second entry
> -      in<var title="">headings list</var>.</p>
> -
> -</dd>
> -
> -<dt>If<var title="">heading</var>  is an<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>&ndash;<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h6</a></code>  element</dt>
> -
> -<dd>
> -
> -<p>Let<var title="">heading text</var>  be the
> -<code><a href="#textcontent">textContent</a></code>  of<var title="">heading</var>.</p>
> -
> -</dd>
> -
> -</dl></li>
> -
> -<li>
> -
> -<p>Append a<code title="">title</code>  element in the<a href="#atom-namespace">Atom
> -    namespace</a>  to the root element of<var title="">R</var>
> -    whose contents is a text node with its data set to<var title="">heading text</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If<var title="">subheading text</var>  is not the empty string,
> -    append a<code title="">subtitle</code>  element in the<a href="#atom-namespace">Atom
> -    namespace</a>  to the root element of<var title="">R</var>
> -    whose contents is a text node with its data set to<var title="">subheading text</var>.</p>
> -
> -</li>
> -
> -<li><p>Let<var title="">global update date</var>  have no
> -   value.</li>
> -
> -<li>
> -
> -<p>For each<code><a href="#the-article-element">article</a></code>  element<var title="">article</var>  that does not have an ancestor
> -<code><a href="#the-article-element">article</a></code>  element, run the following steps:</p>
> -
> -<ol><li><p>Let<var title="">E</var>  be an<code title="">entry</code>  element in the<a href="#atom-namespace">Atom namespace</a>,
> -     and append<var title="">E</var>  to the root element of<var title="">R</var>.</li>
> -
> -<li><p>Let<var title="">heading</var>  be the first element of
> -<a href="#heading-content">heading content</a>  whose nearest ancestor of
> -<a href="#sectioning-content">sectioning content</a>  is<var title="">article</var>,
> -     if any, or null if there is none.</li>
> -
> -<li>
> -
> -<p>Take the appropriate action from the following list, as
> -      determined by the type of the<var title="">heading</var>
> -      element:</p>
> -
> -<dl><dt>If<var title="">heading</var>  is null</dt>
> -
> -<dd>
> -
> -<p>Let<var title="">heading text</var>  be the empty
> -        string.</p>
> -
> -</dd>
> -
> -<dt>If<var title="">heading</var>  is a<code><a href="#the-hgroup-element">hgroup</a></code>  element</dt>
> -
> -<dd>
> -
> -<p>If<var title="">heading</var>  contains no child
> -<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>&ndash;<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h6</a></code>  elements, let<var title="">heading text</var>  be the empty string.</p>
> -
> -<p>Otherwise, let<var title="">headings list</var>  be a list
> -        of all the<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>&ndash;<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h6</a></code>  element
> -        children of<var title="">heading</var>, sorted first by
> -        descending<a href="#rank">rank</a>  and then in<a href="#tree-order">tree
> -        order</a>  (so<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>s first, then
> -<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h2</a></code>s, etc, with each group in the order they
> -        appear in the document). Then, let<var title="">heading
> -        text</var>  be the<code><a href="#textcontent">textContent</a></code>  of the first entry
> -        in<var title="">headings list</var>.</p>
> -
> -</dd>
> -
> -<dt>If<var title="">heading</var>  is an<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h1</a></code>&ndash;<code><a href="#the-h1-h2-h3-h4-h5-and-h6-elements">h6</a></code>  element</dt>
> -
> -<dd>
> -
> -<p>Let<var title="">heading text</var>  be the
> -<code><a href="#textcontent">textContent</a></code>  of<var title="">heading</var>.</p>
> -
> -</dd>
> -
> -</dl></li>
> -
> -<li>
> -
> -<p>Append a<code title="">title</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>  to<var title="">E</var>  whose
> -      contents is a text node with its data set to<var title="">heading text</var>.</p>
> -
> -</li>
> -
> -<!--<atom:author>  is required either at the feed level (above)
> -     or the entry level (here) but we don't provide it -->
> -
> -<li>
> -
> -<p>Clone<var title="">article</var>  and its descendants into an
> -      environment that has<a href="#concept-bc-noscript" title="concept-bc-noscript">scripting
> -      disabled</a>, has no<a href="#plugin" title="plugin">plugins</a>, and
> -      fails any attempt to<a href="#fetch" title="fetch">fetch</a>  any
> -      resources. Let<var title="">cloned article</var>  be the
> -      resulting clone<code><a href="#the-article-element">article</a></code>  element.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>Remove from the subtree rooted at<var title="">cloned
> -      article</var>  any<code><a href="#the-article-element">article</a></code>  elements other than the
> -<var title="">cloned article</var>  itself, any
> -<code><a href="#the-header-element">header</a></code>,<code><a href="#the-footer-element">footer</a></code>, or<code><a href="#the-nav-element">nav</a></code>
> -      elements whose nearest ancestor of<a href="#sectioning-content">sectioning
> -      content</a>  is the<var title="">cloned article</var>, and
> -      the first element of<a href="#heading-content">heading content</a>  whose nearest
> -      ancestor of<a href="#sectioning-content">sectioning content</a>  is the<var title="">cloned article</var>, if any.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If<var title="">cloned article</var>  contains any
> -<code><a href="#the-ins-element">ins</a></code>  or<code><a href="#the-del-element">del</a></code>  elements with<code title="attr-mod-datetime"><a href="#attr-mod-datetime">datetime</a></code>  attributes whose
> -      values<a href="#parse-a-global-date-and-time-string" title="parse a global date and time string">parse
> -      as global date and time strings</a>  without errors, then let
> -<var title="">update date</var>  be the value of the<code title="attr-mod-datetime"><a href="#attr-mod-datetime">datetime</a></code>  attribute that parses
> -      to the newest<a href="#concept-datetime" title="concept-datetime">global date and
> -      time</a>.</p>
> -
> -<p>Otherwise, let<var title="">update date</var>  have no
> -      value.</p>
> -
> -<p class="note">This value is used below; it is calculated here
> -      because in certain cases the next step mutates the<var title="">cloned article</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If the document being converted is an<a href="#html-documents" title="HTML
> -      documents">HTML document</a>, then: Let<var title="">x</var>
> -      be a<code title="">content</code>  element in the<a href="#atom-namespace">Atom
> -      namespace</a>. Add a<code title="">type</code>  attribute
> -      whose value is the string "<code title="">html</code>" to<var title="">x</var>. Append a text node with its data set to the
> -      result of running the<a href="#html-fragment-serialization-algorithm">HTML fragment serialization
> -      algorithm</a>  on<var title="">cloned article</var>  to<var title="">x</var>. Append<var title="">x</var>  to<var title="">E</var>.</p>
> -
> -<p>Otherwise, the document being converted is an<a href="#xml-documents" title="XML documents">XML document</a>: Let<var title="">x</var>  be a<code title="">content</code>  element in
> -      the<a href="#atom-namespace">Atom namespace</a>. Add a<code title="">type</code>  attribute whose value is the string "<code title="">xml</code>" to<var title="">x</var>. Append a
> -<code><a href="#the-div-element">div</a></code>  element to<var title="">x</var>. Move all the
> -      child nodes of the<var title="">cloned article</var>  node to
> -      that<code><a href="#the-div-element">div</a></code>  element, preserving their relative
> -      order. Append<var title="">x</var>  to<var title="">E</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>Establish the value of<var title="">id</var>  and<var title="">has-alternate</var>  from the first of the following to
> -      apply:</p>
> -
> -<dl><dt>If the<var title="">article</var>  node has a descendant
> -<code><a href="#the-a-element">a</a></code>  or<code><a href="#the-area-element">area</a></code>  element with an<code title="attr-hyperlink-href"><a href="#attr-hyperlink-href">href</a></code>  attribute that
> -       successfully<a href="#resolve-a-url" title="resolve a url">resolves</a>
> -       relative to that descendant and a<code title="attr-hyperlink-rel"><a href="#attr-hyperlink-rel">rel</a></code>  attribute whose value
> -       includes the<code title="rel-bookmark"><a href="#link-type-bookmark">bookmark</a></code>
> -       keyword</dt>
> -
> -<dd>Let<var title="">id</var>  be the<a href="#absolute-url">absolute URL</a>
> -       resulting from<a href="#resolve-a-url" title="resolve a url">resolving</a>  the
> -       value of the<code title="attr-hyperlink-href"><a href="#attr-hyperlink-href">href</a></code>
> -       attribute of the first such<code><a href="#the-a-element">a</a></code>  or<code><a href="#the-area-element">area</a></code>
> -       element, relative to the element. Let<var title="">has-alternate</var>  be true.</dd>
> -
> -<dt>If the<var title="">article</var>  node has an<code title="attr-id"><a href="#the-id-attribute">id</a></code>  attribute</dt>
> -
> -<dd>Let<var title="">id</var>  be<a href="#the-document-s-current-address">the document's current
> -       address</a>, with the fragment identifier (if any) removed,
> -       and with a new fragment identifier specified, consisting of the
> -       value of the<var title="">article</var>  element's<code title="attr-id"><a href="#the-id-attribute">id</a></code>  attribute. Let<var title="">has-alternate</var>  be false.</dd>
> -
> -<dt>Otherwise</dt>
> -
> -<dd>Let<var title="">id</var>  be a user-agent-defined
> -       undereferenceable yet globally unique<a href="#valid-url" title="valid
> -       URL">valid</a>  <a href="#absolute-url">absolute URL</a>. The same
> -<a href="#absolute-url">absolute URL</a>  should be generated for each run of
> -       this algorithm when given the same input. Let<var title="">has-alternate</var>  be false.</dd>
> -
> -</dl></li>
> -
> -<li>
> -
> -<p>Append an<code title="">id</code>  element in the<a href="#atom-namespace">Atom
> -      namespace</a>  to<var title="">E</var>  whose contents is a
> -      text node with its data set to<var title="">id</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If<var title="">has-alternate</var>  is true: Let<var title="">x</var>  be a<code title="">link</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>. Add a<code title="">rel</code>
> -      attribute whose value is the string "<code title="">alternate</code>" to<var title="">x</var>. Append a
> -      text node with its data set to<var title="">id</var>  to<var title="">x</var>. Append<var title="">x</var>  to<var title="">E</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If<var title="">article</var>  has a<code><a href="#the-time-element">time</a></code>
> -      element descendant that has a<code title="attr-time-pubdate"><a href="#attr-time-pubdate">pubdate</a></code>  attribute and whose
> -      nearest ancestor<code><a href="#the-article-element">article</a></code>  element is<var title="">article</var>, and the first such element's<a href="#concept-time-date" title="concept-time-date">date</a>  is not unknown, then run
> -      the following substeps, with<var title="">e</var>  being the
> -      first such element:</p>
> -
> -<ol><li><p>Let<var title="">datetime</var>  be a<a href="#concept-datetime" title="concept-datetime">global date and time</a>  whose date
> -       component is the<a href="#concept-time-date" title="concept-time-date">date</a>  of
> -<var title="">e</var>.</li>
> -
> -<li><p>If<var title="">e</var>'s<a href="#concept-time-time" title="concept-time-time">time</a>  and<a href="#concept-time-timezone" title="concept-time-timezone">time-zone offset</a>  are not
> -       unknown, then let<var title="">datetime</var>'s time and
> -       time-zone offset components be the<a href="#concept-time-time" title="concept-time-time">time</a>  and<a href="#concept-time-timezone" title="concept-time-timezone">time-zone offset</a>  of<var title="">e</var>. Otherwise, let them be midnight and no offset
> -       respectively ("<code title="">00:00Z</code>").</li>
> -
> -<li><p>Let<var title="">publication date</var>  be the
> -<a href="#best-representation-of-the-global-date-and-time-string">best representation of the global date and time
> -       string</a>  <var title="">datetime</var>.</li>
> -
> -</ol><p>Otherwise, let<var title="">publication date</var>  have no
> -      value.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If<var title="">update date</var>  has no value but<var title="">publication date</var>  does, then let<var title="">update date</var>  have the value of<var title="">publication date</var>.</p>
> -
> -<p>Otherwise, if<var title="">publication date</var>  has no
> -      value but<var title="">update date</var>  does, then let<var title="">publication date</var>  have the value of<var title="">update date</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If<var title="">update date</var>  has a value, and<var title="">global update date</var>  has no value or is less recent
> -      than<var title="">update date</var>, then let<var title="">global update date</var>  have the value of<var title="">update date</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>If<var title="">publication date</var>  and<var title="">update date</var>  both still have no value, then let
> -      them both value a value that is a<a href="#valid-global-date-and-time-string">valid global date and
> -      time string</a>  representing the<a href="#concept-datetime" title="concept-datetime">global date and time</a>  of the
> -      moment that this algorithm was invoked.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>Append an<code title="">published</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>  to<var title="">E</var>  whose
> -      contents is a text node with its data set to<var title="">publication date</var>.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>Append an<code title="">updated</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>  to<var title="">E</var>  whose
> -      contents is a text node with its data set to<var title="">update date</var>.</p>
> -
> -</li>
> -
> -</ol></li>
> -
> -<li>
> -
> -<p>If<var title="">global update date</var>  has no value, then
> -    let it have a value that is a<a href="#valid-global-date-and-time-string">valid global date and time
> -    string</a>  representing the<a href="#concept-datetime" title="concept-datetime">global date and time</a>  of the date
> -    and time of the<code><a href="#document">Document</a></code>'s source file's last
> -    modification, if it is known, or else of the moment that this
> -    algorithm was invoked.</p>
> -
> -</li>
> -
> -<li>
> -
> -<p>Insert an<code title="">updated</code>  element in the
> -<a href="#atom-namespace">Atom namespace</a>  into the root element of<var title="">R</var>  before the first<code title="">entry</code>  in
> -    the<a href="#atom-namespace">Atom namespace</a>  whose contents is a text node with
> -    its data set to<var title="">global update date</var>.</p>
> -
> -</li>
> -
> -<li><p>Return the Atom document<var title="">R</var>.</li>
> -
> -</ol><p class="note">The above algorithm does not guarantee that the
> -  output will be a conforming Atom feed. In particular, if
> -  insufficient information is provided in the document (e.g. if the
> -  document does not have any<code title="">&lt;meta name="author"
> -  content="..."&gt;</code>  elements), then the output will not be
> -  conforming.</p>
> -
> -<p>The<dfn id="atom-namespace">Atom namespace</dfn>  is:<code>http://www.w3.org/2005/Atom</code></p>
> -
> -
>
>     </div><h2 id="browsers"><span class="secno">5</span>Loading Web pages</h2><p class="XXX annotation"><b>Status:</b><i>Last call for comments</i><div class="impl">
>
> @@ -67614,10 +67161,6 @@
>      <dd>(Non-normative)<cite>Inter Gravissimas</cite>, A. Lilius,
>      C. Clavius. Gregory XIII Papal Bulls, February 1582.</dd>
>
> -<dt id="refsHATOM">[HATOM]</dt>
> -<dd>(Non-normative)<cite><a href="http://microformats.org/wiki/hatom">hAtom</a></cite>, D
> -   Janes. Microformats.</dd>
> -
>      <dt id="refsHTMLDIFF">[HTMLDIFF]</dt>
>      <!--
>      <dd>(Non-normative)<cite><a
>


From emoller at opera.com  Tue Jun  1 23:34:49 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Wed, 02 Jun 2010 08:34:49 +0200
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTinviwOMk1-LAkzv9Kp-c8qqTJs4Heqjbo2SXAgC@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net>
	<AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com>
	<AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com>
	<AANLkTinviwOMk1-LAkzv9Kp-c8qqTJs4Heqjbo2SXAgC@mail.gmail.com>
Message-ID: <op.vdntwbfmr4mipi@emoller-pc.gothenburg.osa>

On Wed, 02 Jun 2010 00:34:17 +0200, James Salsman <jsalsman at gmail.com>  
wrote:


> Nothing about UDP is reliable, you just send packets and hope they get  
> there.
>
>> -Automatic keep-alives
>
> You mean on the incoming-to-client TCP channel in the opposite
> direction from the UDP traffic?
>
>> -Reliable close handshake
>
> Can we use REST/HTTP/HTTPS persistent connections for this?
>
>> -Socket is bound to one address for the duration of its lifetime
>
> That sounds reasonable, but clients do change IP addresses now and
> then, so maybe there should be some anticipation of this possibility?
>
>> -Sockets open sequentially (like current DOS protection in WebSockets)
>
> Do you mean their sequence numbers should be strictly increasing
> incrementally until they roll over?
>
>> -Cap on number of open sockets per server and total per user agent
>
> There was some discussion that people rarely check for the error
> condition when such caps are exausted, so I'm not sure whether that
> should be the same as the system cap, or some fraction, or dozens, or
> a developer configuration parameter.
>

No it can't be UDP, it'll have to be something layered on top of UDP. One  
of the game guys I spoke to last night said "Honestly, I wish we just had  
real sockets.  It always seems like web coding comes down to reinventing a  
very old wheel in a far less convenient or efficient manner." To some  
extent I agree with him, but there's the security aspect we have to take  
into account or we'll see someone hacking the CNN website and injecting a  
little javascript and we'll have the DDOS attack of the century on our  
hands.

The reason I put down "Socket is bound to one address", "Reliable  
handshake", "Reliable close handshake" and "Sockets open sequentially" was  
for that exact reason, to try to make it "DOS and tamper safe". The  
"Sockets open sequentially" means that if you allocate two sockets to the  
same server the second socket will wait for the first one to complete its  
handshake before attempting to connect.

The cap on the number of connections is probably less important, but  
browser vendors will likely want to have some sort of limit in place  
before it completely starves the OS of resources.

-- 
Erik M?ller
Core Developer
Opera Software

From ben.garney at gmail.com  Tue Jun  1 23:41:53 2010
From: ben.garney at gmail.com (Ben Garney)
Date: Tue, 1 Jun 2010 23:41:53 -0700
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <op.vdntwbfmr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<5EFBABCC-E71F-42BD-9E6E-52841653D265@geekhood.net> 
	<AANLkTiksW60dV7ScDoWjTXBkahySqf9NdL7pc0UzaREn@mail.gmail.com> 
	<AANLkTilXmummiL5I0kJYr0abQJA7oyuU7jmWrQHcTDru@mail.gmail.com> 
	<AANLkTinviwOMk1-LAkzv9Kp-c8qqTJs4Heqjbo2SXAgC@mail.gmail.com> 
	<op.vdntwbfmr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTink61lU2xUZdOuuimks0YRaJcf7vnB7tsgvxJdt@mail.gmail.com>

On Tue, Jun 1, 2010 at 11:34 PM, Erik M?ller <emoller at opera.com> wrote:

>
> No it can't be UDP, it'll have to be something layered on top of UDP. One
> of the game guys I spoke to last night said "Honestly, I wish we just had
> real sockets.  It always seems like web coding comes down to reinventing a
> very old wheel in a far less convenient or efficient manner." To


To be clear, for games, the key win is the lossy delivery. That is what
enables the game to make intelligent decisions about dealing with packet
loss, out of order delivery, etc.

There's actually someone who has already deployed a wide-scale UDP p2p
negotiated connection architecture. Adobe launched their Stratus technology
in 2008: http://labs.adobe.com/technologies/stratus/

The downside is they do not expose lossy message delivery to Player content,
it's only used for audio/video delivery.

However something like this that did expose lossy message delivery would be
very handy! A lot of interesting applications could be built mostly
independently of server, saving a lot of scalability pain.

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100601/607decba/attachment.htm>

From emoller at opera.com  Wed Jun  2 01:47:57 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Wed, 02 Jun 2010 10:47:57 +0200
Subject: [whatwg] [hybi]  WebSockets: UDP
In-Reply-To: <AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com>
Message-ID: <op.vdnz17bsr4mipi@emoller-pc.gothenburg.osa>

On Wed, 02 Jun 2010 01:07:48 +0200, Mark Frohnmayer  
<mark.frohnmayer at gmail.com> wrote:

> Glad to see this discussion rolling!  For what it's worth, the Torque
> Sockets design effort was to take a stab at answering this question --
> what is the least-common-denominator "webby" API/protocol that's
> sufficiently useful to be a common foundation for real time games.  I
> did the first stab at porting OpenTNL (now tnl2) atop it; from my
> reading of the RTP protocol that should easily layer as well, but it
> would be worth getting the perspective of some other high-level
> network stack folks (RakNet, etc).

For those who missed Mark's initial post on the subject his TorqueSocket  
API can be found here:
http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt

Perhaps we could communally have a look at how this compares to other  
common network libraries to find a least common denominator of  
functionality?


> Only feedback here would be I think p2p should be looked at in this
> pass -- many client/server game instances are peers from the
> perspective of the hosting service (XBox Live, Quake, Half-Life,
> Battle.net) -- forcing all game traffic to pass through the hosting
> domain is a severe constraint.  My question -- what does a "webby" p2p
> solution look like regarding Origin restrictions, etc?

Although it sure complicates things I don't see why WebSockets couldn't be  
extended to allow peer-to-peer connections if we really wanted to.
User agent A and B connects to WebSocket server C who keeps a list of  
clients connected to it. A and B are informed of the id's of connected  
clients and both decide to set up a peer-to-peer connection. A and B  
simultaneously call socket.connect_to_peer() passing a peer id and the  
call returns a new WebSocket in connecting mode. The user agents  
communicate with the server over the server-socket, retrieves the  
necessary information to connect to the peer including what origin to  
expect and off we go. (Server implementations would of course be free to  
not support this if they choose)
As long as the usual DOS/tamper protection is there it should be  
possible... then there's the success rate of UDP NAT hole punching...

-- 
Erik M?ller
Core Developer
Opera Software

From vetesnik at mrmil.cz  Wed Jun  2 03:51:43 2010
From: vetesnik at mrmil.cz (=?iso-8859-2?B?T2xk+GljaCBWZXRluW7taw==?=)
Date: Wed, 02 Jun 2010 12:51:43 +0200
Subject: [whatwg] Why there is no wrap="off", intentional or forgotten?
Message-ID: <op.vdn5shx5o84pey@pc08.ebrana.cz>

Hi,

I'm missing the wrap="off" value for textarea wrap attribute; is there any  
particular reason why this is not part of HTML5?
Currently the only values mentioned are "soft" and "hard":

http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap

"The wrap attribute is an enumerated attribute with two keywords and  
states: the soft keyword which maps to the Soft state, and the hard  
keyword which maps to the Hard state. The missing value default is the  
Soft state."

However, I'd like to use wrap=off because I don't want the lines to wrap.  
(Like when you have a HTML in textarea.)
I haven't found any other way to "force" this behavior (yep, I tried  
white-space: nowrap;).
I tested it in all major browsers on Windows and it works, it just won't  
validate. :)

Code
<textarea cols=50 rows=10 wrap=soft></textarea>
<textarea cols=50 rows=10 wrap=hard></textarea>
<textarea cols=50 rows=10 wrap=off></textarea>
More at http://server.ebrana.cz/olda/_apps/html5/textarea-wrap.html

There is also no mention in the spec about wrap=virtual and wrap=physical  
back from the days.
http://www.htmlcodetutorial.com/forms/_TEXTAREA_WRAP.html

Thanks,
Ollie

From ash at ashleysheridan.co.uk  Wed Jun  2 04:05:37 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Wed, 02 Jun 2010 12:05:37 +0100
Subject: [whatwg] Why there is no wrap="off", intentional or forgotten?
In-Reply-To: <op.vdn5shx5o84pey@pc08.ebrana.cz>
References: <op.vdn5shx5o84pey@pc08.ebrana.cz>
Message-ID: <1275476737.2933.83.camel@localhost>

On Wed, 2010-06-02 at 12:51 +0200, Old?ich Vete?n?k wrote:

> Hi,
> 
> I'm missing the wrap="off" value for textarea wrap attribute; is there any  
> particular reason why this is not part of HTML5?
> Currently the only values mentioned are "soft" and "hard":
> 
> http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap
> 
> "The wrap attribute is an enumerated attribute with two keywords and  
> states: the soft keyword which maps to the Soft state, and the hard  
> keyword which maps to the Hard state. The missing value default is the  
> Soft state."
> 
> However, I'd like to use wrap=off because I don't want the lines to wrap.  
> (Like when you have a HTML in textarea.)
> I haven't found any other way to "force" this behavior (yep, I tried  
> white-space: nowrap;).
> I tested it in all major browsers on Windows and it works, it just won't  
> validate. :)
> 
> Code
> <textarea cols=50 rows=10 wrap=soft></textarea>
> <textarea cols=50 rows=10 wrap=hard></textarea>
> <textarea cols=50 rows=10 wrap=off></textarea>
> More at http://server.ebrana.cz/olda/_apps/html5/textarea-wrap.html
> 
> There is also no mention in the spec about wrap=virtual and wrap=physical  
> back from the days.
> http://www.htmlcodetutorial.com/forms/_TEXTAREA_WRAP.html
> 
> Thanks,
> Ollie


That does seem odd. I would have thought the default value would be
'off' or 'no' as I've never seen a browser yet wrap text in a textarea
unless a specific wrapping method was specified either via an attribute
or CSS.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From vetesnik at mrmil.cz  Wed Jun  2 04:23:20 2010
From: vetesnik at mrmil.cz (=?iso-8859-2?B?T2xk+GljaCBWZXRluW7taw==?=)
Date: Wed, 02 Jun 2010 13:23:20 +0200
Subject: [whatwg] Why there is no wrap="off", intentional or forgotten?
In-Reply-To: <1275476737.2933.83.camel@localhost>
References: <op.vdn5shx5o84pey@pc08.ebrana.cz>
	<1275476737.2933.83.camel@localhost>
Message-ID: <op.vdn686wbo84pey@pc08.ebrana.cz>

Dne Wed, 02 Jun 2010 13:05:37 +0200 Ashley Sheridan  
<ash at ashleysheridan.co.uk> napsal(a):

> That does seem odd. I would have thought the default value would be
> 'off' or 'no' as I've never seen a browser yet wrap text in a textarea
> unless a specific wrapping method was specified either via an attribute
> or CSS.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk

By default it wraps, otherwise you would end up with with a horizontal  
scroll bar. If only resize: both; worked in all browsers and not just  
webkit :).

Ollie

From pedzsan at gmail.com  Wed Jun  2 04:31:28 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Wed, 2 Jun 2010 06:31:28 -0500
Subject: [whatwg] "entry script"
Message-ID: <7E4DFDD5-C9CC-4E90-98A2-80D93C1FD409@gmail.com>

Sorry for the repeat message...  But "entry script" is a rather fundamental concept in web workers and its not defined as far as I can tell.  Can someone tell me where and how its defined?

I don't see how "entry script" is set, when it is set, or what it is set to.  "Initially, there is no entry script". [1]

Can someone help me out?

[1] http://dev.w3.org/html5/spec/browsers.html#entry-script

Thanks,
Perry
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems


From simonp at opera.com  Wed Jun  2 06:08:56 2010
From: simonp at opera.com (Simon Pieters)
Date: Wed, 02 Jun 2010 15:08:56 +0200
Subject: [whatwg] "entry script"
In-Reply-To: <7E4DFDD5-C9CC-4E90-98A2-80D93C1FD409@gmail.com>
References: <7E4DFDD5-C9CC-4E90-98A2-80D93C1FD409@gmail.com>
Message-ID: <op.vdob43q7idj3kv@simon-pieterss-macbook.local>

On Wed, 02 Jun 2010 13:31:28 +0200, Perry Smith <pedzsan at gmail.com> wrote:

> Sorry for the repeat message...  But "entry script" is a rather  
> fundamental concept in web workers and its not defined as far as I can  
> tell.  Can someone tell me where and how its defined?
>
> I don't see how "entry script" is set, when it is set, or what it is set  
> to.  "Initially, there is no entry script". [1]
>
> Can someone help me out?
>
> [1] http://dev.w3.org/html5/spec/browsers.html#entry-script

See  
http://www.whatwg.org/specs/web-apps/current-work/complete/webappapis.html#calling-scripts

In particular, consider a script that document.write()s another <script>.

The spec should probably make this clearer at the definition of 'entry  
script'.

HTH,
-- 
Simon Pieters
Opera Software

From lachlan.hunt at lachy.id.au  Wed Jun  2 07:10:39 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Wed, 02 Jun 2010 16:10:39 +0200
Subject: [whatwg] Why there is no wrap="off", intentional or forgotten?
In-Reply-To: <1275476737.2933.83.camel@localhost>
References: <op.vdn5shx5o84pey@pc08.ebrana.cz>
	<1275476737.2933.83.camel@localhost>
Message-ID: <4C06665F.6030205@lachy.id.au>

On 2010-06-02 13:05, Ashley Sheridan wrote:
> On Wed, 2010-06-02 at 12:51 +0200, Old?ich Vete?n?k wrote:
>> I'm missing the wrap="off" value for textarea wrap attribute; is there any
>> particular reason why this is not part of HTML5?
>> Currently the only values mentioned are "soft" and "hard":
>>
>> http://dev.w3.org/html5/spec/the-button-element.html#attr-textarea-wrap

The explanation is here.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html

In theory, you can achieve the same effect by using CSS.

textarea { white-space: nowrap; }

This works fine in Opera, WebKit and IE.  Doesn't work in Gecko though.

> That does seem odd. I would have thought the default value would be
> 'off' or 'no' as I've never seen a browser yet wrap text in a textarea
> unless a specific wrapping method was specified either via an attribute
> or CSS.

Netscape 4 was the last browser I'm aware of that defaulted to that 
wrap=off behaviour.  I believe every other mainstream browser I'm aware 
of since then wraps by default.

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

From excors+whatwg at gmail.com  Wed Jun  2 10:48:05 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 2 Jun 2010 18:48:05 +0100
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>

On Tue, Jun 1, 2010 at 9:02 PM, Erik M?ller <emoller at opera.com> wrote:
> On Tue, 01 Jun 2010 21:14:33 +0200, Philip Taylor <excors+whatwg at gmail.com>
> wrote:
>
>> More feedback is certainly good, though I think the libraries I
>> mentioned (DirectPlay/OpenTNL/RakNet/ENet (there's probably more)) are
>> useful as an indicator of common real needs (as opposed to edge-case
>> or merely perceived needs) - they've been used by quite a few games
>> and they seem to have largely converged on a core set of features, so
>> that's better than just guessing.
>>
>> I guess many commercial games write their own instead of reusing
>> third-party libraries, and I guess they often reimplement very similar
>> concepts to these, but it would be good to have more reliable
>> information about that.
>>
>
> I was hoping to be able to avoid looking at what the interfaces of a high vs
> low level option would look like this early on in the discussions, but
> perhaps we need to do just that; look at Torque, RakNet etc and find a least
> common denominator and see what the reactions would be to such an interface.

I'm trying to think of them mainly as indirect examples of use cases,
rather than as direct examples of interfaces. Under the assumption
that most games either use a library like these or implement a
comparable one themselves, and that the library designs are driven by
the game requirements, if a feature is supported by most of the
libraries then it's probably needed by many games; and if a feature is
unsupported in many of the libraries then it's probably unnecessary
for most games. (Also an assumption: games running in web browsers
will have similar needs to native games (though lagging many years
behind state-of-the-art); and we only ought to aim to support the
needs of most games, not all games.)

So they seem to suggest things like:
- many games need a combination of reliable and unreliable-ordered and
unreliable-unordered messages.
- many games need to send large messages (so the libraries do
automatic fragmentation).
- many games need to efficiently send tiny messages (so the libraries
do automatic aggregation).
- many games need some kind of security (I have no idea exactly what,
or how much is still relevant when the client is JavaScript and
trivial to tamper with).
- many games need to prioritise certain messages when bandwidth is limited.
- most games don't need low-level control over individual datagrams
and precise packet loss feedback, they're okay with the socket details
being abstracted away.
- ... probably lots more (and/or less); I'm not very familiar with the
details of the libraries so this is unlikely to be an accurate list,
but I think it may be a useful way to analyse the requirements.

(The solution suggested in your initial post
(socket.send(data_smaller_than_mtu) going over UDP) seems to be one
extreme, which combines with higher-level JS libraries to satisfy
these needs. I think I initially suggested the other extreme of
encoding all the features into the browser API. I guess the best
tradeoff depends largely on what non-game use cases exist that should
be satisfied by the same solution.)

> So, what would the minimal set of limitations be to make a "UDP WebSocket"
> browser-safe?
>
> -No listen sockets
> -No multicast
> -Reliable handshake with origin info
> -Automatic keep-alives
> -Reliable close handshake
> -Socket is bound to one address for the duration of its lifetime
> -Sockets open sequentially (like current DOS protection in WebSockets)
> -Cap on number of open sockets per server and total per user agent

Perhaps also:
- Cap or dynamic limit on bandwidth (you don't want a single web page
flooding the user's network connection and starving all the TCP
connections)
- Protection against session hijacking
- Protection against an attacker initiating a legitimate socket with a
user and then redirecting it (with some kind of IP (un)hijacking) to a
service behind the user's firewall (which isn't a problem when using
TCP since the service will ignore packets when it hasn't done the TCP
handshake; but UDP services might respond to a single packet from the
middle of a websocket stream, so every single packet will have to be
careful not to be misinterpreted dangerously by unsuspecting
services).

-- 
Philip Taylor
excors at gmail.com

From ben.garney at gmail.com  Wed Jun  2 11:35:21 2010
From: ben.garney at gmail.com (Ben Garney)
Date: Wed, 2 Jun 2010 11:35:21 -0700
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> 
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> 
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
Message-ID: <AANLkTiklP3JEyhOmmHPRx-sTKxfblPP0j69UQ9dRwkU_@mail.gmail.com>

On Wed, Jun 2, 2010 at 10:48 AM, Philip Taylor
<excors+whatwg at gmail.com<excors%2Bwhatwg at gmail.com>
> wrote:

>
> I'm trying to think of them mainly as indirect examples of use cases,
> rather than as direct examples of interfaces. Under the assumption
>

This is a very valid approach. (Note that most serious games do not use
DirectPlay and it has not been updated by Microsoft in a while, so don't
burn a lot of braincells on it.)

Games always do weird stuff, focus on what will enable the 80% case and not
break the web! :)

Some thoughts point by point:

So they seem to suggest things like:
> - many games need a combination of reliable and unreliable-ordered and
> unreliable-unordered messages.
>

Yes. But if you unreliable-unordered you can build the rest pretty easily.


> - many games need to send large messages (so the libraries do
> automatic fragmentation).
>

Yes. But many engines do fragmentation more explicitly, since they don't
spend a lot of time dealing with TCP streams. (The usual case is transfer of
asset files over the network connection, for instance, if a client doesn't
have a texture. I suspect for a JS app using UDP this would not be an issue,
they could just ask the web server.)


> - many games need to efficiently send tiny messages (so the libraries
> do automatic aggregation).
>

Sort of. The common cases are most-recent state and message queues. Mostly
they define a packet format and have smart logic for incrementally sending
the most relevant state in each packet.


> - many games need some kind of security (I have no idea exactly what,
> or how much is still relevant when the client is JavaScript and
> trivial to tamper with).
>

What is relevant for this discussion is to prevent man in the middle and DoS
activities. (Smart) game devs always assume the client is compromised - same
as smart web devs. :)


> - many games need to prioritise certain messages when bandwidth is limited.
>

See the aggregation comment. Also, games typically assume bandwidth is
limited - they will target and operate within a fixed bandwidth budget and
often a fixed packet rate. Say, 10 500 byte packets per second. This is
beneficial for many reasons, but primarily it is good because it optimizes
for realtime interaction. For some situations you will want fixed rate, for
others you want to have adaptive rate. (For instance, talking to a game
server in Counterstrike vs. playing an MMO.)


> - most games don't need low-level control over individual datagrams
> and precise packet loss feedback, they're okay with the socket details
> being abstracted away.
>

Disagree, for good networking you need to know about packet delivery state
at quite high levels of the game simulation.


> - ... probably lots more (and/or less); I'm not very familiar with the
> details of the libraries so this is unlikely to be an accurate list,
> but I think it may be a useful way to analyse the requirements.
>

I think you got the major points. (Even though I don't necessarily agree
with all of your conclusions. :))


>
> (The solution suggested in your initial post
> (socket.send(data_smaller_than_mtu) going over UDP) seems to be one
> extreme, which combines with higher-level JS libraries to satisfy
> these needs. I think I initially suggested the other extreme of
> encoding all the features into the browser API. I guess the best
> tradeoff depends largely on what non-game use cases exist that should
> be satisfied by the same solution.)
>

I think the best layer to provide is a notify protocol. That is, provide a
way to send lossy, smaller-than-MTU messages over a connection in realtime,
and notify the dev when a packet has made it (or hasn't). This way the
browser can provide a connection abstraction, which deals with the
DoS/security/origin issues. (For instance, two obvious pieces are connection
puzzles to prevent DoS, and PKI signing to prevent tampering with data. The
browser can also support arranged connections for the p2p case.)

It also keeps the interoperability manageable. Servers have a specific,
fairly small protocol to implement, and can provide some or all of a small
set of features. (For instance, caps might be: basic protocol support,
secure connections, arranged connections.) Beyond that it is application
specific blobs of small size (under a few kb).


All that said, I think looking at the notify protocol in TNL is a good
baseline. On that you can pretty easily implement every game scenario I can
think of. You can reuse a lot of the TCP connection security semantics, too,
since it is a connection - just one with lossy delivery.

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

From bzbarsky at MIT.EDU  Wed Jun  2 13:25:51 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 02 Jun 2010 16:25:51 -0400
Subject: [whatwg] Why there is no wrap="off", intentional or forgotten?
In-Reply-To: <4C06665F.6030205@lachy.id.au>
References: <op.vdn5shx5o84pey@pc08.ebrana.cz>	<1275476737.2933.83.camel@localhost>
	<4C06665F.6030205@lachy.id.au>
Message-ID: <4C06BE4F.8070301@mit.edu>

On 6/2/10 10:10 AM, Lachlan Hunt wrote:
> In theory, you can achieve the same effect by using CSS.
>
> textarea { white-space: nowrap; }
>
> This works fine in Opera, WebKit and IE. Doesn't work in Gecko though.

That would be because nothing defines the interaction of CSS with the 
contents of replaced elements (which textarea happens to be in at least 
Gecko, and probably all browsers).  In particular, Gecko's 
implementation actually has a box inside the textarea that has 
white-space styles applied to it based on the textarea's "wrap" attribute.

If you think that the above style should do something to <textarea>, 
then the HTML spec needs to explicitly say so, since it's what defines 
how the inside of a textarea is rendered, not CSS per se.

-Boris

From emoller at opera.com  Wed Jun  2 23:28:41 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Thu, 03 Jun 2010 08:28:41 +0200
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
Message-ID: <op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>

On Wed, 02 Jun 2010 19:48:05 +0200, Philip Taylor  
<excors+whatwg at gmail.com> wrote:

I'm glad the discussion on this has taken off a bit. I've spoken to a few  
more game devs and even though it's still relatively few there's a slight  
majority that prefer the interface to be at the "Torque/RakNet-level"  
rather than at the "UDP-socket-wrapper-level". I'm hoping I can talk a few  
of them into joining the list and taking a more active part in the  
discussions.

> So they seem to suggest things like:
> - many games need a combination of reliable and unreliable-ordered and
> unreliable-unordered messages.

One thing to remember here is that browsers have other means for  
communication as well. I'm not saying we shouldn't support reliable  
messages over UDP, but just pointing out the option. I believe for example  
World of Warcraft uses this strategy and sends reliable traffic over TCP  
while movement and other real-time data goes over UDP.

> - many games need to send large messages (so the libraries do
> automatic fragmentation).

Again, this is probably because games have no other means of communication  
than the NW-library. I'd think these large reliable messages would mostly  
be files that need to be transferred asynchronously for which browsers  
already have the tried and tested XMLHttpRequest.

> - many games need to efficiently send tiny messages (so the libraries
> do automatic aggregation).

This is probably true for many other use-cases than games, but at least in  
my experience games typically use a bit-packer or range-coder to build the  
complete packet that needs to be sent. But again, it's a matter of what  
level you want to place the interface.

> Perhaps also:
> - Cap or dynamic limit on bandwidth (you don't want a single web page
> flooding the user's network connection and starving all the TCP
> connections)
> - Protection against session hijacking

Great

> - Protection against an attacker initiating a legitimate socket with a
> user and then redirecting it (with some kind of IP (un)hijacking) to a
> service behind the user's firewall (which isn't a problem when using
> TCP since the service will ignore packets when it hasn't done the TCP
> handshake; but UDP services might respond to a single packet from the
> middle of a websocket stream, so every single packet will have to be
> careful not to be misinterpreted dangerously by unsuspecting
> services).

I don't quite follow what you mean here. Can you expand on this with an  
example?

-- 
Erik M?ller
Core Developer
Opera Software

From daniel.glazman at disruptive-innovations.com  Thu Jun  3 06:01:29 2010
From: daniel.glazman at disruptive-innovations.com (Daniel Glazman)
Date: Thu, 03 Jun 2010 15:01:29 +0200
Subject: [whatwg] Comment on 6.6 Offline Web Applications
Message-ID: <4C07A7A9.3040303@disruptive-innovations.com>

Hi there,

I noticed the Application Cache does not allow to remove
a single cached web application from the cache. Is that on
purpose?
I am under the impression the cache is here more an offline
storage for webapps than a normal cache, and that in the long
run browsers will have to implement an "Offline Web Apps" manager.
Since the user is supposedly already provided with a dialog
asking permission to make a webapp available offline, it makes
sense to give him/her a way to remove a single application from
the cache.

</Daniel>

From simonp at opera.com  Thu Jun  3 06:46:14 2010
From: simonp at opera.com (Simon Pieters)
Date: Thu, 03 Jun 2010 15:46:14 +0200
Subject: [whatwg] WebSocket set-cookie
In-Reply-To: <op.vccaoocoidj3kv@dyn105.gothenburg.osa>
References: <op.vccaoocoidj3kv@dyn105.gothenburg.osa>
Message-ID: <op.vdp8jc07idj3kv@simon-pieterss-macbook.local>

On Fri, 07 May 2010 16:32:38 +0200, Simon Pieters <simonp at opera.com> wrote:

> establish a WebSocket connection
>
> [[
> 41. ...
>
> If the entry's name is "set-cookie" or "set-cookie2" or another  
> cookie-related field name
> If the relevant specification is supported by the user agent, handle the  
> cookie as defined by the appropriate specification, with the resource  
> being the one with the host host, the port port, the path (and possibly  
> query parameters) resource name, and the scheme http if secure is false  
> and https if secure is true. [COOKIES]
>
> If the relevant specification is not supported by the user agent, then  
> the field must be ignored.
> ]]
>
> At this point, the handshake can still fail. It seems bad to set cookies  
> if the handshake fails. We want to process set-cookie when the handshake  
> has succeeded (but before changing readyState and firing 'open').

...but still in that same task that changes readyState and fires 'open'.

-- 
Simon Pieters
Opera Software

From excors+whatwg at gmail.com  Thu Jun  3 07:18:23 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Thu, 3 Jun 2010 15:18:23 +0100
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTinbZOM-95txMblbUC9c8h1sElJ90XvBHmt58786@mail.gmail.com>

On Thu, Jun 3, 2010 at 7:28 AM, Erik M?ller <emoller at opera.com> wrote:
> [...]
> One thing to remember here is that browsers have other means for
> communication as well. I'm not saying we shouldn't support reliable messages
> over UDP, but just pointing out the option.

Yep - the relevant use cases ought to be supported decently by the
platform, but not necessarily by this extension to the platform (it
might be a different extension or it might be (probably is) supported
already).

>> - Protection against an attacker initiating a legitimate socket with a
>> user and then redirecting it (with some kind of IP (un)hijacking) to a
>> service behind the user's firewall (which isn't a problem when using
>> TCP since the service will ignore packets when it hasn't done the TCP
>> handshake; but UDP services might respond to a single packet from the
>> middle of a websocket stream, so every single packet will have to be
>> careful not to be misinterpreted dangerously by unsuspecting
>> services).
>
> I don't quite follow what you mean here. Can you expand on this with an
> example?

I was thinking something like: A host at IP 11.11.11.11 on the public
internet runs some UDP service, like DNS or TFTP or something a bit
more secure. That service is restricted so it only responds to packets
received from IP 22.22.22.22 (a trusted user). The UDP Web Socket
handshake is carefully constructed so that it won't trigger dangerous
behaviour in any of those services (like how the TCP Web Socket uses a
safe HTTP-ish handshake).

An attacker hijacks the IP 11.11.11.11 from the perspective of the
user (by advertising new routes near the user), so the user's packets
to that address go to the attacker. The attacker gets the user to
visit a web page which sets up a UDP Web Socket with the attacker's
server at 11.11.11.11, doing all the handshake authentication
correctly.

The attacker then releases its hijacked address, so any subsequent Web
Socket packets will go to the original restricted service. Since
they're being received from the trusted user, the service will trust
them. Since the web browser has already done the Socket handshake, it
will believe it's talking to a legitimate Web Socket server and will
continue sending whatever data packets the attacker's script tells it
to.

The service will then be receiving and responding to
attacker-controlled packets, and will never have seen the carefully
constructed handshake that's designed to protect it. That's not a
danger for TCP services since they'll reject unexpected packets from
the middle of a TCP stream, but UDP services may accept packets from
the middle of a UDP Web Socket stream.

So it's not sufficient to carefully construct the Web Socket handshake
packets to not trigger unwanted behaviour in non-Socket services.
Every data packet sent on the Socket has to be carefully constructed
too.

(This might be a largely impractical or pointless attack, and there's
probably much easier ways to attack the exposed service, but I don't
know enough about security to judge that. Also I don't know what
packet construction would be sufficiently careful. But it seems like a
possible new concern that's introduced when using UDP in this
context.)

-- 
Philip Taylor
excors at gmail.com

From tkent at chromium.org  Thu Jun  3 08:16:00 2010
From: tkent at chromium.org (TAMURA, Kent)
Date: Fri, 4 Jun 2010 00:16:00 +0900
Subject: [whatwg] Form validation against invisible controls
Message-ID: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>



> > An element is a "candidate for constraint validation" if
> > 1. it is a validatable type,
> >    e.g. true if <input type=number>, false if <input type=reset>
> > 2. has no "disabled" attribute,
> > 3. has no "readonly" attribute,
> > 4. inside of a <form> element,
> > 5. has non-empty "name" attribute, and
> > 6. not inside of a <datalist> element.
> >
> > I hope ValidityState and the pseudo classes ignores 2-6.

> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)


I'd like to propose to add another condition:
  7. it is visible (computed 'display' property of CSS isn't 'none' and no
'hidden' content attribute)

I couldn't find exceptional rules for validating invisible controls in the
current draft.
Chrome 5 was released with a part of interactive validation, and we received
a bug report about validation against invisible form controls.

-- 
TAMURA Kent
Software Engineer, Google



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

From jackalmage at gmail.com  Thu Jun  3 08:38:36 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 3 Jun 2010 08:38:36 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
Message-ID: <AANLkTimz50HzzB1ruPKA6VdV-1qYWHZ0gpi-ybZbmMII@mail.gmail.com>

On Thu, Jun 3, 2010 at 8:16 AM, TAMURA, Kent <tkent at chromium.org> wrote:
>> > An element is a "candidate for constraint validation" if
>> > 1. it is a validatable type,
>> > ? ?e.g. true if <input type=number>, false if <input type=reset>
>> > 2. has no "disabled" attribute,
>> > 3. has no "readonly" attribute,
>> > 4. inside of a <form> element,
>> > 5. has non-empty "name" attribute, and
>> > 6. not inside of a <datalist> element.
>> >
>> > I hope ValidityState and the pseudo classes ignores 2-6.
>>
>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)
>
> I'd like to propose to add another condition:
> ?7. it is visible (computed 'display' property of CSS isn't 'none' and no
> 'hidden' content attribute)
> I couldn't find exceptional rules for validating invisible controls in the
> current draft.
> Chrome 5 was released with a part of interactive validation, and we received
> a bug report about validation against invisible form controls.

Adding @hidden to the list of things that skip validation is good.
Adding display:none is not.  That's a big layering violation that we
authors have to suffer through with screen readers already.  I'd
greatly prefer not muddying the waters there.

~TJ

From joaoe at opera.com  Thu Jun  3 08:42:36 2010
From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=)
Date: Thu, 03 Jun 2010 16:42:36 +0100
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
Message-ID: <op.vdqdxasc2q99of@coruscant>

On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent <tkent at chromium.org>  
wrote:

>
>
>> > An element is a "candidate for constraint validation" if
>> > 1. it is a validatable type,
>> >    e.g. true if <input type=number>, false if <input type=reset>
>> > 2. has no "disabled" attribute,
>> > 3. has no "readonly" attribute,
>> > 4. inside of a <form> element,
>> > 5. has non-empty "name" attribute, and
>> > 6. not inside of a <datalist> element.
>> >
>> > I hope ValidityState and the pseudo classes ignores 2-6.
>
>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)
>
>
> I'd like to propose to add another condition:
>   7. it is visible (computed 'display' property of CSS isn't 'none' and  
> no
> 'hidden' content attribute)
>

You'd need to check the visibility or display also of all ancestors, that  
opacity is not 0, that the bounding box has enough size to render the form  
to the user and etc.
That's quite complicated to specify.

Would be easier to tell that user agents might chose to ignore form  
controls that they do not *paint* if that is possible for the UA to  
implement.


> I couldn't find exceptional rules for validating invisible controls in  
> the
> current draft.
> Chrome 5 was released with a part of interactive validation, and we  
> received
> a bug report about validation against invisible form controls.
>


From jackalmage at gmail.com  Thu Jun  3 08:54:44 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 3 Jun 2010 08:54:44 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <op.vdqdxasc2q99of@coruscant>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com> 
	<op.vdqdxasc2q99of@coruscant>
Message-ID: <AANLkTilIZVyj9lMed_NcJTwkn4cU0KX1KxDWXuzD_s5J@mail.gmail.com>

On Thu, Jun 3, 2010 at 8:42 AM, Jo?o Eiras <joaoe at opera.com> wrote:
> On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent <tkent at chromium.org> wrote:
>
>>
>>
>>> > An element is a "candidate for constraint validation" if
>>> > 1. it is a validatable type,
>>> > ? ?e.g. true if <input type=number>, false if <input type=reset>
>>> > 2. has no "disabled" attribute,
>>> > 3. has no "readonly" attribute,
>>> > 4. inside of a <form> element,
>>> > 5. has non-empty "name" attribute, and
>>> > 6. not inside of a <datalist> element.
>>> >
>>> > I hope ValidityState and the pseudo classes ignores 2-6.
>>
>>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)
>>
>>
>> I'd like to propose to add another condition:
>> ?7. it is visible (computed 'display' property of CSS isn't 'none' and no
>> 'hidden' content attribute)
>>
>
> You'd need to check the visibility or display also of all ancestors, that
> opacity is not 0, that the bounding box has enough size to render the form
> to the user and etc.
> That's quite complicated to specify.
>
> Would be easier to tell that user agents might chose to ignore form controls
> that they do not *paint* if that is possible for the UA to implement.

That's even worse - that defeats the time-honored trick to hide
something visually without hiding it in any other way of absolutely
positioning it off the screen.  It might even mean that elements
currently off the screen (but that can be scrolled to) wouldn't
validate.

~TJ

From ash at ashleysheridan.co.uk  Thu Jun  3 09:04:06 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Thu, 03 Jun 2010 17:04:06 +0100
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTilIZVyj9lMed_NcJTwkn4cU0KX1KxDWXuzD_s5J@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<op.vdqdxasc2q99of@coruscant>
	<AANLkTilIZVyj9lMed_NcJTwkn4cU0KX1KxDWXuzD_s5J@mail.gmail.com>
Message-ID: <1275581046.2217.24.camel@localhost>

On Thu, 2010-06-03 at 08:54 -0700, Tab Atkins Jr. wrote:

> On Thu, Jun 3, 2010 at 8:42 AM, Jo?o Eiras <joaoe at opera.com> wrote:
> > On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent <tkent at chromium.org> wrote:
> >
> >>
> >>
> >>> > An element is a "candidate for constraint validation" if
> >>> > 1. it is a validatable type,
> >>> >    e.g. true if <input type=number>, false if <input type=reset>
> >>> > 2. has no "disabled" attribute,
> >>> > 3. has no "readonly" attribute,
> >>> > 4. inside of a <form> element,
> >>> > 5. has non-empty "name" attribute, and
> >>> > 6. not inside of a <datalist> element.
> >>> >
> >>> > I hope ValidityState and the pseudo classes ignores 2-6.
> >>
> >>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)
> >>
> >>
> >> I'd like to propose to add another condition:
> >>  7. it is visible (computed 'display' property of CSS isn't 'none' and no
> >> 'hidden' content attribute)
> >>
> >
> > You'd need to check the visibility or display also of all ancestors, that
> > opacity is not 0, that the bounding box has enough size to render the form
> > to the user and etc.
> > That's quite complicated to specify.
> >
> > Would be easier to tell that user agents might chose to ignore form controls
> > that they do not *paint* if that is possible for the UA to implement.
> 
> That's even worse - that defeats the time-honored trick to hide
> something visually without hiding it in any other way of absolutely
> positioning it off the screen.  It might even mean that elements
> currently off the screen (but that can be scrolled to) wouldn't
> validate.
> 
> ~TJ


But we really shouldn't be positioning things 'off screen' anyway. You
should be considering people who aren't viewing the site through the
traditional computer & web browser. What about people who are using a
speech or Braille browser? What about search engines (most of which
specify in their terms that what you give them should equal the user
experience) and basically any service that legitimately scrapes content
(think web snippets, etc that some browsers are implementing)



Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From tkent at chromium.org  Thu Jun  3 09:11:46 2010
From: tkent at chromium.org (TAMURA, Kent)
Date: Fri, 4 Jun 2010 01:11:46 +0900
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
Message-ID: <AANLkTina1sAGNPs1F0VufYqRoefAKLKKImSrsbdShd27@mail.gmail.com>

Oh, I'm sorry.  I have found a sentence about visibility in the draft.

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
> If one of the controls is not being  
> rendered<rendering.html#being-rendered>
  (e.g. it has the hidden <editing.html#the-hidden-attribute> attribute set)
then user agents may report a script error.

This sentence is about process against controls of which validation result
is invalid.
I think UA doesn't need to validate such controls.


The Chrome bug report is here:
http://code.google.com/p/chromium/issues/detail?id=45640

2010/6/4 TAMURA, Kent <tkent at chromium.org>

> > An element is a "candidate for constraint validation" if
>> > 1. it is a validatable type,
>> >    e.g. true if <input type=number>, false if <input type=reset>
>> > 2. has no "disabled" attribute,
>> > 3. has no "readonly" attribute,
>> > 4. inside of a <form> element,
>> > 5. has non-empty "name" attribute, and
>> > 6. not inside of a <datalist> element.
>> >
>> > I hope ValidityState and the pseudo classes ignores 2-6.

>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)


> I'd like to propose to add another condition:
>   7. it is visible (computed 'display' property of CSS isn't 'none' and no
> 'hidden' content attribute)

> I couldn't find exceptional rules for validating invisible controls in the
> current draft.
> Chrome 5 was released with a part of interactive validation, and we
> received a bug report about validation against invisible form controls.

> --
> TAMURA Kent
> Software Engineer, Google






-- 
TAMURA Kent
Software Engineer, Google



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

From bzbarsky at MIT.EDU  Thu Jun  3 09:18:58 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 03 Jun 2010 12:18:58 -0400
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <op.vdqdxasc2q99of@coruscant>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<op.vdqdxasc2q99of@coruscant>
Message-ID: <4C07D5F2.4010703@mit.edu>

On 6/3/10 11:42 AM, Jo?o Eiras wrote:
> Would be easier to tell that user agents might chose to ignore form
> controls that they do not *paint* if that is possible for the UA to
> implement.

Gecko doesn't necessarily paint form controls that are outside the 
viewport, yet ignoring those seems wrong.

-Boris

From dhtmlkitchen at gmail.com  Thu Jun  3 11:58:55 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 3 Jun 2010 11:58:55 -0700
Subject: [whatwg] fixBrokenLink is not defined
Message-ID: <AANLkTikdRI3y1B1LvdDjSRlZ4pIZ4XMcQU7ZMMlr50V6@mail.gmail.com>

I have noticed over the last year or so, the error "fixBrokenLink"
often popping up.

  fixBrokenLink is not defined.

I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla
http://www.w3.org/Bugs/Public/query.cgi

http://dev.w3.org/html5/spec/Overview.html

  fixBrokenLink is not defined.

The error can be a bit of a distraction when reading and discussing.

The WhatWG-hosted one-pager causes Firefox to freeze for upwards of
forty seconds; I'm not interested in that.

What is fixBrokenLink? Is it DOM-traversal done onload? That's a known
cause of such delay, and the larger the document, the longer the
delay. Although I do not know for certain if this is the case with the
spec on whatwg.org, "fixBrokenLink" seems a suspect possibility.

It would be a good idea to look into the cause of the problem and see
about using another approach.

From peter at lvp-media.com  Thu Jun  3 12:30:17 2010
From: peter at lvp-media.com (Peter Beverloo)
Date: Thu, 3 Jun 2010 21:30:17 +0200
Subject: [whatwg] Comment on 6.6 Offline Web Applications
In-Reply-To: <4C07A7A9.3040303@disruptive-innovations.com>
References: <4C07A7A9.3040303@disruptive-innovations.com>
Message-ID: <AANLkTikSe0FSbdnV7Xc_89vIfH_P52jMS0CO01z9dVRE@mail.gmail.com>

On Thu, Jun 3, 2010 at 15:01, Daniel Glazman
<daniel.glazman at disruptive-innovations.com> wrote:
>
> Hi there,
>
> I noticed the Application Cache does not allow to remove
> a single cached web application from the cache. Is that on
> purpose?
> I am under the impression the cache is here more an offline
> storage for webapps than a normal cache, and that in the long
> run browsers will have to implement an "Offline Web Apps" manager.
> Since the user is supposedly already provided with a dialog
> asking permission to make a webapp available offline, it makes
> sense to give him/her a way to remove a single application from
> the cache.
>
> </Daniel>

Section 6.6.7 talks about expiration of cached data [1], but also
includes a few notes about removing items from the store. It
specifically states that user-agents could have a "delete
site-specific data" feature which also covers removing application
caches, but also hints towards a feature that removes caches on
request of the user.

The API does not state a way allowing an application to remove itself
from the cache, which could be desirable for web authors. If there's
interest for such an addition I'm willing to make a proposal, as it
isn't hard to think about use-cases for such a feature.

Regards,
Peter Beverloo

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#expiring-application-caches

From ian at hixie.ch  Thu Jun  3 14:15:47 2010
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Jun 2010 21:15:47 +0000 (UTC)
Subject: [whatwg] fixBrokenLink is not defined
In-Reply-To: <AANLkTikdRI3y1B1LvdDjSRlZ4pIZ4XMcQU7ZMMlr50V6@mail.gmail.com>
References: <AANLkTikdRI3y1B1LvdDjSRlZ4pIZ4XMcQU7ZMMlr50V6@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1006032115040.22838@ps20323.dreamhostps.com>

On Thu, 3 Jun 2010, Garrett Smith wrote:
>
> I have noticed over the last year or so, the error "fixBrokenLink"
> often popping up.
> 
>   fixBrokenLink is not defined.
> 
> I seem to recall at one point filing a bug but cannot find it in w3c Bugzilla
> http://www.w3.org/Bugs/Public/query.cgi
> 
> http://dev.w3.org/html5/spec/Overview.html
> 
>   fixBrokenLink is not defined.

Does this error occur with the WHATWG versions of the spec? If not, then 
please report it to the W3C, not the WHATWG (it's probably an issue with 
Mike's spec splitter script).

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

From michaeln at google.com  Thu Jun  3 14:40:47 2010
From: michaeln at google.com (Michael Nordman)
Date: Thu, 3 Jun 2010 14:40:47 -0700
Subject: [whatwg] Comment on 6.6 Offline Web Applications
In-Reply-To: <AANLkTikSe0FSbdnV7Xc_89vIfH_P52jMS0CO01z9dVRE@mail.gmail.com>
References: <4C07A7A9.3040303@disruptive-innovations.com>
	<AANLkTikSe0FSbdnV7Xc_89vIfH_P52jMS0CO01z9dVRE@mail.gmail.com>
Message-ID: <AANLkTinKfi2qUg055-45fl5Oy8NpF4CH2eI-YGdT-KU3@mail.gmail.com>

There is a way for the application to remove itself from the cache. If
fetching the manifestUrl returns a 404 or 410 response, all traces of that
manifestUrl are deleted from the cache. See section 6.6.4.

On Thu, Jun 3, 2010 at 12:30 PM, Peter Beverloo <peter at lvp-media.com> wrote:

> On Thu, Jun 3, 2010 at 15:01, Daniel Glazman
> <daniel.glazman at disruptive-innovations.com> wrote:
> >
> > Hi there,
> >
> > I noticed the Application Cache does not allow to remove
> > a single cached web application from the cache. Is that on
> > purpose?
> > I am under the impression the cache is here more an offline
> > storage for webapps than a normal cache, and that in the long
> > run browsers will have to implement an "Offline Web Apps" manager.
> > Since the user is supposedly already provided with a dialog
> > asking permission to make a webapp available offline, it makes
> > sense to give him/her a way to remove a single application from
> > the cache.
> >
> > </Daniel>
>
> Section 6.6.7 talks about expiration of cached data [1], but also
> includes a few notes about removing items from the store. It
> specifically states that user-agents could have a "delete
> site-specific data" feature which also covers removing application
> caches, but also hints towards a feature that removes caches on
> request of the user.
>
> The API does not state a way allowing an application to remove itself
> from the cache, which could be desirable for web authors. If there's
> interest for such an addition I'm willing to make a proposal, as it
> isn't hard to think about use-cases for such a feature.
>
> Regards,
> Peter Beverloo
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#expiring-application-caches
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100603/08f37ce4/attachment.htm>

From Simetrical+w3c at gmail.com  Thu Jun  3 15:48:41 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 3 Jun 2010 18:48:41 -0400
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTina1sAGNPs1F0VufYqRoefAKLKKImSrsbdShd27@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTina1sAGNPs1F0VufYqRoefAKLKKImSrsbdShd27@mail.gmail.com>
Message-ID: <AANLkTinWrRsxmMqli_IX_pIvcu52NXNk-6Ci2pASeg0F@mail.gmail.com>

On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent <tkent at chromium.org> wrote:
> Oh, I'm sorry. ?I have found a sentence about visibility in the draft.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
>> If one of the controls is not?being rendered?(e.g. it has
>> the?hidden?attribute set) then user agents may report a script error.
>
> This sentence is about process against controls of which validation result
> is invalid.
> I think UA doesn't need to validate such controls.
>
> The Chrome bug report is
> here:?http://code.google.com/p/chromium/issues/detail?id=45640

I think this isn't a feasible strategy to pursue.  You'd have to
carefully define what's "not being rendered", and it will violate
layering massively.  CSS should not be able to override constraints
set in HTML.  The latter are part of the semantics of the form, and
the former is supposed to only control presentation.

If the user can't actually change the form to match requirements,
that's a bug in the page.  The browser should not try to guess what
the page really meant using some inevitably complicated heuristic.  It
should respect what the page says, and make it not work.  If the
browser has a UI for form validation errors, it can use that to tell
the user what the problem is in terms that the page author can
understand, so the user can report it and the page can be fixed.

From dhtmlkitchen at gmail.com  Thu Jun  3 16:08:30 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 3 Jun 2010 16:08:30 -0700
Subject: [whatwg] fixBrokenLink is not defined
In-Reply-To: <Pine.LNX.4.64.1006032115040.22838@ps20323.dreamhostps.com>
References: <AANLkTikdRI3y1B1LvdDjSRlZ4pIZ4XMcQU7ZMMlr50V6@mail.gmail.com>
	<Pine.LNX.4.64.1006032115040.22838@ps20323.dreamhostps.com>
Message-ID: <AANLkTilwwI_XbrBjo_iMgUux-7IwkwP_uDj5vouYRfyr@mail.gmail.com>

On 6/3/10, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 3 Jun 2010, Garrett Smith wrote:
>>
>> I have noticed over the last year or so, the error "fixBrokenLink"
>> often popping up.
>>
>>   fixBrokenLink is not defined.
>>
>> I seem to recall at one point filing a bug but cannot find it in w3c
>> Bugzilla
>> http://www.w3.org/Bugs/Public/query.cgi
>>
>> http://dev.w3.org/html5/spec/Overview.html
>>
>>   fixBrokenLink is not defined.
>
> Does this error occur with the WHATWG versions of the spec? If not, then
> please report it to the W3C, not the WHATWG (it's probably an issue with
> Mike's spec splitter script).
>\

I'm not gonna check because that size freezes the browser.

From pkasting at google.com  Thu Jun  3 17:09:29 2010
From: pkasting at google.com (Peter Kasting)
Date: Thu, 3 Jun 2010 17:09:29 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTinWrRsxmMqli_IX_pIvcu52NXNk-6Ci2pASeg0F@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTina1sAGNPs1F0VufYqRoefAKLKKImSrsbdShd27@mail.gmail.com>
	<AANLkTinWrRsxmMqli_IX_pIvcu52NXNk-6Ci2pASeg0F@mail.gmail.com>
Message-ID: <AANLkTikIvMSfbI0YnrmfivBj4_UHSE0CHTImEyzRFJTp@mail.gmail.com>

On Thu, Jun 3, 2010 at 3:48 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent <tkent at chromium.org> wrote:
> > Oh, I'm sorry.  I have found a sentence about visibility in the draft.
> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
> >> If one of the controls is not being rendered (e.g. it has
> >> the hidden attribute set) then user agents may report a script error.
> >
> > The Chrome bug report is
> > here: http://code.google.com/p/chromium/issues/detail?id=45640
>
> I think this isn't a feasible strategy to pursue.  You'd have to
> carefully define what's "not being rendered", and it will violate
> layering massively.  CSS should not be able to override constraints
> set in HTML.  The latter are part of the semantics of the form, and
> the former is supposed to only control presentation.
>
> If the user can't actually change the form to match requirements,
> that's a bug in the page.  The browser should not try to guess what
> the page really meant using some inevitably complicated heuristic.  It
> should respect what the page says, and make it not work.  If the
> browser has a UI for form validation errors, it can use that to tell
> the user what the problem is in terms that the page author can
> understand, so the user can report it and the page can be fixed.


I posted this on the Chromium bug, but I take the sentence Kent quotes to
affect only the UI shown on a validation failure, not the actual results of
validation.  That is, if a control fails validation and has the "hidden"
attribute, validation still fails, but the UA may display a message
indicating the page has an error in addition to/instead of the normal
validation failure message.

I agree that it would be a mistake to exclude "invisible" elements from
validation, as that would be a rathole (and seems conceptually wrong to me).

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100603/851b3dc1/attachment.htm>

From dhtmlkitchen at gmail.com  Thu Jun  3 19:30:22 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 3 Jun 2010 19:30:22 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTina1sAGNPs1F0VufYqRoefAKLKKImSrsbdShd27@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTina1sAGNPs1F0VufYqRoefAKLKKImSrsbdShd27@mail.gmail.com>
Message-ID: <AANLkTimZNibwtQPLBNpgDUF62XarYBUFp9LexNFkRZA-@mail.gmail.com>

On 6/3/10, TAMURA, Kent <tkent at chromium.org> wrote:
> Oh, I'm sorry.  I have found a sentence about visibility in the draft.
>

Where?

> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
>> If one of the controls is not being
>> rendered<rendering.html#being-rendered>
>   (e.g. it has the hidden <editing.html#the-hidden-attribute> attribute set)
> then user agents may report a script error.
>

That's about <input type="hidden">

> This sentence is about process against controls of which validation result
> is invalid.
> I think UA doesn't need to validate such controls.
>

You lost me on that one.

>
> The Chrome bug report is here:
> http://code.google.com/p/chromium/issues/detail?id=45640
>

That bug is describing an error when validating a control that cannot
have focus. That's more specific from a control that is not visible.

Is the issue in defining what is and what isn't focusable?

> 2010/6/4 TAMURA, Kent <tkent at chromium.org>
>
>> > An element is a "candidate for constraint validation" if
>>> > 1. it is a validatable type,
>>> >    e.g. true if <input type=number>, false if <input type=reset>
>>> > 2. has no "disabled" attribute,
>>> > 3. has no "readonly" attribute,
>>> > 4. inside of a <form> element,
>>> > 5. has non-empty "name" attribute, and
>>> > 6. not inside of a <datalist> element.
>>> >
>>> > I hope ValidityState and the pseudo classes ignores 2-6.
>
>>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)
>
>
>> I'd like to propose to add another condition:
>>   7. it is visible (computed 'display' property of CSS isn't 'none' and no
>> 'hidden' content attribute)
>
>> I couldn't find exceptional rules for validating invisible controls in the
>> current draft.
>> Chrome 5 was released with a part of interactive validation, and we
>> received a bug report about validation against invisible form controls.
>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>
>
>
>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
>
>

From brettz9 at yahoo.com  Thu Jun  3 21:59:00 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Fri, 04 Jun 2010 12:59:00 +0800
Subject: [whatwg] URN or protocol attribute
In-Reply-To: <4B9858F7.9070303@yahoo.com>
References: <4B6FCA82.3050508@yahoo.com>	<4B72668C.9070706@degeneration.co.uk>	<4B73AD79.5030701@yahoo.com>	<Pine.LNX.4.64.1003110114370.21376@ps20323.dreamhostps.com>	<4B984E31.9020407@yahoo.com>	<Pine.LNX.4.64.1003110228260.21367@ps20323.dreamhostps.com>
	<4B9858F7.9070303@yahoo.com>
Message-ID: <4C088814.5090301@yahoo.com>

On 3/11/2010 10:44 AM, Brett Zamir wrote:
> On 3/11/2010 10:31 AM, Ian Hickson wrote:
>> I would recommend following a pattern somewhat like the Web's initial
>> development: create a proof of concept, and convince people that it's 
>> what
>> they want. That's the best way to get a feature adopted. This is 
>> described
>> in more detail in the FAQ:
>>
>>     
>> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F 
>>
>
> Ok, fair enough. I think I'll try that as a browser extension <snip>

Just as a follow-up, I have now made a Firefox extension which supports 
two attributes on <a/>: "uris" and "alternateURIs", whereby the former 
takes precedence over "href", and the latter are accessible only by 
right-clicking links (though potentially discoverable by custom styling 
of such links (automatable by the extension)).

My thought is that sites which have the following goals may be 
particularly interested:

1) Those wishing to maintain objectivity and refrain from endorsing 
specific sites, e.g., governments, news institutions, scholars, or sites 
like Wikipedia. Even for a site's internal links, use of "alternateURIs" 
could offer convenience (e.g., Wikipedia would no doubt wish to continue 
to use href to refer to its own ISBN page by default, but could use the 
"alternateURIs" attribute to allow right-clicks on the link to activate 
the URN link which in turn activates their chosen default handler, e.g., 
Amazon, Google Books, etc.). The same could be done for music, etc.
2) giving full user choice as to how to view the data (especially useful 
for information of common and particular interest to the site viewers, 
e.g., links to the Bible in a religious forum)
3) those wishing to try out new protocols of whatever type (not only 
URNs), such as chatting protocols, whether installed via web or browser 
extension, as the proposed markup gives them a convenient fall-back to 
"href", so they don't have to have dead links for those whose browsers 
do not support the protocol.

https://addons.mozilla.org/en-US/firefox/addon/162154/

Brett


From brettz9 at yahoo.com  Thu Jun  3 22:04:57 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Fri, 04 Jun 2010 13:04:57 +0800
Subject: [whatwg] URN or protocol attribute
In-Reply-To: <4C088814.5090301@yahoo.com>
References: <4B6FCA82.3050508@yahoo.com>	<4B72668C.9070706@degeneration.co.uk>	<4B73AD79.5030701@yahoo.com>	<Pine.LNX.4.64.1003110114370.21376@ps20323.dreamhostps.com>	<4B984E31.9020407@yahoo.com>	<Pine.LNX.4.64.1003110228260.21367@ps20323.dreamhostps.com>	<4B9858F7.9070303@yahoo.com>
	<4C088814.5090301@yahoo.com>
Message-ID: <4C088979.60301@yahoo.com>

On 6/4/2010 12:59 PM, Brett Zamir wrote:
> On 3/11/2010 10:44 AM, Brett Zamir wrote:
>> On 3/11/2010 10:31 AM, Ian Hickson wrote:
>>> I would recommend following a pattern somewhat like the Web's initial
>>> development: create a proof of concept, and convince people that 
>>> it's what
>>> they want. That's the best way to get a feature adopted. This is 
>>> described
>>> in more detail in the FAQ:
>>>
>>>     
>>> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F 
>>>
>>
>> Ok, fair enough. I think I'll try that as a browser extension <snip>
>
> Just as a follow-up, I have now made a Firefox extension which 
> supports two attributes on <a/>: "uris" and "alternateURIs", whereby 
> the former takes precedence over "href", and the latter are accessible 
> only by right-clicking links (though potentially discoverable by 
> custom styling of such links (automatable by the extension)).
>
> My thought is that sites which have the following goals may be 
> particularly interested:
>
> 1) Those wishing to maintain objectivity and refrain from endorsing 
> specific sites, e.g., governments, news institutions, scholars, or 
> sites like Wikipedia. Even for a site's internal links, use of 
> "alternateURIs" could offer convenience (e.g., Wikipedia would no 
> doubt wish to continue to use href to refer to its own ISBN page by 
> default, but could use the "alternateURIs" attribute to allow 
> right-clicks on the link to activate the URN link which in turn 
> activates their chosen default handler, e.g., Amazon, Google Books, 
> etc.). The same could be done for music, etc.
> 2) giving full user choice as to how to view the data (especially 
> useful for information of common and particular interest to the site 
> viewers, e.g., links to the Bible in a religious forum)
> 3) those wishing to try out new protocols of whatever type (not only 
> URNs), such as chatting protocols, whether installed via web or 
> browser extension, as the proposed markup gives them a convenient 
> fall-back to "href", so they don't have to have dead links for those 
> whose browsers do not support the protocol.
>
> https://addons.mozilla.org/en-US/firefox/addon/162154/

Just to elaborate a little bit further, one possible future addition 
which could further enhance this experience would be to design a 
protocol (and corresponding markup-detection mechanism), say "created:" 
or "wiki:" which would first check via HEAD request whether the page 
were created or not, and then style the link accordingly and possibly 
alter the URL to lead directly to the editing or alternatively, it could 
make HEAD requests to try out a sequence of URLs, e.g., checking whether 
Citizendium had an article, and if not, creating a link to the Wikipedia 
article if present. While this could be done potentially via the server 
(e.g., this extension for Mediawiki: 
http://www.mediawiki.org/wiki/Extension:BADI_Pages_Created_Links ), I 
believe allowing client-side markup to do it would facilitate use of 
this potential more widely, allowing wikis or open-forums to link with 
one another in a way which prevents wasted visits by their users.

Although URNs could also be used (as supported already potentially in 
the above extension) to try to find encyclopedic articles (e.g., 
urn:name:pizza), or better yet, through a new protocol which could 
suggest intended uses of the information (e.g., 
find:urn:name:pizza?category=order, find:urn:name:pizza?category=define, 
etc.) and thereby avoiding hard-coding information, the "created:" 
suggestion above could give authors more control than they have now if 
they did want to suggest a particular path-way.

Brett


From bijumaillist at gmail.com  Thu Jun  3 23:49:40 2010
From: bijumaillist at gmail.com (Biju)
Date: Fri, 4 Jun 2010 02:49:40 -0400
Subject: [whatwg] Sort child nodes of a DOM node.
Message-ID: <AANLkTimNLX_rDFNIu85EOxmaguL7E2E0pOU0CMqjvIfN@mail.gmail.com>

There are many cases where we want to sort child nodes of a DOM node.
Many times it is TR nodes of a TBODY

Right now user writes javascript code to achive that.
Dont you think it is better if there was built DOM method for each node.
Additionally the method will have a sort function parameter to compare elements
the same way as in JavaScript Array.sort(compare_func)

function compare_func(a,b){
 if(isHeaderRow(a))  return -1;
 if(isHeaderRow(b))  return 1;
 if(a.textContent == b.textContent) return 0;
 if(a.textContent < b.textContent) return -1;
 return 1;
}
tablebody.sortChildNodes(compare_func)

Use cases:-
Example 1: column sorting in yahoo mail

Example 2: you can sort this listing by clicking the column headers
https://bugzilla.mozilla.org/buglist.cgi?short_desc=sort&short_desc_type=allwordssubstr&resolution=---

Example 2: there are bug report in mozilla asking sorting in XUL grids
https://bugzilla.mozilla.org/showdependencytree.cgi?id=482890&hide_resolved=1

From mike at w3.org  Fri Jun  4 01:37:08 2010
From: mike at w3.org (Michael(tm) Smith)
Date: Fri, 4 Jun 2010 17:37:08 +0900
Subject: [whatwg] fixBrokenLink is not defined
In-Reply-To: <AANLkTilwwI_XbrBjo_iMgUux-7IwkwP_uDj5vouYRfyr@mail.gmail.com>
References: <AANLkTikdRI3y1B1LvdDjSRlZ4pIZ4XMcQU7ZMMlr50V6@mail.gmail.com>
	<Pine.LNX.4.64.1006032115040.22838@ps20323.dreamhostps.com>
	<AANLkTilwwI_XbrBjo_iMgUux-7IwkwP_uDj5vouYRfyr@mail.gmail.com>
Message-ID: <20100604083708.GC86859@sideshowbarker>

Garrett Smith <dhtmlkitchen at gmail.com>, 2010-06-03 16:08 -0700:

> On 6/3/10, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 3 Jun 2010, Garrett Smith wrote:
> >>
> >> I have noticed over the last year or so, the error "fixBrokenLink"
> >> often popping up.
> >>
> >>   fixBrokenLink is not defined.
> >>
> >> I seem to recall at one point filing a bug but cannot find it in w3c
> >> Bugzilla

I think it's this:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=9650

> >> http://dev.w3.org/html5/spec/Overview.html
> >>
> >>   fixBrokenLink is not defined.
> >
> > Does this error occur with the WHATWG versions of the spec? If not, then
> > please report it to the W3C, not the WHATWG (it's probably an issue with
> > Mike's spec splitter script).
> >\
> 
> I'm not gonna check because that size freezes the browser.

There's also a multipage WHATWG version -

  http://www.whatwg.org/specs/web-apps/current-work/multipage/

-- 
Michael(tm) Smith
http://people.w3.org/mike

From whatwg at fowlsmurf.net  Fri Jun  4 04:19:44 2010
From: whatwg at fowlsmurf.net (James May)
Date: Fri, 4 Jun 2010 21:19:44 +1000
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTinbZOM-95txMblbUC9c8h1sElJ90XvBHmt58786@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> 
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> 
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com> 
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTinbZOM-95txMblbUC9c8h1sElJ90XvBHmt58786@mail.gmail.com>
Message-ID: <AANLkTiklQtzVw6fgYRqxgl2dUNMpAb5HlO3JyE2ZlZ3N@mail.gmail.com>

Couldn't SCTP/DCCP (or a variant) over UDP (for NAT compatibility) work?

They seem both seem to be session oriented while loosening the other
restrictions of TCP,


On 4 June 2010 00:18, Philip Taylor
<excors+whatwg at gmail.com<excors%2Bwhatwg at gmail.com>
> wrote:

> On Thu, Jun 3, 2010 at 7:28 AM, Erik M?ller <emoller at opera.com> wrote:
> > [...]
> > One thing to remember here is that browsers have other means for
> > communication as well. I'm not saying we shouldn't support reliable
> messages
> > over UDP, but just pointing out the option.
>
> Yep - the relevant use cases ought to be supported decently by the
> platform, but not necessarily by this extension to the platform (it
> might be a different extension or it might be (probably is) supported
> already).
>
> >> - Protection against an attacker initiating a legitimate socket with a
> >> user and then redirecting it (with some kind of IP (un)hijacking) to a
> >> service behind the user's firewall (which isn't a problem when using
> >> TCP since the service will ignore packets when it hasn't done the TCP
> >> handshake; but UDP services might respond to a single packet from the
> >> middle of a websocket stream, so every single packet will have to be
> >> careful not to be misinterpreted dangerously by unsuspecting
> >> services).
> >
> > I don't quite follow what you mean here. Can you expand on this with an
> > example?
>
> I was thinking something like: A host at IP 11.11.11.11 on the public
> internet runs some UDP service, like DNS or TFTP or something a bit
> more secure. That service is restricted so it only responds to packets
> received from IP 22.22.22.22 (a trusted user). The UDP Web Socket
> handshake is carefully constructed so that it won't trigger dangerous
> behaviour in any of those services (like how the TCP Web Socket uses a
> safe HTTP-ish handshake).
>
> An attacker hijacks the IP 11.11.11.11 from the perspective of the
> user (by advertising new routes near the user), so the user's packets
> to that address go to the attacker. The attacker gets the user to
> visit a web page which sets up a UDP Web Socket with the attacker's
> server at 11.11.11.11, doing all the handshake authentication
> correctly.
>
> The attacker then releases its hijacked address, so any subsequent Web
> Socket packets will go to the original restricted service. Since
> they're being received from the trusted user, the service will trust
> them. Since the web browser has already done the Socket handshake, it
> will believe it's talking to a legitimate Web Socket server and will
> continue sending whatever data packets the attacker's script tells it
> to.
>
> The service will then be receiving and responding to
> attacker-controlled packets, and will never have seen the carefully
> constructed handshake that's designed to protect it. That's not a
> danger for TCP services since they'll reject unexpected packets from
> the middle of a TCP stream, but UDP services may accept packets from
> the middle of a UDP Web Socket stream.
>
> So it's not sufficient to carefully construct the Web Socket handshake
> packets to not trigger unwanted behaviour in non-Socket services.
> Every data packet sent on the Socket has to be carefully constructed
> too.
>
> (This might be a largely impractical or pointless attack, and there's
> probably much easier ways to attack the exposed service, but I don't
> know enough about security to judge that. Also I don't know what
> packet construction would be sufficiently careful. But it seems like a
> possible new concern that's introduced when using UDP in this
> context.)
>
> --
> Philip Taylor
> excors at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/dd7f5269/attachment.htm>

From Smylers at stripey.com  Fri Jun  4 04:55:27 2010
From: Smylers at stripey.com (Smylers)
Date: Fri, 4 Jun 2010 12:55:27 +0100
Subject: [whatwg] 'Main Part of the Content' Idiom
Message-ID: <20100604115527.GA15212@stripey.com>

The HTML5 spec should define how to mark up the main content on a page
(even if the answer is "by omission"). This is something that many
authors ask about, the latest example being today's thread on the help
mailing list:
http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html

Please could this be added to the 'idioms' section, perhaps giving
examples of when <article> or <section> might be appropriate as well as
one in which the main content is simply that which isn't in <header>,
<aside>, etc.

Thanks.

Smylers
-- 
http://twitter.com/Smylers2

From hsivonen at iki.fi  Fri Jun  4 04:58:33 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 4 Jun 2010 14:58:33 +0300
Subject: [whatwg] Installable web apps
In-Reply-To: <AANLkTineMrFwRNFrbrd9VOLwAa5nbMCVGeveNehsw-mS@mail.gmail.com>
References: <938287364.274872.1274872436319.JavaMail.root@cm-mail03.mozilla.org>
	<1992128521.274961.1274873457250.JavaMail.root@cm-mail03.mozilla.org>
	<AANLkTineMrFwRNFrbrd9VOLwAa5nbMCVGeveNehsw-mS@mail.gmail.com>
Message-ID: <676E0E73-B0F0-4D76-B45A-6EC0CF47228D@iki.fi>

On May 26, 2010, at 20:10, Aaron Boodman wrote:

> This isn't really the point of this mail, but I just want to point out
> that there are more differences between wgt and crx than the format of
> the manifest file. The most important is that the identify of a crx
> file is a public key, and all crx files are self-signed by their key.
> This makes a crx file's identity unforgeable.

.wgt supports signing, too, but as with Sun .jar or Mozilla .xpi the signing proves that the .wgt came from the entity that the private key belongs to as certified by PKI--as opposed to proving without PKI that it came from the same source as the previous version of the .wgt.

After googling around a bit, I was unable to find a signed .crx file for analysis. (I took apart 3 .crx files and gave up.) Is the signing mechanism documented somewhere? .wgt reinvents the .jar signing wheel by the basic idea of .jar signing with XML Signatures.

(Note that I am not in any way implying that PKI were better. If Google can actually get extension authors to sign their extensions on average and proving that extension updates came from the same source as the previous version, that's a pretty big win over the Firefox extension signing situation. In principle, Firefox extensions can be signed to the stronger level of proving who signed them as opposed to proving just "same as before", but in practice, virtually no one--not even Mozilla Labs--signs Firefox extensions, so it doesn't help much that the level of proof would be stronger if signed.)

> The source of our support for packaged applications is that we have
> gotten a lot of feedback from developers that find packages a very
> convenient way to develop applications that work offline. I think the
> reason is that packages are conceptually much simpler than app caches.
> That said, I think this is mainly a lack of good tool support for app
> cache and good documentation, and I think it can eventually be
> overcome.

I see.

> For now, I would like to focus on live web apps, not packaged local apps.

Great.

>> I think it follows that to install a Web app, you navigate to its URL and bookmark it. There is no need to have an icon in a zip file for this: HTML5 already provides <link rel=icon sizes=... that the app can use to declare its icon, which can be pinned to cache upon bookmarking. So far, nothing new to design.
>> 
>> A plain bookmark doesn't elevate the bookmarked app sufficiently to be special in the system app switcher (like Prism) or inside the tab system of the browser (like Firefox 4 application tabs). A plain bookmark also doesn't pre-grant any permissions or ensure that the app stays in the cache.
>> 
>> I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To "install" a Web application, the user would navigate to the app's URL and create an application bookmark.
> 
> For Chrome this isn't the UX we want. We want users to click a link in
> the content area and be presented with an install dialog. We think
> that going to something in the browser to "applicationify" a web app
> is too indirect and that many users will not get it.
> 
> That said, I think there is room to support multiple models of
> installation (or bookmarking, or whatever you want to call it),
> though.

Why don't you want the UX of the applicatinification process starting from browser chrome? Screen real estate reasons? Expectation or research showing that users don't understand the difference anyway?

Don't you need an annoying "This site is trying to applicationify itself. Allow or Deny?" piece of UI if the site can start the process?

>> If it's still deemed useful to be able to pre-grant permissions, I think the app should, again instead of installed zip files, use <link rel=something> to point to a manifest that shows what the apps wishes to be pre-granted. When the features to be granted have obvious JavaScript entry points from the window object (e.g. navigator.geolocation), the JavaScript names of those entry points should be used to identify the features in the manifest in order to avoid having to standardize separate permission names.
> 
> We have a growing set of metadata you're trying to <link> to:
> 
> - Icons

Mobile Safari and, AFAIK, the default Android browser already use use <link rel=apple-touch-icon> for this, so it seems to me the <link> cat is already out of the bag.

> - Application name (you didn't mention this, but I think it is nice to
> have distinct from the <title>, which is often overloaded with status
> information)

As Lachy mentioned, there's already in-document syntax for this:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta-application-name

I'm not aware of anyone implementing it, though.

> Another one that we would like in Chrome is a path prefix for the app.
> This is to handle the case of applications like Google Reader which
> are on http://www.google.com/reader.

How does giving permissions to a prefixed application interact with the origin-based security model?

> Every URL in an application will have to <link> to this same
> information. It seems like it would be better to just <link> to a
> separate resource that contains the information.
> 
> To me, this all leads to the following proposal:
> 
> <html>
> <head>
> <!-- for UAs that want a button in the browser chrome to appify -->
> <link rel="application-description" href="myapp.json">
> </head>
> <body>
> <!-- for UAs that want a button in the Chrome to appify -->
> <button onclick="navigator.installApplication()">install</button>
> </body>
> </html>
> 
> // myapp.json
> {
>  "name": "My Application",
>  "icons": ...,
>  "urls": [
>    "reader/"
>  ],
>  "permissions": [
>    ...
>  ]
> }
> 
> WDYT?

Makes sense to me (if you add sniffing for navigator.installApplication before showing a button that calls it), although I doubt you'll be able to avoid repeating a <link> to the icon anyway.

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



From danielperssondeluxe at gmail.com  Fri Jun  4 07:27:14 2010
From: danielperssondeluxe at gmail.com (Daniel Persson)
Date: Fri, 4 Jun 2010 16:27:14 +0200
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <20100604115527.GA15212@stripey.com>
References: <20100604115527.GA15212@stripey.com>
Message-ID: <AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>

I am the one posting the question on the help list. To me, the lack of html5
definition of main content, ie body copy in paper publishing, is a big
mistake. Imagine the amount of sites where "everything else" includes a lot
of unimportant extra, or peripheral, content. Content which is not
necessarily hierarchically legible by a machine. Getting authors to be
disciplined about defining main content is more important than being
disciplined about <nav>, <footer>, <header>, <section> etc, in order not to
negate the meaning of html5 structural mark-up.

Suggestion <bodycopy>... or, preferred, <bread>.

/Daniel

On Fri, Jun 4, 2010 at 1:55 PM, Smylers <Smylers at stripey.com> wrote:

> The HTML5 spec should define how to mark up the main content on a page
> (even if the answer is "by omission"). This is something that many
> authors ask about, the latest example being today's thread on the help
> mailing list:
> http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>
> Please could this be added to the 'idioms' section, perhaps giving
> examples of when <article> or <section> might be appropriate as well as
> one in which the main content is simply that which isn't in <header>,
> <aside>, etc.
>
> Thanks.
>
> Smylers
> --
> http://twitter.com/Smylers2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/90da4115/attachment.htm>

From ash at ashleysheridan.co.uk  Fri Jun  4 07:37:11 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 04 Jun 2010 15:37:11 +0100
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
Message-ID: <1275662231.2217.75.camel@localhost>

On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote:

> I am the one posting the question on the help list. To me, the lack of
> html5 definition of main content, ie body copy in paper publishing, is
> a big mistake. Imagine the amount of sites where "everything else"
> includes a lot of unimportant extra, or peripheral, content. Content
> which is not necessarily hierarchically legible by a machine. Getting
> authors to be disciplined about defining main content is more
> important than being disciplined about <nav>, <footer>, <header>,
> <section> etc, in order not to negate the meaning of html5 structural
> mark-up. 
> 
> 
> 
> Suggestion <bodycopy>... or, preferred, <bread>.
> 
> 
> /Daniel
> 
> 
> On Fri, Jun 4, 2010 at 1:55 PM, Smylers <Smylers at stripey.com> wrote:
> 
>         The HTML5 spec should define how to mark up the main content
>         on a page
>         (even if the answer is "by omission"). This is something that
>         many
>         authors ask about, the latest example being today's thread on
>         the help
>         mailing list:
>         http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>         
>         Please could this be added to the 'idioms' section, perhaps
>         giving
>         examples of when <article> or <section> might be appropriate
>         as well as
>         one in which the main content is simply that which isn't in
>         <header>,
>         <aside>, etc.
>         
>         Thanks.
>         
>         Smylers
>         --
>         http://twitter.com/Smylers2
> 
> 
> 

It's my understanding that everything within the <body> tag is
considered body content, and the new <header> and <footer> tags, etc,
are just there to give more meaning about the type of body content.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From danielperssondeluxe at gmail.com  Fri Jun  4 08:05:54 2010
From: danielperssondeluxe at gmail.com (Daniel Persson)
Date: Fri, 4 Jun 2010 17:05:54 +0200
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <1275662231.2217.75.camel@localhost>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
Message-ID: <AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>

If i view the html-web as it is now, inside <body> there are so much
irrelevant content (where else to put it?). In order for <body> to be the
main content, there has to be tags for everything else. This will be very
hard for authors to implement (I am talking real world, amateur,
do-it-yourself, stressed professionals). It is IMHO very beautiful
code-wise, and organisationally, to state that everything in <body> is main
content, but it will not benefit a structurally marked-up web.

Thanks
/Daniel

On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan <ash at ashleysheridan.co.uk>wrote:

>  On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote:
>
> I am the one posting the question on the help list. To me, the lack of
> html5 definition of main content, ie body copy in paper publishing, is a big
> mistake. Imagine the amount of sites where "everything else" includes a lot
> of unimportant extra, or peripheral, content. Content which is not
> necessarily hierarchically legible by a machine. Getting authors to be
> disciplined about defining main content is more important than being
> disciplined about <nav>, <footer>, <header>, <section> etc, in order not to
> negate the meaning of html5 structural mark-up.
>
>
>
>  Suggestion <bodycopy>... or, preferred, <bread>.
>
>
>
>  /Daniel
>
>  On Fri, Jun 4, 2010 at 1:55 PM, Smylers <Smylers at stripey.com> wrote:
>
> The HTML5 spec should define how to mark up the main content on a page
> (even if the answer is "by omission"). This is something that many
> authors ask about, the latest example being today's thread on the help
> mailing list:
> http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>
> Please could this be added to the 'idioms' section, perhaps giving
> examples of when <article> or <section> might be appropriate as well as
> one in which the main content is simply that which isn't in <header>,
> <aside>, etc.
>
> Thanks.
>
> Smylers
> --
> http://twitter.com/Smylers2
>
>
>
>
> It's my understanding that everything within the <body> tag is considered
> body content, and the new <header> and <footer> tags, etc, are just there to
> give more meaning about the type of body content.
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/f65278b1/attachment.htm>

From ash at ashleysheridan.co.uk  Fri Jun  4 08:10:21 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 04 Jun 2010 16:10:21 +0100
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
Message-ID: <1275664221.2217.77.camel@localhost>

On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote:

> If i view the html-web as it is now, inside <body> there are so much
> irrelevant content (where else to put it?). In order for <body> to be
> the main content, there has to be tags for everything else. This will
> be very hard for authors to implement (I am talking real world,
> amateur, do-it-yourself, stressed professionals). It is IMHO very
> beautiful code-wise, and organisationally, to state that everything in
> <body> is main content, but it will not benefit a structurally
> marked-up web.
> 
> 
> 
> Thanks
> /Daniel
> 
> 
> On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> 
>         
>         On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote:
>         
>         > I am the one posting the question on the help list. To me,
>         > the lack of html5 definition of main content, ie body copy
>         > in paper publishing, is a big mistake. Imagine the amount of
>         > sites where "everything else" includes a lot of unimportant
>         > extra, or peripheral, content. Content which is not
>         > necessarily hierarchically legible by a machine. Getting
>         > authors to be disciplined about defining main content is
>         > more important than being disciplined about <nav>, <footer>,
>         > <header>, <section> etc, in order not to negate the meaning
>         > of html5 structural mark-up. 
>         > 
>         > 
>         > Suggestion <bodycopy>... or, preferred, <bread>.
>         > 
>         > 
>         > /Daniel
>         > 
>         > On Fri, Jun 4, 2010 at 1:55 PM, Smylers
>         > <Smylers at stripey.com> wrote:
>         > 
>         >         The HTML5 spec should define how to mark up the main
>         >         content on a page
>         >         (even if the answer is "by omission"). This is
>         >         something that many
>         >         authors ask about, the latest example being today's
>         >         thread on the help
>         >         mailing list:
>         >         http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>         >         
>         >         Please could this be added to the 'idioms' section,
>         >         perhaps giving
>         >         examples of when <article> or <section> might be
>         >         appropriate as well as
>         >         one in which the main content is simply that which
>         >         isn't in <header>,
>         >         <aside>, etc.
>         >         
>         >         Thanks.
>         >         
>         >         Smylers
>         >         --
>         >         http://twitter.com/Smylers2 
>         > 
>         > 
>         > 
>         
>         
>         
>         
>         It's my understanding that everything within the <body> tag is
>         considered body content, and the new <header> and <footer>
>         tags, etc, are just there to give more meaning about the type
>         of body content.
>         
>         Thanks,
>         Ash
>         http://www.ashleysheridan.co.uk
>         
>         
>         
> 
> 
> 

The fact that there is so much irrelevant content inside the <body> tag
is because some people consider that body content. Do you have a more
specific example of this?

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From danielperssondeluxe at gmail.com  Fri Jun  4 09:03:51 2010
From: danielperssondeluxe at gmail.com (Daniel Persson)
Date: Fri, 4 Jun 2010 18:03:51 +0200
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <1275664221.2217.77.camel@localhost>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
Message-ID: <AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>

Some websites are very crowded. I have no particular example. Blogs and
easily accessible CMS's, people trying to make a buck from excessive
advertising on their site, people cramming a lot of info/screen unit.
Companies too, old media: http://www.aftonbladet.se/ (major Swedish paper,
watch your eyes) . <body> will hold a lot of stuff that is not main content,
other content will spill over into <body> (unless there is a conscious
author, and vast use of <aside>).
It should be easy for authors to define main content. It s a pedagogical
issue, where authors not too concerned with standards compliance, should
have an easy escape of at least defining the most important on the site.

Thanks
/Daniel



On Fri, Jun 4, 2010 at 5:10 PM, Ashley Sheridan <ash at ashleysheridan.co.uk>wrote:

>  On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote:
>
> If i view the html-web as it is now, inside <body> there are so much
> irrelevant content (where else to put it?). In order for <body> to be the
> main content, there has to be tags for everything else. This will be very
> hard for authors to implement (I am talking real world, amateur,
> do-it-yourself, stressed professionals). It is IMHO very beautiful
> code-wise, and organisationally, to state that everything in <body> is main
> content, but it will not benefit a structurally marked-up web.
>
>
>
>  Thanks
>
>  /Daniel
>
>  On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan <ash at ashleysheridan.co.uk>
> wrote:
>
>
>   On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote:
>
> I am the one posting the question on the help list. To me, the lack of
> html5 definition of main content, ie body copy in paper publishing, is a big
> mistake. Imagine the amount of sites where "everything else" includes a lot
> of unimportant extra, or peripheral, content. Content which is not
> necessarily hierarchically legible by a machine. Getting authors to be
> disciplined about defining main content is more important than being
> disciplined about <nav>, <footer>, <header>, <section> etc, in order not to
> negate the meaning of html5 structural mark-up.
>
>
> Suggestion <bodycopy>... or, preferred, <bread>.
>
>
> /Daniel
>
> On Fri, Jun 4, 2010 at 1:55 PM, Smylers <Smylers at stripey.com> wrote:
>
> The HTML5 spec should define how to mark up the main content on a page
> (even if the answer is "by omission"). This is something that many
> authors ask about, the latest example being today's thread on the help
> mailing list:
> http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>
> Please could this be added to the 'idioms' section, perhaps giving
> examples of when <article> or <section> might be appropriate as well as
> one in which the main content is simply that which isn't in <header>,
> <aside>, etc.
>
> Thanks.
>
> Smylers
> --
> http://twitter.com/Smylers2
>
>
>
>
>
>   It's my understanding that everything within the <body> tag is
> considered body content, and the new <header> and <footer> tags, etc, are
> just there to give more meaning about the type of body content.
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
>
>
> The fact that there is so much irrelevant content inside the <body> tag is
> because some people consider that body content. Do you have a more specific
> example of this?
>
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/7dff759c/attachment.htm>

From ash at ashleysheridan.co.uk  Fri Jun  4 09:07:14 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 04 Jun 2010 17:07:14 +0100
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
Message-ID: <1275667634.2217.80.camel@localhost>

On Fri, 2010-06-04 at 18:03 +0200, Daniel Persson wrote:
> Some websites are very crowded. I have no particular example. Blogs
> and easily accessible CMS's, people trying to make a buck from
> excessive advertising on their site, people cramming a lot of
> info/screen unit. Companies too, old media: http://www.aftonbladet.se/
> (major Swedish paper, watch your eyes) . <body> will hold a lot of
> stuff that is not main content, other content will spill over into
> <body> (unless there is a conscious author, and vast use of <aside>). 
> It should be easy for authors to define main content. It s a
> pedagogical issue, where authors not too concerned with standards
> compliance, should have an easy escape of at least defining the most
> important on the site.
> 
> 
> Thanks
> /Daniel
> 
> 
> 
> 
> 
> 
> 
> On Fri, Jun 4, 2010 at 5:10 PM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> 
>         
>         On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote:
>         
>         > If i view the html-web as it is now, inside <body> there are
>         > so much irrelevant content (where else to put it?). In order
>         > for <body> to be the main content, there has to be tags for
>         > everything else. This will be very hard for authors to
>         > implement (I am talking real world, amateur, do-it-yourself,
>         > stressed professionals). It is IMHO very beautiful
>         > code-wise, and organisationally, to state that everything in
>         > <body> is main content, but it will not benefit a
>         > structurally marked-up web.
>         > 
>         > 
>         > Thanks
>         > /Daniel
>         > 
>         > On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan
>         > <ash at ashleysheridan.co.uk> wrote:
>         > 
>         >         
>         >         On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson
>         >         wrote:
>         >         
>         >         > I am the one posting the question on the help
>         >         > list. To me, the lack of html5 definition of main
>         >         > content, ie body copy in paper publishing, is a
>         >         > big mistake. Imagine the amount of sites where
>         >         > "everything else" includes a lot of unimportant
>         >         > extra, or peripheral, content. Content which is
>         >         > not necessarily hierarchically legible by a
>         >         > machine. Getting authors to be disciplined about
>         >         > defining main content is more important than being
>         >         > disciplined about <nav>, <footer>, <header>,
>         >         > <section> etc, in order not to negate the meaning
>         >         > of html5 structural mark-up. 
>         >         > 
>         >         > 
>         >         > Suggestion <bodycopy>... or, preferred, <bread>.
>         >         > 
>         >         > 
>         >         > /Daniel
>         >         > 
>         >         > On Fri, Jun 4, 2010 at 1:55 PM, Smylers
>         >         > <Smylers at stripey.com> wrote:
>         >         > 
>         >         >         The HTML5 spec should define how to mark
>         >         >         up the main content on a page
>         >         >         (even if the answer is "by omission").
>         >         >         This is something that many
>         >         >         authors ask about, the latest example
>         >         >         being today's thread on the help
>         >         >         mailing list:
>         >         >         http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>         >         >         
>         >         >         Please could this be added to the 'idioms'
>         >         >         section, perhaps giving
>         >         >         examples of when <article> or <section>
>         >         >         might be appropriate as well as
>         >         >         one in which the main content is simply
>         >         >         that which isn't in <header>,
>         >         >         <aside>, etc.
>         >         >         
>         >         >         Thanks.
>         >         >         
>         >         >         Smylers
>         >         >         --
>         >         >         http://twitter.com/Smylers2 
>         >         > 
>         >         > 
>         >         > 
>         >         
>         >         
>         >         
>         >         It's my understanding that everything within the
>         >         <body> tag is considered body content, and the new
>         >         <header> and <footer> tags, etc, are just there to
>         >         give more meaning about the type of body content.
>         >         
>         >         Thanks,
>         >         Ash
>         >         http://www.ashleysheridan.co.uk
>         >         
>         >         
>         >         
>         >         
>         > 
>         > 
>         > 
>         
>         
>         
>         
>         The fact that there is so much irrelevant content inside the
>         <body> tag is because some people consider that body content.
>         Do you have a more specific example of this?
>         
>         
>         
>         Thanks,
>         Ash
>         http://www.ashleysheridan.co.uk
>         
>         
>         
> 
> 


I believe there was a proposal for an <advert> tag purely for adverts (I
don't remember where I heard it) but it wasn't a realistic idea. If we
could easily identify content we didn't want to see, and could strip it
out before it even got to our browser, what incentive would people have
to use it if the adverts are their only source of revenue? As such, it's
not very feasible to distinguish between different types of content, and
even if there were tags, a lot of people wouldn't use them because it
would have a negative impact.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From danielperssondeluxe at gmail.com  Fri Jun  4 09:39:56 2010
From: danielperssondeluxe at gmail.com (Daniel Persson)
Date: Fri, 4 Jun 2010 18:39:56 +0200
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <1275667634.2217.80.camel@localhost>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
Message-ID: <AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>

I am not advocating ad-tags. The idea of globally structuring content on the
web is very appealing, it would make it easier for a lot of things and a lot
of people. Let's do it!
...but I can't see it happening where <body> would be main content + ads +
anything there is not a sensible tag for + anything a
lazy/stressed/unconscious author didn't tag otherwise. Let's just have a
main content tag or a strong main content strategy.

Thanks
/Daniel


On Fri, Jun 4, 2010 at 6:07 PM, Ashley Sheridan <ash at ashleysheridan.co.uk>wrote:

>  On Fri, 2010-06-04 at 18:03 +0200, Daniel Persson wrote:
>
> Some websites are very crowded. I have no particular example. Blogs and
> easily accessible CMS's, people trying to make a buck from excessive
> advertising on their site, people cramming a lot of info/screen unit.
> Companies too, old media: http://www.aftonbladet.se/ (major Swedish paper,
> watch your eyes) . <body> will hold a lot of stuff that is not main content,
> other content will spill over into <body> (unless there is a conscious
> author, and vast use of <aside>).
>
>  It should be easy for authors to define main content. It s a pedagogical
> issue, where authors not too concerned with standards compliance, should
> have an easy escape of at least defining the most important on the site.
>
>
>
>  Thanks
>
>  /Daniel
>
>
>
>
>
>
>  On Fri, Jun 4, 2010 at 5:10 PM, Ashley Sheridan <ash at ashleysheridan.co.uk>
> wrote:
>
>
>   On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote:
>
> If i view the html-web as it is now, inside <body> there are so much
> irrelevant content (where else to put it?). In order for <body> to be the
> main content, there has to be tags for everything else. This will be very
> hard for authors to implement (I am talking real world, amateur,
> do-it-yourself, stressed professionals). It is IMHO very beautiful
> code-wise, and organisationally, to state that everything in <body> is main
> content, but it will not benefit a structurally marked-up web.
>
>
> Thanks
> /Daniel
>
> On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan <ash at ashleysheridan.co.uk>
> wrote:
>
>
> On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote:
>
> I am the one posting the question on the help list. To me, the lack of
> html5 definition of main content, ie body copy in paper publishing, is a big
> mistake. Imagine the amount of sites where "everything else" includes a lot
> of unimportant extra, or peripheral, content. Content which is not
> necessarily hierarchically legible by a machine. Getting authors to be
> disciplined about defining main content is more important than being
> disciplined about <nav>, <footer>, <header>, <section> etc, in order not to
> negate the meaning of html5 structural mark-up.
>
>
> Suggestion <bodycopy>... or, preferred, <bread>.
>
>
> /Daniel
>
> On Fri, Jun 4, 2010 at 1:55 PM, Smylers <Smylers at stripey.com> wrote:
>
> The HTML5 spec should define how to mark up the main content on a page
> (even if the answer is "by omission"). This is something that many
> authors ask about, the latest example being today's thread on the help
> mailing list:
> http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>
> Please could this be added to the 'idioms' section, perhaps giving
> examples of when <article> or <section> might be appropriate as well as
> one in which the main content is simply that which isn't in <header>,
> <aside>, etc.
>
> Thanks.
>
> Smylers
> --
> http://twitter.com/Smylers2
>
>
>
>
>
> It's my understanding that everything within the <body> tag is considered
> body content, and the new <header> and <footer> tags, etc, are just there to
> give more meaning about the type of body content.
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
>
>
>
>
>   The fact that there is so much irrelevant content inside the <body> tag
> is because some people consider that body content. Do you have a more
> specific example of this?
>
>
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
>
> I believe there was a proposal for an <advert> tag purely for adverts (I
> don't remember where I heard it) but it wasn't a realistic idea. If we could
> easily identify content we didn't want to see, and could strip it out before
> it even got to our browser, what incentive would people have to use it if
> the adverts are their only source of revenue? As such, it's not very
> feasible to distinguish between different types of content, and even if
> there were tags, a lot of people wouldn't use them because it would have a
> negative impact.
>
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/18a1d638/attachment-0001.htm>

From admin at subcide.com  Fri Jun  4 09:43:07 2010
From: admin at subcide.com (Steve Dennis)
Date: Fri, 4 Jun 2010 17:43:07 +0100
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
Message-ID: <33E342D9-5DA4-4715-9EBA-74C3B419C131@subcide.com>

The purpose of all the new tags, is so the machine can figure out what is NOT main content, and assume everything else is.  With proper use of sectioning and aside as well as header and footers this can be mostly achieved today.

On 4/06/2010, at 5:39 PM, Daniel Persson wrote:

> I am not advocating ad-tags. The idea of globally structuring content on the web is very appealing, it would make it easier for a lot of things and a lot of people. Let's do it!
> ...but I can't see it happening where <body> would be main content + ads + anything there is not a sensible tag for + anything a lazy/stressed/unconscious author didn't tag otherwise. Let's just have a main content tag or a strong main content strategy.
> 
> Thanks
> /Daniel
> 
> 
> On Fri, Jun 4, 2010 at 6:07 PM, Ashley Sheridan <ash at ashleysheridan.co.uk> wrote:
> On Fri, 2010-06-04 at 18:03 +0200, Daniel Persson wrote:
>> 
>> Some websites are very crowded. I have no particular example. Blogs and easily accessible CMS's, people trying to make a buck from excessive advertising on their site, people cramming a lot of info/screen unit. Companies too, old media: http://www.aftonbladet.se/ (major Swedish paper, watch your eyes) . <body> will hold a lot of stuff that is not main content, other content will spill over into <body> (unless there is a conscious author, and vast use of <aside>). 
>> It should be easy for authors to define main content. It s a pedagogical issue, where authors not too concerned with standards compliance, should have an easy escape of at least defining the most important on the site.
>> 
>> 
>> Thanks
>> /Daniel
>> 
>> 
>> 
>> 
>> 
>> On Fri, Jun 4, 2010 at 5:10 PM, Ashley Sheridan <ash at ashleysheridan.co.uk> wrote:
>> 
>> On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote:
>>> If i view the html-web as it is now, inside <body> there are so much irrelevant content (where else to put it?). In order for <body> to be the main content, there has to be tags for everything else. This will be very hard for authors to implement (I am talking real world, amateur, do-it-yourself, stressed professionals). It is IMHO very beautiful code-wise, and organisationally, to state that everything in <body> is main content, but it will not benefit a structurally marked-up web.
>>> 
>>> 
>>> Thanks
>>> /Daniel
>>> 
>>> On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan <ash at ashleysheridan.co.uk> wrote:
>>> 
>>> On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote:
>>>> I am the one posting the question on the help list. To me, the lack of html5 definition of main content, ie body copy in paper publishing, is a big mistake. Imagine the amount of sites where "everything else" includes a lot of unimportant extra, or peripheral, content. Content which is not necessarily hierarchically legible by a machine. Getting authors to be disciplined about defining main content is more important than being disciplined about <nav>, <footer>, <header>, <section> etc, in order not to negate the meaning of html5 structural mark-up. 
>>>> 
>>>> 
>>>> Suggestion <bodycopy>... or, preferred, <bread>.
>>>> 
>>>> 
>>>> /Daniel
>>>> 
>>>> On Fri, Jun 4, 2010 at 1:55 PM, Smylers <Smylers at stripey.com> wrote:
>>>> The HTML5 spec should define how to mark up the main content on a page
>>>> (even if the answer is "by omission"). This is something that many
>>>> authors ask about, the latest example being today's thread on the help
>>>> mailing list:
>>>> http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html
>>>> 
>>>> Please could this be added to the 'idioms' section, perhaps giving
>>>> examples of when <article> or <section> might be appropriate as well as
>>>> one in which the main content is simply that which isn't in <header>,
>>>> <aside>, etc.
>>>> 
>>>> Thanks.
>>>> 
>>>> Smylers
>>>> --
>>>> http://twitter.com/Smylers2 
>>>> 
>>>> 
>>> 
>>> 
>>> It's my understanding that everything within the <body> tag is considered body content, and the new <header> and <footer> tags, etc, are just there to give more meaning about the type of body content.
>>> 
>>> Thanks,
>>> Ash
>>> http://www.ashleysheridan.co.uk
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> The fact that there is so much irrelevant content inside the <body> tag is because some people consider that body content. Do you have a more specific example of this?
>> 
>> 
>> Thanks,
>> Ash
>> http://www.ashleysheridan.co.uk
>> 
>> 
>> 
>> 
> 
> I believe there was a proposal for an <advert> tag purely for adverts (I don't remember where I heard it) but it wasn't a realistic idea. If we could easily identify content we didn't want to see, and could strip it out before it even got to our browser, what incentive would people have to use it if the adverts are their only source of revenue? As such, it's not very feasible to distinguish between different types of content, and even if there were tags, a lot of people wouldn't use them because it would have a negative impact.
> 
> 
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 
> 

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

From jackalmage at gmail.com  Fri Jun  4 09:43:55 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 4 Jun 2010 09:43:55 -0700
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com> 
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com> 
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com> 
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
Message-ID: <AANLkTikBfbFKdr8HX7x43TSnqy0IY1Ebjl5YK1jdFXSb@mail.gmail.com>

On Fri, Jun 4, 2010 at 9:39 AM, Daniel Persson
<danielperssondeluxe at gmail.com> wrote:
>
> I am not advocating ad-tags. The idea of globally structuring content on the web is very appealing, it would make it easier for a lot of things and a lot of people. Let's do it!
> ...but I can't see it happening where <body> would be main content + ads + anything there is not a sensible tag for + anything a lazy/stressed/unconscious author didn't tag otherwise. Let's just have a main content tag or a strong main content strategy.

Authors can either use <aside> to mark up all the irrelevant stuff on
their page that isn't main content, or they can wrap the main content
in an <article> (not ideal, but workable).

~TJ

From rob at mtn-i.com  Fri Jun  4 10:05:01 2010
From: rob at mtn-i.com (Rob Evans)
Date: Fri, 4 Jun 2010 18:05:01 +0100
Subject: [whatwg] Canvas putImageData - Can we scale?
Message-ID: <064c01cb0408$123c6af0$36b540d0$@com>

Hi,

 

                I wonder if this is the correct place to post this but I
cannot find any resources online as canvas is so new.

 

                After grabbing some image data from a canvas with the
getImageData call, I cannot find a way to put the image data onto a canvas
scaled down.

 

                If I use the canvas scale function and then put the image
data, no scaling occurs. Is there any way to scale with putImageData?

 

                If not I think it would be a useful addition to the
specification. I can imagine many situations where copying a section of the
canvas and applying scaling before pasting it back to the canvas would be
useful!

 

Thanks,

 

Rob Evans

CTO

mtn-i LTD

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

From glsimpso at indiana.edu  Fri Jun  4 10:18:06 2010
From: glsimpso at indiana.edu (Simpson, Grant Leyton)
Date: Fri, 4 Jun 2010 13:18:06 -0400
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
Message-ID: <6DB3B6CC-8404-4D44-8B39-F72FC2E57DDF@indiana.edu>

But wouldn't we create a situation where the main content tag is misused and essentially then we'd recreate the situation with <body>?

Best,
Grant

On Jun 4, 2010, at 12:39 PM, Daniel Persson wrote:

I am not advocating ad-tags. The idea of globally structuring content on the web is very appealing, it would make it easier for a lot of things and a lot of people. Let's do it!
...but I can't see it happening where <body> would be main content + ads + anything there is not a sensible tag for + anything a lazy/stressed/unconscious author didn't tag otherwise. Let's just have a main content tag or a strong main content strategy.

Thanks
/Daniel


On Fri, Jun 4, 2010 at 6:07 PM, Ashley Sheridan <ash at ashleysheridan.co.uk<mailto:ash at ashleysheridan.co.uk>> wrote:
On Fri, 2010-06-04 at 18:03 +0200, Daniel Persson wrote:
Some websites are very crowded. I have no particular example. Blogs and easily accessible CMS's, people trying to make a buck from excessive advertising on their site, people cramming a lot of info/screen unit. Companies too, old media: http://www.aftonbladet.se/ (major Swedish paper, watch your eyes) . <body> will hold a lot of stuff that is not main content, other content will spill over into <body> (unless there is a conscious author, and vast use of <aside>).
It should be easy for authors to define main content. It s a pedagogical issue, where authors not too concerned with standards compliance, should have an easy escape of at least defining the most important on the site.


Thanks
/Daniel





On Fri, Jun 4, 2010 at 5:10 PM, Ashley Sheridan <ash at ashleysheridan.co.uk<mailto:ash at ashleysheridan.co.uk>> wrote:

On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote:
If i view the html-web as it is now, inside <body> there are so much irrelevant content (where else to put it?). In order for <body> to be the main content, there has to be tags for everything else. This will be very hard for authors to implement (I am talking real world, amateur, do-it-yourself, stressed professionals). It is IMHO very beautiful code-wise, and organisationally, to state that everything in <body> is main content, but it will not benefit a structurally marked-up web.


Thanks
/Daniel

On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan <ash at ashleysheridan.co.uk<mailto:ash at ashleysheridan.co.uk>> wrote:

On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote:
I am the one posting the question on the help list. To me, the lack of html5 definition of main content, ie body copy in paper publishing, is a big mistake. Imagine the amount of sites where "everything else" includes a lot of unimportant extra, or peripheral, content. Content which is not necessarily hierarchically legible by a machine. Getting authors to be disciplined about defining main content is more important than being disciplined about <nav>, <footer>, <header>, <section> etc, in order not to negate the meaning of html5 structural mark-up.


Suggestion <bodycopy>... or, preferred, <bread>.


/Daniel

On Fri, Jun 4, 2010 at 1:55 PM, Smylers <Smylers at stripey.com<mailto:Smylers at stripey.com>> wrote:
The HTML5 spec should define how to mark up the main content on a page
(even if the answer is "by omission"). This is something that many
authors ask about, the latest example being today's thread on the help
mailing list:
http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html

Please could this be added to the 'idioms' section, perhaps giving
examples of when <article> or <section> might be appropriate as well as
one in which the main content is simply that which isn't in <header>,
<aside>, etc.

Thanks.

Smylers
--
http://twitter.com/Smylers2




It's my understanding that everything within the <body> tag is considered body content, and the new <header> and <footer> tags, etc, are just there to give more meaning about the type of body content.

Thanks,
Ash
http://www.ashleysheridan.co.uk<http://www.ashleysheridan.co.uk/>









The fact that there is so much irrelevant content inside the <body> tag is because some people consider that body content. Do you have a more specific example of this?


Thanks,
Ash
http://www.ashleysheridan.co.uk<http://www.ashleysheridan.co.uk/>






I believe there was a proposal for an <advert> tag purely for adverts (I don't remember where I heard it) but it wasn't a realistic idea. If we could easily identify content we didn't want to see, and could strip it out before it even got to our browser, what incentive would people have to use it if the adverts are their only source of revenue? As such, it's not very feasible to distinguish between different types of content, and even if there were tags, a lot of people wouldn't use them because it would have a negative impact.


Thanks,
Ash
http://www.ashleysheridan.co.uk<http://www.ashleysheridan.co.uk/>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/1de916c2/attachment-0001.htm>

From oliver at apple.com  Fri Jun  4 10:40:16 2010
From: oliver at apple.com (Oliver Hunt)
Date: Fri, 4 Jun 2010 10:40:16 -0700
Subject: [whatwg] Canvas putImageData - Can we scale?
In-Reply-To: <064c01cb0408$123c6af0$36b540d0$@com>
References: <064c01cb0408$123c6af0$36b540d0$@com>
Message-ID: <8EDC98C1-2C8B-4FBB-A9CA-77E070D48D03@apple.com>

On Jun 4, 2010, at 10:05 AM, Rob Evans wrote:

> Hi,
>  
>                 I wonder if this is the correct place to post this but I cannot find any resources online as canvas is so new.
Canvas isn't new -- it's at least 4 or 5 years old, and has been in the html5 spec for at least 2 or 3 of those years -- I believe the MDC has some of the best API documentation (at least in terms of providing examples of how the APIs are used.)

>  
>                 After grabbing some image data from a canvas with the getImageData call, I cannot find a way to put the image data onto a canvas scaled down.
>  
>                 If I use the canvas scale function and then put the image data, no scaling occurs. Is there any way to scale with putImageData?

No. The ImageData API documentation is very clear on this, and has not changed substantively in a few years now.  get/putImageData are not effected by the current CTM.


>                 If not I think it would be a useful addition to the specification. I can imagine many situations where copying a section of the canvas and applying scaling before pasting it back to the canvas would be useful!

You shouldn't be using ImageData to do this -- CanvasRenderingContext2D.drawImage supports canvas elements, and has well defined semantics for drawing the contents of a canvas element into its own context -- in addition to supporting non-identity CTMs this is also likely quite a bit faster in the identity case than an imagedata based approach.  Is there some specific reason you want to use the ImageData API?

--Oliver
>  
> Thanks,
>  
> Rob Evans
> CTO
> mtn-i LTD

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

From rob at mtn-i.com  Fri Jun  4 10:57:40 2010
From: rob at mtn-i.com (Rob Evans)
Date: Fri, 4 Jun 2010 18:57:40 +0100
Subject: [whatwg] Canvas putImageData - Can we scale?
In-Reply-To: <8EDC98C1-2C8B-4FBB-A9CA-77E070D48D03@apple.com>
References: <064c01cb0408$123c6af0$36b540d0$@com>
	<8EDC98C1-2C8B-4FBB-A9CA-77E070D48D03@apple.com>
Message-ID: <066301cb040f$6d544190$47fcc4b0$@com>

1: My bad.

2: Fair enough.

3: Thanks, I had totally skipped the extra parameters available on the
drawImage function... oops. I think I'll blog it so anyone else who
skim-reads the MDC will find my mistake on google when they search!

 

From: Oliver Hunt [mailto:oliver at apple.com] 
Sent: 04 June 2010 18:40
To: Rob Evans
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Canvas putImageData - Can we scale?

 

On Jun 4, 2010, at 10:05 AM, Rob Evans wrote:





Hi,

 

                I wonder if this is the correct place to post this but I
cannot find any resources online as canvas is so new.

Canvas isn't new -- it's at least 4 or 5 years old, and has been in the
html5 spec for at least 2 or 3 of those years -- I believe the MDC has some
of the best API documentation (at least in terms of providing examples of
how the APIs are used.)





 

                After grabbing some image data from a canvas with the
getImageData call, I cannot find a way to put the image data onto a canvas
scaled down.

 

                If I use the canvas scale function and then put the image
data, no scaling occurs. Is there any way to scale with putImageData?

 

No. The ImageData API documentation is very clear on this, and has not
changed substantively in a few years now.  get/putImageData are not effected
by the current CTM.

 





                If not I think it would be a useful addition to the
specification. I can imagine many situations where copying a section of the
canvas and applying scaling before pasting it back to the canvas would be
useful!

 

You shouldn't be using ImageData to do this --
CanvasRenderingContext2D.drawImage supports canvas elements, and has well
defined semantics for drawing the contents of a canvas element into its own
context -- in addition to supporting non-identity CTMs this is also likely
quite a bit faster in the identity case than an imagedata based approach.
Is there some specific reason you want to use the ImageData API?

 

--Oliver



 

Thanks,

 

Rob Evans

CTO

mtn-i LTD

 

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

From asargent at google.com  Fri Jun  4 11:22:49 2010
From: asargent at google.com (Antony Sargent)
Date: Fri, 4 Jun 2010 11:22:49 -0700
Subject: [whatwg] Installable web apps
In-Reply-To: <676E0E73-B0F0-4D76-B45A-6EC0CF47228D@iki.fi>
References: <938287364.274872.1274872436319.JavaMail.root@cm-mail03.mozilla.org>
	<1992128521.274961.1274873457250.JavaMail.root@cm-mail03.mozilla.org> 
	<AANLkTineMrFwRNFrbrd9VOLwAa5nbMCVGeveNehsw-mS@mail.gmail.com> 
	<676E0E73-B0F0-4D76-B45A-6EC0CF47228D@iki.fi>
Message-ID: <AANLkTil06Yll4Mv1fEVeXADzJHS8HFTEi1uH14GaueSV@mail.gmail.com>

On Fri, Jun 4, 2010 at 4:58 AM, Henri Sivonen <hsivonen at iki.fi> wrote:

> After googling around a bit, I was unable to find a signed .crx file for
> analysis. (I took apart 3 .crx files and gave up.) Is the signing mechanism
> documented somewhere? .wgt reinvents the .jar signing wheel by the basic
> idea of .jar signing with XML Signatures.
>

All .crx files are signed - they're just a zip with the public key and
signature appended on to them. The chrome extensions gallery has lots of
them:

https://chrome.google.com/extensions

For developers who choose to use it, the gallery takes care of
generating/storing the private key and signing new versions. They just
upload a plain zip file with their extension's resources. For those who want
to do this themselves, the developer tools on the chrome://extensions page
inside chrome itself lets you create a signed .crx file.


You can find some documentation here:
http://code.google.com/chrome/extensions/packaging.html

And here's the browser code to create .crx files:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_creator.cc

<http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_creator.cc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/9fe527c0/attachment-0001.htm>

From aa at google.com  Fri Jun  4 11:25:18 2010
From: aa at google.com (=?UTF-8?B?QWFyb24gQm9vZG1hbiAo5YqJKQ==?=)
Date: Fri, 4 Jun 2010 11:25:18 -0700
Subject: [whatwg] Installable web apps
In-Reply-To: <676E0E73-B0F0-4D76-B45A-6EC0CF47228D@iki.fi>
References: <938287364.274872.1274872436319.JavaMail.root@cm-mail03.mozilla.org>
	<1992128521.274961.1274873457250.JavaMail.root@cm-mail03.mozilla.org>
	<AANLkTineMrFwRNFrbrd9VOLwAa5nbMCVGeveNehsw-mS@mail.gmail.com>
	<676E0E73-B0F0-4D76-B45A-6EC0CF47228D@iki.fi>
Message-ID: <AANLkTikJFyS785j23HI2nJWtLgIexhxxJW6lZwmBONR7@mail.gmail.com>

On Fri, Jun 4, 2010 at 4:58 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On May 26, 2010, at 20:10, Aaron Boodman wrote:
>
>> This isn't really the point of this mail, but I just want to point out
>> that there are more differences between wgt and crx than the format of
>> the manifest file. The most important is that the identify of a crx
>> file is a public key, and all crx files are self-signed by their key.
>> This makes a crx file's identity unforgeable.
>
> .wgt supports signing, too, but as with Sun .jar or Mozilla .xpi the signing proves that the .wgt came from the entity that the private key belongs to as certified by PKI--as opposed to proving without PKI that it came from the same source as the previous version of the .wgt.
>
> After googling around a bit, I was unable to find a signed .crx file for analysis. (I took apart 3 .crx files and gave up.) Is the signing mechanism documented somewhere? .wgt reinvents the .jar signing wheel by the basic idea of .jar signing with XML Signatures.
>
> (Note that I am not in any way implying that PKI were better. If Google can actually get extension authors to sign their extensions on average and proving that extension updates came from the same source as the previous version, that's a pretty big win over the Firefox extension signing situation. In principle, Firefox extensions can be signed to the stronger level of proving who signed them as opposed to proving just "same as before", but in practice, virtually no one--not even Mozilla Labs--signs Firefox extensions, so it doesn't help much that the level of proof would be stronger if signed.)

Every crx file is signed. The signature and public key are part of the
zip file itself, just after the signature. The zip format allows extra
data there. When you took apart those crx files, if you used 'unzip'
from the command line, you may have seen 'Ignoring xx bytes of extra
data...'. That was the public key and signature being discarded :).

For the most part developers don't know or care about the details of
how signing works. We tried really hard to make it something that just
happens as part of developing your extension.

For users who host on our gallery, it is totally hidden. They just
upload zip files and the the gallery manages the key.

For users who self-host, they will be aware that there is something
called a "key file" that contains gibberish, which they need to keep
safe and need to use each time they package their extension.

You can get a feel for what this is like from a developer's point of view here:

http://code.google.com/chrome/extensions/packaging.html

If you're interested in the actual format, it has been a longstanding
todo to document it precisely :-/ But it is basically: <zip
header><crx version><key><signature><zip data>. Somebody created a
tiny ruby script that does it, here:

http://github.com/Constellation/crxmake/blob/master/lib/crxmake.rb#-196

>>> I think it follows that to install a Web app, you navigate to its URL and bookmark it. There is no need to have an icon in a zip file for this: HTML5 already provides <link rel=icon sizes=... that the app can use to declare its icon, which can be pinned to cache upon bookmarking. So far, nothing new to design.
>>>
>>> A plain bookmark doesn't elevate the bookmarked app sufficiently to be special in the system app switcher (like Prism) or inside the tab system of the browser (like Firefox 4 application tabs). A plain bookmark also doesn't pre-grant any permissions or ensure that the app stays in the cache.
>>>
>>> I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To "install" a Web application, the user would navigate to the app's URL and create an application bookmark.
>>
>> For Chrome this isn't the UX we want. We want users to click a link in
>> the content area and be presented with an install dialog. We think
>> that going to something in the browser to "applicationify" a web app
>> is too indirect and that many users will not get it.
>>
>> That said, I think there is room to support multiple models of
>> installation (or bookmarking, or whatever you want to call it),
>> though.
>
> Why don't you want the UX of the applicatinification process starting from browser chrome? Screen real estate reasons? Expectation or research showing that users don't understand the difference anyway?

Our experience is that:

a) Users typically don't see this kind of UI in the browser chrome.
The easy example is the feed badge in the URL bar, which fails with
normal people. To make this more discoverable, browsers ended up
supporting navigating directly to a feed file to initiate
feedification.

b) Because users miss the browser UI, developers end up wanting to
help and end up resorting to terrible things like putting a big arrow
in their content that says "click over there >>".

> Don't you need an annoying "This site is trying to applicationify itself. Allow or Deny?" piece of UI if the site can start the process?

Yes, and we need to only honor the script call if it comes from a user
gesture. But we still think on the whole this is a better tradeoff.

But like I said, I think there's room for both kinds of UX. And in
fact, Chrome may some day support both kinds. But to start we are most
interested in content-initiated.

>> - Application name (you didn't mention this, but I think it is nice to
>> have distinct from the <title>, which is often overloaded with status
>> information)
>
> As Lachy mentioned, there's already in-document syntax for this:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta-application-name
>
> I'm not aware of anyone implementing it, though.

Actually Chrome implements it for our application shortcuts :-/. Left
hand, meet right hand.

>> Another one that we would like in Chrome is a path prefix for the app.
>> This is to handle the case of applications like Google Reader which
>> are on http://www.google.com/reader.
>
> How does giving permissions to a prefixed application interact with the origin-based security model?

Poorly. Origin is baked so low into the platform, it is the true
boundary, and that can probably never be changed. In Chrome, we can
get close because we can enforce process isolation based on the path,
but it is an ongoing project to make that bulletproof that might never
complete.

However, I think it is still useful to know the paths an application
uses. One example of this is storage.

It would be really nice to be able to show users storage used by
applications ("Google Docs", "Google Reader"). But this isn't possible
since many apps are frequently served from the same origin. The best
we can currently do is "www.google.com".

If we add paths to the mix, we can do this. Applications on the same
origin can circumvent it if they want, but why would they? SOP already
guarantees that apps on the same origin are friendly and cooperate
with each other. That doesn't mean it isn't useful for the UA to know
which one is which.

>> Every URL in an application will have to <link> to this same
>> information. It seems like it would be better to just <link> to a
>> separate resource that contains the information.
>>
>> To me, this all leads to the following proposal:
>>
>> <html>
>> <head>
>> <!-- for UAs that want a button in the browser chrome to appify -->
>> <link rel="application-description" href="myapp.json">
>> </head>
>> <body>
>> <!-- for UAs that want a button in the Chrome to appify -->
>> <button onclick="navigator.installApplication()">install</button>
>> </body>
>> </html>
>>
>> // myapp.json
>> {
>> ?"name": "My Application",
>> ?"icons": ...,
>> ?"urls": [
>> ? ?"reader/"
>> ?],
>> ?"permissions": [
>> ? ?...
>> ?]
>> }
>>
>> WDYT?
>
> Makes sense to me (if you add sniffing for navigator.installApplication before showing a button that calls it), although I doubt you'll be able to avoid repeating a <link> to the icon anyway.

As I said in my follow up email to this one, I do agree it is a shame
to not use the platform features that have already been added that
start to meet these needs. I think it is worth starting by trying to
just reuse those.

Thanks for the feedback,

- a

From rescator at emsai.net  Fri Jun  4 12:58:24 2010
From: rescator at emsai.net (=?ISO-8859-1?Q?Roger_H=E5gensen?=)
Date: Fri, 04 Jun 2010 21:58:24 +0200
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>	<1275662231.2217.75.camel@localhost>	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>	<1275664221.2217.77.camel@localhost>	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
Message-ID: <4C095AE0.6060504@emsai.net>

On 2010-06-04 18:39, Daniel Persson wrote:
> I am not advocating ad-tags. The idea of globally structuring content 
> on the web is very appealing, it would make it easier for a lot of 
> things and a lot of people. Let's do it!
> ...but I can't see it happening where <body> would be main content + 
> ads + anything there is not a sensible tag for + anything a 
> lazy/stressed/unconscious author didn't tag otherwise. Let's just have 
> a main content tag or a strong main content strategy.
>

Hmm! It is a valid point actually.
Oh and here is some food for though. This works in all latest browsers. 
Opera and Firefox have same behavior, while Chrome is a tad different, 
and as IE is unable to style unknown tags sadly.

<!doctype html>
<html>
<head>
<title>Test</title>
<style>
   aside {border:1px solid #bf0000;white-space:nowrap;}
</style>
</head>
<aside>
  Just testing aside outside body!
</aside>
<body>
<article>
   Main part of article.
</article>
</body>
</html>

As you can see the aside is outside the body, all latest browsers seem 
to handle this pretty fine.
http://validator.w3.org/ on the other hand gives the error " /Line 12, 
Column 6/: body start tag found but the body element is already open.| 
<body*>*|"

Now, either that is a bug in the validator, or the body is automatic.
And sure enough, removing the <body> and </body> tags the document 
validates, and none of the browsers behave differently at all.
Is the body tag optional or could even be redundant in HTML5 ?

I don't mind really, as currently I only use body to put all the "other" 
tags inside, so not having to use the body tag at all would be welcome,
though I suspect a lot of legacy things rely on the body tag.

-- 
Roger "Rescator" H?gensen.
Freelancer - http://EmSai.net/

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

From jackalmage at gmail.com  Fri Jun  4 13:03:11 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 4 Jun 2010 13:03:11 -0700
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <4C095AE0.6060504@emsai.net>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com> 
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com> 
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com> 
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com> 
	<4C095AE0.6060504@emsai.net>
Message-ID: <AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>

On Fri, Jun 4, 2010 at 12:58 PM, Roger H?gensen <rescator at emsai.net> wrote:
> On 2010-06-04 18:39, Daniel Persson wrote:
>
> I am not advocating ad-tags. The idea of globally structuring content on the
> web is very appealing, it would make it easier for a lot of things and a lot
> of people. Let's do it!
> ...but I can't see it happening where <body> would be main content + ads +
> anything there is not a sensible tag for + anything a
> lazy/stressed/unconscious author didn't tag otherwise. Let's just have a
> main content tag or a strong main content strategy.
>
>
> Hmm! It is a valid point actually.
> Oh and here is some food for though. This works in all latest browsers.
> Opera and Firefox have same behavior, while Chrome is a tad different, and
> as IE is unable to style unknown tags sadly.
>
> <!doctype html>
> <html>
> <head>
> ?<title>Test</title>
> ?<style>
> ? aside {border:1px solid #bf0000;white-space:nowrap;}
> ?</style>
> </head>
> <aside>
> ?Just testing aside outside body!
> </aside>
> <body>
> ?<article>
> ? Main part of article.
> ?</article>
> </body>
> </html>
>
> As you can see the aside is outside the body, all latest browsers seem to
> handle this pretty fine.
> http://validator.w3.org/ on the other hand gives the error " Line 12, Column
> 6: body start tag found but the body element is already open. <body>"
>
> Now, either that is a bug in the validator, or the body is automatic.
> And sure enough, removing the <body> and </body> tags the document
> validates, and none of the browsers behave differently at all.
> Is the body tag optional or could even be redundant in HTML5 ?

<body> is optional.  It automatically gets added as soon as the parser
sees an element that doesn't belong in the <head>.  (The <head> is
optional too, as is the <html>.)  So the <aside> triggers a <body>
element to be created and opened, and then later explicit <body> tags
get dropped.

> I don't mind really, as currently I only use body to put all the "other"
> tags inside, so not having to use the body tag at all would be welcome,
> though I suspect a lot of legacy things rely on the body tag.

No browser depends on you using the <body> element explicitly.  It's
perfectly fine to write your document like this:

<!doctype html>
<title>Test</title>
<style>
  aside {border:1px solid #bf0000;white-space:nowrap;}
</style>
<aside>
  Just testing aside outside body!
</aside>
<article>
  Main part of article.
</article>

The <title> and <style> get auto-wrapped in a <head>, the <aside> and
<article> get auto-wrapped in a <body>, and the whole thing below the
doctype gets auto-wrapped in an <html>.

~TJ

From rescator at emsai.net  Fri Jun  4 13:16:38 2010
From: rescator at emsai.net (=?UTF-8?B?Um9nZXIgSMOlZ2Vuc2Vu?=)
Date: Fri, 04 Jun 2010 22:16:38 +0200
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<4C095AE0.6060504@emsai.net>
	<AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
Message-ID: <4C095F26.6020909@emsai.net>

On 2010-06-04 22:03, Tab Atkins Jr. wrote:
> On Fri, Jun 4, 2010 at 12:58 PM, Roger H?gensen<rescator at emsai.net>  wrote:
>> ...
>> As you can see the aside is outside the body, all latest browsers seem to
>> handle this pretty fine.
>> http://validator.w3.org/ on the other hand gives the error " Line 12, Column
>> 6: body start tag found but the body element is already open.<body>"
>>
>> Now, either that is a bug in the validator, or the body is automatic.
>> And sure enough, removing the<body>  and</body>  tags the document
>> validates, and none of the browsers behave differently at all.
>> Is the body tag optional or could even be redundant in HTML5 ?
> <body>  is optional.  It automatically gets added as soon as the parser
> sees an element that doesn't belong in the<head>.  (The<head>  is
> optional too, as is the<html>.)  So the<aside>  triggers a<body>
> element to be created and opened, and then later explicit<body>  tags
> get dropped.
>> I don't mind really, as currently I only use body to put all the "other"
>> tags inside, so not having to use the body tag at all would be welcome,
>> though I suspect a lot of legacy things rely on the body tag.
> No browser depends on you using the<body>  element explicitly.  It's
> perfectly fine to write your document like this:
>
> <!doctype html>
> <title>Test</title>
> <style>
>    aside {border:1px solid #bf0000;white-space:nowrap;}
> </style>
> <aside>
>    Just testing aside outside body!
> </aside>
> <article>
>    Main part of article.
> </article>
>
> The<title>  and<style>  get auto-wrapped in a<head>, the<aside>  and
> <article>  get auto-wrapped in a<body>, and the whole thing below the
> doctype gets auto-wrapped in an<html>.

Hmm! Intriguing. That is way cleaner than the "container" wrappers.
What browsers/engines behaves like that?
Does all HTML 4.01+ compliant browsers behave like this?

Roger.

-- 
Roger "Rescator" H?gensen.
Freelancer - http://EmSai.net/


From davis.peixoto at gmail.com  Fri Jun  4 13:25:04 2010
From: davis.peixoto at gmail.com (no body)
Date: Fri, 4 Jun 2010 13:25:04 -0700 (PDT)
Subject: [whatwg] no body wants to stay in touch on LinkedIn
Message-ID: <1682276978.1385007.1275683104166.JavaMail.app@ech3-cdn10.prod>

LinkedIn
------------

   
I'd like to add you to my professional network on LinkedIn.

- no body

no body
Student at Universidad de Montevideo
Uruguay

Confirm that you know no body
https://www.linkedin.com/e/isd/1361348824/0ScZquf7/


 
------
(c) 2010, LinkedIn Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/8a81bb02/attachment.htm>

From jackalmage at gmail.com  Fri Jun  4 13:28:31 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 4 Jun 2010 13:28:31 -0700
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <4C095F26.6020909@emsai.net>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com> 
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com> 
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com> 
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com> 
	<4C095AE0.6060504@emsai.net>
	<AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com> 
	<4C095F26.6020909@emsai.net>
Message-ID: <AANLkTilBilBY_uEOh7ATGuaaorLEHN62Cp_TjJ23NWcr@mail.gmail.com>

On Fri, Jun 4, 2010 at 1:16 PM, Roger H?gensen <rescator at emsai.net> wrote:
> On 2010-06-04 22:03, Tab Atkins Jr. wrote:
>>
>> On Fri, Jun 4, 2010 at 12:58 PM, Roger H?gensen<rescator at emsai.net>
>> ?wrote:
>>>
>>> ...
>>> As you can see the aside is outside the body, all latest browsers seem to
>>> handle this pretty fine.
>>> http://validator.w3.org/ on the other hand gives the error " Line 12,
>>> Column
>>> 6: body start tag found but the body element is already open.<body>"
>>>
>>> Now, either that is a bug in the validator, or the body is automatic.
>>> And sure enough, removing the<body> ?and</body> ?tags the document
>>> validates, and none of the browsers behave differently at all.
>>> Is the body tag optional or could even be redundant in HTML5 ?
>>
>> <body> ?is optional. ?It automatically gets added as soon as the parser
>> sees an element that doesn't belong in the<head>. ?(The<head> ?is
>> optional too, as is the<html>.) ?So the<aside> ?triggers a<body>
>> element to be created and opened, and then later explicit<body> ?tags
>> get dropped.
>>>
>>> I don't mind really, as currently I only use body to put all the "other"
>>> tags inside, so not having to use the body tag at all would be welcome,
>>> though I suspect a lot of legacy things rely on the body tag.
>>
>> No browser depends on you using the<body> ?element explicitly. ?It's
>> perfectly fine to write your document like this:
>>
>> <!doctype html>
>> <title>Test</title>
>> <style>
>> ? aside {border:1px solid #bf0000;white-space:nowrap;}
>> </style>
>> <aside>
>> ? Just testing aside outside body!
>> </aside>
>> <article>
>> ? Main part of article.
>> </article>
>>
>> The<title> ?and<style> ?get auto-wrapped in a<head>, the<aside> ?and
>> <article> ?get auto-wrapped in a<body>, and the whole thing below the
>> doctype gets auto-wrapped in an<html>.
>
> Hmm! Intriguing. That is way cleaner than the "container" wrappers.
> What browsers/engines behaves like that?
> Does all HTML 4.01+ compliant browsers behave like this?

All browsers that you could possibly care about (any FF, Safari,
Chrome, Opera, or IE produced in the last decade) should act like
that.  That's why it got specified - when everyone agrees on behavior,
it's a good thing to figure that out and standardize it.  ^_^

~TJ

From ash at ashleysheridan.co.uk  Fri Jun  4 13:32:07 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 04 Jun 2010 21:32:07 +0100
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTilBilBY_uEOh7ATGuaaorLEHN62Cp_TjJ23NWcr@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<4C095AE0.6060504@emsai.net>
	<AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
	<4C095F26.6020909@emsai.net>
	<AANLkTilBilBY_uEOh7ATGuaaorLEHN62Cp_TjJ23NWcr@mail.gmail.com>
Message-ID: <1275683527.2217.84.camel@localhost>

On Fri, 2010-06-04 at 13:28 -0700, Tab Atkins Jr. wrote:

> On Fri, Jun 4, 2010 at 1:16 PM, Roger H?gensen <rescator at emsai.net> wrote:
> > On 2010-06-04 22:03, Tab Atkins Jr. wrote:
> >>
> >> On Fri, Jun 4, 2010 at 12:58 PM, Roger H?gensen<rescator at emsai.net>
> >>  wrote:
> >>>
> >>> ...
> >>> As you can see the aside is outside the body, all latest browsers seem to
> >>> handle this pretty fine.
> >>> http://validator.w3.org/ on the other hand gives the error " Line 12,
> >>> Column
> >>> 6: body start tag found but the body element is already open.<body>"
> >>>
> >>> Now, either that is a bug in the validator, or the body is automatic.
> >>> And sure enough, removing the<body>  and</body>  tags the document
> >>> validates, and none of the browsers behave differently at all.
> >>> Is the body tag optional or could even be redundant in HTML5 ?
> >>
> >> <body>  is optional.  It automatically gets added as soon as the parser
> >> sees an element that doesn't belong in the<head>.  (The<head>  is
> >> optional too, as is the<html>.)  So the<aside>  triggers a<body>
> >> element to be created and opened, and then later explicit<body>  tags
> >> get dropped.
> >>>
> >>> I don't mind really, as currently I only use body to put all the "other"
> >>> tags inside, so not having to use the body tag at all would be welcome,
> >>> though I suspect a lot of legacy things rely on the body tag.
> >>
> >> No browser depends on you using the<body>  element explicitly.  It's
> >> perfectly fine to write your document like this:
> >>
> >> <!doctype html>
> >> <title>Test</title>
> >> <style>
> >>   aside {border:1px solid #bf0000;white-space:nowrap;}
> >> </style>
> >> <aside>
> >>   Just testing aside outside body!
> >> </aside>
> >> <article>
> >>   Main part of article.
> >> </article>
> >>
> >> The<title>  and<style>  get auto-wrapped in a<head>, the<aside>  and
> >> <article>  get auto-wrapped in a<body>, and the whole thing below the
> >> doctype gets auto-wrapped in an<html>.
> >
> > Hmm! Intriguing. That is way cleaner than the "container" wrappers.
> > What browsers/engines behaves like that?
> > Does all HTML 4.01+ compliant browsers behave like this?
> 
> All browsers that you could possibly care about (any FF, Safari,
> Chrome, Opera, or IE produced in the last decade) should act like
> that.  That's why it got specified - when everyone agrees on behavior,
> it's a good thing to figure that out and standardize it.  ^_^
> 
> ~TJ


And I'm guessing Fx too?

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From svartman95 at gmail.com  Fri Jun  4 13:36:35 2010
From: svartman95 at gmail.com (bjartur)
Date: Fri, 04 Jun 2010 20:36:35 +0000
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <4C095F26.6020909@emsai.net>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<4C095AE0.6060504@emsai.net>
	<AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
	<4C095F26.6020909@emsai.net>
Message-ID: <4c0963e4.0a41df0a.7bde.4253@mx.google.com>

On 2010-06-04 rescator at emsai.net wrote:
>On 2010-06-04 22:03, Tab Atkins Jr. wrote:
>> No browser depends on you using the<body>  element explicitly.  It's
>> perfectly fine to write your document like this:
>>
>> <!doctype html>
>> <title>Test</title>
>> <style>
>>    aside {border:1px solid #bf0000;white-space:nowrap;}
>> </style>
>> <aside>
>>    Just testing aside outside body!
>> </aside>
>> <article>
>>    Main part of article.
>> </article>
>>
>> The<title>  and<style>  get auto-wrapped in a<head>, the<aside>  and
>> <article>  get auto-wrapped in a<body>, and the whole thing below the
>> doctype gets auto-wrapped in an<html>.
>
>Hmm! Intriguing. That is way cleaner than the "container" wrappers.
>What browsers/engines behaves like that?
>Does all HTML 4.01+ compliant browsers behave like this?
As I understand it the opening and closing tags of the <html>, <head> and
<body> elements are optional so that whenever content that belongs in
one of those elements (such as text) is encountered it's automatically
opened. Same as <p> elements get closed when block content is encountered
(in HTML 4 that is). This is fully specified and documented and is in the
DTD.

This is valid HTML 4.

is in fact a valid HTML file with an empty <head>.

From Simetrical+w3c at gmail.com  Fri Jun  4 14:00:24 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 4 Jun 2010 17:00:24 -0400
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTimZNibwtQPLBNpgDUF62XarYBUFp9LexNFkRZA-@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTina1sAGNPs1F0VufYqRoefAKLKKImSrsbdShd27@mail.gmail.com>
	<AANLkTimZNibwtQPLBNpgDUF62XarYBUFp9LexNFkRZA-@mail.gmail.com>
Message-ID: <AANLkTine0vSyxmrPUcYQ6ZBx2af-Ug-qq65T5LZNpepa@mail.gmail.com>

On Thu, Jun 3, 2010 at 10:30 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On 6/3/10, TAMURA, Kent <tkent at chromium.org> wrote:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation
>>> If one of the controls is not being
>>> rendered<rendering.html#being-rendered>
>> ? (e.g. it has the hidden <editing.html#the-hidden-attribute> attribute set)
>> then user agents may report a script error.
>>
>
> That's about <input type="hidden">

No, it's not.  Look at the definition of "being rendered":

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#being-rendered

It gives the hidden *attribute* (not type) as an example.

From Simetrical+w3c at gmail.com  Fri Jun  4 14:24:13 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 4 Jun 2010 17:24:13 -0400
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<4C095AE0.6060504@emsai.net>
	<AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
Message-ID: <AANLkTinZEDxBpd4EBY4j0L6ftN4JdGdLleO1T2ZDu_2t@mail.gmail.com>

On Fri, Jun 4, 2010 at 4:03 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> No browser depends on you using the <body> element explicitly. ?It's
> perfectly fine to write your document like this:
>
> <!doctype html>
> <title>Test</title>
> <style>
> ?aside {border:1px solid #bf0000;white-space:nowrap;}
> </style>
> <aside>
> ?Just testing aside outside body!
> </aside>
> <article>
> ?Main part of article.
> </article>

It's unwise to omit <body> unless you can guarantee that the first
element in the body will actually trigger the end of the head.  In
your case, I believe that at least IE will put <aside> and <article>
in the head, because it doesn't recognize them as only belonging in
the body.  (It seems like the HTML5 parser does put it in the body --
although as far as I can tell, this means we can never introduce new
elements that can go in the head.)

On Fri, Jun 4, 2010 at 4:36 PM, bjartur <svartman95 at gmail.com> wrote:
> As I understand it the opening and closing tags of the <html>, <head> and
> <body> elements are optional so that whenever content that belongs in
> one of those elements (such as text) is encountered it's automatically
> opened. Same as <p> elements get closed when block content is encountered
> (in HTML 4 that is). This is fully specified and documented and is in the
> DTD.
>
> This is valid HTML 4.
>
> is in fact a valid HTML file with an empty <head>.

Something seems to have been left out of your e-mail, but anyway, a
valid HTML file cannot have an empty <head>.  All HTML documents must
have a <title> element, which must be contained in a <head>.  This was
true in HTML 4.01 just as it is in HTML5.

From ash at ashleysheridan.co.uk  Fri Jun  4 14:50:11 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 04 Jun 2010 22:50:11 +0100
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTimV7yTGc3FRVHT7UUFn5-euvOr9LJeEqpXYxeVK@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<4C095AE0.6060504@emsai.net>
	<AANLkTilgMq_IFi1K162F7V3X32m3G6LvzADmYehP_7bO@mail.gmail.com>
	<4C095F26.6020909@emsai.net>
	<AANLkTilBilBY_uEOh7ATGuaaorLEHN62Cp_TjJ23NWcr@mail.gmail.com>
	<1275683527.2217.84.camel@localhost>
	<AANLkTimV7yTGc3FRVHT7UUFn5-euvOr9LJeEqpXYxeVK@mail.gmail.com>
Message-ID: <1275688211.2217.85.camel@localhost>

On Fri, 2010-06-04 at 14:47 -0700, Tab Atkins Jr. wrote:

> On Fri, Jun 4, 2010 at 1:32 PM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> > On Fri, 2010-06-04 at 13:28 -0700, Tab Atkins Jr. wrote:
> > All browsers that you could possibly care about (any FF, Safari,
> > Chrome, Opera, or IE produced in the last decade) should act like
> > that.  That's why it got specified - when everyone agrees on behavior,
> > it's a good thing to figure that out and standardize it.  ^_^
> >
> > ~TJ
> >
> > And I'm guessing Fx too?
> 
> That would be the "FF" I referred to.  Firefox lost the battle to be
> abbreviated as "Fx" a *long* time ago.  ^_^
> 
> ~TJ


Someone should tell Mozilla about it then, because they still prefer
Fx ;)

http://www.mozilla.com/en-US/firefox/releases/1.5.html 

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From diego.perini at gmail.com  Fri Jun  4 14:58:29 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Fri, 4 Jun 2010 23:58:29 +0200
Subject: [whatwg] bubbling events on labels
Message-ID: <AANLkTilf7RXLyJ4UVVGsp2thSDrIFgZ0Ttusg3K5Wqbo@mail.gmail.com>

I have different behavior in browsers with the "checked" state of a checkbox
input element.

I have filed a ticket in Webkit and I am looking after some
advice/suggestion about the correct behavior expected from this HTML:

   <label>
     <input type="checkbox">
     <a href="#">Enable</a>
   </label>

It seems Safari/Chrome are discarding the click bubbling at the link level,
thus never reaching the label and not toggling the checkbox.

The behavior in Firefox/Opera and in Safari/Chrome is different and the
checkbox is correctly "checked" (as I would have expected).

Should a click on the link make the input checked ?

Thank you in advance, sincerely


Diego Perini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/139d8bc4/attachment.htm>

From jackalmage at gmail.com  Fri Jun  4 15:21:39 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 4 Jun 2010 15:21:39 -0700
Subject: [whatwg] bubbling events on labels
In-Reply-To: <AANLkTilf7RXLyJ4UVVGsp2thSDrIFgZ0Ttusg3K5Wqbo@mail.gmail.com>
References: <AANLkTilf7RXLyJ4UVVGsp2thSDrIFgZ0Ttusg3K5Wqbo@mail.gmail.com>
Message-ID: <AANLkTiml8gcR2XHYiJI5uOvENPseY2LY2iPZ1kD0I4DO@mail.gmail.com>

On Fri, Jun 4, 2010 at 2:58 PM, Diego Perini <diego.perini at gmail.com> wrote:
> I have different behavior in browsers with the "checked" state of a checkbox
> input element.
>
> I have filed a ticket in Webkit and I am looking after some
> advice/suggestion about the correct behavior expected from this HTML:
>
> ?? <label>
> ???? <input type="checkbox">
> ???? <a href="#">Enable</a>
> ?? </label>
>
> It seems Safari/Chrome are discarding the click bubbling at the link level,
> thus never reaching the label and not toggling the checkbox.
>
> The behavior in Firefox/Opera and in Safari/Chrome is different and the
> checkbox is correctly "checked" (as I would have expected).
>
> Should a click on the link make the input checked ?

As far as I can tell, section 3.5.2.1.7 (Interactive Content)
specifies that clicking the link in that situation should activate the
link and not toggle the checkbox.

~TJ

From ash at ashleysheridan.co.uk  Fri Jun  4 15:24:06 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 04 Jun 2010 23:24:06 +0100
Subject: [whatwg] bubbling events on labels
In-Reply-To: <AANLkTiml8gcR2XHYiJI5uOvENPseY2LY2iPZ1kD0I4DO@mail.gmail.com>
References: <AANLkTilf7RXLyJ4UVVGsp2thSDrIFgZ0Ttusg3K5Wqbo@mail.gmail.com>
	<AANLkTiml8gcR2XHYiJI5uOvENPseY2LY2iPZ1kD0I4DO@mail.gmail.com>
Message-ID: <1275690246.2217.87.camel@localhost>

On Fri, 2010-06-04 at 15:21 -0700, Tab Atkins Jr. wrote:

> On Fri, Jun 4, 2010 at 2:58 PM, Diego Perini <diego.perini at gmail.com> wrote:
> > I have different behavior in browsers with the "checked" state of a checkbox
> > input element.
> >
> > I have filed a ticket in Webkit and I am looking after some
> > advice/suggestion about the correct behavior expected from this HTML:
> >
> >    <label>
> >      <input type="checkbox">
> >      <a href="#">Enable</a>
> >    </label>
> >
> > It seems Safari/Chrome are discarding the click bubbling at the link level,
> > thus never reaching the label and not toggling the checkbox.
> >
> > The behavior in Firefox/Opera and in Safari/Chrome is different and the
> > checkbox is correctly "checked" (as I would have expected).
> >
> > Should a click on the link make the input checked ?
> 
> As far as I can tell, section 3.5.2.1.7 (Interactive Content)
> specifies that clicking the link in that situation should activate the
> link and not toggle the checkbox.
> 
> ~TJ


I do wonder though in what situation you would ever have that sort if
code layout and want the checkbox selected when the link is clicked.
Clicking the link will navigate away anyway, making the form element
useless in that context.

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100604/24e31f25/attachment-0001.htm>

From jackalmage at gmail.com  Fri Jun  4 15:26:43 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 4 Jun 2010 15:26:43 -0700
Subject: [whatwg] bubbling events on labels
In-Reply-To: <1275690246.2217.87.camel@localhost>
References: <AANLkTilf7RXLyJ4UVVGsp2thSDrIFgZ0Ttusg3K5Wqbo@mail.gmail.com> 
	<AANLkTiml8gcR2XHYiJI5uOvENPseY2LY2iPZ1kD0I4DO@mail.gmail.com> 
	<1275690246.2217.87.camel@localhost>
Message-ID: <AANLkTikLB1FobS3LMl957M4BoBjGxj9hVDTXo5UW6MjK@mail.gmail.com>

On Fri, Jun 4, 2010 at 3:24 PM, Ashley Sheridan
<ash at ashleysheridan.co.uk> wrote:
> On Fri, 2010-06-04 at 15:21 -0700, Tab Atkins Jr. wrote:
>> On Fri, Jun 4, 2010 at 2:58 PM, Diego Perini <diego.perini at gmail.com> wrote:
>>> I have different behavior in browsers with the "checked" state of a checkbox
>>> input element.
>>>
>>> I have filed a ticket in Webkit and I am looking after some
>>> advice/suggestion about the correct behavior expected from this HTML:
>>>
>>> ?? <label>
>>> ???? <input type="checkbox">
>>> ???? <a href="#">Enable</a>
>>> ?? </label>
>>>
>>> It seems Safari/Chrome are discarding the click bubbling at the link level,
>>> thus never reaching the label and not toggling the checkbox.
>>>
>>> The behavior in Firefox/Opera and in Safari/Chrome is different and the
>>> checkbox is correctly "checked" (as I would have expected).
>>>
>>> Should a click on the link make the input checked ?
>> As far as I can tell, section 3.5.2.1.7 (Interactive Content)
>> specifies that clicking the link in that situation should activate the
>> link and not toggle the checkbox.
>
> I do wonder though in what situation you would ever have that sort if code layout and want the checkbox selected when the link is clicked. Clicking the link will navigate away anyway, making the form element useless in that context.

Not if the link is just to a target on the page, like it is in the
example given.

~TJ

From jsalsman at gmail.com  Fri Jun  4 15:46:10 2010
From: jsalsman at gmail.com (James Salsman)
Date: Fri, 4 Jun 2010 15:46:10 -0700
Subject: [whatwg] WebSockets: UDP
In-Reply-To: <AANLkTiklQtzVw6fgYRqxgl2dUNMpAb5HlO3JyE2ZlZ3N@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTinbZOM-95txMblbUC9c8h1sElJ90XvBHmt58786@mail.gmail.com>
	<AANLkTiklQtzVw6fgYRqxgl2dUNMpAb5HlO3JyE2ZlZ3N@mail.gmail.com>
Message-ID: <AANLkTime4e8B54qtzOSfBvZSX8Y745DNYgTOwNXha314@mail.gmail.com>

On Fri, Jun 4, 2010 at 4:19 AM, James May <whatwg at fowlsmurf.net> wrote:
> Couldn't SCTP/DCCP (or a variant) over UDP (for NAT compatibility) work?

No, DCCP is much newer than most NAT hardware in operation.

When a client user agent is sending UDP, client-initiated TCP streams
such as HTTP or HTTPS persistent connections for all data from the
server including packet acknowledgment is likely to be the most
reliable.  Bandwidth from the server to the client is usually greater
than or equal to bandwidth from client to server.

From julian.reschke at gmx.de  Sat Jun  5 00:26:16 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 05 Jun 2010 09:26:16 +0200
Subject: [whatwg] ISSUE-86,
 Re: hixie: Remove the HTML-to-Atom mapping definition from the W3C
 version of the spec. (whatwg r5100)
In-Reply-To: <4C05EAC0.3020506@gmx.de>
References: <20100602042010.512582BCC3@toro.w3.mag.keio.ac.jp>
	<4C05EAC0.3020506@gmx.de>
Message-ID: <4C09FC18.9070605@gmx.de>

On 02.06.2010 07:23, Julian Reschke wrote:
> Hi Ian,
>
> thanks for the removal.
>
> I notice that you kept the text in the WHATWG version of the spec.
>
> Various problems have been reported with respect to the mapping, notably
>
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7806>
>
> and
>
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546>
> ...

For completeness, here's a related feature request:

   <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7545>

Best regards, Julian

From asqueella at gmail.com  Sat Jun  5 15:28:12 2010
From: asqueella at gmail.com (Nickolay Ponomarev)
Date: Sun, 6 Jun 2010 02:28:12 +0400
Subject: [whatwg] Why is DOMContentLoaded event not bubbling?
Message-ID: <AANLkTinR6WxtAUw50HlKYxOWYsfYCGq5T1V98tqWfesc@mail.gmail.com>

Hi,

Currently DOMContentLoaded is specified [1] with this sentence:
> Queue a task to fire a simple event named DOMContentLoaded at the
Document.

and "fire a simple event" is defined [2] as "does not bubble (except where
otherwise stated) and is not cancelable (except where otherwise stated)". So
it's not bubbling and, as far as I understand, per [3] it means it doesn't
bubble to Window.

I checked Gecko (trunk), Safari (4), Chrome (6) and in all of them it
bubbles to window and reports itself as bubbling. (Gecko also reports it as
cancellable, but it's a bug I think.)

The "fire simple event" wording was added [4] along with the comment that
"the firing of events needs to be unified", but that issue appears to be
resolved now, so is this a spec bug?

Nickolay

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#fire-a-simple-event
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#events-and-the-window-object
[4]
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2007/000041.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100606/1511cd3d/attachment.htm>

From danielperssondeluxe at gmail.com  Mon Jun  7 02:13:34 2010
From: danielperssondeluxe at gmail.com (Daniel Persson)
Date: Mon, 7 Jun 2010 11:13:34 +0200
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <6DB3B6CC-8404-4D44-8B39-F72FC2E57DDF@indiana.edu>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<6DB3B6CC-8404-4D44-8B39-F72FC2E57DDF@indiana.edu>
Message-ID: <AANLkTilBv7-w7yGnnMVVW0GQsuXQAKvbRfsLWtjPUUFs@mail.gmail.com>

> But wouldn't we create a situation where the main content tag is misused
> and essentially then we'd recreate the situation with <body>?
>

IMHO you can't stop tags from being misused, and that goes for any tag.

What I am taking about is that it is upside down to expect honest people to
define everything except the main content. Pedagogically and
methodologically. Main content is main content, the most important to
define. That should be the starting point for the structure.

Not all html-developing pros have a consciousness when it comes to writing
correct mark-up and the non-pros just want to publish their content. One of
the points of html5 is to make it easier to "do the right thing"
mark-up-wise, to be structured and in standards compliance.

The simplest tutorial on html5 authoring should be: Getting doctype and
charset right, html, head, body. Then define main content. Finished. Ready
to be indexed.

For the following tutorials, mark up the rest of the structure (if you can
be bothered/have the time/stamina/lust) learning all of the structural tags.
Then add all the bits and bobs that are not necessarily part of any
definable structure, finding some suitable tag for that gallery of lolcats
that is popping up when you hover a link. Many people interested in just
publishing their content will have dropped off by now, not really paying
attention to the correct tags as long as it works on the screen...

...bu at least the main content (as defined by the author) can be reached,
indexed, sorted or stacked by machines.

All the best
/Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/ff83a9da/attachment.htm>

From narendra at narendrasisodiya.com  Mon Jun  7 02:34:49 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Mon, 7 Jun 2010 15:04:49 +0530
Subject: [whatwg] What is not possible with HTML5
Message-ID: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>

May someone explore what is not possible with HTML5 in spec and in
Implementations

For example video telephony in browser is possible ? we draft DAP spec but
no implementations. So not possible at this moment.



-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/95404c02/attachment.htm>

From glsimpso at indiana.edu  Mon Jun  7 04:49:10 2010
From: glsimpso at indiana.edu (Simpson, Grant Leyton)
Date: Mon, 7 Jun 2010 07:49:10 -0400
Subject: [whatwg] 'Main Part of the Content' Idiom
In-Reply-To: <AANLkTilBv7-w7yGnnMVVW0GQsuXQAKvbRfsLWtjPUUFs@mail.gmail.com>
References: <20100604115527.GA15212@stripey.com>
	<AANLkTinKQvl4Imw9wfO5o3vsPjQP2q8lEF_dYdJjw3aL@mail.gmail.com>
	<1275662231.2217.75.camel@localhost>
	<AANLkTikfy1xgz3VKI_HQCIEMXLkDg0yr1xdnMs94xxKg@mail.gmail.com>
	<1275664221.2217.77.camel@localhost>
	<AANLkTikxdowgDAqm5LfGlSV_FmAne2wlVz0Sur0qgshP@mail.gmail.com>
	<1275667634.2217.80.camel@localhost>
	<AANLkTik1az36FI9Ik9h0ODBv0A8ftBniXbJQgaPV0OBx@mail.gmail.com>
	<6DB3B6CC-8404-4D44-8B39-F72FC2E57DDF@indiana.edu>
	<AANLkTilBv7-w7yGnnMVVW0GQsuXQAKvbRfsLWtjPUUFs@mail.gmail.com>
Message-ID: <BAD2C868-4FF2-4094-A05E-B2DD31E26DE8@indiana.edu>

For the record, I don't disagree with any of what you said below.

On Jun 7, 2010, at 5:13 AM, Daniel Persson wrote:


But wouldn't we create a situation where the main content tag is misused and essentially then we'd recreate the situation with <body>?

IMHO you can't stop tags from being misused, and that goes for any tag.

What I am taking about is that it is upside down to expect honest people to define everything except the main content. Pedagogically and methodologically. Main content is main content, the most important to define. That should be the starting point for the structure.

Not all html-developing pros have a consciousness when it comes to writing correct mark-up and the non-pros just want to publish their content. One of the points of html5 is to make it easier to "do the right thing" mark-up-wise, to be structured and in standards compliance.

The simplest tutorial on html5 authoring should be: Getting doctype and charset right, html, head, body. Then define main content. Finished. Ready to be indexed.

For the following tutorials, mark up the rest of the structure (if you can be bothered/have the time/stamina/lust) learning all of the structural tags. Then add all the bits and bobs that are not necessarily part of any definable structure, finding some suitable tag for that gallery of lolcats that is popping up when you hover a link. Many people interested in just publishing their content will have dropped off by now, not really paying attention to the correct tags as long as it works on the screen...

...bu at least the main content (as defined by the author) can be reached, indexed, sorted or stacked by machines.

All the best
/Daniel

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

From schalk at ossreleasefeed.com  Mon Jun  7 04:53:29 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Mon, 7 Jun 2010 13:53:29 +0200
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTilIZVyj9lMed_NcJTwkn4cU0KX1KxDWXuzD_s5J@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<op.vdqdxasc2q99of@coruscant>
	<AANLkTilIZVyj9lMed_NcJTwkn4cU0KX1KxDWXuzD_s5J@mail.gmail.com>
Message-ID: <00c601cb0638$0e9ac3b0$2bd04b10$@com>

I would also go with not using the visual state of an element as an indication of whether it needs to be validated or not but rather an additional attribute link the @hidden attribute proposed earlier.

I do see though that one might ask the question, how will I indicate an error on a specific field if that field is visually hidden? Good question but, that should be left up to the developer to handle and not the UA. Currently I reckon this is a problem as the UA decides where to place its validation, hoping there will be a way to override this behavior, if desired, in future.

Schalk

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Tab Atkins Jr.
Sent: Thursday, June 03, 2010 5:55 PM
To: Jo?o Eiras
Cc: TAMURA, Kent; whatwg; Ian Hickson
Subject: Re: [whatwg] Form validation against invisible controls

On Thu, Jun 3, 2010 at 8:42 AM, Jo?o Eiras <joaoe at opera.com> wrote:
> On Thu, 03 Jun 2010 16:16:00 +0100, TAMURA, Kent <tkent at chromium.org> wrote:
>
>>
>>
>>> > An element is a "candidate for constraint validation" if 1. it is 
>>> > a validatable type,
>>> >    e.g. true if <input type=number>, false if <input type=reset> 
>>> > 2. has no "disabled" attribute, 3. has no "readonly" attribute, 4. 
>>> > inside of a <form> element, 5. has non-empty "name" attribute, and 
>>> > 6. not inside of a <datalist> element.
>>> >
>>> > I hope ValidityState and the pseudo classes ignores 2-6.
>>
>>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now 
>>> removed.)
>>
>>
>> I'd like to propose to add another condition:
>>  7. it is visible (computed 'display' property of CSS isn't 'none' 
>> and no 'hidden' content attribute)
>>
>
> You'd need to check the visibility or display also of all ancestors, 
> that opacity is not 0, that the bounding box has enough size to render 
> the form to the user and etc.
> That's quite complicated to specify.
>
> Would be easier to tell that user agents might chose to ignore form 
> controls that they do not *paint* if that is possible for the UA to implement.

That's even worse - that defeats the time-honored trick to hide something visually without hiding it in any other way of absolutely positioning it off the screen.  It might even mean that elements currently off the screen (but that can be scrolled to) wouldn't validate.

~TJ


From mikewse at hotmail.com  Mon Jun  7 05:11:05 2010
From: mikewse at hotmail.com (Mike Wilson)
Date: Mon, 7 Jun 2010 14:11:05 +0200
Subject: [whatwg] Installable web apps
In-Reply-To: <AANLkTikJFyS785j23HI2nJWtLgIexhxxJW6lZwmBONR7@mail.gmail.com>
Message-ID: <04ea01cb063a$81fa85a0$0a01a8c0@mikedeskxp>

Aaron Boodman wrote:
> On Fri, Jun 4, 2010 at 4:58 AM, Henri Sivonen wrote:
> > On May 26, 2010, at 20:10, Aaron Boodman wrote:
> >> Another one that we would like in Chrome is a path prefix
> >> for the app.
> >> This is to handle the case of applications like Google Reader
> >> which are on http://www.google.com/reader.
> >
> > How does giving permissions to a prefixed application
> > interact with the origin-based security model?
>
> Poorly. Origin is baked so low into the platform, it is the true
> boundary, and that can probably never be changed. In Chrome, we can
> get close because we can enforce process isolation based on the path,
> but it is an ongoing project to make that bulletproof that might never
> complete.

Raising security based on path is interesting. FYI, there was a small
discussion about it last year:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/022412.html

Best regards
Mike Wilson 



From diego.perini at gmail.com  Mon Jun  7 06:41:50 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Mon, 7 Jun 2010 15:41:50 +0200
Subject: [whatwg] bubbling events on labels
In-Reply-To: <AANLkTikLB1FobS3LMl957M4BoBjGxj9hVDTXo5UW6MjK@mail.gmail.com>
References: <AANLkTilf7RXLyJ4UVVGsp2thSDrIFgZ0Ttusg3K5Wqbo@mail.gmail.com>
	<AANLkTiml8gcR2XHYiJI5uOvENPseY2LY2iPZ1kD0I4DO@mail.gmail.com>
	<1275690246.2217.87.camel@localhost>
	<AANLkTikLB1FobS3LMl957M4BoBjGxj9hVDTXo5UW6MjK@mail.gmail.com>
Message-ID: <AANLkTilReb_ZKVZxdI9zqrkSv4ntZXlC9vTjAeqobOI_@mail.gmail.com>

Sorry for the previous spam ... :) I am new to this !

Exactly TJ, I am trying to navigate through internal targets inside the same
page.

I have to admit Ashley is correctly suspicious since I walked over the
difference in browsers behavior by trying to use the CSS3 :target selector
for a simple navigation menu. I didn't expect complete success by stretching
the limits like this but I was just trying to avoid Javascript for such a
simple task. I needed a way to keep the state of the current active menu and
I thought I could use a checkbox group for that. And yes it is a bit of a
hack, sorry for that !

There are probably better solutions/approach without too much complexity I
was just pushing a bit and see what I could get at from the pseudo selectors
!

Many thanks TJ for pointing me to the relevant documentation, will read
through it immediately.

Diego Perini


On Sat, Jun 5, 2010 at 12:26 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Fri, Jun 4, 2010 at 3:24 PM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> > On Fri, 2010-06-04 at 15:21 -0700, Tab Atkins Jr. wrote:
> >> On Fri, Jun 4, 2010 at 2:58 PM, Diego Perini <diego.perini at gmail.com>
> wrote:
> >>> I have different behavior in browsers with the "checked" state of a
> checkbox
> >>> input element.
> >>>
> >>> I have filed a ticket in Webkit and I am looking after some
> >>> advice/suggestion about the correct behavior expected from this HTML:
> >>>
> >>>    <label>
> >>>      <input type="checkbox">
> >>>      <a href="#">Enable</a>
> >>>    </label>
> >>>
> >>> It seems Safari/Chrome are discarding the click bubbling at the link
> level,
> >>> thus never reaching the label and not toggling the checkbox.
> >>>
> >>> The behavior in Firefox/Opera and in Safari/Chrome is different and the
> >>> checkbox is correctly "checked" (as I would have expected).
> >>>
> >>> Should a click on the link make the input checked ?
> >> As far as I can tell, section 3.5.2.1.7 (Interactive Content)
> >> specifies that clicking the link in that situation should activate the
> >> link and not toggle the checkbox.
> >
> > I do wonder though in what situation you would ever have that sort if
> code layout and want the checkbox selected when the link is clicked.
> Clicking the link will navigate away anyway, making the form element useless
> in that context.
>
> Not if the link is just to a target on the page, like it is in the
> example given.
>
> ~TJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/26263111/attachment-0001.htm>

From neelen at amvonet.com  Mon Jun  7 07:01:29 2010
From: neelen at amvonet.com (Nikita Eelen)
Date: Mon, 7 Jun 2010 10:01:29 -0400
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
Message-ID: <AANLkTilmi01vpNJLvk2ghaZarpc8N0qW1KdL3w_9NCdf@mail.gmail.com>

I believe video telephony is not possible due to security limitations in
browser, but it was in spec but never acted upon as of yet (IE device access
using something like a microphone/camera etc.), however i believe this is
possible to work around (with individual browser extensions, like firefox
extensions, or
a native plugin (flash comes to mind but sucks for mobile devices in terms
of battery life), so I think for all those as of now need to be written as
either
A.) An application that acts as a plugin (ex: Flash)
B.) An extension to a browser (Firefox extension/active x control etc.)
C.) A native application that reads the camera/microphone for a given device
when the above is not possible (Ex: iPhone/iPad),
if this is possible any other ways I would be very interested if anyone
could comment,
Thanks,
Nikita

On Mon, Jun 7, 2010 at 5:34 AM, narendra sisodiya <
narendra at narendrasisodiya.com> wrote:

> May someone explore what is not possible with HTML5 in spec and in
> Implementations
>
> For example video telephony in browser is possible ? we draft DAP spec but
> no implementations. So not possible at this moment.
>
>
>
> --
> ???????????????????????????
> ?    Narendra Sisodiya
> ?    http://narendrasisodiya.com
> ???????????????????????????
>



-- 
Nikita Eelen
Network Manager

AVE INTERVISION LLC
6 4 0 West State Street
Alliance, Ohio 4 4 6 0 1

Office: 330-821-7117  ext. 108
Cell: 330-257-9647
email: neelen at amvonet.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/efe97e2b/attachment.htm>

From jorlow at chromium.org  Mon Jun  7 07:28:37 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Mon, 7 Jun 2010 15:28:37 +0100
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
Message-ID: <AANLkTils5QV4RUKmpswsEtQTDi6mFGVCl1kg1BbzENNd@mail.gmail.com>

What is the point of this thread?  I ask because I'm concerned this mailing
list is not the right place for such a discussion and/or such a discussion
isn't a fruitful use of time.  (We know there are many gaps between what you
can do on the web and what you can do on the desktop.  The problem is one of
resources to implement solutions.)

J

On Mon, Jun 7, 2010 at 10:34 AM, narendra sisodiya <
narendra at narendrasisodiya.com> wrote:

> May someone explore what is not possible with HTML5 in spec and in
> Implementations
>
> For example video telephony in browser is possible ? we draft DAP spec but
> no implementations. So not possible at this moment.
>
>
>
> --
> ???????????????????????????
> ?    Narendra Sisodiya
> ?    http://narendrasisodiya.com
> ???????????????????????????
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/772a2e59/attachment.htm>

From mikewse at hotmail.com  Mon Jun  7 07:36:19 2010
From: mikewse at hotmail.com (Mike Wilson)
Date: Mon, 7 Jun 2010 16:36:19 +0200
Subject: [whatwg] History API, pushState(), and related feedback
In-Reply-To: <Pine.LNX.4.64.1004090152080.4772@ps20323.dreamhostps.com>
Message-ID: <050301cb064e$cbf70390$0a01a8c0@mikedeskxp>

It seems the big questions here are whether to regard pushState
as a storage API, and whether to invent new API patterns instead
of reusing existing ones.


Is pushState about storage?
---------------------------

Ian Hickson wrote:
> Mike Wilson wrote:
> > the semantic contract is coming closer and closer to that 
> > of the other storage APIs, so I think it would be an 
> > advantage to use the same interface as well.
> 
> I don't see the relevance of storage APIs here. This isn't a
> storage model. It's more a callback model.

I disagree. Once an API persists state between page loads it 
deserves to be regarded as a storage API and not just a callback 
API.
The data objects supplied in pushState calls may be persisted for 
the lifetime of their browsing context (unless history entry is 
removed), just like data in session storage.


Invent new API pattern instead of reusing?
------------------------------------------

There should be good reasons why not to reuse existing API 
patterns.

Why is "pushState" inventing a new API pattern where a copy of
the state is forwarded through new methods and events, instead
of accessing it through a storage facade (see sessionStorage and
localStorage) as in WebStorage?

Why is "pushState" defining a more restrictive model to state
access (read once / write anytime) compared to WebStorage 
(read anytime / write anytime) ?

What use-cases are solvable in the current "pushState" model
but not in a WebStorage-style model? (see below for 
WebStorage-style example)

Ian Hickson wrote:
> Mike Wilson wrote:
> > Why not use the same API as in Web Storage:
> >   interface Storage {
> >     readonly attribute unsigned long length;
> >     getter DOMString key(in unsigned long index);
> >     getter any getItem(in DOMString key);
> >     setter creator void setItem(in DOMString key, in any data);
> >     deleter void removeItem(in DOMString key);
> >     void clear();
> >   };
> > and make the current entry's Storage instance always available
> > as f ex:
> >   interface History {
> >     readonly attribute Storage state;
> >   }
> > 
> > Then pushState's state parameter may be removed and there is
> > no longer a need for the replaceState method.
> 
> I don't understand how this would work. When does the history 
> get updated in this model?

The pushState method (without state parameter and possibly 
renamed) remains to create a new session history entry:

  function() {
    history.state.setItem("a", 1); // set on current history entry
    history.pushState(title, url); // create new history entry
    history.state.getItem("a"); // get from new history entry (null)
    history.state.setItem("a", 2); // set on new history entry
  }

> How do you know you've gone back in history? 

The popstate event (without state attribute) remains to inform 
us that history entry has been switched and that the corresponding
data is now available through history.state.


Best regards
Mike Wilson


From jorlow at chromium.org  Mon Jun  7 08:17:44 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Mon, 7 Jun 2010 16:17:44 +0100
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTilwp_76ucfSQGap0zpVjTgiUGRlgWJktDNMSaOp@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com> 
	<AANLkTils5QV4RUKmpswsEtQTDi6mFGVCl1kg1BbzENNd@mail.gmail.com> 
	<AANLkTilwp_76ucfSQGap0zpVjTgiUGRlgWJktDNMSaOp@mail.gmail.com>
Message-ID: <AANLkTimmmSiF0MBscb8WPNZVsOZyvQa7zbcLVe4pmpB1@mail.gmail.com>

In that case, I think your original email could have been much more clear
and direct.

On Mon, Jun 7, 2010 at 4:03 PM, Nikita Eelen <neelen at amvonet.com> wrote:

> The point is will the device spec be implemented ever or even seriously
> discussed, and if not why is it listed in the spec?
>
>
> On Mon, Jun 7, 2010 at 10:28 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> What is the point of this thread?  I ask because I'm concerned this
>> mailing list is not the right place for such a discussion and/or such a
>> discussion isn't a fruitful use of time.  (We know there are many gaps
>> between what you can do on the web and what you can do on the desktop.  The
>> problem is one of resources to implement solutions.)
>>
>> J
>>
>> On Mon, Jun 7, 2010 at 10:34 AM, narendra sisodiya <
>> narendra at narendrasisodiya.com> wrote:
>>
>>> May someone explore what is not possible with HTML5 in spec and in
>>> Implementations
>>>
>>> For example video telephony in browser is possible ? we draft DAP spec
>>> but no implementations. So not possible at this moment.
>>>
>>>
>>>
>>> --
>>> ???????????????????????????
>>> ?    Narendra Sisodiya
>>> ?    http://narendrasisodiya.com
>>> ???????????????????????????
>>>
>>
>>
>
>
> --
> Nikita Eelen
> Network Manager
>
> AVE INTERVISION LLC
> 6 4 0 West State Street
> Alliance, Ohio 4 4 6 0 1
>
> Office: 330-821-7117  ext. 108
> Cell: 330-257-9647
> email: neelen at amvonet.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/02e01d6f/attachment.htm>

From WeBMartians at verizon.net  Mon Jun  7 08:18:16 2010
From: WeBMartians at verizon.net (Bruce de Graaf)
Date: Mon, 07 Jun 2010 11:18:16 -0400
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTilmi01vpNJLvk2ghaZarpc8N0qW1KdL3w_9NCdf@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
	<AANLkTilmi01vpNJLvk2ghaZarpc8N0qW1KdL3w_9NCdf@mail.gmail.com>
Message-ID: <4C0D0DB8.4000303@verizon.net>

3D Video and Real-time Multi-format Video! Ooops... My "bad." It doesn't 
seem feasible even outside of HTML!

Apologies for being facetious and trying to be a "wag," but that latter 
point (multi-format video) is a good candidate for attention ... and 
that is what the query (What is not possible with HTML5) is about, 
right? "To what have we failed to pay due consideration?"

A Statement of the Problem (apologies aforehand for offensive terminology):
Real-time, multi-format video (there must be a better term for this) is 
the acquisition of audio and video in one form (say, 1920 x 1080 with 
7.1 sound) and its propagation in native as well as other formats (say, 
160 x 112 with monaural sound). This is the "Fat Man's Trousers" problem 
- How do you stuff that belly into such small pants? [and THAT is the 
most polite of the various titles] Right now, with either H.264 or with 
Ogg, no matter which, this task is Sysiphean. Simply put, it is the 
difficulty in cramming 8+ Mb/s through a 300 kb/s pipe (to a display 
that cannot present, anyway, the high resolution image) and then 
randomly "adjusting" the bandwidth. Think of being in a car, watching an 
iPad (as a passenger, we hope and pray) and trying to watch a video as 
the feed wobbles from several megabits to mere kilobits per second and 
back again. ...and then being foolish enough to recommend the video to 
an iPhone user...

Just recode ... on-the-fly? Oh, you have not begun to address the 
problems! You see, when your feed collapses, your clients lose 
compression synchronization: compressed audio and video that depend on a 
particular client state must be halted until some form of re-atunment 
occurs ... possibly several seconds (hopefully not minutes). ...not good 
in a commercial environment (somebody's not getting that for which 
he/she is paying...).

There have been related discussions (focused on reporting actual 
bandwidth) on this forum about the challenges. Some have said, with good 
reason, that it is outside of the HTML5 envelope. Yet, the current need 
is so great and that need's growth is of such magnitude (it could reach, 
quickly, the major portion of all traffic) as to warrant some cycles in 
its discussion.

...and, not to complicate and confuse matters, deserving of attention is 
an analogous problem with mere layout of HTML pages: view a commercial 
page (say, Bloomberg or Der Spiegel) on a decently sized screen and then 
try to view such pages on an iPhone or Droid ... not a pleasant 
experience. Whilst not dynamic as the described media feed problem is, 
the difficulties are analogous (again, even if "spatial rather than 
temporal"). If the documentation could offer some guidance, it would be 
well received and yield great returns.

What say ye?
===
On 2010-06-07 10:01, Nikita Eelen wrote:
> I believe video telephony is not possible due to security limitations 
> in browser, but it was in spec but never acted upon as of yet (IE 
> device access
> using something like a microphone/camera etc.), however i believe this 
> is possible to work around (with individual browser extensions, like 
> firefox extensions, or
> a native plugin (flash comes to mind but sucks for mobile devices in 
> terms of battery life), so I think for all those as of now need to be 
> written as either
> A.) An application that acts as a plugin (ex: Flash)
> B.) An extension to a browser (Firefox extension/active x control etc.)
> C.) A native application that reads the camera/microphone for a given 
> device when the above is not possible (Ex: iPhone/iPad),
> if this is possible any other ways I would be very interested if 
> anyone could comment,
> Thanks,
> Nikita
>
> On Mon, Jun 7, 2010 at 5:34 AM, narendra sisodiya 
> <narendra at narendrasisodiya.com <mailto:narendra at narendrasisodiya.com>> 
> wrote:
>
>     May someone explore what is not possible with HTML5 in spec and in
>     Implementations
>
>     For example video telephony in browser is possible ? we draft DAP
>     spec but no implementations. So not possible at this moment.
>
>
>
>     -- 
>     ???????????????????????????
>     ?    Narendra Sisodiya
>     ? http://narendrasisodiya.com
>     ???????????????????????????
>
>
>
>
> -- 
> Nikita Eelen
> Network Manager
>
> AVE INTERVISION LLC
> 6 4 0 West State Street
> Alliance, Ohio 4 4 6 0 1
>
> Office: 330-821-7117  ext. 108
> Cell: 330-257-9647
> email: neelen at amvonet.com <mailto:neelen at amvonet.com>

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

From jorlow at chromium.org  Mon Jun  7 08:22:40 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Mon, 7 Jun 2010 16:22:40 +0100
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTimmmSiF0MBscb8WPNZVsOZyvQa7zbcLVe4pmpB1@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com> 
	<AANLkTils5QV4RUKmpswsEtQTDi6mFGVCl1kg1BbzENNd@mail.gmail.com> 
	<AANLkTilwp_76ucfSQGap0zpVjTgiUGRlgWJktDNMSaOp@mail.gmail.com> 
	<AANLkTimmmSiF0MBscb8WPNZVsOZyvQa7zbcLVe4pmpB1@mail.gmail.com>
Message-ID: <AANLkTin4zVl1h74OEoAdDDGU9r6cW_hTkaysMCHc2APB@mail.gmail.com>

On Mon, Jun 7, 2010 at 4:17 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> In that case, I think your original email could have been much more clear
> and direct.


Er...ignore that response...got mixed up with who I was responding to.

Proper response:
I was responding to Narenda's original email which was a much more
general question of "what is not possible with HTML5".  You seem to have
gotten hung up on the example Narenda was using.  If you'd like to discuss
the specific example of video conferencing, perhaps you should fork this
thread (i.e. change the subject)?

J

On Mon, Jun 7, 2010 at 4:03 PM, Nikita Eelen <neelen at amvonet.com> wrote:
>
>> The point is will the device spec be implemented ever or even seriously
>> discussed, and if not why is it listed in the spec?
>>
>>
>> On Mon, Jun 7, 2010 at 10:28 AM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>
>>> What is the point of this thread?  I ask because I'm concerned this
>>> mailing list is not the right place for such a discussion and/or such a
>>> discussion isn't a fruitful use of time.  (We know there are many gaps
>>> between what you can do on the web and what you can do on the desktop.  The
>>> problem is one of resources to implement solutions.)
>>>
>>> J
>>>
>>> On Mon, Jun 7, 2010 at 10:34 AM, narendra sisodiya <
>>> narendra at narendrasisodiya.com> wrote:
>>>
>>>> May someone explore what is not possible with HTML5 in spec and in
>>>> Implementations
>>>>
>>>> For example video telephony in browser is possible ? we draft DAP spec
>>>> but no implementations. So not possible at this moment.
>>>>
>>>>
>>>>
>>>> --
>>>> ???????????????????????????
>>>> ?    Narendra Sisodiya
>>>> ?    http://narendrasisodiya.com
>>>> ???????????????????????????
>>>>
>>>
>>>
>>
>>
>> --
>> Nikita Eelen
>> Network Manager
>>
>> AVE INTERVISION LLC
>> 6 4 0 West State Street
>> Alliance, Ohio 4 4 6 0 1
>>
>> Office: 330-821-7117  ext. 108
>> Cell: 330-257-9647
>> email: neelen at amvonet.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/9266ef10/attachment.htm>

From narendra at narendrasisodiya.com  Mon Jun  7 09:00:31 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Mon, 7 Jun 2010 21:30:31 +0530
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTils5QV4RUKmpswsEtQTDi6mFGVCl1kg1BbzENNd@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
	<AANLkTils5QV4RUKmpswsEtQTDi6mFGVCl1kg1BbzENNd@mail.gmail.com>
Message-ID: <AANLkTilZQVP4YcLho8yDXqLYatcLuTIB1auoK-eZjZxe@mail.gmail.com>

On Mon, Jun 7, 2010 at 7:58 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> What is the point of this thread?  I ask because I'm concerned this mailing
> list is not the right place for such a discussion and/or such a discussion
> isn't a fruitful use of time.  (We know there are many gaps between what you
> can do on the web and what you can do on the desktop.  The problem is one of
> resources to implement solutions.)
>
> J
>
> On Mon, Jun 7, 2010 at 10:34 AM, narendra sisodiya <
> narendra at narendrasisodiya.com> wrote:
>
>> May someone explore what is not possible with HTML5 in spec and in
>> Implementations
>>
>> For example video telephony in browser is possible ? we draft DAP spec but
>> no implementations. So not possible at this moment.
>>
>>
>>

Dear J,
    rightly said, there is a gap between web and desktop. I was just curious
about what is remaining to fill the gap ? Developer may work on the gap
filling. Let me ask same question in different way  -- What new features
will be added in HTML6 and 7...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/b6c2ee18/attachment.htm>

From narendra at narendrasisodiya.com  Mon Jun  7 09:44:20 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Mon, 7 Jun 2010 22:14:20 +0530
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTin4zVl1h74OEoAdDDGU9r6cW_hTkaysMCHc2APB@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
	<AANLkTils5QV4RUKmpswsEtQTDi6mFGVCl1kg1BbzENNd@mail.gmail.com>
	<AANLkTilwp_76ucfSQGap0zpVjTgiUGRlgWJktDNMSaOp@mail.gmail.com>
	<AANLkTimmmSiF0MBscb8WPNZVsOZyvQa7zbcLVe4pmpB1@mail.gmail.com>
	<AANLkTin4zVl1h74OEoAdDDGU9r6cW_hTkaysMCHc2APB@mail.gmail.com>
Message-ID: <AANLkTik25E_VS7jmIZH-cNWbLVtlTGn_ZFGfeIJheyeE@mail.gmail.com>

On Mon, Jun 7, 2010 at 8:52 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Mon, Jun 7, 2010 at 4:17 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> In that case, I think your original email could have been much more clear
>> and direct.
>
>
> Er...ignore that response...got mixed up with who I was responding to.
>
> Proper response:
> I was responding to Narenda's original email which was a much more
> general question of "what is not possible with HTML5".  You seem to have
> gotten hung up on the example Narenda was using.  If you'd like to discuss
> the specific example of video conferencing, perhaps you should fork this
> thread (i.e. change the subject)?
>
>
My concern was very much clear.. What will be in HTML6&7 spec, What is the
remaining tasks to do. What is not possible with HTML5. at spec level and at
the implementation level.

I gave video telephony as example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/ac288eeb/attachment.htm>

From dolske at mozilla.com  Mon Jun  7 09:53:20 2010
From: dolske at mozilla.com (Justin Dolske)
Date: Mon, 07 Jun 2010 09:53:20 -0700
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
Message-ID: <4C0D2400.8000901@mozilla.com>

On 6/7/10 2:34 AM, narendra sisodiya wrote:
> May someone explore what is not possible with HTML5 in spec and in
> Implementations

According to http://html5zombo.com/: you can do anything, the only limit 
is yourself.

Justin

From narendra at narendrasisodiya.com  Mon Jun  7 09:55:01 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Mon, 7 Jun 2010 22:25:01 +0530
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <4C0D2400.8000901@mozilla.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
	<4C0D2400.8000901@mozilla.com>
Message-ID: <AANLkTimvO_HfNgsqXu3UUtcDPjjRQBFMBYJrpT-qZ6LJ@mail.gmail.com>

On Mon, Jun 7, 2010 at 10:23 PM, Justin Dolske <dolske at mozilla.com> wrote:

> On 6/7/10 2:34 AM, narendra sisodiya wrote:
>
>> May someone explore what is not possible with HTML5 in spec and in
>> Implementations
>>
>
> According to http://html5zombo.com/: you can do anything, the only limit
> is yourself.
>
> Justin
>

they are wrong ! If everything is possible , we have reached the end of
technology.

-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/371a17be/attachment.htm>

From narendra at narendrasisodiya.com  Mon Jun  7 09:52:49 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Mon, 7 Jun 2010 22:22:49 +0530
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTik25E_VS7jmIZH-cNWbLVtlTGn_ZFGfeIJheyeE@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
	<AANLkTils5QV4RUKmpswsEtQTDi6mFGVCl1kg1BbzENNd@mail.gmail.com>
	<AANLkTilwp_76ucfSQGap0zpVjTgiUGRlgWJktDNMSaOp@mail.gmail.com>
	<AANLkTimmmSiF0MBscb8WPNZVsOZyvQa7zbcLVe4pmpB1@mail.gmail.com>
	<AANLkTin4zVl1h74OEoAdDDGU9r6cW_hTkaysMCHc2APB@mail.gmail.com>
	<AANLkTik25E_VS7jmIZH-cNWbLVtlTGn_ZFGfeIJheyeE@mail.gmail.com>
Message-ID: <AANLkTingW4Lcr0RGhRnqiEAzQVEujCFk50fhvCv0H8gb@mail.gmail.com>

On Mon, Jun 7, 2010 at 10:14 PM, narendra sisodiya <
narendra at narendrasisodiya.com> wrote:

>
>
> On Mon, Jun 7, 2010 at 8:52 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> On Mon, Jun 7, 2010 at 4:17 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>>
>>> In that case, I think your original email could have been much more clear
>>> and direct.
>>
>>
>> Er...ignore that response...got mixed up with who I was responding to.
>>
>> Proper response:
>> I was responding to Narenda's original email which was a much more
>> general question of "what is not possible with HTML5".  You seem to have
>> gotten hung up on the example Narenda was using.  If you'd like to discuss
>> the specific example of video conferencing, perhaps you should fork this
>> thread (i.e. change the subject)?
>>
>>
> My concern was very much clear.. What will be in HTML6&7 spec, What is the
> remaining tasks to do. What is not possible with HTML5. at spec level and at
> the implementation level.
>
> I gave video telephony as example.
>

I clearly see the huge market in Virtual worlds like second life
and augmented reality in mobile phones. WebGL is a rendering specification.
I think , on top of webGL , we may need some higher order specification for
3D web.
Who know, HTMLx may include <3dwall orientation='right' id='facebook-wall'
/> type of tags,

Anyway , I am a strong believer of Matrix. We will be having a similar sort
of Matrix is future. So It is the question of future that - 'will Matrix us
flash/sliverlight or Open Standards'

If All of sudden we got huge bandwidth and second life will be
most popular web browser. in second life one can have a 2D browser and other
technologies. I was just trying to have a discussion of future version of
HTMLx , open standards and future technologies...

I have seen a 'lazy web' nature. first close standards comes and then we
fight for an equivilant open standard.

-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100607/69784e5d/attachment-0001.htm>

From jsalsman at gmail.com  Mon Jun  7 15:01:46 2010
From: jsalsman at gmail.com (James Salsman)
Date: Mon, 7 Jun 2010 15:01:46 -0700
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com>
Message-ID: <AANLkTikp388V6JG8rSAX_bvnMMZ_57aHXLYrPBIygzBt@mail.gmail.com>

On Jun 7, 2010 2:34 AM, "narendra sisodiya"
<narendra at narendrasisodiya.com> wrote:
>
> May someone explore what is not possible with HTML5 in spec and in Implementations

input type=file accept=audio per HTML 3.2, 4, 5 and
http://www.w3.org/TR/device-upload has been around for more than a
decade without browser implementation, even though hundreds language
instructors and Tim Berners-Lee himself have asked for implementation
because it would enable many different kinds of apps.

My W3C invited-expert position on the issue is detailed at
http://talknicer.com/convAppsPosn.pdf

There is a Mozilla bug on this --
https://bugzilla.mozilla.org/show_bug.cgi?id=46135 -- which has been
open for a whole decade, with 37 votes, and even had a patch back when
it was first opened.

Does anyone know how I can update my email address in Mozilla's
bugzilla?  I am no longer at bovik.org.

--James Salsman

From silviapfeiffer1 at gmail.com  Mon Jun  7 15:42:09 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 8 Jun 2010 08:42:09 +1000
Subject: [whatwg] What is not possible with HTML5
In-Reply-To: <4C0D0DB8.4000303@verizon.net>
References: <AANLkTim6ZKDEO3mtvkjdaiJJEjMou-NMtAYmjl5LsZVz@mail.gmail.com> 
	<AANLkTilmi01vpNJLvk2ghaZarpc8N0qW1KdL3w_9NCdf@mail.gmail.com> 
	<4C0D0DB8.4000303@verizon.net>
Message-ID: <AANLkTikbaxWGWw1l0fwlN81rPzBTI58Fj-DVkOBiRtHQ@mail.gmail.com>

I think what you call "multi-format video" is being implemented as
HTTP adaptive streaming, where you have multiple different
bandwidth-versions of the same media resource on the server and they
have synchronisation points (usually the keyframes of the video) at
which the user agent can switch over from one resource to another
using byte range requests depending on the user agent's situation.

I still wonder whether we should standardise HTTP adaptive streaming
across video formats here or somewhere else. At this moment, several
different solutions exist for MPEG video and none for Ogg or WebM.

Cheers,
Silvia,


On Tue, Jun 8, 2010 at 1:18 AM, Bruce de Graaf <WeBMartians at verizon.net> wrote:
> 3D Video and Real-time Multi-format Video! Ooops... My "bad." It doesn't
> seem feasible even outside of HTML!
>
> Apologies for being facetious and trying to be a "wag," but that latter
> point (multi-format video) is a good candidate for attention ... and that is
> what the query (What is not possible with HTML5) is about, right? "To what
> have we failed to pay due consideration?"
>
> A Statement of the Problem (apologies aforehand for offensive terminology):
> Real-time, multi-format video (there must be a better term for this) is the
> acquisition of audio and video in one form (say, 1920 x 1080 with 7.1 sound)
> and its propagation in native as well as other formats (say, 160 x 112 with
> monaural sound). This is the "Fat Man's Trousers" problem - How do you stuff
> that belly into such small pants? [and THAT is the most polite of the
> various titles] Right now, with either H.264 or with Ogg, no matter which,
> this task is Sysiphean. Simply put, it is the difficulty in cramming 8+ Mb/s
> through a 300 kb/s pipe (to a display that cannot present, anyway, the high
> resolution image) and then randomly "adjusting" the bandwidth. Think of
> being in a car, watching an iPad (as a passenger, we hope and pray) and
> trying to watch a video as the feed wobbles from several megabits to mere
> kilobits per second and back again. ...and then being foolish enough to
> recommend the video to an iPhone user...
>
> Just recode ... on-the-fly? Oh, you have not begun to address the problems!
> You see, when your feed collapses, your clients lose compression
> synchronization: compressed audio and video that depend on a particular
> client state must be halted until some form of re-atunment occurs ...
> possibly several seconds (hopefully not minutes). ...not good in a
> commercial environment (somebody's not getting that for which he/she is
> paying...).
>
> There have been related discussions (focused on reporting actual bandwidth)
> on this forum about the challenges. Some have said, with good reason, that
> it is outside of the HTML5 envelope. Yet, the current need is so great and
> that need's growth is of such magnitude (it could reach, quickly, the major
> portion of all traffic) as to warrant some cycles in its discussion.
>
> ...and, not to complicate and confuse matters, deserving of attention is an
> analogous problem with mere layout of HTML pages: view a commercial page
> (say, Bloomberg or Der Spiegel) on a decently sized screen and then try to
> view such pages on an iPhone or Droid ... not a pleasant experience. Whilst
> not dynamic as the described media feed problem is, the difficulties are
> analogous (again, even if "spatial rather than temporal"). If the
> documentation could offer some guidance, it would be well received and yield
> great returns.
>
> What say ye?
> ===
> On 2010-06-07 10:01, Nikita Eelen wrote:
>
> I believe video telephony is not possible due to security limitations in
> browser, but it was in spec but never acted upon as of yet (IE device access
> using something like a microphone/camera etc.), however i believe this is
> possible to work around (with individual browser extensions, like firefox
> extensions, or
> a native plugin (flash comes to mind but sucks for mobile devices in terms
> of battery life), so I think for all those as of now need to be written as
> either
> A.) An application that acts as a plugin (ex: Flash)
> B.) An extension to a browser (Firefox extension/active x control etc.)
> C.) A native application that reads the camera/microphone for a given device
> when the above is not possible (Ex: iPhone/iPad),
> if this is possible any other ways I would be very interested if anyone
> could comment,
> Thanks,
> Nikita
>
> On Mon, Jun 7, 2010 at 5:34 AM, narendra sisodiya
> <narendra at narendrasisodiya.com> wrote:
>>
>> May someone explore what is not possible with HTML5 in spec and in
>> Implementations
>> For example video telephony in browser is possible ? we draft DAP spec but
>> no implementations. So not possible at this moment.
>>
>>
>> --
>> ???????????????????????????
>> ? ? ?Narendra Sisodiya
>> ? ? ?http://narendrasisodiya.com
>> ???????????????????????????
>
>
>
> --
> Nikita Eelen
> Network Manager
>
> AVE INTERVISION LLC
> 6 4 0 West State Street
> Alliance, Ohio 4 4 6 0 1
>
> Office: 330-821-7117 ?ext. 108
> Cell: 330-257-9647
> email: neelen at amvonet.com
>
>

From hsivonen at iki.fi  Tue Jun  8 04:17:41 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 8 Jun 2010 04:17:41 -0700 (PDT)
Subject: [whatwg] Installable web apps
In-Reply-To: <292720809.384044.1275995855838.JavaMail.root@cm-mail03.mozilla.org>
Message-ID: <200951292.384046.1275995861082.JavaMail.root@cm-mail03.mozilla.org>

"Aaron Boodman (?)" <aa at google.com> wrote:

> Every crx file is signed. The signature and public key are part of
> the
> zip file itself, just after the signature. The zip format allows
> extra
> data there. When you took apart those crx files, if you used 'unzip'
> from the command line, you may have seen 'Ignoring xx bytes of extra
> data...'. That was the public key and signature being discarded :).

Ooh. I was looking for traces of the signing mechanism in the unzipped data.

Is there a reason why .crx reinvents zip file signing instead of using the mechanism that .jar and .xpi use? .wgt, ODF and OOXML also put the signature inside the zipped data.

> >> Another one that we would like in Chrome is a path prefix for the
> >> app.
> >> This is to handle the case of applications like Google Reader
> >> which
> >> are on http://www.google.com/reader.
> >
> > How does giving permissions to a prefixed application interact with
> > the origin-based security model?
> 
> Poorly. Origin is baked so low into the platform, it is the true
> boundary, and that can probably never be changed. In Chrome, we can
> get close because we can enforce process isolation based on the path,
> but it is an ongoing project to make that bulletproof that might
> never
> complete.
> 
> However, I think it is still useful to know the paths an application
> uses. One example of this is storage.
> 
> It would be really nice to be able to show users storage used by
> applications ("Google Docs", "Google Reader"). But this isn't
> possible
> since many apps are frequently served from the same origin. The best
> we can currently do is "www.google.com".
> 
> If we add paths to the mix, we can do this. Applications on the same
> origin can circumvent it if they want, but why would they? SOP
> already
> guarantees that apps on the same origin are friendly and cooperate
> with each other. That doesn't mean it isn't useful for the UA to know
> which one is which.

I have to wonder why Google needs the browser team to solve this instead of having the Reader team relocate their stuff to reader.google.com (like maps.google.com is located already).

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

From mounir.lamouri at gmail.com  Tue Jun  8 07:26:17 2010
From: mounir.lamouri at gmail.com (Mounir Lamouri)
Date: Tue, 08 Jun 2010 16:26:17 +0200
Subject: [whatwg] IDL attribute reflecting enumerated attributes not limited
 to only know values
Message-ID: <4C0E5309.6070506@gmail.com>

Hi,

According to the HTML5 specification, an IDL attribute reflecting an
enumerated attribute will have the default reflecting behavior (ie.
return the content attribute on getting and setting it on setting)
except if the attribute is "limited to only known values" [1]. There are
three attributes limited to only known values in the current state of
the specs: @dir, @shape (area element) and @keytype (keygen element).

In other words, that means if @toto is an enumerated attribute with
"foo" and "bar" states/keywords and "foo" as a default missing value, if
@toto is set to "foobar", .toto will return "foobar". To have .toto
returning "foo", the attribute has to be limited to only known value.
Having .toto returning "foo" in this situation seems to be what we
should expect because the content attribute is already accessible with
@toto.

An example where this behavior seems buggy:
- input.type and button.type: every browser makes it return "text" if
@type isn't set to a known value. If we follow the specifications, .type
should return the current value of @type.

Examples where having another behavior would help:
- method, formmethod, enctype and formenctype have a list of
keywords/states with a default missing value. It would be great to have
the IDL attribute returning the current state instead of the content.
So, scripts wouldn't have to look at the content, checking for values
they know and falling-back to the default value to know the current state.
- input.autocomplete: at the moment, it is returning the content but it
could return the resulting autocompletion state which is maybe a bit
more than just being limited to only known values but still in the same
spirit.

Maybe, instead of having some attributes "limited to only known values"
we could have some attributes "not limited to only known values", thus
inverting the default reflecting behavior for enumerated attriutes ?

[1] http://dev.w3.org/html5/spec/Overview.html#limited-to-only-known-values

Thanks,
--
Mounir

From lists at eitanadler.com  Tue Jun  8 07:32:42 2010
From: lists at eitanadler.com (Eitan Adler)
Date: Tue, 8 Jun 2010 17:32:42 +0300
Subject: [whatwg] input type=upload (not just files) proposal
Message-ID: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>

A lot of websites let you upload either from a file on your hard drive
or from a link on the web.
Most of the time this is done by having two different inputs: One for
a file and the other for a URL.

If there were some type of input like "upload' which will allow for
any complete input.
Something like
file:///home/eitan/file_to_upload.pdf
or
http://example.com/file.pdf
or
ftp://user:password at example.com/file.pdf

It would then be the server's job to fetch the file unless the user
passed it a file:// scheme it which case the file would be provided by
the UI.


-- 
Eitan Adler

From glsimpso at indiana.edu  Tue Jun  8 07:37:50 2010
From: glsimpso at indiana.edu (Simpson, Grant Leyton)
Date: Tue, 8 Jun 2010 10:37:50 -0400
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
Message-ID: <9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>

Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url?

On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:

> It would then be the server's job to fetch the file unless the user
> passed it a file:// scheme it which case the file would be provided by
> the UI.


From lists at eitanadler.com  Tue Jun  8 07:45:22 2010
From: lists at eitanadler.com (Eitan Adler)
Date: Tue, 8 Jun 2010 17:45:22 +0300
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com> 
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
Message-ID: <AANLkTiklJZqJAWo7iKIrrRabJPnNGsHh3NnyoJltc1sY@mail.gmail.com>

On Tue, Jun 8, 2010 at 5:37 PM, Simpson, Grant Leyton
<glsimpso at indiana.edu> wrote:
> Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url?
>
> On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:
>
>> It would then be the server's job to fetch the file unless the user
>> passed it a file:// scheme it which case the file would be provided by
>> the UI.
>
>

I imagine this would be a UI decision - not one made by the spec.
However I, with very limited experience in UI creation, am envisioning
a dialog box as you mention.
Another option would be to have buttons to the side of the textbox one
that has a web icon and another that has a folder icon.


-- 
Eitan Adler

From ash at ashleysheridan.co.uk  Tue Jun  8 07:47:17 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 08 Jun 2010 15:47:17 +0100
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
Message-ID: <1276008437.2246.23.camel@localhost>

On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton wrote:

> Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url?
> 
> On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:
> 
> > It would then be the server's job to fetch the file unless the user
> > passed it a file:// scheme it which case the file would be provided by
> > the UI.
> 


I can see how this might work, but in theory it would be more difficult
than it sounds. For example, passing an FTP uri would only work if that
FTP server allowed anonymous access, as you wouldn't want to pass your
own FTP access credentials to an unknown server.

The local machine could determine if the FTP server they are giving a
file reference to allows anonymous access I guess, and in cases where
the FTP server doesn't, then it could behave like the KIO slaves in KDE,
which allow local mapping of files at remote locations, such as SMB,
FTP, SFTP, SVN, etc. But this is something that can only really be
offered at the operating system level.

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100608/86e85bd9/attachment-0001.htm>

From glsimpso at indiana.edu  Tue Jun  8 07:52:02 2010
From: glsimpso at indiana.edu (Simpson, Grant Leyton)
Date: Tue, 8 Jun 2010 10:52:02 -0400
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <AANLkTiklJZqJAWo7iKIrrRabJPnNGsHh3NnyoJltc1sY@mail.gmail.com>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
	<AANLkTiklJZqJAWo7iKIrrRabJPnNGsHh3NnyoJltc1sY@mail.gmail.com>
Message-ID: <F3855E7F-577B-48E5-BB58-EADF68A466D1@indiana.edu>

O.K. Just wanted to clarify. With this sort of dialog in mind, I like your proposal. (I find it unrealistic to think that the average user would write out "file://..." but maybe I am mistaken.) 

However, I see one possible issue. Some apps provide the means to work with local files, URLs, and direct text input (such as the W3C's validator: http://validator.w3.org/). Might others expand your suggestion to include the direct text option? I don't have an opinion on that other than to say that the appropriate balance between utility and complexity would need to be found.

On Jun 8, 2010, at 10:45 AM, Eitan Adler wrote:

> On Tue, Jun 8, 2010 at 5:37 PM, Simpson, Grant Leyton
> <glsimpso at indiana.edu> wrote:
>> Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url?
>> 
>> On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:
>> 
>>> It would then be the server's job to fetch the file unless the user
>>> passed it a file:// scheme it which case the file would be provided by
>>> the UI.
>> 
>> 
> 
> I imagine this would be a UI decision - not one made by the spec.
> However I, with very limited experience in UI creation, am envisioning
> a dialog box as you mention.
> Another option would be to have buttons to the side of the textbox one
> that has a web icon and another that has a folder icon.
> 
> 
> -- 
> Eitan Adler


From mike.shaver at gmail.com  Tue Jun  8 07:58:14 2010
From: mike.shaver at gmail.com (Mike Shaver)
Date: Tue, 8 Jun 2010 10:58:14 -0400
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <1276008437.2246.23.camel@localhost>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
	<1276008437.2246.23.camel@localhost>
Message-ID: <AANLkTinx5hnp_whKxVknpa5Q-KYcW25p7DWrCXhYm_H1@mail.gmail.com>

On Tue, Jun 8, 2010 at 10:47 AM, Ashley Sheridan
<ash at ashleysheridan.co.uk>wrote:

>  On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton wrote:
>
> Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url?
>
> On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:
>
> > It would then be the server's job to fetch the file unless the user
> > passed it a file:// scheme it which case the file would be provided by
> > the UI.
>
>
>  I can see how this might work, but in theory it would be more difficult
> than it sounds. For example, passing an FTP uri would only work if that FTP
> server allowed anonymous access, as you wouldn't want to pass your own FTP
> access credentials to an unknown server.
>

Or the UA could fetch the remote resource and then re-transfer it, as is
sometimes an option on desktop mail clients when attaching a URL ("attach
page" vs "attach link", or similar).  Then it's just a UA issue, since the
client can do that for any file input, and could even permit creating one
from the clipboard.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100608/7ecfeaa7/attachment.htm>

From lachlan.hunt at lachy.id.au  Tue Jun  8 08:00:45 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Tue, 08 Jun 2010 17:00:45 +0200
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
Message-ID: <4C0E5B1D.7020602@lachy.id.au>

On 2010-06-08 16:37, Simpson, Grant Leyton wrote:
> Are you wanting the user to manually enter the filename, including
> the file:// scheme? If not, are you envisioning the file dialog box
> to provide a choice between selecting local files and entering an
> http/ftp url?

My understanding of the proposal is that given this particular control, 
the browser would provide an interface for either selecting a local file 
or entering a URL.  If a file is selected, the file is uploaded as 
normal, equivalent to <input type="file" name="foo">.

Otherwise, if a URL is entered, the field is instead submitted as text, 
equivalent to <input type="url" name="foo">.

The server would then determine whether the "foo" field that was 
submitted was a file upload or a text field value, and if it were a text 
field, then it would supposedly be treated as a URL that should then be 
fetched.

Eitan, have I understood your proposal correctly?

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

From ash at ashleysheridan.co.uk  Tue Jun  8 08:02:52 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 08 Jun 2010 16:02:52 +0100
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <AANLkTinx5hnp_whKxVknpa5Q-KYcW25p7DWrCXhYm_H1@mail.gmail.com>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
	<1276008437.2246.23.camel@localhost>
	<AANLkTinx5hnp_whKxVknpa5Q-KYcW25p7DWrCXhYm_H1@mail.gmail.com>
Message-ID: <1276009372.2246.30.camel@localhost>

On Tue, 2010-06-08 at 10:58 -0400, Mike Shaver wrote:
> On Tue, Jun 8, 2010 at 10:47 AM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> 
>         
>         On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton
>         wrote: 
>         
>         > Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url?
>         > 
>         > On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote:
>         > 
>         > > It would then be the server's job to fetch the file unless the user
>         > > passed it a file:// scheme it which case the file would be provided by
>         > > the UI.
>         > 
>         
>         I can see how this might work, but in theory it would be more
>         difficult than it sounds. For example, passing an FTP uri
>         would only work if that FTP server allowed anonymous access,
>         as you wouldn't want to pass your own FTP access credentials
>         to an unknown server.
>         
> 
> Or the UA could fetch the remote resource and then re-transfer it, as
> is sometimes an option on desktop mail clients when attaching a URL
> ("attach page" vs "attach link", or similar).  Then it's just a UA
> issue, since the client can do that for any file input, and could even
> permit creating one from the clipboard.
> 
> 
> 
> Mike
> 


Yes, and the rest of my email said that.

KIO slaves on KDE work just like that. It's not something that I think a
user agent can easily just add in, but something that needs to be
supported at the OS level.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From mike.shaver at gmail.com  Tue Jun  8 08:13:49 2010
From: mike.shaver at gmail.com (Mike Shaver)
Date: Tue, 8 Jun 2010 11:13:49 -0400
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <1276009372.2246.30.camel@localhost>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
	<1276008437.2246.23.camel@localhost>
	<AANLkTinx5hnp_whKxVknpa5Q-KYcW25p7DWrCXhYm_H1@mail.gmail.com>
	<1276009372.2246.30.camel@localhost>
Message-ID: <AANLkTinYDmC8gxNxRokSiLfQmNm5laKfQdBiWOX4DT-h@mail.gmail.com>

On Tue, Jun 8, 2010 at 11:02 AM, Ashley Sheridan
<ash at ashleysheridan.co.uk>wrote:

>  Yes, and the rest of my email said that.
>

Sorry, I am not familiar with KIO, and didn't see the need for OS support.


> KIO slaves on KDE work just like that. It's not something that I think a
> user agent can easily just add in, but something that needs to be supported
> at the OS level.
>

I'm not sure why -- if the UA can save the resource to disk, and it can
upload files from disk to the site, then it can do all the things required.
It could optimize by chaining the streams together so it didn't have to
buffer the whole resource on disk, but an uploaded file is just a bunch of
bytes, so I don't think the OS needs to provide any sendfile-like magic.

I'd actually be a little surprised if there wasn't a Firefox add-on that
permitted this already, though overlaying the native file dialog is sort of
tricky I guess...

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100608/24ff621f/attachment.htm>

From ash at ashleysheridan.co.uk  Tue Jun  8 08:46:02 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 08 Jun 2010 16:46:02 +0100
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <AANLkTinYDmC8gxNxRokSiLfQmNm5laKfQdBiWOX4DT-h@mail.gmail.com>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
	<1276008437.2246.23.camel@localhost>
	<AANLkTinx5hnp_whKxVknpa5Q-KYcW25p7DWrCXhYm_H1@mail.gmail.com>
	<1276009372.2246.30.camel@localhost>
	<AANLkTinYDmC8gxNxRokSiLfQmNm5laKfQdBiWOX4DT-h@mail.gmail.com>
Message-ID: <1276011963.2246.35.camel@localhost>

On Tue, 2010-06-08 at 11:13 -0400, Mike Shaver wrote:
> On Tue, Jun 8, 2010 at 11:02 AM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> 
>         Yes, and the rest of my email said that.
>         
> 
> Sorry, I am not familiar with KIO, and didn't see the need for OS
> support.
>  
>         KIO slaves on KDE work just like that. It's not something that
>         I think a user agent can easily just add in, but something
>         that needs to be supported at the OS level.
>         
> 
> 
> I'm not sure why -- if the UA can save the resource to disk, and it
> can upload files from disk to the site, then it can do all the things
> required.  It could optimize by chaining the streams together so it
> didn't have to buffer the whole resource on disk, but an uploaded file
> is just a bunch of bytes, so I don't think the OS needs to provide any
> sendfile-like magic.
> 
> I'd actually be a little surprised if there wasn't a Firefox add-on
> that permitted this already, though overlaying the native file dialog
> is sort of tricky I guess...
> 
> Mike
>  


Because if it wasn't supported at the OS level, we would be back into
the bad old days where each and every program had to reinvent the wheel
for file dialogues, and no doubt every browser would have it's own
unique way of presenting connecting to a remote resource. Not only that,
but when implemented, you'd have different browsers implementing
different subsets of connectivity. Some will offer only FTP, others will
offer FTP and SFTP, others might offer FTP and SVN only.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From lists at eitanadler.com  Tue Jun  8 09:10:15 2010
From: lists at eitanadler.com (Eitan Adler)
Date: Tue, 8 Jun 2010 19:10:15 +0300
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <4C0E5B1D.7020602@lachy.id.au>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com> 
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
	<4C0E5B1D.7020602@lachy.id.au>
Message-ID: <AANLkTinWDHLGeMb8-CU2MSIhY4Se69f94wsndR-NhzUA@mail.gmail.com>

> My understanding of the proposal is that given this particular control, the
> browser would provide an interface for either selecting a local file or
> entering a URL. ?If a file is selected, the file is uploaded as normal,
> equivalent to <input type="file" name="foo">.
>
> Otherwise, if a URL is entered, the field is instead submitted as text,
> equivalent to <input type="url" name="foo">.
>
> The server would then determine whether the "foo" field that was submitted
> was a file upload or a text field value, and if it were a text field, then
> it would supposedly be treated as a URL that should then be fetched.
>
> Eitan, have I understood your proposal correctly?
>

Yes - exactly.

-- 
Eitan Adler

From chuck at jumis.com  Tue Jun  8 09:26:15 2010
From: chuck at jumis.com (Charles Pritchard)
Date: Tue, 08 Jun 2010 09:26:15 -0700
Subject: [whatwg] input type=ink proposal
Message-ID: <4C0E6F27.40508@jumis.com>

Has there been prior discussion about an input type="ink" form element?

This element would simply capture coordinates from a mouse (or touch/pen 
input device),
allowing the user to reset the value of the element at their discretion.

InkML is in last call:
http://www.w3.org/TR/InkML/

We could use <trace> elements as the data container:
http://www.w3.org/TR/InkML/#trace

It's a fairly simple element, there's no particular reason why it 
couldn't be widely supported.

Digital signatures, amongst other things, have been common for quite 
awhile, just not
in the browser.


Use Case:

As part of a web form, a user signs their digital signature to confirm 
acceptance of terms.

Use Case:

While filling out an online profile, a user submits a simple doodle as 
their avatar.

Use Case:

To quickly log into an online system, a user scribbles a password,
which their server tests for fidelity to their prior scribbled input.


-Charles


From adam at ashannon.us  Tue Jun  8 10:05:40 2010
From: adam at ashannon.us (Adam Shannon)
Date: Tue, 8 Jun 2010 12:05:40 -0500
Subject: [whatwg] input type=ink proposal
In-Reply-To: <4C0E6F27.40508@jumis.com>
References: <4C0E6F27.40508@jumis.com>
Message-ID: <AANLkTilkXweM89JXhMpbslp8U91_lIYTvi3eh8x1xrdj@mail.gmail.com>

I can't remember any discussion (and searching my email returns no
results), The idea seems interesting and useful.

Have you thought about how it will work on mobile platforms (will the
touch screen act as the "pad"?).

I'm guessing that the browser could save an image of the coordinates
plotted together.

Use Case:
Draw on canvas with the pad, just like how "pads" can act like a mouse.

On Tue, Jun 8, 2010 at 11:26, Charles Pritchard <chuck at jumis.com> wrote:
> Has there been prior discussion about an input type="ink" form element?
>
> This element would simply capture coordinates from a mouse (or touch/pen
> input device),
> allowing the user to reset the value of the element at their discretion.
>
> InkML is in last call:
> http://www.w3.org/TR/InkML/
>
> We could use <trace> elements as the data container:
> http://www.w3.org/TR/InkML/#trace
>
> It's a fairly simple element, there's no particular reason why it couldn't
> be widely supported.
>
> Digital signatures, amongst other things, have been common for quite awhile,
> just not
> in the browser.
>
>
> Use Case:
>
> As part of a web form, a user signs their digital signature to confirm
> acceptance of terms.
>
> Use Case:
>
> While filling out an online profile, a user submits a simple doodle as their
> avatar.
>
> Use Case:
>
> To quickly log into an online system, a user scribbles a password,
> which their server tests for fidelity to their prior scribbled input.
>
>
> -Charles
>
>



-- 
Adam Shannon
 Web Developer
 http://ashannon.us

From w3c at adambarth.com  Tue Jun  8 10:47:43 2010
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 8 Jun 2010 10:47:43 -0700
Subject: [whatwg] Installable web apps
In-Reply-To: <200951292.384046.1275995861082.JavaMail.root@cm-mail03.mozilla.org>
References: <292720809.384044.1275995855838.JavaMail.root@cm-mail03.mozilla.org>
	<200951292.384046.1275995861082.JavaMail.root@cm-mail03.mozilla.org>
Message-ID: <AANLkTile0R1PGsFni57pP_Cfn5nQ567hWk21gwQuPTX2@mail.gmail.com>

On Tue, Jun 8, 2010 at 4:17 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> "Aaron Boodman (?)" <aa at google.com> wrote:
>> If we add paths to the mix, we can do this. Applications on the same
>> origin can circumvent it if they want, but why would they? SOP
>> already
>> guarantees that apps on the same origin are friendly and cooperate
>> with each other. That doesn't mean it isn't useful for the UA to know
>> which one is which.
>
> I have to wonder why Google needs the browser team to solve this instead of having the Reader team relocate their stuff to reader.google.com (like maps.google.com is located already).

Last time I asked about this, the answer I got was that there were
performance and branding considerations around whether to host an app
on www or on a dedicated subdomain.  For security, putting each app on
a separate subdomain is a win.

Adam

From avarma at mozilla.com  Tue Jun  8 12:26:12 2010
From: avarma at mozilla.com (Atul Varma)
Date: Tue, 08 Jun 2010 12:26:12 -0700
Subject: [whatwg] Installable web apps
In-Reply-To: <AANLkTile0R1PGsFni57pP_Cfn5nQ567hWk21gwQuPTX2@mail.gmail.com>
References: <292720809.384044.1275995855838.JavaMail.root@cm-mail03.mozilla.org>	<200951292.384046.1275995861082.JavaMail.root@cm-mail03.mozilla.org>
	<AANLkTile0R1PGsFni57pP_Cfn5nQ567hWk21gwQuPTX2@mail.gmail.com>
Message-ID: <4C0E9954.9000603@mozilla.com>

  On 6/8/10 10:47 AM, Adam Barth wrote:
> On Tue, Jun 8, 2010 at 4:17 AM, Henri Sivonen<hsivonen at iki.fi>  wrote:
>> "Aaron Boodman (?)"<aa at google.com>  wrote:
>>> If we add paths to the mix, we can do this. Applications on the same
>>> origin can circumvent it if they want, but why would they? SOP
>>> already
>>> guarantees that apps on the same origin are friendly and cooperate
>>> with each other. That doesn't mean it isn't useful for the UA to know
>>> which one is which.
>> I have to wonder why Google needs the browser team to solve this instead of having the Reader team relocate their stuff to reader.google.com (like maps.google.com is located already).
> Last time I asked about this, the answer I got was that there were
> performance and branding considerations around whether to host an app
> on www or on a dedicated subdomain.  For security, putting each app on
> a separate subdomain is a win.
>
> Adam
For what it's worth, I think that giving developers tools to easily 
define more granular security mechanisms without resorting to subdomains 
is a win in terms of usability, as it's quite difficult to figure out 
how to create subdomains and do virtual hosting--to say nothing of doing 
it over SSL.

That said, introducing a brand new mechanism for security on top of SOP 
does seem like it might make the security landscape more complex as a 
whole, and thereby potentially more vulnerable.

- Atul

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

From w3c at adambarth.com  Tue Jun  8 13:17:32 2010
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 8 Jun 2010 13:17:32 -0700
Subject: [whatwg] Installable web apps
In-Reply-To: <4C0E9954.9000603@mozilla.com>
References: <292720809.384044.1275995855838.JavaMail.root@cm-mail03.mozilla.org>
	<200951292.384046.1275995861082.JavaMail.root@cm-mail03.mozilla.org> 
	<AANLkTile0R1PGsFni57pP_Cfn5nQ567hWk21gwQuPTX2@mail.gmail.com> 
	<4C0E9954.9000603@mozilla.com>
Message-ID: <AANLkTimli_nGowhaSgF33cKZd89FQWZ9tzcs09m33Gn4@mail.gmail.com>

On Tue, Jun 8, 2010 at 12:26 PM, Atul Varma <avarma at mozilla.com> wrote:
> On 6/8/10 10:47 AM, Adam Barth wrote:
> On Tue, Jun 8, 2010 at 4:17 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> "Aaron Boodman (?)" <aa at google.com> wrote:
> If we add paths to the mix, we can do this. Applications on the same
> origin can circumvent it if they want, but why would they? SOP
> already
> guarantees that apps on the same origin are friendly and cooperate
> with each other. That doesn't mean it isn't useful for the UA to know
> which one is which.
>
> I have to wonder why Google needs the browser team to solve this instead of
> having the Reader team relocate their stuff to reader.google.com (like
> maps.google.com is located already).
>
> Last time I asked about this, the answer I got was that there were
> performance and branding considerations around whether to host an app
> on www or on a dedicated subdomain.  For security, putting each app on
> a separate subdomain is a win.
>
> Adam
>
> For what it's worth, I think that giving developers tools to easily define
> more granular security mechanisms without resorting to subdomains is a win
> in terms of usability, as it's quite difficult to figure out how to create
> subdomains and do virtual hosting--to say nothing of doing it over SSL.
>
> That said, introducing a brand new mechanism for security on top of SOP does
> seem like it might make the security landscape more complex as a whole, and
> thereby potentially more vulnerable.

Yes, doing this correctly is quite subtle.  I'd pitch the feature more
as developer connivence rather than for security.  Apps that are
hosted in the same origin need to trust each other.

One analogy is cookie paths, which provide no additional security but
are quite useful for developers.

Adam

From aa at google.com  Tue Jun  8 13:21:02 2010
From: aa at google.com (Aaron Boodman)
Date: Tue, 8 Jun 2010 13:21:02 -0700
Subject: [whatwg] Installable web apps
In-Reply-To: <AANLkTimli_nGowhaSgF33cKZd89FQWZ9tzcs09m33Gn4@mail.gmail.com>
References: <292720809.384044.1275995855838.JavaMail.root@cm-mail03.mozilla.org>
	<200951292.384046.1275995861082.JavaMail.root@cm-mail03.mozilla.org>
	<AANLkTile0R1PGsFni57pP_Cfn5nQ567hWk21gwQuPTX2@mail.gmail.com>
	<4C0E9954.9000603@mozilla.com>
	<AANLkTimli_nGowhaSgF33cKZd89FQWZ9tzcs09m33Gn4@mail.gmail.com>
Message-ID: <AANLkTimA6YjRIh40_few-GpwOQ6MHEEAZ9oRJOgd6APr@mail.gmail.com>

On Tue, Jun 8, 2010 at 1:17 PM, Adam Barth <w3c at adambarth.com> wrote:
> Yes, doing this correctly is quite subtle. ?I'd pitch the feature more
> as developer connivence rather than for security. ?Apps that are
> hosted in the same origin need to trust each other.

That is what we were planning on.

- a

From annevk at opera.com  Tue Jun  8 23:01:47 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 09 Jun 2010 08:01:47 +0200
Subject: [whatwg] Installable web apps
In-Reply-To: <4C0E9954.9000603@mozilla.com>
References: <292720809.384044.1275995855838.JavaMail.root@cm-mail03.mozilla.org>
	<200951292.384046.1275995861082.JavaMail.root@cm-mail03.mozilla.org>
	<AANLkTile0R1PGsFni57pP_Cfn5nQ567hWk21gwQuPTX2@mail.gmail.com>
	<4C0E9954.9000603@mozilla.com>
Message-ID: <op.vd0q09s564w2qv@annevk-t60>

On Tue, 08 Jun 2010 21:26:12 +0200, Atul Varma <avarma at mozilla.com> wrote:
> For what it's worth, I think that giving developers tools to easily
> define more granular security mechanisms without resorting to subdomains
> is a win in terms of usability, as it's quite difficult to figure out
> how to create subdomains and do virtual hosting--to say nothing of doing
> it over SSL.

On DreamHost creating a new subdomain is a couple of clicks...


> That said, introducing a brand new mechanism for security on top of SOP
> does seem like it might make the security landscape more complex as a
> whole, and thereby potentially more vulnerable.


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

From rob at mtn-i.com  Wed Jun  9 05:22:43 2010
From: rob at mtn-i.com (Rob Evans)
Date: Wed, 9 Jun 2010 13:22:43 +0100
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <AANLkTinWDHLGeMb8-CU2MSIhY4Se69f94wsndR-NhzUA@mail.gmail.com>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>	<4C0E5B1D.7020602@lachy.id.au>
	<AANLkTinWDHLGeMb8-CU2MSIhY4Se69f94wsndR-NhzUA@mail.gmail.com>
Message-ID: <02a001cb07ce$76fd4bc0$64f7e340$@com>

Forgive me if this has already been discussed... I cannot find it on the current working draft spec...

I think an interesting addition to the input type=upload would be a script-accessible progress value. Either as a percentage, or probably more useful two values, one being the size of the upload and the other being current bytes sent.

Is this already in the spec somewhere? I can't find anything...

Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element?

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Eitan Adler
Sent: 08 June 2010 17:10
To: Lachlan Hunt
Cc: whatwg at whatwg.org; Simpson, Grant Leyton
Subject: Re: [whatwg] input type=upload (not just files) proposal

> My understanding of the proposal is that given this particular control, the
> browser would provide an interface for either selecting a local file or
> entering a URL.  If a file is selected, the file is uploaded as normal,
> equivalent to <input type="file" name="foo">.
>
> Otherwise, if a URL is entered, the field is instead submitted as text,
> equivalent to <input type="url" name="foo">.
>
> The server would then determine whether the "foo" field that was submitted
> was a file upload or a text field value, and if it were a text field, then
> it would supposedly be treated as a URL that should then be fetched.
>
> Eitan, have I understood your proposal correctly?
>

Yes - exactly.

-- 
Eitan Adler


From rob at mtn-i.com  Wed Jun  9 05:34:57 2010
From: rob at mtn-i.com (Rob Evans)
Date: Wed, 9 Jun 2010 13:34:57 +0100
Subject: [whatwg] Device Element
Message-ID: <02a701cb07d0$2d3c0010$87b40030$@com>

Having a look over the draft, I notice a comment about the device element,
"RS232 is only included below to give an idea of where we could go with
this. Should we instead just make this only useful for audiovisual streams?
Unless there are compelling reasons, we probably should not be this generic.
So far, the reasons aren't that compelling."

 

I have a usage case that would benefit from other types of device access
other than audiovisual:

 

We currently run a news service that requires users log on to access our
data and market reports (practically all major banking institutions in the
world use us). I could envisage either a thumb-print reader allowing us to
authenticate the user biometrically, or providing each user with a USB thumb
stick that contains a unique identifier of some sort that when read using
the device element could be used to authenticate them like a sort-of
"web-dongle".

 

One of our big issues is plagiarism and password sharing amongst our
clients. This type of access would allow us to lock down secure content
without having to install applications on the client computers which as you
can imagine, is a no-no when dealing with banks!

 

Comments anyone?

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

From jsalsman at gmail.com  Wed Jun  9 05:47:04 2010
From: jsalsman at gmail.com (James Salsman)
Date: Wed, 9 Jun 2010 05:47:04 -0700
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <02a001cb07ce$76fd4bc0$64f7e340$@com>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>
	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>
	<4C0E5B1D.7020602@lachy.id.au>
	<AANLkTinWDHLGeMb8-CU2MSIhY4Se69f94wsndR-NhzUA@mail.gmail.com>
	<02a001cb07ce$76fd4bc0$64f7e340$@com>
Message-ID: <AANLkTiloNOVKc_UxPzTAxdK2QJwrW-WCHQHMw2zNwDRa@mail.gmail.com>

On Wed, Jun 9, 2010 at 5:22 AM, Rob Evans <rob at mtn-i.com> wrote:
>
> I think an interesting addition to the input type=upload would be a script-accessible progress value.
> Either as a percentage, or probably more useful two values, one being the size of the upload and
> the other being current bytes sent.

If you are uploading by reference to URL (which presumably the server
would fetch to save bandwidth) then progress information is probably
not something that can easily be exposed by the HTML interface.  You
might want to use an out-of-band ajax-style channel with javascript to
show progress instead.

> Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element?

That's been in there since HTML 3.2, I believe, and was implemented by
some browsers (IE 5-8?).  User interface concerns almost always end up
preferring dynamic form behaviors, with variable numbers of input
type=file elements added and removed on an as-needed basis before the
form is submitted.

From huskyr at gmail.com  Wed Jun  9 06:05:47 2010
From: huskyr at gmail.com (Hay (Husky))
Date: Wed, 9 Jun 2010 15:05:47 +0200
Subject: [whatwg] A 'muted' event for the <video> element
Message-ID: <AANLkTilj3irhXqb1gT6_J93RpL6cjFjH4kV0-kEkjx5n@mail.gmail.com>

Hi everyone,
i'm currently building a Javascript based interface for the <video>
element. One of the things that really seem to be lacking from the
specification (and hence, browsers too) is a distinct 'muted' event
that occurs whenever you set the muted property to 'true' or 'false'.
Of course, the 'volumechange' event occurs, but that also happens
whenever you set the volume so you have to check every time the event
occurs if it originated from a change on the volume or muted property.
Because these two capabilities of the <video> element have different
properties, it seems to make sense to let them trigger different
events too (or have the muted property trigger 'volumechange' as
well).

Regards,
-- Hay Kranen

From rob at mtn-i.com  Wed Jun  9 06:10:19 2010
From: rob at mtn-i.com (Rob Evans)
Date: Wed, 9 Jun 2010 14:10:19 +0100
Subject: [whatwg] input type=upload (not just files) proposal
In-Reply-To: <AANLkTiloNOVKc_UxPzTAxdK2QJwrW-WCHQHMw2zNwDRa@mail.gmail.com>
References: <AANLkTilDDjCRlEjjfASIdij1jLuaHC-ai_SLBJ_iP8sn@mail.gmail.com>	<9E7B8E4B-FC06-44EF-BF5C-B56BD29756FC@indiana.edu>	<4C0E5B1D.7020602@lachy.id.au>	<AANLkTinWDHLGeMb8-CU2MSIhY4Se69f94wsndR-NhzUA@mail.gmail.com>	<02a001cb07ce$76fd4bc0$64f7e340$@com>
	<AANLkTiloNOVKc_UxPzTAxdK2QJwrW-WCHQHMw2zNwDRa@mail.gmail.com>
Message-ID: <02b701cb07d5$1ce4b450$56ae1cf0$@com>

> If you are uploading by reference to URL (which presumably the server
> would fetch to save bandwidth) then progress information is probably
> not something that can easily be exposed by the HTML interface.  You
> might want to use an out-of-band ajax-style channel with javascript to
> show progress instead.

Indeed, when referencing a URL I don't think progress bars are much of an issue, but when dealing with a local file upload it would be great to have those values exposed to scripts! I hate having to poll the server for a progress update... it's so 1990. Or has this already been exposed to scripts... am I behind the times? So much to keep up with!

> That's been in there since HTML 3.2, I believe, and was implemented by
> some browsers (IE 5-8?).  User interface concerns almost always end up
> preferring dynamic form behaviors, with variable numbers of input
> type=file elements added and removed on an as-needed basis before the
> form is submitted.

I guess it's a matter of preference, but if you're uploading a load of images for instance, it gets tiresome having to keep clicking select file on every new input element. I wasn't aware that IE had implemented multiple file selection inside a single element however I would never have noticed anyway as I shun IE and avoid it like the plague.

-----Original Message-----
From: James Salsman [mailto:jsalsman at gmail.com] 
Sent: 09 June 2010 13:47
To: Rob Evans; whatwg at lists.whatwg.org
Subject: Re: [whatwg] input type=upload (not just files) proposal

On Wed, Jun 9, 2010 at 5:22 AM, Rob Evans <rob at mtn-i.com> wrote:
>
> I think an interesting addition to the input type=upload would be a script-accessible progress value.
> Either as a percentage, or probably more useful two values, one being the size of the upload and
> the other being current bytes sent.

If you are uploading by reference to URL (which presumably the server
would fetch to save bandwidth) then progress information is probably
not something that can easily be exposed by the HTML interface.  You
might want to use an out-of-band ajax-style channel with javascript to
show progress instead.

> Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element?

That's been in there since HTML 3.2, I believe, and was implemented by
some browsers (IE 5-8?).  User interface concerns almost always end up
preferring dynamic form behaviors, with variable numbers of input
type=file elements added and removed on an as-needed basis before the
form is submitted.


From narendra at narendrasisodiya.com  Wed Jun  9 11:29:01 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Wed, 9 Jun 2010 23:59:01 +0530
Subject: [whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
Message-ID: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>

Canvas API is just great and I love it, You will also love it , if not, just
see Canvas demos - http://www.canvasdemos.com

But we have potential danger to misuse it also for the sake of
non-standards.

<prediction>
*Case 1 *- Abode can make its flash-player inside canvas API. I know, it
will not be 100% compatible. They can create a CanvasAPI based flash player.
Their are already  2 client side run time engine in JavaScript - Smokescreen
and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest
advantage with JS and client side is that you can see sourcecode. In order
to hide the source code , Adobe can use server side. Some processing will be
on server side and output will be streamed (in form of image) to client side
and renders into CANVAS area with pixel. You can grab event from canvas area
and send bacl to server. This way Developer may come up with a *Server Side
HTML5 toolkit* which will reuse BAD standards like flash with Hiding Source
code of a Web Application . Adobe or other companies can modify their
products and generate server side HTML5 code which will render the
application CANVAS API.
A huge number of dummy developer use such non-standards tools and with this,
they will be able to reuse skills by this and will not adopt a true spirit
of HTML5.
          So, This I do not like,,,--> ''designer/developers will be using
non-standard server side code, generated from non-standards ToolKits, and
pretend that we also use HTML5"

We urgently need HTML5 authoring tool. we urgently needs SVG authoring
tools.


</prediction>

I *guess*, with the advance of html5, Adobe has been working hard to run
flash on canvas from server inorder to save its presence.


.
-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
Yet another HTML5 Developer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100609/ac5a9424/attachment.htm>

From peter at lvp-media.com  Wed Jun  9 11:50:17 2010
From: peter at lvp-media.com (Peter Beverloo)
Date: Wed, 9 Jun 2010 20:50:17 +0200
Subject: [whatwg] Potential Danger with Canvas API in html5 #html5
	#canvas
In-Reply-To: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
References: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
Message-ID: <AANLkTil8MEDaNMWRK-eD3p0ndd9SYOX4fjlR8bYUMqCg@mail.gmail.com>

On Wed, Jun 9, 2010 at 20:29, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
>
> Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com
>
> But we have potential danger to misuse it also for the sake of non-standards.
>
> <prediction>
> Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already? 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API.
> A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5.
> ????????? So, This I do not like,,,--> ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5"
>
> We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools.
>
>
> </prediction>
>
> I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence.
>
>
> .
> --
> ???????????????????????????
> ? ? ?Narendra Sisodiya
> ? ? ?http://narendrasisodiya.com
> ???????????????????????????
> Yet another HTML5 Developer.

Hello Narandra,

Do you have any links or sources backing up that Adobe is working on
the server-side? While your scenario certainly is possible, even with
today's possibilities, I see a number of problems with it:

1) The number of simultaneous users in any web application will be
severely limited by the available processing power of the server.
Thinking of the current uses of Flash, a really large part of which
are video players and games, it does not seem realistic. Extend this
to Flash applications such as FarmVille on Facebook and server-side
processing and rendering will be pretty close to impossible.

2) How exactly is this different from normal webpages? A lot of
websites use scripting languages as their back end, such as PHP,
delivering a certain flexibility which is not directly visible to the
user. The same thing can be applied to achieve creating personalized
Application Cache Manifests.

On top of that, there are various Javascript obfuscators around which
convert code to nearly unreadable pieces of text. While code
formatting can be normalized using a range of tools, variables like
"_" and "___" will be continue to be confusing nonetheless. Such
obfuscation is enough to stop 99% of the people from getting/copying
the code, going through the trouble of continuous connections and
server-side processing for that last percent seems unlikely.

If any application is that critical, the author should consider
limiting access to the application altogether.

Regards,
Peter

From Simetrical+w3c at gmail.com  Wed Jun  9 11:54:31 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 9 Jun 2010 14:54:31 -0400
Subject: [whatwg] Potential Danger with Canvas API in html5 #html5
	#canvas
In-Reply-To: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
References: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
Message-ID: <AANLkTiktlfj2Kdq8VCyXnu1ncrmgJnk7A6ZxFqItjMaj@mail.gmail.com>

On Wed, Jun 9, 2010 at 2:29 PM, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
> Case 1 - Abode can make its flash-player inside canvas API. I know, it will
> not be 100% compatible. They can create a CanvasAPI based flash player.
> Their are already? 2 client side run time engine in JavaScript - Smokescreen
> and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest
> advantage with JS and client side is that you can see sourcecode. In order
> to hide the source code , Adobe can use server side. Some processing will be
> on server side and output will be streamed (in form of image) to client side
> and renders into CANVAS area with pixel. You can grab event from canvas area
> and send bacl to server. This way Developer may come up with a Server Side
> HTML5 toolkit which will reuse BAD standards like flash with Hiding Source
> code of a Web Application . Adobe or other companies can modify their
> products and generate server side HTML5 code which will render the
> application CANVAS API.
> A huge number of dummy developer use such non-standards tools and with this,
> they will be able to reuse skills by this and will not adopt a true spirit
> of HTML5.
> ????????? So, This I do not like,,,--> ''designer/developers will be using
> non-standard server side code, generated from non-standards ToolKits, and
> pretend that we also use HTML5"

The goal of HTML5 is that all browsers and platforms should be able to
display all web pages, without dependence on any particular software
vendor.  If a company like Adobe writes a framework using
cross-browser, cross-platform, openly specified APIs, we're in a far
better situation than now.  It would really be no different from
jQuery.

Furthermore, it's not *possible* to prevent anyone from writing
toolkits that use HTML5 features.  Or do you have any suggestions to
stop it?

From narendra at narendrasisodiya.com  Wed Jun  9 12:26:36 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Thu, 10 Jun 2010 00:56:36 +0530
Subject: [whatwg] Potential Danger with Canvas API in html5 #html5
	#canvas
In-Reply-To: <AANLkTiktlfj2Kdq8VCyXnu1ncrmgJnk7A6ZxFqItjMaj@mail.gmail.com>
References: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
	<AANLkTiktlfj2Kdq8VCyXnu1ncrmgJnk7A6ZxFqItjMaj@mail.gmail.com>
Message-ID: <AANLkTimnEIQfqvVIquQ-enpl3DoEpOcNboAzkGo-u7Fr@mail.gmail.com>

On Thu, Jun 10, 2010 at 12:24 AM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Wed, Jun 9, 2010 at 2:29 PM, narendra sisodiya
> <narendra at narendrasisodiya.com> wrote:
> > Case 1 - Abode can make its flash-player inside canvas API. I know, it
> will
> > not be 100% compatible. They can create a CanvasAPI based flash player.
> > Their are already  2 client side run time engine in JavaScript -
> Smokescreen
> > and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest
> > advantage with JS and client side is that you can see sourcecode. In
> order
> > to hide the source code , Adobe can use server side. Some processing will
> be
> > on server side and output will be streamed (in form of image) to client
> side
> > and renders into CANVAS area with pixel. You can grab event from canvas
> area
> > and send bacl to server. This way Developer may come up with a Server
> Side
> > HTML5 toolkit which will reuse BAD standards like flash with Hiding
> Source
> > code of a Web Application . Adobe or other companies can modify their
> > products and generate server side HTML5 code which will render the
> > application CANVAS API.
> > A huge number of dummy developer use such non-standards tools and with
> this,
> > they will be able to reuse skills by this and will not adopt a true
> spirit
> > of HTML5.
> >           So, This I do not like,,,--> ''designer/developers will be
> using
> > non-standard server side code, generated from non-standards ToolKits, and
> > pretend that we also use HTML5"
>
> The goal of HTML5 is that all browsers and platforms should be able to
> display all web pages, without dependence on any particular software
> vendor.  If a company like Adobe writes a framework using
> cross-browser, cross-platform, openly specified APIs, we're in a far
> better situation than now.  It would really be no different from
> jQuery.
>
>
Yes, sure, I love to advocate adobe/similarcompany and modify my video -
http://tinyvid.tv/show/2dz18ka146nfz , Provided they should do it in Client
side so source can be seen.* Providing a server side or similar rendering
system which use 'Canvas' for displaying everything inside canvas from
server side is as bad as flash player/plugin.Web may be hidden again under
pixels.*


> Furthermore, it's not *possible* to prevent anyone from writing
> toolkits that use HTML5 features.  Or do you have any suggestions to
> stop it?
>

We can't stop anyone. Advocate SVG and making SVG-animation support with SVG
animation authoring tools is a good way to reduce 'server side canvas
rendering'.



-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100610/c6b83b77/attachment.htm>

From Simetrical+w3c at gmail.com  Wed Jun  9 12:47:40 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 9 Jun 2010 15:47:40 -0400
Subject: [whatwg] Potential Danger with Canvas API in html5 #html5
	#canvas
In-Reply-To: <AANLkTimnEIQfqvVIquQ-enpl3DoEpOcNboAzkGo-u7Fr@mail.gmail.com>
References: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
	<AANLkTiktlfj2Kdq8VCyXnu1ncrmgJnk7A6ZxFqItjMaj@mail.gmail.com>
	<AANLkTimnEIQfqvVIquQ-enpl3DoEpOcNboAzkGo-u7Fr@mail.gmail.com>
Message-ID: <AANLkTikElxOUGccuD3RGVgpQATHfpWCF-YLHYt87E4eJ@mail.gmail.com>

On Wed, Jun 9, 2010 at 3:26 PM, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
> Yes, sure, I love to advocate adobe/similarcompany and modify my video -
> http://tinyvid.tv/show/2dz18ka146nfz , Provided they should do it in Client
> side so source can be seen. Providing a server side or similar rendering
> system which use 'Canvas' for displaying everything inside canvas from
> server side is as bad as flash player/plugin.Web may be hidden again under
> pixels.

It's not as bad.  It will work equally on all browsers and all
platforms, and several parties will get to compete on some key aspects
of the implementation (such as the speed and stability of the
underlying JavaScript).  It's not much different from any website
using closed-source server-side code.

> We can't stop anyone. Advocate SVG and making SVG-animation support with SVG
> animation authoring tools is a good way to reduce 'server side canvas
> rendering'.

If you don't have spec changes to propose, this is probably the wrong list.

From narendra at narendrasisodiya.com  Wed Jun  9 13:05:35 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Thu, 10 Jun 2010 01:35:35 +0530
Subject: [whatwg] Potential Danger with Canvas API in html5 #html5
	#canvas
In-Reply-To: <AANLkTil8MEDaNMWRK-eD3p0ndd9SYOX4fjlR8bYUMqCg@mail.gmail.com>
References: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
	<AANLkTil8MEDaNMWRK-eD3p0ndd9SYOX4fjlR8bYUMqCg@mail.gmail.com>
Message-ID: <AANLkTilpcAzgIZlegV4UxQSk_6hEax1r_dxtJn6MPUCN@mail.gmail.com>

On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo <peter at lvp-media.com>wrote:

> On Wed, Jun 9, 2010 at 20:29, narendra sisodiya
> <narendra at narendrasisodiya.com> wrote:
> >
> > Canvas API is just great and I love it, You will also love it , if not,
> just see Canvas demos - http://www.canvasdemos.com
> >
> > But we have potential danger to misuse it also for the sake of
> non-standards.
> >
> > <prediction>
> > Case 1 - Abode can make its flash-player inside canvas API. I know, it
> will not be 100% compatible. They can create a CanvasAPI based flash player.
> Their are already  2 client side run time engine in JavaScript - Smokescreen
> and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest
> advantage with JS and client side is that you can see sourcecode. In order
> to hide the source code , Adobe can use server side. Some processing will be
> on server side and output will be streamed (in form of image) to client side
> and renders into CANVAS area with pixel. You can grab event from canvas area
> and send bacl to server. This way Developer may come up with a Server Side
> HTML5 toolkit which will reuse BAD standards like flash with Hiding Source
> code of a Web Application . Adobe or other companies can modify their
> products and generate server side HTML5 code which will render the
> application CANVAS API.
> > A huge number of dummy developer use such non-standards tools and with
> this, they will be able to reuse skills by this and will not adopt a true
> spirit of HTML5.
> >           So, This I do not like,,,--> ''designer/developers will be
> using non-standard server side code, generated from non-standards ToolKits,
> and pretend that we also use HTML5"
> >
> > We urgently need HTML5 authoring tool. we urgently needs SVG authoring
> tools.
> >
> >
> > </prediction>
> >
> > I guess, with the advance of html5, Adobe has been working hard to run
> flash on canvas from server inorder to save its presence.
> >
> >
> > .
> > --
> > ???????????????????????????
> > ?    Narendra Sisodiya
> > ?    http://narendrasisodiya.com
> > ???????????????????????????
> > Yet another HTML5 Developer.
>
> Hello Narandra,
>
> Do you have any links or sources backing up that Adobe is working on
> the server-side? While your scenario certainly is possible, even with
> today's possibilities, I see a number of problems with it:
>
>
No, i  do not have any info. I am independent developer who enjoy making
predictions -
http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html


> 1) The number of simultaneous users in any web application will be
> severely limited by the available processing power of the server.
> Thinking of the current uses of Flash, a really large part of which
> are video players and games, it does not seem realistic. Extend this
> to Flash applications such as FarmVille on Facebook and server-side
> processing and rendering will be pretty close to impossible.
>


Yes, you are correct at this points,



> 2) How exactly is this different from normal webpages? A lot of
> websites use scripting languages as their back end, such as PHP,
> delivering a certain flexibility which is not directly visible to the
> user. The same thing can be applied to achieve creating personalized
> Application Cache Manifests.
>
>
PHP script generate HTML code along with JavaScript. It make our task easy.


But, Lets imagine
if we have a very good Tookkit which have everything for webdesign like
buttions, menus, dropdown and final code renders everything in CANVAS.
ToolKits may use altogether different higher level sytax to generate canvas
based applications. further this toolkit has JavaScript unzip library. then
you will be able to create a application in zipped format.
Let me explain this more

   - Designer/Developer will use drag and drop based Toolkit which has
   altogether different higher level sytax which generate CANVAS based
   application.
   - Toolkit Or some JavaScript code will generate JavaScript code with all
   resource like image, htmlcode, source code and everything in application
   directory.
   - Toolkit will zip the whole application and finally designer/developer
   will get a *myfirstgame.wapp *

Now developer/designer need to write this much code

<script src="./js/wapp-engine.js"></script>
<div class='wapp-application' data-src='./myfirstgame.wapp' width='600'
height='800' />

This wapp-engine.js will be a wapp player which load
*myfirstgame.wapp*using Ajax and unzip files. Create a dynamic canvas,
and render the game in
canvas area.

So we are using HTML5 canvas but what are we doing

   - Fast and GUI based development tools with a non-standards/proprietary
   ToolKit for generating a .wapp files which can be distributed and developed
   easily
   - .wapp will be played in browser will be JS wapp player which render it
   inside CANVAS API with hiding images, text and everything under pixels which
   is the prime requirement of many website
   - Desktop based wapp player inorder to play downloded .wapp files.
   - Web will become a binary world.

So, it is quite possible to introduce a new non-standard technology under
the CANVAS API with Javascript unzip library.





> On top of that, there are various Javascript obfuscators around which
> convert code to nearly unreadable pieces of text. While code
> formatting can be normalized using a range of tools, variables like
> "_" and "___" will be continue to be confusing nonetheless.


Wow, I have not having this idea in my mind. thanks for the trick.


> Such
> obfuscation is enough to stop 99% of the people from getting/copying
> the code, going through the trouble of continuous connections and
> server-side processing for that last percent seems unlikely.
>
> If any application is that critical, the author should consider
> limiting access to the application altogether.
>
> Regards,
> Peter
>



-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100610/632b8a0f/attachment-0001.htm>

From Jeff.Hodges at KingsMountain.com  Wed Jun  9 15:40:35 2010
From: Jeff.Hodges at KingsMountain.com (=JeffH)
Date: Wed, 09 Jun 2010 15:40:35 -0700
Subject: [whatwg] IETF BoF @IETF-78 Maastricht: HASMAT - HTTP Application
 Security Minus Authentication and Transport
Message-ID: <4C101863.70804@KingsMountain.com>

[apologies for cross-post]

Hi,

We will be hosting the "HTTP Application Security Minus Authentication and
Transport (HASMAT)" Birds-of-a-Feather (BoF) session at IETF-78 in Maastricht
NL during the week of July 25-30, 2010  (see [0] for mailing list).

The purpose of IETF BoFs is to determine whether there is a problem worth
solving, and whether the IETF is the right group to solve it. To that end, the
problem statement is summarized below in the Draft HASMAT Working Group
Charter, and is drawn from this paper [1].

Various facets of this work are already underway, as outlined below in the
draft WG charter, e.g. Strict Transport Security (STS) [2].

Of course the scope of "HTTP application security" is quite broad (as outlined
in [1]), thus the intent is to coordinate this work closely with related work
likely to land in the W3C (and possibly other orgs), e.g. Content Security
Policy (CSP) [3].

We have created a public mailing list [0] for pre-BoF discussion --
hasmat at ietf.org -- to which you can freely subscribe here:
<https://www.ietf.org/mailman/listinfo/hasmat>

We encourage all interested parties to join the hasmat@ mailing list and engage
in the on-going discussion there.

thanks,

=JeffH             (current IETF HTTPstate WG chair)
Peter Saint-Andre  (IETF Applications Area Director)
Hannes Tschofenig  (IAB, IETF WG chair)
----------------------------------------------------

[0] HASMAT mailing list.
https://www.ietf.org/mailman/listinfo/hasmat

[1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy
Framework", W2SP position paper, 2010.
http://w2spconf.com/2010/papers/p11.pdf

[2] Hodges, Jackson, and Barth, "Strict Transport Security (STS)",
revision -06.
http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html 


see also: http://en.wikipedia.org/wiki/Strict_Transport_Security


[3] Sterne and Stamm, "Content Security Policy (CSP)".
https://wiki.mozilla.org/Security/CSP/Specification
see also: http://people.mozilla.org/~bsterne/content-security-policy/
           https://wiki.mozilla.org/Security/CSP/Design_Considerations


###

Proposed HASMAT BoF agenda
--------------------------

Chairs: Hannes Tschofenig and Jeff Hodges

5 min   Agenda bashing (Chairs)

10 min  Description of the problem space (TBD)

20 min  Motivation for standardizing (TBD)
         draft-abarth-mime-sniff
         draft-abarth-origin
         draft-hodges-stricttransportsec (to-be-submitted)

15 min  Presentation of charter text (TBD)

60 min  Discussion of charter text and choice of the initial
specifications (All)

10 min  Conclusion (Chairs/ADs)



###

Draft Charter for HASMAT:

    HTTP Application Security Minus Authentication and Transport WG


Problem Statement

Although modern Web applications are built on top of HTTP, they provide
rich functionality and have requirements beyond the original vision of
static web pages.  HTTP, and the applications built on it, have evolved
organically.  Over the past few years, we have seen a proliferation of
AJAX-based web applications (AJAX being shorthand for asynchronous
JavaScript and XML), as well as Rich Internet Applications (RIAs), based
on so-called Web 2.0 technologies.  These applications bring both
luscious eye-candy and convenient functionality, e.g. social networking,
to their users, making them quite compelling.  At the same time, we are
seeing an increase in attacks against these applications and their
underlying technologies.

The list of attacks is long and includes Cross-Site-Request Forgery
(CSRF)-based attacks, content-sniffing cross-site-scripting (XSS)
attacks, attacks against browsers supporting anti-XSS policies,
clickjacking attacks, malvertising attacks, as well as man-in-the-middle
(MITM) attacks against "secure" (e.g. Transport Layer Security
(TLS/SSL)-based) web sites along with distribution of the tools to carry
out such attacks (e.g. sslstrip).


Objectives and Scope

With the arrival of new attacks the introduction of new web security
indicators, security techniques, and policy communication mechanisms
have sprinkled throughout the various layers of the Web and HTTP.

The goal of this working group is to standardize a small number of
selected specifications that have proven to improve security of Internet
Web applications. The requirements guiding the work will be taken from
the Web application and Web security communities.  Initial work will be
limited to the following topics:

    - Same origin policy, as discussed in draft-abarth-origin

    - Strict transport security, as discussed in
      draft-hodges-stricttransportsec (to be submitted shortly)

    - Media type sniffing, as discussed in draft-abarth-mime-sniff

In addition, this working group will consider the overall topic of HTTP
application security and compose a "problem statement and requirements"
document that can be used to guide further work.

This working group will work closely with IETF Apps Area WGs (such as
HYBI, HTTPstate, and HTTPbis), as well as W3C WebApps working group(s).


Out of Scope

As noted in this working group's title, this working group's scope does
not include working on HTTP Authentication nor underlying transport
(secure or not) topics. So, for example, these items are out-of-scope
for this WG:

    - Replacements for BASIC and DIGEST authentication

    - New transports (e.g. SCTP and the like)


Deliverables

1. A document illustrating the security problems Web applications are
facing and listing design requirements.  This document shall be
Informational.

2. A selected set of technical specifications documenting deployed
HTTP-based Web security solutions.
These documents shall be Standards Track.


Goals and Milestones

Oct 2010    Submit "HTTP Application Security Problem Statement and
             Requirements" as initial WG item.

Oct 2010    Submit "Media Type Sniffing" as initial WG item.

Oct 2010    Submit "Web Origin Concept" as initial WG item.

Oct 2010    Submit "Strict Transport Security" as initial WG item.

Feb 2011    Submit "HTTP Application Security Problem Statement and
             Requirements" to the IESG for consideration as an
             Informational RFC.

Mar 2011    Submit "Media Type Sniffing" to the IESG for consideration
             as a Standards Track RFC.

Mar 2011    Submit "Web Origin Concept" to the IESG for consideration as
             a Standards Track RFC.

Mar 2011    Submit "Strict Transport Security" to the IESG for
             consideration as a Standards Track RFC.

Apr 2011    Possible re-chartering



###




From kevinmarks at gmail.com  Wed Jun  9 17:05:25 2010
From: kevinmarks at gmail.com (Kevin Marks)
Date: Wed, 9 Jun 2010 17:05:25 -0700
Subject: [whatwg] audio and video: volume and muted as content
	attributes?
In-Reply-To: <op.vdly0w0aatwj1d@philip-pc.oslo.osa>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com>
	<op.vdlxapn2atwj1d@philip-pc.oslo.osa>
	<AANLkTikfSnCdoCOdeBeJYqb3_JvO3njI5papjOcUvhh7@mail.gmail.com>
	<op.vdly0w0aatwj1d@philip-pc.oslo.osa>
Message-ID: <AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com>

Setting volume above 1.0 can be very useful if the original is too quiet.
For example, Quicktime allows a volume of 300% to amplify quiet tracks

On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote:

On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer <
silviapfeiffer1 at gmail.com> wrote:

> On Tue, Ju...
This would make volume even more special, as a float that reflects as an
integer percentage. Just using the existing definition for reflecting a
float would be simpler.



>> So, I am neither in favor or against of reflecting volume and mute as
>> content attributes. Im...
I'd be fine with reflecting muted if many people think it would be useful.
I'm not the one to make that judgment though.

Volume isn't a huge problem, just not as trivial as one might suspect.
Another thing to consider is that it is currently impossible to set volume
to a value outside the range [0,1] via the DOM API. With a content
attribute, volume="-1" and volume="1.1" would need to be handled too. I'd
prefer it being ignored rather than being clamped.



>> [1]
>>
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
>
>
>
> Ch...

-- 
Philip J?genstedt
Core Developer
Opera Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100609/1dddc9df/attachment.htm>

From silviapfeiffer1 at gmail.com  Wed Jun  9 18:52:27 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 10 Jun 2010 11:52:27 +1000
Subject: [whatwg] audio and video: volume and muted as content
	attributes?
In-Reply-To: <AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com> 
	<op.vdlxapn2atwj1d@philip-pc.oslo.osa>
	<AANLkTikfSnCdoCOdeBeJYqb3_JvO3njI5papjOcUvhh7@mail.gmail.com> 
	<op.vdly0w0aatwj1d@philip-pc.oslo.osa>
	<AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com>
Message-ID: <AANLkTinR5Jo_B0p9KG15MHMxb8QBuzLY8Uc73PIsGX2Q@mail.gmail.com>

I don't think that is possible in the way that the volume attribute is
currently defined as a value between [0;1]. That is an orthogonal, but
still important question about the volume attribute then.

So, if you say 300%, I assume you mean 3 times louder than what the
track is given as? I do wonder how to do that with the current volume
attribute - right now the spec says that the default value set is 1.0
[1]. It seems that means we cannot amplify a quiet audio track but
have to rely on the user to turn up the volume on their computer? I
would actually prefer if the default setting was something like 0.5
and we could then turn the volume up or down in javascript or
preferably event through a content attribute as mentioned.

Cheers,
Silvia.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume


On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks <kevinmarks at gmail.com> wrote:
> Setting volume above 1.0 can be very useful if the original is too quiet.
> For example, Quicktime allows a volume of 300% to amplify quiet tracks
>
> On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote:
>
> On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>
>> On Tue, Ju...
>
> This would make volume even more special, as a float that reflects as an
> integer percentage. Just using the existing definition for reflecting a
> float would be simpler.
>
>>> So, I am neither in favor or against of reflecting volume and mute as
>>> content attributes. Im...
>
> I'd be fine with reflecting muted if many people think it would be useful.
> I'm not the one to make that judgment though.
>
> Volume isn't a huge problem, just not as trivial as one might suspect.
> Another thing to consider is that it is currently impossible to set volume
> to a value outside the range [0,1] via the DOM API. With a content
> attribute, volume="-1" and volume="1.1" would need to be handled too. I'd
> prefer it being ignored rather than being clamped.
>
>>> [1]
>>>
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
>>
>>
>>
>> Ch...
>
> --
> Philip J?genstedt
> Core Developer
> Opera Software

From ash at ashleysheridan.co.uk  Wed Jun  9 18:55:22 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Thu, 10 Jun 2010 02:55:22 +0100
Subject: [whatwg] audio and video: volume and muted as content
 attributes?
In-Reply-To: <AANLkTinR5Jo_B0p9KG15MHMxb8QBuzLY8Uc73PIsGX2Q@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com>
	<op.vdlxapn2atwj1d@philip-pc.oslo.osa>
	<AANLkTikfSnCdoCOdeBeJYqb3_JvO3njI5papjOcUvhh7@mail.gmail.com>
	<op.vdly0w0aatwj1d@philip-pc.oslo.osa>
	<AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com>
	<AANLkTinR5Jo_B0p9KG15MHMxb8QBuzLY8Uc73PIsGX2Q@mail.gmail.com>
Message-ID: <1276134922.2247.1.camel@localhost>

On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote:

> I don't think that is possible in the way that the volume attribute is
> currently defined as a value between [0;1]. That is an orthogonal, but
> still important question about the volume attribute then.
> 
> So, if you say 300%, I assume you mean 3 times louder than what the
> track is given as? I do wonder how to do that with the current volume
> attribute - right now the spec says that the default value set is 1.0
> [1]. It seems that means we cannot amplify a quiet audio track but
> have to rely on the user to turn up the volume on their computer? I
> would actually prefer if the default setting was something like 0.5
> and we could then turn the volume up or down in javascript or
> preferably event through a content attribute as mentioned.
> 
> Cheers,
> Silvia.
> 
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume
> 
> 
> On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks <kevinmarks at gmail.com> wrote:
> > Setting volume above 1.0 can be very useful if the original is too quiet.
> > For example, Quicktime allows a volume of 300% to amplify quiet tracks
> >
> > On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote:
> >
> > On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer
> > <silviapfeiffer1 at gmail.com> wrote:
> >
> >> On Tue, Ju...
> >
> > This would make volume even more special, as a float that reflects as an
> > integer percentage. Just using the existing definition for reflecting a
> > float would be simpler.
> >
> >>> So, I am neither in favor or against of reflecting volume and mute as
> >>> content attributes. Im...
> >
> > I'd be fine with reflecting muted if many people think it would be useful.
> > I'm not the one to make that judgment though.
> >
> > Volume isn't a huge problem, just not as trivial as one might suspect.
> > Another thing to consider is that it is currently impossible to set volume
> > to a value outside the range [0,1] via the DOM API. With a content
> > attribute, volume="-1" and volume="1.1" would need to be handled too. I'd
> > prefer it being ignored rather than being clamped.
> >
> >>> [1]
> >>>
> >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
> >>
> >>
> >>
> >> Ch...
> >
> > --
> > Philip J?genstedt
> > Core Developer
> > Opera Software


Or you could just raise the volume of the audio track itself. I think
being able to raise the volume like this (beyond 100% of what it is)
with script just makes it something more likely to be abused (think how
the TV adverts always seem twice as loud as the programs they surround)
and so will end up getting blocked more often.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From silviapfeiffer1 at gmail.com  Wed Jun  9 19:03:55 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 10 Jun 2010 12:03:55 +1000
Subject: [whatwg] audio and video: volume and muted as content
	attributes?
In-Reply-To: <1276134922.2247.1.camel@localhost>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com> 
	<op.vdlxapn2atwj1d@philip-pc.oslo.osa>
	<AANLkTikfSnCdoCOdeBeJYqb3_JvO3njI5papjOcUvhh7@mail.gmail.com> 
	<op.vdly0w0aatwj1d@philip-pc.oslo.osa>
	<AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com> 
	<AANLkTinR5Jo_B0p9KG15MHMxb8QBuzLY8Uc73PIsGX2Q@mail.gmail.com> 
	<1276134922.2247.1.camel@localhost>
Message-ID: <AANLkTilEgi30SMkyTypg0qIcOENJ-9EuYph33dAacZAl@mail.gmail.com>

On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan
<ash at ashleysheridan.co.uk>wrote:

>  On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote:
>
> I don't think that is possible in the way that the volume attribute is
> currently defined as a value between [0;1]. That is an orthogonal, but
> still important question about the volume attribute then.
>
> So, if you say 300%, I assume you mean 3 times louder than what the
> track is given as? I do wonder how to do that with the current volume
> attribute - right now the spec says that the default value set is 1.0
> [1]. It seems that means we cannot amplify a quiet audio track but
> have to rely on the user to turn up the volume on their computer? I
> would actually prefer if the default setting was something like 0.5
> and we could then turn the volume up or down in javascript or
> preferably event through a content attribute as mentioned.
>
> Cheers,
> Silvia.
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume
>
>
> On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks <kevinmarks at gmail.com> wrote:
> > Setting volume above 1.0 can be very useful if the original is too quiet.
> > For example, Quicktime allows a volume of 300% to amplify quiet tracks
> >
> > On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote:
> >
> > On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer
> > <silviapfeiffer1 at gmail.com> wrote:
> >
> >> On Tue, Ju...
> >
> > This would make volume even more special, as a float that reflects as an
> > integer percentage. Just using the existing definition for reflecting a
> > float would be simpler.
> >
> >>> So, I am neither in favor or against of reflecting volume and mute as
> >>> content attributes. Im...
> >
> > I'd be fine with reflecting muted if many people think it would be useful.
> > I'm not the one to make that judgment though.
> >
> > Volume isn't a huge problem, just not as trivial as one might suspect.
> > Another thing to consider is that it is currently impossible to set volume
> > to a value outside the range [0,1] via the DOM API. With a content
> > attribute, volume="-1" and volume="1.1" would need to be handled too. I'd
> > prefer it being ignored rather than being clamped.
> >
> >>> [1]
> >>>
> >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
> >>
> >>
> >>
> >> Ch...
> >
> > --
> > Philip J?genstedt
> > Core Developer
> > Opera Software
>
>
> Or you could just raise the volume of the audio track itself. I think being
> able to raise the volume like this (beyond 100% of what it is) with script
> just makes it something more likely to be abused (think how the TV adverts
> always seem twice as loud as the programs they surround) and so will end up
> getting blocked more often.
>
>
That requires editing the resource. Think about it from a process
point-of-view: you're a Web developer and have been given a set of media
resources to put on a Website. As you put it all together, you notice that
the volume of the different files is different and thus playing them back
next to each other will create a very confusing user experience. Do you
really want to shoot the files back to the production to adjust the volume
settings so they are all similar? If you're under time pressure, you'd
probably much prefer just setting a volume attribute on each so they all
play back with the same level.

Your example of TV ads being louder than the rest of the program is indeed a
production issue but would not replicable through a volume setting for the
resource, since that volume applies to the whole resource and not just to
the ad clip inside it. I don't think that kind of abuse would originate from
JavaScript - it already originates from production and doesn't really apply
to this issue.

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100610/536c1c9f/attachment-0001.htm>

From ash at ashleysheridan.co.uk  Wed Jun  9 19:13:37 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Thu, 10 Jun 2010 03:13:37 +0100
Subject: [whatwg] audio and video: volume and muted as content
 attributes?
In-Reply-To: <AANLkTilEgi30SMkyTypg0qIcOENJ-9EuYph33dAacZAl@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com>
	<op.vdlxapn2atwj1d@philip-pc.oslo.osa>
	<AANLkTikfSnCdoCOdeBeJYqb3_JvO3njI5papjOcUvhh7@mail.gmail.com>
	<op.vdly0w0aatwj1d@philip-pc.oslo.osa>
	<AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com>
	<AANLkTinR5Jo_B0p9KG15MHMxb8QBuzLY8Uc73PIsGX2Q@mail.gmail.com>
	<1276134922.2247.1.camel@localhost>
	<AANLkTilEgi30SMkyTypg0qIcOENJ-9EuYph33dAacZAl@mail.gmail.com>
Message-ID: <1276136017.2247.9.camel@localhost>

On Thu, 2010-06-10 at 12:03 +1000, Silvia Pfeiffer wrote:

> On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> 
>         
>         On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote: 
>         
>         > I don't think that is possible in the way that the volume attribute is
>         > currently defined as a value between [0;1]. That is an orthogonal, but
>         > still important question about the volume attribute then.
>         > 
>         > So, if you say 300%, I assume you mean 3 times louder than what the
>         > track is given as? I do wonder how to do that with the current volume
>         > attribute - right now the spec says that the default value set is 1.0
>         > [1]. It seems that means we cannot amplify a quiet audio track but
>         > have to rely on the user to turn up the volume on their computer? I
>         > would actually prefer if the default setting was something like 0.5
>         > and we could then turn the volume up or down in javascript or
>         > preferably event through a content attribute as mentioned.
>         > 
>         > Cheers,
>         > Silvia.
>         > 
>         > [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume
>         > 
>         > 
>         > On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks <kevinmarks at gmail.com> wrote:
>         > > Setting volume above 1.0 can be very useful if the original is too quiet.
>         > > For example, Quicktime allows a volume of 300% to amplify quiet tracks
>         > >
>         > > On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote:
>         > >
>         > > On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer
>         > > <silviapfeiffer1 at gmail.com> wrote:
>         > >
>         > >> On Tue, Ju...
>         > >
>         > > This would make volume even more special, as a float that reflects as an
>         > > integer percentage. Just using the existing definition for reflecting a
>         > > float would be simpler.
>         > >
>         > >>> So, I am neither in favor or against of reflecting volume and mute as
>         > >>> content attributes. Im...
>         > >
>         > > I'd be fine with reflecting muted if many people think it would be useful.
>         > > I'm not the one to make that judgment though.
>         > >
>         > > Volume isn't a huge problem, just not as trivial as one might suspect.
>         > > Another thing to consider is that it is currently impossible to set volume
>         > > to a value outside the range [0,1] via the DOM API. With a content
>         > > attribute, volume="-1" and volume="1.1" would need to be handled too. I'd
>         > > prefer it being ignored rather than being clamped.
>         > >
>         > >>> [1]
>         > >>>
>         > >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
>         > >>
>         > >>
>         > >>
>         > >> Ch...
>         > >
>         > > --
>         > > Philip J?genstedt
>         > > Core Developer
>         > > Opera Software
>         
>         
>         
>         
>         Or you could just raise the volume of the audio track itself.
>         I think being able to raise the volume like this (beyond 100%
>         of what it is) with script just makes it something more likely
>         to be abused (think how the TV adverts always seem twice as
>         loud as the programs they surround) and so will end up getting
>         blocked more often. 
>         
>         
>         
> 
> 
> 
> That requires editing the resource. Think about it from a process
> point-of-view: you're a Web developer and have been given a set of
> media resources to put on a Website. As you put it all together, you
> notice that the volume of the different files is different and thus
> playing them back next to each other will create a very confusing user
> experience. Do you really want to shoot the files back to the
> production to adjust the volume settings so they are all similar? If
> you're under time pressure, you'd probably much prefer just setting a
> volume attribute on each so they all play back with the same level.
> 
> 
> Your example of TV ads being louder than the rest of the program is
> indeed a production issue but would not replicable through a volume
> setting for the resource, since that volume applies to the whole
> resource and not just to the ad clip inside it. I don't think that
> kind of abuse would originate from JavaScript - it already originates
> from production and doesn't really apply to this issue.
> 
> 
> Cheers,
> Silvia.
> 
> 

If, like you mentioned in your example, all the media files are of
different volumes, then your script would have to somehow detect the
actual real volume of them in order to give the right level of
adjustment for normalisation, something which I don't believe is
possible just at the moment.

If I was in such a situation, yes I would most likely send them back to
the post production team, or at the very least normalise them myself
with ffmpeg or some similar tool.

It would be like sourcing a bunch of images for a website and using
canvas to applying a filter to adjust the light volumes of them all.
Sure, it might be possible, but the images really should have been
adjusted before they were used on the site. Why should we encourage
sloppy content producers?

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From silviapfeiffer1 at gmail.com  Wed Jun  9 19:32:07 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 10 Jun 2010 12:32:07 +1000
Subject: [whatwg] audio and video: volume and muted as content
	attributes?
In-Reply-To: <1276136017.2247.9.camel@localhost>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com> 
	<op.vdlxapn2atwj1d@philip-pc.oslo.osa>
	<AANLkTikfSnCdoCOdeBeJYqb3_JvO3njI5papjOcUvhh7@mail.gmail.com> 
	<op.vdly0w0aatwj1d@philip-pc.oslo.osa>
	<AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com> 
	<AANLkTinR5Jo_B0p9KG15MHMxb8QBuzLY8Uc73PIsGX2Q@mail.gmail.com> 
	<1276134922.2247.1.camel@localhost>
	<AANLkTilEgi30SMkyTypg0qIcOENJ-9EuYph33dAacZAl@mail.gmail.com> 
	<1276136017.2247.9.camel@localhost>
Message-ID: <AANLkTinBygNGLVA4MlQxAtUZqZlCRpddmSg-z3K7kTix@mail.gmail.com>

On Thu, Jun 10, 2010 at 12:13 PM, Ashley Sheridan
<ash at ashleysheridan.co.uk>wrote:

>  On Thu, 2010-06-10 at 12:03 +1000, Silvia Pfeiffer wrote:
>
> On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan <
> ash at ashleysheridan.co.uk> wrote:
>
>
>   On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer wrote:
>
> I don't think that is possible in the way that the volume attribute is
> currently defined as a value between [0;1]. That is an orthogonal, but
> still important question about the volume attribute then.
>
> So, if you say 300%, I assume you mean 3 times louder than what the
> track is given as? I do wonder how to do that with the current volume
> attribute - right now the spec says that the default value set is 1.0
> [1]. It seems that means we cannot amplify a quiet audio track but
> have to rely on the user to turn up the volume on their computer? I
> would actually prefer if the default setting was something like 0.5
> and we could then turn the volume up or down in javascript or
> preferably event through a content attribute as mentioned.
>
> Cheers,
> Silvia.
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume
>
>
> On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks <kevinmarks at gmail.com> wrote:
> > Setting volume above 1.0 can be very useful if the original is too quiet.
> > For example, Quicktime allows a volume of 300% to amplify quiet tracks
> >
> > On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote:
> >
> > On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer
> > <silviapfeiffer1 at gmail.com> wrote:
> >
> >> On Tue, Ju...
> >
> > This would make volume even more special, as a float that reflects as an
> > integer percentage. Just using the existing definition for reflecting a
> > float would be simpler.
> >
> >>> So, I am neither in favor or against of reflecting volume and mute as
> >>> content attributes. Im...
> >
> > I'd be fine with reflecting muted if many people think it would be useful.
> > I'm not the one to make that judgment though.
> >
> > Volume isn't a huge problem, just not as trivial as one might suspect.
> > Another thing to consider is that it is currently impossible to set volume
> > to a value outside the range [0,1] via the DOM API. With a content
> > attribute, volume="-1" and volume="1.1" would need to be handled too. I'd
> > prefer it being ignored rather than being clamped.
> >
> >>> [1]
> >>>
> >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
> >>
> >>
> >>
> >> Ch...
> >
> > --
> > Philip J?genstedt
> > Core Developer
> > Opera Software
>
>
>
>   Or you could just raise the volume of the audio track itself. I think
> being able to raise the volume like this (beyond 100% of what it is) with
> script just makes it something more likely to be abused (think how the TV
> adverts always seem twice as loud as the programs they surround) and so will
> end up getting blocked more often.
>
>
>
>
>  That requires editing the resource. Think about it from a process
> point-of-view: you're a Web developer and have been given a set of media
> resources to put on a Website. As you put it all together, you notice that
> the volume of the different files is different and thus playing them back
> next to each other will create a very confusing user experience. Do you
> really want to shoot the files back to the production to adjust the volume
> settings so they are all similar? If you're under time pressure, you'd
> probably much prefer just setting a volume attribute on each so they all
> play back with the same level.
>
>
>
>  Your example of TV ads being louder than the rest of the program is
> indeed a production issue but would not replicable through a volume setting
> for the resource, since that volume applies to the whole resource and not
> just to the ad clip inside it. I don't think that kind of abuse would
> originate from JavaScript - it already originates from production and
> doesn't really apply to this issue.
>
>
>
>  Cheers,
>
>  Silvia.
>
>
>
>
> If, like you mentioned in your example, all the media files are of
> different volumes, then your script would have to somehow detect the actual
> real volume of them in order to give the right level of adjustment for
> normalisation, something which I don't believe is possible just at the
> moment.
>


It is possible, but not necessary. You can just make some changes yourself -
after all, it's only done once, since the resources won't change.



> If I was in such a situation, yes I would most likely send them back to the
> post production team, or at the very least normalise them myself with ffmpeg
> or some similar tool.
>

Yes, sure you can. But should it be the only possibility?



> It would be like sourcing a bunch of images for a website and using canvas
> to applying a filter to adjust the light volumes of them all. Sure, it might
> be possible, but the images really should have been adjusted before they
> were used on the site. Why should we encourage sloppy content producers?
>

If you get the videos from different producers, how should they be able to
normalise the volume?

Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100610/988b6977/attachment-0001.htm>

From peter at lvp-media.com  Wed Jun  9 23:05:34 2010
From: peter at lvp-media.com (Peter Beverloo)
Date: Thu, 10 Jun 2010 08:05:34 +0200
Subject: [whatwg] Potential Danger with Canvas API in html5 #html5
	#canvas
In-Reply-To: <AANLkTilpcAzgIZlegV4UxQSk_6hEax1r_dxtJn6MPUCN@mail.gmail.com>
References: <AANLkTinZFr8MqIreWhha3Ux47Lf4vjhjGzk5StFe93uW@mail.gmail.com>
	<AANLkTil8MEDaNMWRK-eD3p0ndd9SYOX4fjlR8bYUMqCg@mail.gmail.com>
	<AANLkTilpcAzgIZlegV4UxQSk_6hEax1r_dxtJn6MPUCN@mail.gmail.com>
Message-ID: <AANLkTiks0KtBZizt7RS6118jahBYndfs6e1lMfqjKGj0@mail.gmail.com>

On Wed, Jun 9, 2010 at 22:05, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
>
>
> On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo <peter at lvp-media.com> wrote:
>>
>> On Wed, Jun 9, 2010 at 20:29, narendra sisodiya
>> <narendra at narendrasisodiya.com> wrote:
>> >
>> > Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com
>> >
>> > But we have potential danger to misuse it also for the sake of non-standards.
>> >
>> > <prediction>
>> > Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already? 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API.
>> > A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5.
>> > ????????? So, This I do not like,,,--> ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5"
>> >
>> > We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools.
>> >
>> >
>> > </prediction>
>> >
>> > I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence.
>> >
>> >
>> > .
>> > --
>> > ???????????????????????????
>> > ? ? ?Narendra Sisodiya
>> > ? ? ?http://narendrasisodiya.com
>> > ???????????????????????????
>> > Yet another HTML5 Developer.
>>
>> Hello Narandra,
>>
>> Do you have any links or sources backing up that Adobe is working on
>> the server-side? While your scenario certainly is possible, even with
>> today's possibilities, I see a number of problems with it:
>>
>
> No, i? do not have any info. I am independent developer who enjoy making predictions - http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html
>
>>
>> 1) The number of simultaneous users in any web application will be
>> severely limited by the available processing power of the server.
>> Thinking of the current uses of Flash, a really large part of which
>> are video players and games, it does not seem realistic. Extend this
>> to Flash applications such as FarmVille on Facebook and server-side
>> processing and rendering will be pretty close to impossible.
>>
>
> Yes, you are correct at this points,
>
>
>>
>> 2) How exactly is this different from normal webpages? A lot of
>> websites use scripting languages as their back end, such as PHP,
>> delivering a certain flexibility which is not directly visible to the
>> user. The same thing can be applied to achieve creating personalized
>> Application Cache Manifests.
>>
>
> PHP script generate HTML code along with JavaScript. It make our task easy.
>
> But, Lets imagine
> if we have a very good Tookkit which have everything for webdesign like buttions, menus, dropdown and final code renders everything in CANVAS. ToolKits may use altogether different higher level sytax to generate canvas based applications. further this toolkit has JavaScript unzip library. then you will be able to create a application in zipped format.
> Let me explain this more
>
> Designer/Developer will use drag and drop based Toolkit which has altogether different higher level sytax which generate CANVAS based application.
> Toolkit Or some JavaScript code will generate JavaScript code with all resource like image, htmlcode, source code and everything in application directory.
> Toolkit will zip the whole application and finally designer/developer will get a myfirstgame.wapp
>
> Now developer/designer need to write this much code
>
> <script src="./js/wapp-engine.js"></script>
> <div class='wapp-application' data-src='./myfirstgame.wapp' width='600' height='800' />
>
> This wapp-engine.js will be a wapp player which load myfirstgame.wapp using Ajax and unzip files. Create a dynamic canvas, and render the game in canvas area.
>
> So we are using HTML5 canvas but what are we doing
>
> Fast and GUI based development tools with a non-standards/proprietary ToolKit for generating a .wapp files which can be distributed and developed easily
> .wapp will be played in browser will be JS wapp player which render it inside CANVAS API with hiding images, text and everything under pixels which is the prime requirement of many website
> Desktop based wapp player inorder to play downloded .wapp files.
> Web will become a binary world.
>
> So, it is quite possible to introduce a new non-standard technology under the CANVAS API with Javascript unzip library.
>

It's a very interesting idea, proven by the fact that it partially has
been documented already in the W3C Widgets specification[1]. While the
Widgets currently mostly get used to distribute mobile applications,
which already has been implemented in Presto 2.5 and works on various
phones, it's uses are not limited to the mobile platform alone. The
specification could perfectly be used to create a Widget run-time in
Javascript, albeit in a very limited fashion as creating applications
on <canvas> is a lot harder than using raw HTML in, for example, an
iframe.

Also, keep in mind that the browser, specifically Javascript, needs to
know how to extract such a package (regardless whether it's a ZIP file
or another format) in order to gain access to it's contents. Any
developer who's quite savvy with Javascript will be able to add a few
lines of code that output the image to an <img> tag, instead of
rendering it on a canvas. With the upcoming live-editing Javascript
features in various browsers that won't be much of a problem.

Regards,
Peter Beverloo

[1] http://www.w3.org/TR/widgets/

From ash at ashleysheridan.co.uk  Thu Jun 10 05:45:33 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Thu, 10 Jun 2010 13:45:33 +0100
Subject: [whatwg] audio and video: volume and muted as content
 attributes?
In-Reply-To: <AANLkTinBygNGLVA4MlQxAtUZqZlCRpddmSg-z3K7kTix@mail.gmail.com>
References: <AANLkTilYqFgVi5azYr4ZpXjiqctL7GiCKfHzPeV6G7eu@mail.gmail.com>
	<op.vdlxapn2atwj1d@philip-pc.oslo.osa>
	<AANLkTikfSnCdoCOdeBeJYqb3_JvO3njI5papjOcUvhh7@mail.gmail.com>
	<op.vdly0w0aatwj1d@philip-pc.oslo.osa>
	<AANLkTikzHlw9enrDz2ZOgXF1bX37ac4oxEnVgr8pgzbA@mail.gmail.com>
	<AANLkTinR5Jo_B0p9KG15MHMxb8QBuzLY8Uc73PIsGX2Q@mail.gmail.com>
	<1276134922.2247.1.camel@localhost>
	<AANLkTilEgi30SMkyTypg0qIcOENJ-9EuYph33dAacZAl@mail.gmail.com>
	<1276136017.2247.9.camel@localhost>
	<AANLkTinBygNGLVA4MlQxAtUZqZlCRpddmSg-z3K7kTix@mail.gmail.com>
Message-ID: <1276173933.2247.11.camel@localhost>

On Thu, 2010-06-10 at 12:32 +1000, Silvia Pfeiffer wrote:

> On Thu, Jun 10, 2010 at 12:13 PM, Ashley Sheridan
> <ash at ashleysheridan.co.uk> wrote:
> 
>         
>         On Thu, 2010-06-10 at 12:03 +1000, Silvia Pfeiffer wrote:
>         
>         > On Thu, Jun 10, 2010 at 11:55 AM, Ashley Sheridan
>         > <ash at ashleysheridan.co.uk> wrote:
>         > 
>         >         
>         >         On Thu, 2010-06-10 at 11:52 +1000, Silvia Pfeiffer
>         >         wrote: 
>         >         
>         >         > I don't think that is possible in the way that the volume attribute is
>         >         > currently defined as a value between [0;1]. That is an orthogonal, but
>         >         > still important question about the volume attribute then.
>         >         > 
>         >         > So, if you say 300%, I assume you mean 3 times louder than what the
>         >         > track is given as? I do wonder how to do that with the current volume
>         >         > attribute - right now the spec says that the default value set is 1.0
>         >         > [1]. It seems that means we cannot amplify a quiet audio track but
>         >         > have to rely on the user to turn up the volume on their computer? I
>         >         > would actually prefer if the default setting was something like 0.5
>         >         > and we could then turn the volume up or down in javascript or
>         >         > preferably event through a content attribute as mentioned.
>         >         > 
>         >         > Cheers,
>         >         > Silvia.
>         >         > 
>         >         > [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-volume
>         >         > 
>         >         > 
>         >         > On Thu, Jun 10, 2010 at 10:05 AM, Kevin Marks <kevinmarks at gmail.com> wrote:
>         >         > > Setting volume above 1.0 can be very useful if the original is too quiet.
>         >         > > For example, Quicktime allows a volume of 300% to amplify quiet tracks
>         >         > >
>         >         > > On May 31, 2010 11:30 PM, "Philip J?genstedt" <philipj at opera.com> wrote:
>         >         > >
>         >         > > On Tue, 01 Jun 2010 14:17:03 +0800, Silvia Pfeiffer
>         >         > > <silviapfeiffer1 at gmail.com> wrote:
>         >         > >
>         >         > >> On Tue, Ju...
>         >         > >
>         >         > > This would make volume even more special, as a float that reflects as an
>         >         > > integer percentage. Just using the existing definition for reflecting a
>         >         > > float would be simpler.
>         >         > >
>         >         > >>> So, I am neither in favor or against of reflecting volume and mute as
>         >         > >>> content attributes. Im...
>         >         > >
>         >         > > I'd be fine with reflecting muted if many people think it would be useful.
>         >         > > I'm not the one to make that judgment though.
>         >         > >
>         >         > > Volume isn't a huge problem, just not as trivial as one might suspect.
>         >         > > Another thing to consider is that it is currently impossible to set volume
>         >         > > to a value outside the range [0,1] via the DOM API. With a content
>         >         > > attribute, volume="-1" and volume="1.1" would need to be handled too. I'd
>         >         > > prefer it being ignored rather than being clamped.
>         >         > >
>         >         > >>> [1]
>         >         > >>>
>         >         > >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflect
>         >         > >>
>         >         > >>
>         >         > >>
>         >         > >> Ch...
>         >         > >
>         >         > > --
>         >         > > Philip J?genstedt
>         >         > > Core Developer
>         >         > > Opera Software
>         >         
>         >         
>         >         
>         >         Or you could just raise the volume of the audio
>         >         track itself. I think being able to raise the volume
>         >         like this (beyond 100% of what it is) with script
>         >         just makes it something more likely to be abused
>         >         (think how the TV adverts always seem twice as loud
>         >         as the programs they surround) and so will end up
>         >         getting blocked more often. 
>         >         
>         >         
>         >         
>         >         
>         > 
>         > 
>         > That requires editing the resource. Think about it from a
>         > process point-of-view: you're a Web developer and have been
>         > given a set of media resources to put on a Website. As you
>         > put it all together, you notice that the volume of the
>         > different files is different and thus playing them back next
>         > to each other will create a very confusing user experience.
>         > Do you really want to shoot the files back to the production
>         > to adjust the volume settings so they are all similar? If
>         > you're under time pressure, you'd probably much prefer just
>         > setting a volume attribute on each so they all play back
>         > with the same level.
>         > 
>         > 
>         > Your example of TV ads being louder than the rest of the
>         > program is indeed a production issue but would not
>         > replicable through a volume setting for the resource, since
>         > that volume applies to the whole resource and not just to
>         > the ad clip inside it. I don't think that kind of abuse
>         > would originate from JavaScript - it already originates from
>         > production and doesn't really apply to this issue.
>         > 
>         > 
>         > Cheers,
>         > Silvia.
>         > 
>         > 
>         
>         
>         
>         
>         If, like you mentioned in your example, all the media files
>         are of different volumes, then your script would have to
>         somehow detect the actual real volume of them in order to give
>         the right level of adjustment for normalisation, something
>         which I don't believe is possible just at the moment.
>         
> 
> 
> 
> 
> It is possible, but not necessary. You can just make some changes
> yourself - after all, it's only done once, since the resources won't
> change.
> 
> 
>  
>         If I was in such a situation, yes I would most likely send
>         them back to the post production team, or at the very least
>         normalise them myself with ffmpeg or some similar tool.
>         
> 
> 
> Yes, sure you can. But should it be the only possibility?
> 
> 
>  
>         It would be like sourcing a bunch of images for a website and
>         using canvas to applying a filter to adjust the light volumes
>         of them all. Sure, it might be possible, but the images really
>         should have been adjusted before they were used on the site.
>         Why should we encourage sloppy content producers?
> 
> 
> If you get the videos from different producers, how should they be
> able to normalise the volume?
> 
> 
> Silvia.
> 
> 

There are ways that the different producers can normalise the files,
even if there are many producers. I used to work in a post production
house, so I know this is possible.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From ericsc at gmail.com  Thu Jun 10 08:01:37 2010
From: ericsc at gmail.com (Eric Schurman)
Date: Thu, 10 Jun 2010 08:01:37 -0700
Subject: [whatwg] Prefetch issues
Message-ID: <AANLkTil4CJgOvN6yy76s0RiATBRqFlLzznVpfwXR5IKH@mail.gmail.com>

As described, the link prefetching capability seems to have some
limitations that work counter to the performance of the page using it.

It appears as though LINK elements are metadata elements and that
these may only be supported inside the HEAD of the document. If so,
then this is an issue in the real world, because at the time a web
server flushes chunks containing the HEAD section of a document, the
links we would want to prefetch are often not known. This is true for
all the large sites I've analyzed or worked at. For example, many
pages on a site will contain the same visual header, and we want to
flush the HEAD and visual header content while the server is in the
process of figuring out what the content of the page will be - which
will contain the links we'd like to prefetch.

Am I reading this correctly? Or is there a something that would allow
the flushing scenario I describe above?

One of the simplest approaches may be to add support for
rel="prefetch" to A and AREA's, but it's been explicitly excluded from
those. Why?

Another approach could be to allow LINK throughout the document. This
would allow for prefetching content like images even if you didn't
know them at HEAD rendering time.

Any opinions?

From peter at lvp-media.com  Thu Jun 10 09:46:28 2010
From: peter at lvp-media.com (Peter Beverloo)
Date: Thu, 10 Jun 2010 18:46:28 +0200
Subject: [whatwg] Prefetch issues
In-Reply-To: <AANLkTil4CJgOvN6yy76s0RiATBRqFlLzznVpfwXR5IKH@mail.gmail.com>
References: <AANLkTil4CJgOvN6yy76s0RiATBRqFlLzznVpfwXR5IKH@mail.gmail.com>
Message-ID: <AANLkTinoygzu65shQoGLZcC4-D0GVXrVxCcB7RNQIeP1@mail.gmail.com>

On Thu, Jun 10, 2010 at 17:01, Eric Schurman <ericsc at gmail.com> wrote:
> As described, the link prefetching capability seems to have some
> limitations that work counter to the performance of the page using it.
>
> It appears as though LINK elements are metadata elements and that
> these may only be supported inside the HEAD of the document. If so,
> then this is an issue in the real world, because at the time a web
> server flushes chunks containing the HEAD section of a document, the
> links we would want to prefetch are often not known. This is true for
> all the large sites I've analyzed or worked at. For example, many
> pages on a site will contain the same visual header, and we want to
> flush the HEAD and visual header content while the server is in the
> process of figuring out what the content of the page will be - which
> will contain the links we'd like to prefetch.
>
> Am I reading this correctly? Or is there a something that would allow
> the flushing scenario I describe above?
>
> One of the simplest approaches may be to add support for
> rel="prefetch" to A and AREA's, but it's been explicitly excluded from
> those. Why?
>
> Another approach could be to allow LINK throughout the document. This
> would allow for prefetching content like images even if you didn't
> know them at HEAD rendering time.
>
> Any opinions?
>

While I have not found the original discussion about including the
prefetch relation in area and anchor tags, my guess would be that it's
a feature that would quite easily be abused by web authors. Adding
@rel="prefetch" to all anchors is a lot easier than putting them in
the header, so why not just preload every page on the site? Again,
someone else will probably have the answer you're looking for.

Mozilla's Developer Center has a page about the attribute value[1]
which already suggests that they might add the feature on normal
anchor tags if there is sufficient interest in that. Their page also
contains a chapter about how to implement prefetching using the Link
HTTP header, which would be a solution if your website uses output
buffering.

Considering you're specifically talking about flushing the header
before the links are known, however, I'm assuming that won't be a
possibility either. The link tag is specifically used for metadata
about the current document, so using that across the entire document
doesn't sound like a good idea to me. Despite the possibility of abuse
by authors, it seems to me that it's a fair use-case for including the
attribute.

Regards,
Peter Beverloo

[1] https://developer.mozilla.org/En/Link_prefetching_FAQ

From ericsc at gmail.com  Thu Jun 10 09:50:56 2010
From: ericsc at gmail.com (Eric Schurman)
Date: Thu, 10 Jun 2010 09:50:56 -0700
Subject: [whatwg] Prefetch issues
In-Reply-To: <AANLkTinoygzu65shQoGLZcC4-D0GVXrVxCcB7RNQIeP1@mail.gmail.com>
References: <AANLkTil4CJgOvN6yy76s0RiATBRqFlLzznVpfwXR5IKH@mail.gmail.com>
	<AANLkTinoygzu65shQoGLZcC4-D0GVXrVxCcB7RNQIeP1@mail.gmail.com>
Message-ID: <AANLkTinXjqK-W2H5qb3jWrl84oiQX5d_WpsK8U3MsUqZ@mail.gmail.com>

Like you do say, the link header doesn't work for exactly the same
reason - we'd have already flushed.
It does seem like adding rel=prefetch to A and AREA may be the best solution.


On Thu, Jun 10, 2010 at 9:46 AM, Peter Beverloo <peter at lvp-media.com> wrote:
> On Thu, Jun 10, 2010 at 17:01, Eric Schurman <ericsc at gmail.com> wrote:
>> As described, the link prefetching capability seems to have some
>> limitations that work counter to the performance of the page using it.
>>
>> It appears as though LINK elements are metadata elements and that
>> these may only be supported inside the HEAD of the document. If so,
>> then this is an issue in the real world, because at the time a web
>> server flushes chunks containing the HEAD section of a document, the
>> links we would want to prefetch are often not known. This is true for
>> all the large sites I've analyzed or worked at. For example, many
>> pages on a site will contain the same visual header, and we want to
>> flush the HEAD and visual header content while the server is in the
>> process of figuring out what the content of the page will be - which
>> will contain the links we'd like to prefetch.
>>
>> Am I reading this correctly? Or is there a something that would allow
>> the flushing scenario I describe above?
>>
>> One of the simplest approaches may be to add support for
>> rel="prefetch" to A and AREA's, but it's been explicitly excluded from
>> those. Why?
>>
>> Another approach could be to allow LINK throughout the document. This
>> would allow for prefetching content like images even if you didn't
>> know them at HEAD rendering time.
>>
>> Any opinions?
>>
>
> While I have not found the original discussion about including the
> prefetch relation in area and anchor tags, my guess would be that it's
> a feature that would quite easily be abused by web authors. Adding
> @rel="prefetch" to all anchors is a lot easier than putting them in
> the header, so why not just preload every page on the site? Again,
> someone else will probably have the answer you're looking for.
>
> Mozilla's Developer Center has a page about the attribute value[1]
> which already suggests that they might add the feature on normal
> anchor tags if there is sufficient interest in that. Their page also
> contains a chapter about how to implement prefetching using the Link
> HTTP header, which would be a solution if your website uses output
> buffering.
>
> Considering you're specifically talking about flushing the header
> before the links are known, however, I'm assuming that won't be a
> possibility either. The link tag is specifically used for metadata
> about the current document, so using that across the entire document
> doesn't sound like a good idea to me. Despite the possibility of abuse
> by authors, it seems to me that it's a fair use-case for including the
> attribute.
>
> Regards,
> Peter Beverloo
>
> [1] https://developer.mozilla.org/En/Link_prefetching_FAQ
>

From emoller at opera.com  Thu Jun 10 12:35:39 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Thu, 10 Jun 2010 21:35:39 +0200
Subject: [whatwg] [hybi]  WebSockets: UDP
In-Reply-To: <op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <op.vd3ndpzqr4mipi@emoller-pc.gothenburg.osa>

During the Opera Network Seminar held in Oslo this week I discussed the  
possible addition of a new wsd: URL scheme to WebSockets that would allow  
relaxing the packet resends and enable demanding real-time applications to  
be written. I'd like to summarize some of the conclusions a few of us came  
to when discussing this (informally).

Regarding the discussions on at what level the API of a UDP-WebSocket  
should be: One of the most important aspects to remember are that for this  
to be interesting to application developers we need all the browser  
vendors to support this feature in a compatible way. Therefore it doesn't  
seem reasonable to standardize and spec a higher level network API akin to  
RakNet / Torque Socket and hope all vendors will be willing to spend the  
(quite large amount of) resources required for their own implementation of  
TCP over UDP, bandwidth throttling etc. In our opinion we're much better  
off standardizing a minimal UDP-like socket. For most application  
developers it seems likely they will be able to work with a mix of  
XMLHttpRequest, WebSockets and this new UDP-WebSocket to achieve the same  
functionality provided by those higher level APIs. If deemed necessary for  
an application the higher level network API can be written in JavaScript  
and work on-top of the much smaller hopefully cross-browser compatible  
UDP-WebSocket API.

As discussed the following features/limitations are suggested:
-Same API as WebSockets with the possible addition of an attribute that  
allows the application developer to find the path MTU of a connected  
socket.
-Max allowed send size is 65,507 bytes.
-Socket is bound to one remote address at creation and stays connected to  
that host for the duration of its lifetime.
-IP Broadcast/Multicast addresses are not valid remote addresses and only  
a set range of ports are valid.
-Reliable handshake with origin info (Connection timeout will trigger  
close event.)
-Automatic keep-alives (to detect force close at remote host and keep NAT  
traversal active)
-Reliable close handshake
-Sockets open sequentially (like current DOS protection in WebSockets) or  
perhaps have a limit of one socket per remote host.
-Cap on number of open sockets per host and global user-agent limit.

Some additional points that were suggested on this list were:
-Key exchange and encryption
  If you do want to have key exchange and encryption you really shouldn't  
reinvent the wheel but rather use a secure WebSocket connection in  
addition to the UDP-WebSocket. Adding key exchange and encryption to the  
UDP-WebSocket is discouraged.

-Client puzzles to reduce connection depletion/CPU depletion attacks to  
the handshake.
  If the goal is to prevent DOS attacks on the accepting server this seems  
futile. Client puzzles only raises the bar ever so slightly for an  
attacker so this is also discouraged.

-Packet delivery notification to be a part of the API.
  Again this is believed to be better left outside the UDP-WebSockets spec  
and implemented in javascript if the application developer requires it.

Best Regards,

-- 
Erik M?ller
Core Developer
Opera Software

From chuck at jumis.com  Thu Jun 10 14:14:05 2010
From: chuck at jumis.com (Charles Pritchard)
Date: Thu, 10 Jun 2010 14:14:05 -0700
Subject: [whatwg] Revisiting MIDI - <device> and <audio>
Message-ID: <4C11559D.1000804@jumis.com>

Hello All,

Thought I'd review the topic of supporting MIDI devices in HTML 5.

My initial post about MIDI treated the format as a text stream:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026524.html


Let's start looking at the <device> tag.
a MIDI device, is, quite surely, a <device>.

http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices

I'd warn, that while MIDI is typically thought of as a media device,
it's actually just a plain old Event Source.

It seems that Stream is appropriate (enough), to enable MIDI support in 
the browser.
It's a light event source.

It also seems that the peer-2-peer section allows for multiple device 
streams;
whereas the simple device section allows only one media device (a webcam).

MIDI does require the ability to handle multiple event sources, for 
live-use.



-Charles

From mark.frohnmayer at gmail.com  Thu Jun 10 15:21:38 2010
From: mark.frohnmayer at gmail.com (Mark Frohnmayer)
Date: Thu, 10 Jun 2010 15:21:38 -0700
Subject: [whatwg] [hybi] WebSockets: UDP
In-Reply-To: <op.vd3ndpzqr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> 
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> 
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com> 
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
	<op.vd3ndpzqr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTilrDDGU10AZQ3KZ2lkuwmEt-RKRJUIls38ajtb6@mail.gmail.com>

On Thu, Jun 10, 2010 at 12:35 PM, Erik M?ller <emoller at opera.com> wrote:
> Regarding the discussions on at what level the API of a UDP-WebSocket should
> be: One of the most important aspects to remember are that for this to be
> interesting to application developers we need all the browser vendors to
> support this feature in a compatible way. Therefore it doesn't seem
> reasonable to standardize and spec a higher level network API akin to RakNet
> / Torque Socket and hope all vendors will be willing to spend the (quite
> large amount of) resources required for their own implementation of TCP over
> UDP, bandwidth throttling etc. In our opinion we're much better off
> standardizing a minimal UDP-like socket. For most application developers it

TorqueSocket is not in the same category as RakNet or OpenTNL -- the
point of the TorqueSocket effort was to find the web equivalent of a
minimal UDP'ish socket (understanding of course that it would be in
the context of a connected packet stream).  RakNet and OpenTNL provide
higher level data guarantees, RPC, object state replication, etc.
TorqueSocket is a simple send/recv packet protocol - it does no TCP
over UDP or bandwidth throttling.

>
> As discussed the following features/limitations are suggested:
> -Same API as WebSockets with the possible addition of an attribute that
> allows the application developer to find the path MTU of a connected socket.
> -Max allowed send size is 65,507 bytes.

I'd recommend doing some real-world testing for max packet size.  Back
when the original QuakeWorld came out it started by sending a large
connect packet (could be ~8K) and a good number of routers would just
drop those packets unconditionally.  The solution (iirc) was to keep
all packet sends below the Ethernet max of 1500 bytes.  I haven't
verified this lately to see if that's still the case, but it seems
real-world functionality should be considered.

> Some additional points that were suggested on this list were:
> -Key exchange and encryption
> ?If you do want to have key exchange and encryption you really shouldn't
> reinvent the wheel but rather use a secure WebSocket connection in addition
> to the UDP-WebSocket. Adding key exchange and encryption to the
> UDP-WebSocket is discouraged.

If WebSocket supports an encrypted and unencrypted mode, why would the
real-time version not support data security and integrity?

>
> -Client puzzles to reduce connection depletion/CPU depletion attacks to the
> handshake.
> ?If the goal is to prevent DOS attacks on the accepting server this seems
> futile. Client puzzles only raises the bar ever so slightly for an attacker
> so this is also discouraged.

Client puzzles allow the host to allocate zero resources for a pending
connection until it knows that the source address of the client
request is valid and that the client has done some work; you could
still take a similar (though not client computationally expensive)
approach by having the host hash the client identity (IP/port) with a
server-generated secret.  Any approach that allocates memory or does
work on the host without verifying the client source address first is
vulnerable to a super-trivial DOS attack (connection depletion before
even any bandwidth overwhelm).

>
> -Packet delivery notification to be a part of the API.
> ?Again this is believed to be better left outside the UDP-WebSockets spec
> and implemented in javascript if the application developer requires it.

I'd propose that doing this in the javascript level would result in
unnecessary extra overhead (sequence numbering, acknowledgements) that
could easily be a part of the underlying protocol.  Having implemented
multiple iterations of a high-level networking API, the notification
function is a critical, low-overhead tool for making effective
higher-level data guarantees possible.

Regards,
Mark

From Olli.Pettay at helsinki.fi  Thu Jun 10 15:51:15 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Fri, 11 Jun 2010 01:51:15 +0300
Subject: [whatwg] IDL attribute reflecting enumerated attributes not
 limited to only know values
In-Reply-To: <4C0E5309.6070506@gmail.com>
References: <4C0E5309.6070506@gmail.com>
Message-ID: <4C116C63.9070700@helsinki.fi>

On 6/8/10 5:26 PM, Mounir Lamouri wrote:
> Hi,
>
> According to the HTML5 specification, an IDL attribute reflecting an
> enumerated attribute will have the default reflecting behavior (ie.
> return the content attribute on getting and setting it on setting)
> except if the attribute is "limited to only known values" [1]. There are
> three attributes limited to only known values in the current state of
> the specs: @dir, @shape (area element) and @keytype (keygen element).
>
> In other words, that means if @toto is an enumerated attribute with
> "foo" and "bar" states/keywords and "foo" as a default missing value, if
> @toto is set to "foobar", .toto will return "foobar". To have .toto
> returning "foo", the attribute has to be limited to only known value.
> Having .toto returning "foo" in this situation seems to be what we
> should expect because the content attribute is already accessible with
> @toto.
>
> An example where this behavior seems buggy:
> - input.type and button.type: every browser makes it return "text" if
> @type isn't set to a known value. If we follow the specifications, .type
> should return the current value of @type.
>
> Examples where having another behavior would help:
> - method, formmethod, enctype and formenctype have a list of
> keywords/states with a default missing value. It would be great to have
> the IDL attribute returning the current state instead of the content.
> So, scripts wouldn't have to look at the content, checking for values
> they know and falling-back to the default value to know the current state.
> - input.autocomplete: at the moment, it is returning the content but it
> could return the resulting autocompletion state which is maybe a bit
> more than just being limited to only known values but still in the same
> spirit.
>
> Maybe, instead of having some attributes "limited to only known values"
> we could have some attributes "not limited to only known values", thus
> inverting the default reflecting behavior for enumerated attriutes ?

Yeah, this sound ok to me. The current enumerate attribute handling
is weird and at least in some cases just buggy.


-Olli

>
> [1] http://dev.w3.org/html5/spec/Overview.html#limited-to-only-known-values
>
> Thanks,
> --
> Mounir
>


From emoller at opera.com  Fri Jun 11 03:18:24 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Fri, 11 Jun 2010 12:18:24 +0200
Subject: [whatwg] [hybi] WebSockets: UDP
In-Reply-To: <AANLkTilrDDGU10AZQ3KZ2lkuwmEt-RKRJUIls38ajtb6@mail.gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
	<op.vd3ndpzqr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTilrDDGU10AZQ3KZ2lkuwmEt-RKRJUIls38ajtb6@mail.gmail.com>
Message-ID: <op.vd4r8yvlr4mipi@emoller-pc.gothenburg.osa>

On Fri, 11 Jun 2010 00:21:38 +0200, Mark Frohnmayer  
<mark.frohnmayer at gmail.com> wrote:

> TorqueSocket is not in the same category as RakNet or OpenTNL

Ah, sorry I got the names mixed up, I meant to say RakNet/OpenTNL and not  
RakNet/TorqueSocket.

> I'd recommend doing some real-world testing for max packet size.  Back
> when the original QuakeWorld came out it started by sending a large
> connect packet (could be ~8K) and a good number of routers would just
> drop those packets unconditionally.  The solution (iirc) was to keep
> all packet sends below the Ethernet max of 1500 bytes.  I haven't
> verified this lately to see if that's still the case, but it seems
> real-world functionality should be considered.

Absolutely, that's why the path-MTU attribute was suggested. The ~64k  
limit is an absolute limit though at which sends can be rejected  
immediately without even trying.

> If WebSocket supports an encrypted and unencrypted mode, why would the
> real-time version not support data security and integrity?

The reasoning was that if you do need data security and integrity the  
secure websocket over TCP uses the same state-of-the-art implementation as  
the browsers already have implemented. Secure connections over UDP would  
either require a full TCP over UDP implementation (to use TLS) or a second  
implementation that would need to be maintained. That implementation would  
be either a very complex piece or software or clearly inferior to that  
users are accustomed to.
So what's a good use-case where you want a secure connection over UDP and  
cannot use a second TLS connection?

> Client puzzles allow the host to allocate zero resources for a pending
> connection until it knows that the source address of the client
> request is valid and that the client has done some work; you could
> still take a similar (though not client computationally expensive)
> approach by having the host hash the client identity (IP/port) with a
> server-generated secret.  Any approach that allocates memory or does
> work on the host without verifying the client source address first is
> vulnerable to a super-trivial DOS attack (connection depletion before
> even any bandwidth overwhelm).

Right, this is probably an area that needs to be looked more carefully at  
if/when real work is started on a spec.

> I'd propose that doing this in the javascript level would result in
> unnecessary extra overhead (sequence numbering, acknowledgements) that
> could easily be a part of the underlying protocol.  Having implemented
> multiple iterations of a high-level networking API, the notification
> function is a critical, low-overhead tool for making effective
> higher-level data guarantees possible.

Yes, no doubt it's useful for those implementing higher level APIs. As  
usual it's a matter of at what level to place the API.

-- 
Erik M?ller
Core Developer
Opera Software

From emoller at opera.com  Fri Jun 11 03:25:12 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Fri, 11 Jun 2010 12:25:12 +0200
Subject: [whatwg] [hybi]  WebSockets: UDP
In-Reply-To: <FA20049A-5B22-46F6-B6F4-78E31B742C61@nokia.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com>
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com>
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com>
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
	<op.vd3ndpzqr4mipi@emoller-pc.gothenburg.osa>
	<FA20049A-5B22-46F6-B6F4-78E31B742C61@nokia.com>
Message-ID: <op.vd4skahdr4mipi@emoller-pc.gothenburg.osa>

On Fri, 11 Jun 2010 06:25:41 +0200, Lars Eggert <lars.eggert at nokia.com>  
wrote:

> Hi,
>
> on a purely managerial level, let me point out that this work is far  
> beyond the current charter of the HYBI WG. This defines an entirely new  
> protocol, and will definitely require a charter discussion.
>
> (If there is community/developer interest, we should by all means have  
> that discussion.)
>
> Lars
>

Sure, this just felt like the appropriate venue for these initial  
discussions. If not please say so and we'll move it somewhere else.

 From my personal experience when discussing this with developers and  
people from adjacent industries there's significant interest in the _final  
product_ but not so much interest in getting directly involved in the  
process.

-- 
Erik M?ller
Core Developer
Opera Software

From julian.reschke at gmx.de  Fri Jun 11 06:55:25 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 11 Jun 2010 15:55:25 +0200
Subject: [whatwg] ISSUE-86,
 Re: hixie: Remove the HTML-to-Atom mapping definition from the W3C
 version of the spec. (whatwg r5100)
In-Reply-To: <4C09FC18.9070605@gmx.de>
References: <20100602042010.512582BCC3@toro.w3.mag.keio.ac.jp>	<4C05EAC0.3020506@gmx.de>
	<4C09FC18.9070605@gmx.de>
Message-ID: <4C12404D.3000204@gmx.de>

On 05.06.2010 09:26, Julian Reschke wrote:
> On 02.06.2010 07:23, Julian Reschke wrote:
>> Hi Ian,
>>
>> thanks for the removal.
>>
>> I notice that you kept the text in the WHATWG version of the spec.
>>
>> Various problems have been reported with respect to the mapping, notably
>>
>> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7806>
>>
>> and
>>
>> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9546>
>> ...
>
> For completeness, here's a related feature request:
>
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=7545>
>
> Best regards, Julian

And a blog:

<http://www.xn--8ws00zhy3a.com/blog/2010/06/html5-atom-gone-wrong>

Best regards, Julian


From mark.frohnmayer at gmail.com  Fri Jun 11 08:52:45 2010
From: mark.frohnmayer at gmail.com (Mark Frohnmayer)
Date: Fri, 11 Jun 2010 08:52:45 -0700
Subject: [whatwg] [hybi] WebSockets: UDP
In-Reply-To: <op.vd4r8yvlr4mipi@emoller-pc.gothenburg.osa>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> 
	<op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa>
	<AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> 
	<op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa>
	<AANLkTimPvtS9hE-frSVQq8dWBEG9-fvCfnTsOVCbVXQt@mail.gmail.com> 
	<op.vdpn931pr4mipi@emoller-pc.gothenburg.osa>
	<op.vd3ndpzqr4mipi@emoller-pc.gothenburg.osa> 
	<AANLkTilrDDGU10AZQ3KZ2lkuwmEt-RKRJUIls38ajtb6@mail.gmail.com> 
	<op.vd4r8yvlr4mipi@emoller-pc.gothenburg.osa>
Message-ID: <AANLkTim3-lHhZp1Ek_cQSNTfB-UDwDDFL1RnLhRplMEe@mail.gmail.com>

On Fri, Jun 11, 2010 at 3:18 AM, Erik M?ller <emoller at opera.com> wrote:
> Absolutely, that's why the path-MTU attribute was suggested. The ~64k limit
> is an absolute limit though at which sends can be rejected immediately
> without even trying.

Ah, gotcha.  I was trying to separate the cases of MTU before
fragmentation and maximum packet size (fragmented) before some host
along the way silently discards the packet.

> The reasoning was that if you do need data security and integrity the secure
> websocket over TCP uses the same state-of-the-art implementation as the
> browsers already have implemented. Secure connections over UDP would either
> require a full TCP over UDP implementation (to use TLS) or a second
> implementation that would need to be maintained. That implementation would
> be either a very complex piece or software or clearly inferior to that users
> are accustomed to.
> So what's a good use-case where you want a secure connection over UDP and
> cannot use a second TLS connection?

I guess I was thinking more in the direction of a well conceived, well
reviewed protocol (TLS-level of scrutiny) for encryption of the
unreliable packet stream - a secure data stream is a useful primitive
and would otherwise have to be implemented at the application level.
I'd rather have security done well at the platform level (what
developers expect from a modern browser).  I'm not sure I'd agree that
it has to be super complex in order to be effective, and could likely
use much of the same functionality (ciphers, etc).

I'm also not assuming a second message channel -- if a developer is
using an API like TNL or RakNet that handles higher level data and
message guarantees then the addition of multiple message streams is
unneeded complexity.

>
> Yes, no doubt it's useful for those implementing higher level APIs. As usual
> it's a matter of at what level to place the API.

Agreed.  This goes back to Phil's point that UDP by itself isn't a
great primitive to build on -- the key element for real-time
applications is that dropped packets shouldn't stall the communication
stream nor be automatically retransmitted.  A slightly higher level
approach (connection handshake, security, etc), as long as its
overhead is low, could be a more effective foundation to build on.

Cheers,
Mark

From jackalmage at gmail.com  Fri Jun 11 16:48:40 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 11 Jun 2010 16:48:40 -0700
Subject: [whatwg] Problems with the Atom Conversion algorithm.
Message-ID: <AANLkTilNchQJNfF1c5jWaeE7aeUyU1G60p4xlu0ebuTi@mail.gmail.com>

On http://www.???.com/blog/2010/06/html5-atom-gone-wrong, a comparison
is made between an example Atom feed (presumably constructed from blog
metadata) and one constructed by the HTML algorithm reading over the
example blog page.  Not all of these differences are valid, but some
are, and should be fixed in the HTML algo.

1. The HTML algo puts the url for atom:link elements in the content of
the <link>.  It should be in the @href of the <link>. (Issue 1 in the
blog post)

2. The <title> of atom entries is constrained to contain text only,
but this "text" can include properly-escaped markup in practice.  The
HTML algo strips that markup out and just uses the textContent of the
appropriate heading.  Some practices, such as using a "sarcastic
<del>" in a heading, are adversely impacted by this - the meaning of
"I &lt;del>don't&lt;/del> like HTML" and "I don't like HTML" are
completely opposite.  The HTML algo should use the escaped innerHTML
of the appropriate heading instead. (Issue 3 in the blog post)

3. The HTML algo sets the @type attribute on atom:content to "xml" in
some circumstances.  It should be "xhtml". (Issue 4 in the blog post)

4. The HTML algo should include an <xml:base> element in the produced
feed so that relative links work correctly.  Alternately, it should
make all links absolute.  (Issue 8 in the blog post)

5. I'm not 100% certain on this one, but I think that, in the current
step 15.8 of the HTML algo, it should produce a <div> element in the
XHTML namespace.  The algo currently doesn't specify a namespace for
the element. (Issue 5 in the blog post)

Issues 2, 6, and 7 in the blog post appear to be a result of the post
author either reading the spec incorrectly or writing a bad page to
begin with.  There are potential problems around Issue 2, but this
blog post did not run into them.

Issue 9 in the blog post is true, but can't be simply fixed.  In most
circumstances this won't matter - most blogs are written by a single
author.

The issues listed in the blog post:
1. The URLs for <link> elements should be stored in the @href
attribute and not in the link content.
2. The values used for <id> should be both stable and unique. Using a
copy of the permalink meets neither requirement.
3. Stripping the markup from <title> elements has resulted in one
title changing its meaning entirely.
4. The @type attribute on <content> elements should be "xhtml" for
XHTML content, and not "xml".
5. The XHTML <div> element that is an immediate child of <content> is
not correctly namespaced.
6. The dates in the <published> elements are incorrectly formatted and
in the wrong timezone.
7. The <updated> elements are merely duplicates of the <published>
elements, failing to detect the correct update times.
8. Without an @base attribute, relative URLs inside the <content>
elements will not be correctly resolved.
9. The <author> elements are missing altogether since the algorithm is
only capable of recognising feed-level authors, at best.

~TJ

From hober0 at gmail.com  Fri Jun 11 17:00:56 2010
From: hober0 at gmail.com (Edward O'Connor)
Date: Fri, 11 Jun 2010 17:00:56 -0700
Subject: [whatwg] Problems with the Atom Conversion algorithm.
In-Reply-To: <AANLkTilNchQJNfF1c5jWaeE7aeUyU1G60p4xlu0ebuTi@mail.gmail.com>
References: <AANLkTilNchQJNfF1c5jWaeE7aeUyU1G60p4xlu0ebuTi@mail.gmail.com>
Message-ID: <AANLkTincylFy_UR1e6jxXOk3TlAqpZDKOSAblFtKtOq8@mail.gmail.com>

> 2. The <title> of atom entries is constrained to contain text only,

That's not quite right. <atom:title> is an Atom Text Construct, which,
despite having the word 'text' in its name, can contain all sorts of
things. <atom:title> is the same as <atom:summary>, <atom:content>,
and <atom:rights>, so the algo should handle it in the same way as it
does <atom:content>.

From jackalmage at gmail.com  Fri Jun 11 17:39:45 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 11 Jun 2010 17:39:45 -0700
Subject: [whatwg] Problems with the Atom Conversion algorithm.
In-Reply-To: <AANLkTincylFy_UR1e6jxXOk3TlAqpZDKOSAblFtKtOq8@mail.gmail.com>
References: <AANLkTilNchQJNfF1c5jWaeE7aeUyU1G60p4xlu0ebuTi@mail.gmail.com> 
	<AANLkTincylFy_UR1e6jxXOk3TlAqpZDKOSAblFtKtOq8@mail.gmail.com>
Message-ID: <AANLkTilZSwEoDg4DTzz40NhHulGMDbYW-DqJfdZuHDrl@mail.gmail.com>

On Fri, Jun 11, 2010 at 5:00 PM, Edward O'Connor <hober0 at gmail.com> wrote:
>> 2. The <title> of atom entries is constrained to contain text only,
>
> That's not quite right. <atom:title> is an Atom Text Construct, which,
> despite having the word 'text' in its name, can contain all sorts of
> things. <atom:title> is the same as <atom:summary>, <atom:content>,
> and <atom:rights>, so the algo should handle it in the same way as it
> does <atom:content>.

Ah, you are correct.  I was misled by the blog post author's "correct"
feed which escaped the <del> elements.  In reality the <title> should
have a @type and then contain html content.

~TJ

From svartman95 at gmail.com  Sat Jun 12 11:14:57 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sat, 12 Jun 2010 18:14:57 +0000
Subject: [whatwg] Do we really need a <device> element?
Message-ID: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>

What is the use case for <device>?
I?ve searched the archives, read a thread, Googled around and read a
document on the subject, but still I haven?t found a use case for it
other than it is going to magically increase user privacy.

<input type=file accept="audio/*"> is a standard and compatible way to
request audio stream(s). I can?t see any drawbacks to using <input>
for audiovisual streams at least.

--
kv,
  - Bjartur

From jsalsman at gmail.com  Sat Jun 12 14:47:10 2010
From: jsalsman at gmail.com (James Salsman)
Date: Sat, 12 Jun 2010 14:47:10 -0700
Subject: [whatwg] Do we really need a <device> element?
In-Reply-To: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
References: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
Message-ID: <AANLkTimN8P1oKnVe1S60lYofYXaY2p5boClpiATQkhe-@mail.gmail.com>

Bjartur, real-time streaming audio uploads enable pronunciation assessment
for language instruction during multiplayer online roleplaying games such as
those by http://www.8dworld.com

input type=file accept="audio/x-speex;quality=(0-10);bitrate=..." is more
important, and accept="audio/ogg video/x-webm, video/ogg" are all fairly
important, too.

On Jun 12, 2010 11:15 AM, "Bjartur Thorlacius" <svartman95 at gmail.com> wrote:

What is the use case for <device>?
I?ve searched the archives, read a thread, Googled around and read a
document on the subject, but still I haven?t found a use case for it
other than it is going to magically increase user privacy.

<input type=file accept="audio/*"> is a standard and compatible way to
request audio stream(s). I can?t see any drawbacks to using <input>
for audiovisual streams at least.

--
kv,
  - Bjartur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100612/ee49375e/attachment.htm>

From narendra at narendrasisodiya.com  Sat Jun 12 14:50:23 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Sun, 13 Jun 2010 03:20:23 +0530
Subject: [whatwg] Do we really need a <device> element?
In-Reply-To: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
References: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
Message-ID: <AANLkTikiVH3BG4R-vQTkquvqa-II8KP8Yo0kwKBFRBUx@mail.gmail.com>

On Sat, Jun 12, 2010 at 11:44 PM, Bjartur Thorlacius
<svartman95 at gmail.com>wrote:

> What is the use case for <device>?
> I?ve searched the archives, read a thread, Googled around and read a
> document on the subject, but still I haven?t found a use case for it
> other than it is going to magically increase user privacy.
>
> <input type=file accept="audio/*"> is a standard and compatible way to
> request audio stream(s). I can?t see any drawbacks to using <input>
> for audiovisual streams at least.
>
>
I would love to see this implementations, This will be helpfull in
webbased  "Screencastings" Or "SlideCastings" Or "audio/video telephony"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100613/796884c3/attachment.htm>

From brettz9 at yahoo.com  Sat Jun 12 22:57:53 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Sun, 13 Jun 2010 13:57:53 +0800
Subject: [whatwg] Syntax highlighting language attribute for editable
	elements
Message-ID: <4C147361.2050602@yahoo.com>

Has thought been given to allow textarea, input and/or contenteditable 
elements to use an attribute (maybe like <code/> does with 
class=language-XX) so that user agents might be able to display the 
editable text with syntax highlighting code automatically?

This should not adversely affect users who do not have such browser 
support, nor does it put pressure on browsers to implement immediately 
(add-ons might take care of such a role). But having a convention in 
place (even if languages are not predefined) would ensure that the 
burden of implementing such support could be shifted away from the 
developer if they are not so inclined.

I'd prefer to see a dedicated attribute (also on <code/>) since the 
language type does convey general interest semantic information, but I 
think it would also ideally be consistent (i.e., the same attribute to 
be used in <code/> as in <textarea/>, etc.).

Maybe @lang/@xml:lang could be used for this purpose if its definition 
could someone be widened to recognize computer languages.

It would be nice, however, to also have some means of indicating that 
the web author is providing their own styling of the element in the 
event they wish to use their own editor.

thank you,
Brett Zamir

From ash at ashleysheridan.co.uk  Sun Jun 13 04:12:13 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Sun, 13 Jun 2010 12:12:13 +0100
Subject: [whatwg] Syntax highlighting language attribute for editable
 elements
In-Reply-To: <4C147361.2050602@yahoo.com>
References: <4C147361.2050602@yahoo.com>
Message-ID: <1276427533.3935.20.camel@localhost>

On Sun, 2010-06-13 at 13:57 +0800, Brett Zamir wrote:

> Has thought been given to allow textarea, input and/or contenteditable 
> elements to use an attribute (maybe like <code/> does with 
> class=language-XX) so that user agents might be able to display the 
> editable text with syntax highlighting code automatically?
> 
> This should not adversely affect users who do not have such browser 
> support, nor does it put pressure on browsers to implement immediately 
> (add-ons might take care of such a role). But having a convention in 
> place (even if languages are not predefined) would ensure that the 
> burden of implementing such support could be shifted away from the 
> developer if they are not so inclined.
> 
> I'd prefer to see a dedicated attribute (also on <code/>) since the 
> language type does convey general interest semantic information, but I 
> think it would also ideally be consistent (i.e., the same attribute to 
> be used in <code/> as in <textarea/>, etc.).
> 
> Maybe @lang/@xml:lang could be used for this purpose if its definition 
> could someone be widened to recognize computer languages.
> 
> It would be nice, however, to also have some means of indicating that 
> the web author is providing their own styling of the element in the 
> event they wish to use their own editor.
> 
> thank you,
> Brett Zamir


I think maybe not a class, as the class attribute already has a purpose
and is probably already used in a <code class="php"> type of capacity
already by some sites showing code excerpts. I'd suggest maybe extending
the lang attribute, but it's also conceivable that a code snippet might
be in Perl and written with French comments, and the lang attribute
wasn't meant for multiple values like the class attribute is. Perhaps
the best solution is to use another new attribute altogether?

It is a good idea though, I think, as it does add a lot of semantic
meaning to the content.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From svartman95 at gmail.com  Sun Jun 13 07:00:30 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 13 Jun 2010 14:00:30 +0000
Subject: [whatwg] Do we really need a <device> element?
In-Reply-To: <AANLkTimN8P1oKnVe1S60lYofYXaY2p5boClpiATQkhe-@mail.gmail.com>
References: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
	<AANLkTimN8P1oKnVe1S60lYofYXaY2p5boClpiATQkhe-@mail.gmail.com>
Message-ID: <AANLkTikaWgMwp4sUX8_vGU3UzD5gNFVZninCwdw8TPZl@mail.gmail.com>

On 6/12/10, James Salsman <jsalsman at gmail.com> wrote:
> Bjartur, real-time streaming audio uploads enable pronunciation assessment
> for language instruction during multiplayer online roleplaying games such as
> those by http://www.8dworld.com
>
> input type=file accept="audio/x-speex;quality=(0-10);bitrate=..." is more
> important, and accept="audio/ogg video/x-webm, video/ogg" are all fairly
> important, too.
>
> On Jun 12, 2010 11:15 AM, "Bjartur Thorlacius" <svartman95 at gmail.com> wrote:
>
> What is the use case for <device>?
> I?ve searched the archives, read a thread, Googled around and read a
> document on the subject, but still I haven?t found a use case for it
> other than it is going to magically increase user privacy.
>
> <input type=file accept="audio/*"> is a standard and compatible way to
> request audio stream(s). I can?t see any drawbacks to using <input>
> for audiovisual streams at least.
>
> --
> kv,
>   - Bjartur
>


-- 
kv,
  - Bjartur

From svartman95 at gmail.com  Sun Jun 13 07:33:30 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 13 Jun 2010 14:33:30 +0000
Subject: [whatwg] Do we really need a <device> element?
In-Reply-To: <AANLkTikaWgMwp4sUX8_vGU3UzD5gNFVZninCwdw8TPZl@mail.gmail.com>
References: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
	<AANLkTimN8P1oKnVe1S60lYofYXaY2p5boClpiATQkhe-@mail.gmail.com>
	<AANLkTikaWgMwp4sUX8_vGU3UzD5gNFVZninCwdw8TPZl@mail.gmail.com>
Message-ID: <AANLkTilsAQpUBKZYhuiJrrnZBi0C5AYnKWx3cLMr5NTE@mail.gmail.com>

On 6/12/10, James Salsman <jsalsman at gmail.com> wrote:
> Bjartur, real-time streaming audio uploads enable pronunciation
> assessment
> for language instruction during multiplayer online roleplaying games such
> as
> those by http://www.8dworld.com
Yes, applications may need audio/visual input, hence W3C's WG DAP has
created an API for accessing audiovisual "devices". As there's already a
standard for accessing such devices, what value does <device> add?
And why should this even be a HTML element in the first place, rather than
an (JS) API?
> input type=file accept="audio/x-speex;quality=(0-10);bitrate=..." is more
> important, and accept="audio/ogg video/x-webm, video/ogg" are all fairly
> important, too.
One non-native English writer to another: I peg your pardon?

P.S. sry for prev. post; gmail fkd up.

From svartman95 at gmail.com  Sun Jun 13 07:45:01 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 13 Jun 2010 14:45:01 +0000
Subject: [whatwg] Syntax highlighting language attribute for editable
	elements
In-Reply-To: <1276427533.3935.20.camel@localhost>
References: <4C147361.2050602@yahoo.com> <1276427533.3935.20.camel@localhost>
Message-ID: <AANLkTilihw71YAC9Il-qbydNJqZgIjiYym9aV89ImPOM@mail.gmail.com>

While using @lang for this purpose sound good in theory it will simply
overload it with information it wasn't really designed for. Something
like @type=application/perl or somesuch might work better. That also
has the benefit that we don't need to build a new list of names of
programming languages (and take care of languages with similiar/same
names, such as Go vs Go!).

On 6/13/10, Ashley Sheridan <ash at ashleysheridan.co.uk> wrote:
> On Sun, 2010-06-13 at 13:57 +0800, Brett Zamir wrote:
>
>> Has thought been given to allow textarea, input and/or contenteditable
>> elements to use an attribute (maybe like <code/> does with
>> class=language-XX) so that user agents might be able to display the
>> editable text with syntax highlighting code automatically?
>>
>> This should not adversely affect users who do not have such browser
>> support, nor does it put pressure on browsers to implement immediately
>> (add-ons might take care of such a role). But having a convention in
>> place (even if languages are not predefined) would ensure that the
>> burden of implementing such support could be shifted away from the
>> developer if they are not so inclined.
>>
>> I'd prefer to see a dedicated attribute (also on <code/>) since the
>> language type does convey general interest semantic information, but I
>> think it would also ideally be consistent (i.e., the same attribute to
>> be used in <code/> as in <textarea/>, etc.).
>>
>> Maybe @lang/@xml:lang could be used for this purpose if its definition
>> could someone be widened to recognize computer languages.
>>
>> It would be nice, however, to also have some means of indicating that
>> the web author is providing their own styling of the element in the
>> event they wish to use their own editor.
>>
>> thank you,
>> Brett Zamir
>
>
> I think maybe not a class, as the class attribute already has a purpose
> and is probably already used in a <code class="php"> type of capacity
> already by some sites showing code excerpts. I'd suggest maybe extending
> the lang attribute, but it's also conceivable that a code snippet might
> be in Perl and written with French comments, and the lang attribute
> wasn't meant for multiple values like the class attribute is. Perhaps
> the best solution is to use another new attribute altogether?
>
> It is a good idea though, I think, as it does add a lot of semantic
> meaning to the content.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>


-- 
kv,
  - Bjartur

From schalk at ossreleasefeed.com  Sun Jun 13 08:17:51 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Sun, 13 Jun 2010 17:17:51 +0200
Subject: [whatwg] Proposal for a widget tag
Message-ID: <005c01cb0b0b$98fb8f80$caf2ae80$@com>

Hi there,

 

I have watched one video after the other, and read articles just the same. I
know we are all unsure when to use section and when to use article. But
marking up something as simple as a blogroll as an article? This really
makes no semantic sense to me.

 

Therefore I suggest the addition of the widget tag. Below is the most
obvious use case and makes much more sense to me. Thoughts?

 

<section>

     <widget id="blogroll">

 

    </widget>

    <widget id="search"> 

 

    </widget>

</section>

 

Kind Regards,

Schalk Neethling

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

From peter at lvp-media.com  Sun Jun 13 13:31:22 2010
From: peter at lvp-media.com (Peter Beverloo)
Date: Sun, 13 Jun 2010 22:31:22 +0200
Subject: [whatwg] Proposal for a widget tag
In-Reply-To: <005c01cb0b0b$98fb8f80$caf2ae80$@com>
References: <005c01cb0b0b$98fb8f80$caf2ae80$@com>
Message-ID: <AANLkTimWOtk40QWD813E-fUSSr_XdswfvkJBPG1gs2ni@mail.gmail.com>

On Sun, Jun 13, 2010 at 17:17, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Hi there,
>
>
>
> I have watched one video after the other, and read articles just the same. I
> know we are all unsure when to use section and when to use article. But
> marking up something as simple as a blogroll as an article? This really
> makes no semantic sense to me.
>
>
>
> Therefore I suggest the addition of the widget tag. Below is the most
> obvious use case and makes much more sense to me. Thoughts?
>
>
>
> <section>
>
> ???? <widget id=?blogroll?>
>
>
>
> ??? </widget>
>
> ??? <widget id=?search?>
>
>
>
> ??? </widget>
>
> </section>
>
>
>
> Kind Regards,
>
> Schalk Neethling

What advantages would <widget> have over <section>, <article> or
simply a grouping <div>? I fail to see why <widget id="search"> would
make significantly more sense than <div id="search">, or even a
fieldset (because that's what a search-area usually consists of). Same
goes for blog-roll, why not simply use an <ol> element?

There has been a lot of discussion about the new elements lately,
their use-cases and rationales, not only about <section> and
<article>, but also the <aside> element. Before starting yet another
discussion you might want to include several use-cases, advantages of
the new element (also in terms of accessibility) and define how it's
going to improve semantics in general. The term "widget" can be very
widely interpreted, as a widget technically can contain anything, how
is that going to make choosing a sectioning element easier?

Peter

From jsalsman at gmail.com  Sun Jun 13 18:36:42 2010
From: jsalsman at gmail.com (James Salsman)
Date: Sun, 13 Jun 2010 18:36:42 -0700
Subject: [whatwg] Do we really need a <device> element?
In-Reply-To: <AANLkTilsAQpUBKZYhuiJrrnZBi0C5AYnKWx3cLMr5NTE@mail.gmail.com>
References: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
	<AANLkTimN8P1oKnVe1S60lYofYXaY2p5boClpiATQkhe-@mail.gmail.com>
	<AANLkTikaWgMwp4sUX8_vGU3UzD5gNFVZninCwdw8TPZl@mail.gmail.com>
	<AANLkTilsAQpUBKZYhuiJrrnZBi0C5AYnKWx3cLMr5NTE@mail.gmail.com>
Message-ID: <AANLkTik0XKyJZK1Hx14qkXUrYoxBn1xHlh6lJ2CTCsjJ@mail.gmail.com>

Summary:  I have been persuaded that the device element is
unnecessary, given recent announcements for the
accept="...;source=..." type specification proposed by Android and
Firefox developers.  Does anyone have any reasons to the contrary?

On Sun, Jun 13, 2010 at 7:33 AM, Bjartur Thorlacius
<svartman95 at gmail.com> wrote:
> On 6/12/10, James Salsman <jsalsman at gmail.com> wrote:
>
>> Bjartur, real-time streaming audio uploads enable pronunciation
>> assessment for language instruction during multiplayer online
>> roleplaying games such as those by http://www.8dworld.com
>
> Yes, applications may need audio/visual input, hence W3C's WG DAP has
> created an API for accessing audiovisual "devices".

"Created" is as yet too past tense for something that's supposed to be
documenting practice, of which the only so far is to use Adobe Flash
instead of HTML.

> As there's already a standard for accessing such devices, what value does <device> add?

Per http://dev.w3.org/html5/html-device/ the device element is a way
for a page to request permission for its scripts to access a device.
Note that it, as a proposal, isn't finalized.  I can certainly see the
argument for implicit behavior when either input type=... accept=...
form elements or real-time javascript streaming interfaces attempt to
access a particular device:  The same permission request should occur
in either case, so why have a separate element for it?

> And why should this even be a HTML element in the first place, rather than
> an (JS) API?

I don't have a good answer to that.  What do others think?

>> input type=file accept="audio/x-speex;quality=(0-10);bitrate=..." is more
>> important, and accept="audio/ogg video/x-webm, video/ogg" are all fairly
>> important, too.
>
> One non-native English writer to another: I beg your pardon?

I mean that Speex, Ogg Vorbis, Google VP8/webm, and possibly Ogg
Theora if the W3C patent examination staff finds anything wrong with
VP8, should be included in form-based device input and upload,
ideally, as well as the real-time streaming javascript interface which
seems more ephemeral at this point.  On the other hand, audio/wav
should not be (it is currently referenced in at least one DAP draft
document), because it's a minefield union type, and its subtypes are
either too high-bandwidth (such as PCM like audio/L16), too low
quality (like a-law or mu-law), have such poor compression artifacts,
or are of too poor or uncertain encumbrance status to use.

I should have written input type=file
accept='audio/x-speex;quality=(0-10);bitrate=...;source=microphone' to
reflect the newly-announced Android/Firefox placement of the source=
parameter.  I would like to see something like that for device
type=audio per http://dev.w3.org/html5/html-device/#stream-api ("This
will be pinned down to a specific codec.")  But again, I think the
issues raised here are good ones and if anyone knows why there is an
actual need for a separate device element, please tell me.

From tkent at chromium.org  Sun Jun 13 22:16:33 2010
From: tkent at chromium.org (TAMURA, Kent)
Date: Mon, 14 Jun 2010 14:16:33 +0900
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
Message-ID: <AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>

There are some objections against omitting invisible controls from form
validation. However, it is a real issue with existing sites and users can't
submit such forms at all though they can submit it with non-HTML5 browsers.

My conclusion is it's better to disable interactive form validation for
existing sites as possible. e.g. disabling interactive form validation for
documents without "<!DOCTYPE html>".


On Fri, Jun 4, 2010 at 00:16, TAMURA, Kent <tkent at chromium.org> wrote:

> > An element is a "candidate for constraint validation" if
>> > 1. it is a validatable type,
>> >    e.g. true if <input type=number>, false if <input type=reset>
>> > 2. has no "disabled" attribute,
>> > 3. has no "readonly" attribute,
>> > 4. inside of a <form> element,
>> > 5. has non-empty "name" attribute, and
>> > 6. not inside of a <datalist> element.
>> >
>> > I hope ValidityState and the pseudo classes ignores 2-6.

>> The pseudo-classes do not ignore 2, 3, and 6. (4 and 5 are now removed.)


> I'd like to propose to add another condition:
>   7. it is visible (computed 'display' property of CSS isn't 'none' and no
> 'hidden' content attribute)

> I couldn't find exceptional rules for validating invisible controls in the
> current draft.
> Chrome 5 was released with a part of interactive validation, and we
> received a bug report about validation against invisible form controls.

> --
> TAMURA Kent
> Software Engineer, Google






-- 
TAMURA Kent
Software Engineer, Google



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

From pkasting at google.com  Sun Jun 13 22:41:40 2010
From: pkasting at google.com (Peter Kasting)
Date: Sun, 13 Jun 2010 22:41:40 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
Message-ID: <AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>

On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent <tkent at chromium.org> wrote:

> There are some objections against omitting invisible controls from form
> validation. However, it is a real issue with existing sites and users can't
> submit such forms at all though they can submit it with non-HTML5 browsers.


How many existing sites?  What sites are asking for form validation but then
not actually working with it?  If this isn't a large number, I would prefer
to stay as-is and let the sites fix themselves.

My conclusion is it's better to disable interactive form validation for
> existing sites as possible. e.g. disabling interactive form validation for
> documents without "<!DOCTYPE html>".
>

I think this is a mistake.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100613/4b8b091a/attachment.htm>

From jsalsman at gmail.com  Sun Jun 13 23:57:36 2010
From: jsalsman at gmail.com (James Salsman)
Date: Sun, 13 Jun 2010 23:57:36 -0700
Subject: [whatwg] Do we really need a <device> element?
In-Reply-To: <AANLkTik0XKyJZK1Hx14qkXUrYoxBn1xHlh6lJ2CTCsjJ@mail.gmail.com>
References: <AANLkTiml-iQ0yow3R6cfy6x66VH6S4qp3LocXAIaRJlV@mail.gmail.com>
	<AANLkTimN8P1oKnVe1S60lYofYXaY2p5boClpiATQkhe-@mail.gmail.com>
	<AANLkTikaWgMwp4sUX8_vGU3UzD5gNFVZninCwdw8TPZl@mail.gmail.com>
	<AANLkTilsAQpUBKZYhuiJrrnZBi0C5AYnKWx3cLMr5NTE@mail.gmail.com>
	<AANLkTik0XKyJZK1Hx14qkXUrYoxBn1xHlh6lJ2CTCsjJ@mail.gmail.com>
Message-ID: <AANLkTinD6FjJlNPL-1Im5E1JOSY2shTTOYLoDN2JgKW6@mail.gmail.com>

On Sun, Jun 13, 2010 at 6:36 PM, James Salsman <jsalsman at gmail.com> wrote:
>
>... I [was] persuaded that the device element is
> unnecessary, given recent announcements for the
> accept="...;source=..." type specification proposed by Android and
> Firefox developers. ?Does anyone have any reasons to the contrary?

A device element with a type parameter would be useful when the HTML
author is unaware of the target browsers' choice of specific elements
such as embed, object, video, microphone, camera, camcorder etc. to
control placement of, for example, audio volume and recording level
controls, microphone visual feedback, video display viewports, camera
and camcorder viewfinders, etc. for real-time device access, which
does seem to be very reasonable to do in HTML instead of Flash.  Use
cases include teleconferencing, screen grabs (device
type=image;source=desktop?), maybe shared whiteboards (device
type=pointer;source=canvas-id producing coordinate streams and up/down
codes?)  Real-time camcorder upload has as compelling use case as
buffered form-based input type=file accept=video;source=webcam does
under lower bandwidth situations. People will want both, so I am not
ready to write off the device element yet.

From jonas at sicking.cc  Mon Jun 14 00:44:09 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 14 Jun 2010 00:44:09 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com> 
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com> 
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
Message-ID: <AANLkTin-RU-b20ffy8R7lqkajLUi475OP3g4jy_pDgz-@mail.gmail.com>

On Sun, Jun 13, 2010 at 10:41 PM, Peter Kasting <pkasting at google.com> wrote:
> On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent <tkent at chromium.org> wrote:
>>
>> There are some objections against omitting invisible controls from form
>> validation. However, it is a real issue with existing sites and users can't
>> submit such forms at all though they can submit it with non-HTML5 browsers.
>
> How many existing sites? ?What sites are asking for form validation but then
> not actually working with it? ?If this isn't a large number, I would prefer
> to stay as-is and let the sites fix themselves.
>>
>> My conclusion is it's better to disable interactive form validation for
>> existing sites as possible. e.g. disabling interactive form validation for
>> documents without "<!DOCTYPE html>".
>
> I think this is a mistake.

Agreed on both accounts. Both these suggestions add a lot of
complexity to the platform and we should avoid it if at all possible.
To the extent that if there is lots of broken sites out there because
they happen to use attribute names that collide with HTML5, but only
partially match the HTML5 behavior, then we should consider renaming
those attributes in HTML5.

/ Jonas

From olak at opera.com  Mon Jun 14 02:55:20 2010
From: olak at opera.com (Ola P. Kleiven)
Date: Mon, 14 Jun 2010 11:55:20 +0200
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
Message-ID: <op.veaa6igfnw228i@id-c0814.oslo.osa>

On Mon, 14 Jun 2010 07:41:40 +0200, Peter Kasting <pkasting at google.com>  
wrote:

> On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent <tkent at chromium.org>  
> wrote:
>
>> There are some objections against omitting invisible controls from form
>> validation. However, it is a real issue with existing sites and users  
>> can't
>> submit such forms at all though they can submit it with non-HTML5  
>> browsers.
>
>
> How many existing sites?  What sites are asking for form validation but  
> then
> not actually working with it?  If this isn't a large number, I would  
> prefer
> to stay as-is and let the sites fix themselves.

The following sites have workarounds in Opera's browser.js to allow form  
submit:

airgreenland.com (using required on hidden elements)
barnesandnoble.com (using required on visible elements that are supposed  
to be empty on submit...)
bookryanair.com (using required=false - this usage has also been found in  
JS libraries)
ingdirect.com.au (using required on a visible field, but then emptying the  
field with JS before submit)
usairways.com (using required on hidden elements)

Most of these have been using it for several years and have not responded  
to change requests from our side.

We have also seen a couple of instances of wrong input types (number where  
text expected etc.), but the usage of "required" is the biggest problem in  
my experience.

> My conclusion is it's better to disable interactive form validation for
>> existing sites as possible. e.g. disabling interactive form validation  
>> for
>> documents without "<!DOCTYPE html>".
>>
>
> I think this is a mistake.
>
> PK


-- 
Ola P. Kleiven, Core Compatibility, Opera Software

From ian at hixie.ch  Mon Jun 14 03:40:46 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 14 Jun 2010 10:40:46 +0000 (UTC)
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <op.veaa6igfnw228i@id-c0814.oslo.osa>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
Message-ID: <Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>

On Mon, 14 Jun 2010, Ola P. Kleiven wrote:
> 
> The following sites have workarounds in Opera's browser.js to allow form
> submit:
> 
> airgreenland.com (using required on hidden elements)
> barnesandnoble.com (using required on visible elements that are supposed to be
> empty on submit...)
> bookryanair.com (using required=false - this usage has also been found in JS
> libraries)
> ingdirect.com.au (using required on a visible field, but then emptying the
> field with JS before submit)
> usairways.com (using required on hidden elements)
> 
> Most of these have been using it for several years and have not responded to
> change requests from our side.
> 
> We have also seen a couple of instances of wrong input types (number 
> where text expected etc.), but the usage of "required" is the biggest 
> problem in my experience.

Incorrect use of "required" in HTML4-era documents also seems to be the 
common problem Chrome ran into -- at the risk of starting a bikeshed 
discussion, does anyone have any good suggestions for alternative names?

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

From micdesim at gmail.com  Mon Jun 14 04:04:49 2010
From: micdesim at gmail.com (Michelangelo De Simone)
Date: Mon, 14 Jun 2010 13:04:49 +0200
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
	<Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>
Message-ID: <EEC7C4AB-1C7B-4320-B8EC-702AB866C058@gmail.com>


Il giorno 14/giu/2010, alle ore 12.40, Ian Hickson ha scritto:

> Incorrect use of "required" in HTML4-era documents also seems to be the 
> common problem Chrome ran into -- at the risk of starting a bikeshed 
> discussion, does anyone have any good suggestions for alternative names?

I believe "mandatory" would keep the same semantic and clarity "required" does.
--
Bye,
Michelangelo





From annevk at opera.com  Mon Jun 14 07:27:10 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 14 Jun 2010 16:27:10 +0200
Subject: [whatwg] Installable web apps
In-Reply-To: <AANLkTinPuMSlo2zq7VbXWWYlzsxpTghnovAShnPHVBHX@mail.gmail.com>
References: <938287364.274872.1274872436319.JavaMail.root@cm-mail03.mozilla.org>
	<1992128521.274961.1274873457250.JavaMail.root@cm-mail03.mozilla.org>
	<AANLkTineMrFwRNFrbrd9VOLwAa5nbMCVGeveNehsw-mS@mail.gmail.com>
	<4BFE610C.4040200@lachy.id.au>
	<AANLkTinPuMSlo2zq7VbXWWYlzsxpTghnovAShnPHVBHX@mail.gmail.com>
Message-ID: <op.veanrkck64w2qv@annevk-t60>

On Thu, 27 May 2010 18:22:03 +0200, Aaron Boodman <aa at google.com> wrote:
> On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au>  
> wrote:
>> <meta name="application-name" content="...">
>
> You're right -- that one does exist already within the page. And it is
> a shame to waste these existing features.
>
> The more I think about it, the more I start to agree that just using
> the <meta> and <link> tags we already have (with perhaps one addition
> for permissions), could work.
>
> Let me think about it some more.

I think if we do more things it would make more sense to build them on top  
of <html manifest> rather than creating some new kind of JSON-based format  
that needs to be separately fetched.


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

From csolisr at gmail.com  Mon Jun 14 12:38:07 2010
From: csolisr at gmail.com (=?ISO-8859-1?Q?Carlos_Andr=E9s_Sol=EDs?=)
Date: Mon, 14 Jun 2010 13:38:07 -0600
Subject: [whatwg] Is there a way to stop scrolling when pressing directional
	arrows?
Message-ID: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>

Hello! I've been noticing a problem in many HTML5 test apps, very especially
games. When the directional arrow buttons are pressed, the screen scrolls.
This is a problem that, as far as I know, Flash had solved by changing the
focus of the application to the app. Is this doable in HTML5?
- Carlos Sol?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100614/66f49750/attachment.htm>

From ash at ashleysheridan.co.uk  Mon Jun 14 12:43:24 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Mon, 14 Jun 2010 20:43:24 +0100
Subject: [whatwg] Is there a way to stop scrolling when pressing
 directional arrows?
In-Reply-To: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>
References: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>
Message-ID: <1276544604.2314.69.camel@localhost>

On Mon, 2010-06-14 at 13:38 -0600, Carlos Andr?s Sol?s wrote:

> Hello! I've been noticing a problem in many HTML5 test apps, very
> especially games. When the directional arrow buttons are pressed, the
> screen scrolls. This is a problem that, as far as I know, Flash had
> solved by changing the focus of the application to the app. Is this
> doable in HTML5?
> - Carlos Sol?s


I don't think it's something that was 'solved'  by Flash. To be honest,
I'm often annoyed at the way Flash steals the focus of all my key
presses making it almost impossible to navigate using only the keyboard.

You could use Javascript to put the focus onto an object, capture all
the key presses on that and return false for them all maybe.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From gphemsley at gmail.com  Mon Jun 14 12:58:57 2010
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Mon, 14 Jun 2010 15:58:57 -0400
Subject: [whatwg] Is there a way to stop scrolling when pressing
	directional arrows?
In-Reply-To: <1276544604.2314.69.camel@localhost>
References: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com> 
	<1276544604.2314.69.camel@localhost>
Message-ID: <AANLkTikQun5Mg5DJOiO2Uul2LFQk4zD23MwaE-FVJk5L@mail.gmail.com>

For what it's worth, I am actually of the opposite opinion, Ash.

I like it when Flash steals the focus of the keyboard, and here's why:
Besides the arrow keys, which are available to everyone, I also use the
"Find As You Type" feature in Firefox. However, that usually means that I
can't play any HTML5 games that use letters as play keys. Because the HTML5
game usually doesn't steal the focus of the keyboard, typing a letter key
activates the FAYT feature and distracts me from the game.

With that being said, Bespin (from Mozilla Labs) uses <canvas>, and it has
no problem stealing the keyboard focus (with JavaScript) for most
keypresses.

Gordon

2010/6/14 Ashley Sheridan <ash at ashleysheridan.co.uk>

>  On Mon, 2010-06-14 at 13:38 -0600, Carlos Andr?s Sol?s wrote:
>
> Hello! I've been noticing a problem in many HTML5 test apps, very
> especially games. When the directional arrow buttons are pressed, the screen
> scrolls. This is a problem that, as far as I know, Flash had solved by
> changing the focus of the application to the app. Is this doable in HTML5?
> - Carlos Sol?s
>
>
> I don't think it's something that was 'solved'  by Flash. To be honest, I'm
> often annoyed at the way Flash steals the focus of all my key presses making
> it almost impossible to navigate using only the keyboard.
>
> You could use Javascript to put the focus onto an object, capture all the
> key presses on that and return false for them all maybe.
>
>   Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>


-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/
http://sasha.sourceforge.net/ ? http://www.yoursasha.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100614/5100b46e/attachment.htm>

From ash at ashleysheridan.co.uk  Mon Jun 14 13:02:11 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Mon, 14 Jun 2010 21:02:11 +0100
Subject: [whatwg] Is there a way to stop scrolling when pressing
 directional arrows?
In-Reply-To: <AANLkTikQun5Mg5DJOiO2Uul2LFQk4zD23MwaE-FVJk5L@mail.gmail.com>
References: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>
	<1276544604.2314.69.camel@localhost>
	<AANLkTikQun5Mg5DJOiO2Uul2LFQk4zD23MwaE-FVJk5L@mail.gmail.com>
Message-ID: <1276545731.2314.71.camel@localhost>

On Mon, 2010-06-14 at 15:58 -0400, Gordon P. Hemsley wrote:

> For what it's worth, I am actually of the opposite opinion, Ash.
> 
> I like it when Flash steals the focus of the keyboard, and here's why:
> Besides the arrow keys, which are available to everyone, I also use
> the "Find As You Type" feature in Firefox. However, that usually means
> that I can't play any HTML5 games that use letters as play keys.
> Because the HTML5 game usually doesn't steal the focus of the
> keyboard, typing a letter key activates the FAYT feature and distracts
> me from the game.
> 
> With that being said, Bespin (from Mozilla Labs) uses <canvas>, and it
> has no problem stealing the keyboard focus (with JavaScript) for most
> keypresses.
> 
> Gordon
> 
> 
> 2010/6/14 Ashley Sheridan <ash at ashleysheridan.co.uk>
> 
>         On Mon, 2010-06-14 at 13:38 -0600, Carlos Andr?s Sol?s wrote:
>         
>         > Hello! I've been noticing a problem in many HTML5 test apps,
>         > very especially games. When the directional arrow buttons
>         > are pressed, the screen scrolls. This is a problem that, as
>         > far as I know, Flash had solved by changing the focus of the
>         > application to the app. Is this doable in HTML5?
>         > - Carlos Sol?s
>         
>         
>         
>         
>         I don't think it's something that was 'solved'  by Flash. To
>         be honest, I'm often annoyed at the way Flash steals the focus
>         of all my key presses making it almost impossible to navigate
>         using only the keyboard.
>         
>         You could use Javascript to put the focus onto an object,
>         capture all the key presses on that and return false for them
>         all maybe.
>         
>         Thanks,
>         Ash
>         http://www.ashleysheridan.co.uk
>         
>         
>         
> 
> 
> 
> 
> -- 
> Gordon P. Hemsley
> me at gphemsley.org
> http://gphemsley.org/ ? http://gphemsley.org/blog/
> http://sasha.sourceforge.net/ ? http://www.yoursasha.com/


It's not that I have it in for Flash, but I feel it's not the most
accessibility friendly of things you find on the web.

Thanks,
Ash
http://www.ashleysheridan.co.uk


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

From kornel at geekhood.net  Mon Jun 14 15:16:13 2010
From: kornel at geekhood.net (Kornel Lesinski)
Date: Mon, 14 Jun 2010 23:16:13 +0100
Subject: [whatwg] Is there a way to stop scrolling when pressing
 directional arrows?
In-Reply-To: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>
References: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>
Message-ID: <op.vea9hbybptj49s@aimac.local>

On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andr?s Sol?s  
<csolisr at gmail.com> wrote:

> Hello! I've been noticing a problem in many HTML5 test apps, very  
> especially games. When the directional arrow buttons are pressed, the  
> screen scrolls.
> This is a problem that, as far as I know, Flash had solved by changing  
> the focus of the application to the app. Is this doable in HTML5?

Yes. It's possible already ? page just has to return false from keypress  
handler:

window.onkeypress = function(){return false}

That's just one line that, unfortunately, many web-based games forget to  
include.

-- 
regards, Kornel Lesi?ski

From mjs at apple.com  Mon Jun 14 15:24:37 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Mon, 14 Jun 2010 15:24:37 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
	<Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>
Message-ID: <DD63BEE9-CEF1-43F8-AF3A-EA76402027A7@apple.com>


On Jun 14, 2010, at 3:40 AM, Ian Hickson wrote:

> On Mon, 14 Jun 2010, Ola P. Kleiven wrote:
>> 
>> The following sites have workarounds in Opera's browser.js to allow form
>> submit:
>> 
>> airgreenland.com (using required on hidden elements)
>> barnesandnoble.com (using required on visible elements that are supposed to be
>> empty on submit...)
>> bookryanair.com (using required=false - this usage has also been found in JS
>> libraries)
>> ingdirect.com.au (using required on a visible field, but then emptying the
>> field with JS before submit)
>> usairways.com (using required on hidden elements)
>> 
>> Most of these have been using it for several years and have not responded to
>> change requests from our side.
>> 
>> We have also seen a couple of instances of wrong input types (number 
>> where text expected etc.), but the usage of "required" is the biggest 
>> problem in my experience.
> 
> Incorrect use of "required" in HTML4-era documents also seems to be the 
> common problem Chrome ran into -- at the risk of starting a bikeshed 
> discussion, does anyone have any good suggestions for alternative names?


A few suggestions:

required-field
value-required

Regards,
Maciej


From kornel at geekhood.net  Mon Jun 14 15:51:17 2010
From: kornel at geekhood.net (Kornel Lesinski)
Date: Mon, 14 Jun 2010 23:51:17 +0100
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <AANLkTin-RU-b20ffy8R7lqkajLUi475OP3g4jy_pDgz-@mail.gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
	<AANLkTin-RU-b20ffy8R7lqkajLUi475OP3g4jy_pDgz-@mail.gmail.com>
Message-ID: <op.veba3r13ptj49s@aimac.local>

On Mon, 14 Jun 2010 08:44:09 +0100, Jonas Sicking <jonas at sicking.cc> wrote:

> Agreed on both accounts. Both these suggestions add a lot of
> complexity to the platform and we should avoid it if at all possible.
> To the extent that if there is lots of broken sites out there because
> they happen to use attribute names that collide with HTML5, but only
> partially match the HTML5 behavior, then we should consider renaming
> those attributes in HTML5.

I don't agree that there are "lots" of broken sites. My main browser is  
Opera and I haven't noticed that problem yet.

The fact that there are some sites using 'required' attribute proves that  
it's a good, intuitive name.

HTML5 is likely to outlive those broken sites. I think it would be shame  
to change to worse name for HTML's lifetime just to avoid temporary  
problem with some sites.

-- 
regards, Kornel Lesi?ski

From simonp at opera.com  Mon Jun 14 15:56:26 2010
From: simonp at opera.com (Simon Pieters)
Date: Tue, 15 Jun 2010 00:56:26 +0200
Subject: [whatwg] Is there a way to stop scrolling when pressing
 directional arrows?
In-Reply-To: <op.vea9hbybptj49s@aimac.local>
References: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>
	<op.vea9hbybptj49s@aimac.local>
Message-ID: <op.vebbccryidj3kv@simon-pieterss-macbook.local>

On Tue, 15 Jun 2010 00:16:13 +0200, Kornel Lesinski <kornel at geekhood.net>  
wrote:

> On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andr?s Sol?s  
> <csolisr at gmail.com> wrote:
>
>> Hello! I've been noticing a problem in many HTML5 test apps, very  
>> especially games. When the directional arrow buttons are pressed, the  
>> screen scrolls.
>> This is a problem that, as far as I know, Flash had solved by changing  
>> the focus of the application to the app. Is this doable in HTML5?
>
> Yes. It's possible already ? page just has to return false from keypress  
> handler:
>
> window.onkeypress = function(){return false}
>
> That's just one line that, unfortunately, many web-based games forget to  
> include.

If a game is embedded in a page with other content, it could make the  
<canvas> (or whatever) focusable with tabindex='0' and only disable keys  
when the game has focus. It could also be nice and only disable the keys  
it chooses to use.

<script>
var mapping = {37: 'left', 38: 'up', 39: 'right', 40:'down'}
function press(e) {
   if (!e.shiftKey && !e.ctrlKey && !e.metaKey && e.keyCode > 36 &&  
e.keyCode < 41) {
     var ctx = e.target.getContext('2d');
     ctx.clearRect(0, 0, e.target.width, e.target.height);
     ctx.fillText(mapping[e.keyCode], 20, 20);
     e.preventDefault();
   }
}
</script>
<canvas tabindex=0 onkeypress=press(event)></canvas>

In Opera, I can scroll using the arrow keys, navigate to the game,  
interact with it using the arrow keys without it scrolling the page, and  
navigate away from it using spatnav (shift+arrow keys).

-- 
Simon Pieters
Opera Software

From jonas at sicking.cc  Mon Jun 14 16:05:14 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 14 Jun 2010 16:05:14 -0700
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <DD63BEE9-CEF1-43F8-AF3A-EA76402027A7@apple.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com> 
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com> 
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com> 
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
	<Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com> 
	<DD63BEE9-CEF1-43F8-AF3A-EA76402027A7@apple.com>
Message-ID: <AANLkTimvghWo1OWZ6aFaK_HraRirZXUMqQDMblZIbCnW@mail.gmail.com>

On Mon, Jun 14, 2010 at 3:24 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jun 14, 2010, at 3:40 AM, Ian Hickson wrote:
>
>> On Mon, 14 Jun 2010, Ola P. Kleiven wrote:
>>>
>>> The following sites have workarounds in Opera's browser.js to allow form
>>> submit:
>>>
>>> airgreenland.com (using required on hidden elements)
>>> barnesandnoble.com (using required on visible elements that are supposed to be
>>> empty on submit...)
>>> bookryanair.com (using required=false - this usage has also been found in JS
>>> libraries)
>>> ingdirect.com.au (using required on a visible field, but then emptying the
>>> field with JS before submit)
>>> usairways.com (using required on hidden elements)
>>>
>>> Most of these have been using it for several years and have not responded to
>>> change requests from our side.
>>>
>>> We have also seen a couple of instances of wrong input types (number
>>> where text expected etc.), but the usage of "required" is the biggest
>>> problem in my experience.
>>
>> Incorrect use of "required" in HTML4-era documents also seems to be the
>> common problem Chrome ran into -- at the risk of starting a bikeshed
>> discussion, does anyone have any good suggestions for alternative names?
>
>
> A few suggestions:
>
> required-field
> value-required

This is a pretty short list of sites. I'd really like to avoid
renaming the attribute at this point as I strongly suspect that we can
get these sites fixed within a few months.

It might have been very hard to get these sites to listen when only
one browser broke. However in a very short order 4 out of the top 5
browsers will implement the "required" attribute, which should be very
strong incentive.

I've contacted our evangelism team which in the passed have been
pretty successful at getting sites to change, so I'm pretty hopeful we
can do that here too.

/ Jonas

From jackalmage at gmail.com  Mon Jun 14 16:42:26 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 14 Jun 2010 16:42:26 -0700
Subject: [whatwg] Is there a way to stop scrolling when pressing
	directional arrows?
In-Reply-To: <op.vebbccryidj3kv@simon-pieterss-macbook.local>
References: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com> 
	<op.vea9hbybptj49s@aimac.local>
	<op.vebbccryidj3kv@simon-pieterss-macbook.local>
Message-ID: <AANLkTilp78Ru2C8p1mRHNbpn6BszT-EhQcLkp-6h9Gta@mail.gmail.com>

On Mon, Jun 14, 2010 at 3:56 PM, Simon Pieters <simonp at opera.com> wrote:
> On Tue, 15 Jun 2010 00:16:13 +0200, Kornel Lesinski <kornel at geekhood.net>
> wrote:
>
>> On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andr?s Sol?s
>> <csolisr at gmail.com> wrote:
>>
>>> Hello! I've been noticing a problem in many HTML5 test apps, very
>>> especially games. When the directional arrow buttons are pressed, the screen
>>> scrolls.
>>> This is a problem that, as far as I know, Flash had solved by changing
>>> the focus of the application to the app. Is this doable in HTML5?
>>
>> Yes. It's possible already ? page just has to return false from keypress
>> handler:
>>
>> window.onkeypress = function(){return false}
>>
>> That's just one line that, unfortunately, many web-based games forget to
>> include.
>
> If a game is embedded in a page with other content, it could make the
> <canvas> (or whatever) focusable with tabindex='0' and only disable keys
> when the game has focus. It could also be nice and only disable the keys it
> chooses to use.
>
> <script>
> var mapping = {37: 'left', 38: 'up', 39: 'right', 40:'down'}
> function press(e) {
> ?if (!e.shiftKey && !e.ctrlKey && !e.metaKey && e.keyCode > 36 && e.keyCode
> < 41) {
> ? ?var ctx = e.target.getContext('2d');
> ? ?ctx.clearRect(0, 0, e.target.width, e.target.height);
> ? ?ctx.fillText(mapping[e.keyCode], 20, 20);
> ? ?e.preventDefault();
> ?}
> }
> </script>
> <canvas tabindex=0 onkeypress=press(event)></canvas>
>
> In Opera, I can scroll using the arrow keys, navigate to the game, interact
> with it using the arrow keys without it scrolling the page, and navigate
> away from it using spatnav (shift+arrow keys).

Random note: the keypress event isn't interoperably supported in this
area - in IE and webkit-based browsers, keys that don't generate a
character won't generate a keypress event.  You can use keydown to
capture the press instead.

~TJ

From bringert at google.com  Mon Jun 14 16:50:31 2010
From: bringert at google.com (Bjorn Bringert)
Date: Mon, 14 Jun 2010 23:50:31 +0000
Subject: [whatwg] Speech input element
In-Reply-To: <4bf5667b.8d07cc0a.20bd.05c4@mx.google.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
	<AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>
	<op.vcx1a5o664w2qv@annevk-t60>
	<AANLkTimt9eQGkH1NhcHHXepKJugi31SkTVnc71B34I7b@mail.gmail.com>
	<op.vcx1xiqd64w2qv@annevk-t60>
	<AANLkTikI2Ob6OJCcAaomXSJNOxHEYVFnFJmqviOHN80H@mail.gmail.com>
	<4C191C19-FC75-40BA-B2FB-7188E7354695@apple.com>
	<AANLkTin3w7CSrWO2gMzEssIl_1-VCfy2Gg9lfjJ5sICj@mail.gmail.com>
	<op.vcz7r4ah64w2qv@annevk-t60>
	<AANLkTin5rfkj6wjhC7dQeVH7IgXs4xDlX3EB_Wh4tg2Y@mail.gmail.com>
	<4bf5667b.8d07cc0a.20bd.05c4@mx.google.com>
Message-ID: <AANLkTime1XUJ9leHV2Ghj9j30TSXlRHJ7CYPVT0Snj7W@mail.gmail.com>

Based on the feedback in this thread we've worked out a new speech
input proposal that adds a @speech attribute to most input elements,
instead of a new <input type="speech">. Please see
http://docs.google.com/View?id=dcfg79pz_5dhnp23f5 for the new
proposal.

/Bjorn Bringert & Satish Sampath

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

From andrew at ado.is-a-geek.net  Tue Jun 15 03:52:12 2010
From: andrew at ado.is-a-geek.net (Andrew Oakley)
Date: Tue, 15 Jun 2010 11:52:12 +0100
Subject: [whatwg] DOM Range Deletions
Message-ID: <4C175B5C.2050106@ado.is-a-geek.net>

I've been trying to implement DOM Range but can't work out how ranges
are supposed to work under mutation.

In the following examples I use *this* to indicate a range being deleted
and slashes to indicate another range.


Section 2.6 - Deleting Content with a Range gives the example of

<FOO>X*Y<BAR>Z*W</BAR>Q</FOO> -> <FOO>X^<BAR>W</BAR>Q</FOO>


Section 2.12.2 - Deletions says:

"If a boundary-point of the original Range is within the content being
deleted, then after the deletion it will be at the same position as the
resulting boundary-point of the (now collapsed) Range used to delete the
contents."

We then have the example of:

<P>ABCD *efgh The <EM>R*ange</EM> ijkl</P>
              /            \

Goes to

<P>ABCD <EM>ange</EM> ijkl</P>
           /    \

I assume that the range indicated by the underline in the spec and like
*this* here collapses to just before the <EM> tag as this document has
the same structure as the other example I pulled out of the spec.  This
would mean that the start point of the other range should also be just
before the <EM>, but that isn't what has happened in this example.

Any idea what I've got wrong?  Some browsers (e.g. Safari) seem to
behave as in the example, others (e.g. Firefox) put the end point before
the <EM> (as I would have expected).

Thanks

-- 
Andrew Oakley


From WeBMartians at verizon.net  Tue Jun 15 05:29:57 2010
From: WeBMartians at verizon.net (Bruce de Graaf)
Date: Tue, 15 Jun 2010 08:29:57 -0400
Subject: [whatwg] Form validation against invisible controls
In-Reply-To: <EEC7C4AB-1C7B-4320-B8EC-702AB866C058@gmail.com>
References: <AANLkTinOBn1abnSIchlCVQ87A5N-QUVcAQhr4kDgwBu1@mail.gmail.com>
	<AANLkTilmAID5LkTsOPglAuNoosh4Du9hGpihYQxdvrnA@mail.gmail.com>
	<AANLkTikwzjhSo0c9u0-fXAo5qa7O-isLsSPC2r-fJyKI@mail.gmail.com>
	<op.veaa6igfnw228i@id-c0814.oslo.osa>
	<Pine.LNX.4.64.1006141039560.22659@ps20323.dreamhostps.com>
	<EEC7C4AB-1C7B-4320-B8EC-702AB866C058@gmail.com>
Message-ID: <4C177245.9030605@verizon.net>

I remember an article that stated that "required" was used 29 times more 
often than "mandatory" in instructions and specifications (WWWeb pages 
were mentioned as being part of the search source).

Mandatory implies that there may be reprisals for failure to comply, 
because, and, secondarily, such failures could lead to loss of sovereign 
integrity.

Required has no connotation that failure to comply will result in loss 
of integrity and, while cooperation may be conditional, certainly, does 
not intimate retribution.
===
On 2010-06-14 07:04, Michelangelo De Simone wrote:
> Il giorno 14/giu/2010, alle ore 12.40, Ian Hickson ha scritto:
>
>    
>> Incorrect use of "required" in HTML4-era documents also seems to be the
>> common problem Chrome ran into -- at the risk of starting a bikeshed
>> discussion, does anyone have any good suggestions for alternative names?
>>      
> I believe "mandatory" would keep the same semantic and clarity "required" does.
> --
> Bye,
> Michelangelo
>
>
>
>
>
>    


From satish at google.com  Tue Jun 15 08:08:40 2010
From: satish at google.com (Satish Sampath)
Date: Tue, 15 Jun 2010 16:08:40 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTime1XUJ9leHV2Ghj9j30TSXlRHJ7CYPVT0Snj7W@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
	<AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>
	<op.vcx1a5o664w2qv@annevk-t60>
	<AANLkTimt9eQGkH1NhcHHXepKJugi31SkTVnc71B34I7b@mail.gmail.com>
	<op.vcx1xiqd64w2qv@annevk-t60>
	<AANLkTikI2Ob6OJCcAaomXSJNOxHEYVFnFJmqviOHN80H@mail.gmail.com>
	<4C191C19-FC75-40BA-B2FB-7188E7354695@apple.com>
	<AANLkTin3w7CSrWO2gMzEssIl_1-VCfy2Gg9lfjJ5sICj@mail.gmail.com>
	<op.vcz7r4ah64w2qv@annevk-t60>
	<AANLkTin5rfkj6wjhC7dQeVH7IgXs4xDlX3EB_Wh4tg2Y@mail.gmail.com>
	<4bf5667b.8d07cc0a.20bd.05c4@mx.google.com>
	<AANLkTime1XUJ9leHV2Ghj9j30TSXlRHJ7CYPVT0Snj7W@mail.gmail.com>
Message-ID: <AANLkTiniDHX2UVUgN6ISkgqvLX9q8gkwvSBZ8oWe9kXU@mail.gmail.com>

To add a little more clarity - we initially proposed a speech input API
using a new <input type="speech"> element. The top feedback we received was
to extend speech as a form of input to existing elements instead of creating
a new speech control. We have taken that into account in the new proposal
which extends speech input to existing form elements and other editable
elements. Please take a fresh look and share your thoughts.

--
Cheers
Satish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100615/7ae698a5/attachment.htm>

From jonas at sicking.cc  Tue Jun 15 11:25:21 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 15 Jun 2010 11:25:21 -0700
Subject: [whatwg] Don't throw for HTMLInputElement.files
Message-ID: <AANLkTikMA1hZEggx8aLhMklPZXB11Sx7uAtBQbZlX-O_@mail.gmail.com>

Hi All,

Currently HTMLInputElement.files throws if accessed when type !=
"file". I think it would be better to return null or an empty list. We
generally try to avoid throwing in general, and in particular things
like HTMLInputElement.checked doesn't throw even if the value doesn't
apply. So for consistency I don't think HTMLInputElement.files should
throw either.

Another reason not to throw is that people every so often enumerate
all the IDL attributes of element using |for each| constructs in
javascript. Such code tends to break if there are properties that
throw upon access.

/ Jonas

From svartman95 at gmail.com  Tue Jun 15 15:09:10 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 15 Jun 2010 22:09:10 +0000
Subject: [whatwg] Is there a way to stop scrolling when pressing
	directional arrows?
In-Reply-To: <op.vea9hbybptj49s@aimac.local>
References: <AANLkTimSb0FkcCPnle6cdz-uSETSGZAcHn0SHHaQsHc0@mail.gmail.com>
	<op.vea9hbybptj49s@aimac.local>
Message-ID: <AANLkTimQWMyE_DBPVJ3S-yGm1bPdhZX9gc_wxjnuE4mv@mail.gmail.com>

On 6/14/10, Kornel Lesinski <kornel at geekhood.net> wrote:
> On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andr?s Sol?s
> <csolisr at gmail.com> wrote:
>
>> Hello! I've been noticing a problem in many HTML5 test apps, very
>> especially games. When the directional arrow buttons are pressed, the
>> screen scrolls.
>> This is a problem that, as far as I know, Flash had solved by changing
>> the focus of the application to the app. Is this doable in HTML5?
>
> Yes. It's possible already ? page just has to return false from keypress
> handler:
>
> window.onkeypress = function(){return false}
>
> That's just one line that, unfortunately, many web-based games forget to
> include.
>
The bad thing about the Flash behaviour is that it seems to completely steal
keyboard focus if programs even listen to onkeypress. window.onkeydown
should return false only when the application is actually going to use that
keypress.

-- 
kv,
  - Bjartur

From dhtmlkitchen at gmail.com  Tue Jun 15 16:01:59 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 15 Jun 2010 16:01:59 -0700
Subject: [whatwg] Fwd:  Don't throw for HTMLInputElement.files
In-Reply-To: <AANLkTinTBhSoygAIFRmKgRP0aGLpX6l6dtHo6TFMRjpY@mail.gmail.com>
References: <AANLkTikMA1hZEggx8aLhMklPZXB11Sx7uAtBQbZlX-O_@mail.gmail.com>
	<AANLkTinTBhSoygAIFRmKgRP0aGLpX6l6dtHo6TFMRjpY@mail.gmail.com>
Message-ID: <AANLkTimvsDo4Q9strB9sldXzvEh6S8tyEPDjXxMsFSLC@mail.gmail.com>

Jonas suggested I fwd these comments to the list.

---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen at gmail.com>
Date: Tue, 15 Jun 2010 15:04:16 -0700
Subject: Re: [whatwg] Don't throw for HTMLInputElement.files
To: Jonas Sicking <jonas at sicking.cc>

On 6/15/10, Jonas Sicking <jonas at sicking.cc> wrote:
> Hi All,
>
> Currently HTMLInputElement.files throws if accessed when type !=
> "file". I think it would be better to return null or an empty list. We
> generally try to avoid throwing in general, and in particular things
> like HTMLInputElement.checked doesn't throw even if the value doesn't
> apply. So for consistency I don't think HTMLInputElement.files should
> throw either.
>

The calling code can perform a check - if(x.type == "file") -. I can't
see a good reason for not having x.files be designed to return
`undefined`. Besides, throwin an error there is totally inconsistent
with other state-specific properties (like `valueAsNumber` or
`valueAsDate` etc). On those, both of those are needless complexity
anyway; +inp.value is a common-use alternative to valueAsNumber and
valueAsDate can be gotten by using the Date constructor, which,
although buggy in Firefox, is specified in ES5 to parse a superset of
the ISO8601 formats in HTML5.

> Another reason not to throw is that people every so often enumerate
> all the IDL attributes of element using |for each| constructs in

The for-in loop. |for each| is a spidermonkey syntax extension. It is
not widely implemented and nobody uses it.

Garrett

From svartman95 at gmail.com  Tue Jun 15 16:34:13 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 15 Jun 2010 23:34:13 +0000
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTiniDHX2UVUgN6ISkgqvLX9q8gkwvSBZ8oWe9kXU@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
	<AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>
	<op.vcx1a5o664w2qv@annevk-t60>
	<AANLkTimt9eQGkH1NhcHHXepKJugi31SkTVnc71B34I7b@mail.gmail.com>
	<op.vcx1xiqd64w2qv@annevk-t60>
	<AANLkTikI2Ob6OJCcAaomXSJNOxHEYVFnFJmqviOHN80H@mail.gmail.com>
	<4C191C19-FC75-40BA-B2FB-7188E7354695@apple.com>
	<AANLkTin3w7CSrWO2gMzEssIl_1-VCfy2Gg9lfjJ5sICj@mail.gmail.com>
	<op.vcz7r4ah64w2qv@annevk-t60>
	<AANLkTin5rfkj6wjhC7dQeVH7IgXs4xDlX3EB_Wh4tg2Y@mail.gmail.com>
	<4bf5667b.8d07cc0a.20bd.05c4@mx.google.com>
	<AANLkTime1XUJ9leHV2Ghj9j30TSXlRHJ7CYPVT0Snj7W@mail.gmail.com>
	<AANLkTiniDHX2UVUgN6ISkgqvLX9q8gkwvSBZ8oWe9kXU@mail.gmail.com>
Message-ID: <AANLkTimxRtROvLyYPhNUPgET64mWkh6cLD5w9Fyq5Xo5@mail.gmail.com>

>From TFA:
> We would like some way of having speech control in a web application, without any input
> fields. For example, in a webmail client, there are buttons, links etc that lets the user take
> actions such as deleting or replying to email. We would like to make it easy to implement a
> speech interface where the user can say "read next message", "archive", "reply" etc, without
> having to show a text field where the sa