From privat at ni-po.com  Sat May  1 02:09:19 2010
From: privat at ni-po.com (Nikita Popov)
Date: Sat, 01 May 2010 11:09:19 +0200
Subject: [whatwg] Headings and sections, role of H2-H6
In-Reply-To: <4BDB8B9B.9000300@mit.edu>
References: <5A125DA3E79E424DBD735503F4D59039@p> <4BDAC6E3.2010302@ni-po.com>
	<4BDAE4FF.6070507@mit.edu> <4BDB1CB7.4080704@ni-po.com>
	<4BDB8B9B.9000300@mit.edu>
Message-ID: <4BDBEFBF.8020107@ni-po.com>

On 01.05.2010 04:02, Boris Zbarsky wrote:
> On 4/30/10 2:08 PM, Nikita Popov wrote:
>> I don't know whether I would be happy, if all headings in my document
>> were shown *BIG*, 'cause I use h1 everywhere. I would much more
>> appreciate them to be unstyled. (But this is only personal opinion.)
>
> Really?  Given:
>
> <h>This is a header</h>
>   This is some text after the header.
>
> The "unstyled" rendering you would see is:
>
>   This is a headerThis is some text after the header.
Yeah, you're right. This would be problematic. This does convince me, 
that using <h> is not a good idea.
>
>> I easily think that using h1 everywhere isn't semantically correct.
>> Especially if the subsections (with their h1s) cannot be redistributed
>> solely it does not make any sense.
>
> I'm not sure I follow.
I wanted to say, that it does not make sense to me, to use a highest 
ranking heading in all sections, subsections, and subsubsubsections, 
especially if they cannot be used solely (out of context).
>
>> But maybe you are right. The html5 spec is already blown up with stuff
>> nobody will ever use (keygen?) enough.
>
> Amusingly enough, keygen is something I use once a year or so (when my 
> user certificate expires), and something that MIT students need to use 
> to, say, register for classes (or view their grades, deal with 
> bursar's office stuff online, etc, etc).  See 
> https://ca.mit.edu/ca/certgen (though that will likely require a 
> login... that you may not have).  See 
> http://ist.mit.edu/services/certificates for the various documentation.
I do not deny, that keygen has it's use cases (the "nobody" was 
hyperbolic). I only think, that the use cases are *very* rare. It is 
overkill to introduce an HTML element therefore. It would be much more 
sane to provide a JS API (as Janos proposed.) [I would do it myself, but 
I have only very little knowledge on encryption.]

From herenvardo at gmail.com  Sat May  1 04:11:58 2010
From: herenvardo at gmail.com (Eduard Pascual)
Date: Sat, 1 May 2010 13:11:58 +0200
Subject: [whatwg] The real issue with HTML5's sectioning model
In-Reply-To: <op.vbz7oxw264w2qv@annevk-t60>
References: <x2j6ea53251004301157hf07485dap9a7a0f2f110b01be@mail.gmail.com> 
	<op.vbz6a5hs64w2qv@annevk-t60>
	<z2pad1a0c1e1004301842i5871dde0j1fad91ac32d9f513@mail.gmail.com>
	<op.vbz7oxw264w2qv@annevk-t60>
Message-ID: <m2l6ea53251005010411u8d34d24ax59713120583b3c0a@mail.gmail.com>

On Sat, May 1, 2010 at 3:56 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Sat, 01 May 2010 10:42:03 +0900, James Robinson <jamesr at google.com>
> wrote:
>>
>> Is this sort of reply really necessary? ?I have not been following the
>> surrounding discussion, but this email showed up as a new thread in my
>> mail client. ?Based on this tone, I now have no desire to catch up on the
>> rest of the discussion.
>
> My bad. It's just that we've been over this discussion like a gazillion
> times
Really? Then I must have missed something.
Please keep in mind that this was *not* another HTML5 vs. XHTML2
thread; but a discussion on the issues triggered by HTML5's approach
(styling, compatibility, room for future evolution, spec-bloating).
The (partial) comparison with XHTML2 was only intended to help
highlighting the root of these issues.
Anyway, I'm working on a formal proposal that will describe the
problems in terms of use-cases and examples, and my suggested solution
in the form of (mostly) spec-ready text, accompanied with rationales
for each proposed change to the current draft, but *without* any
mention to XHTML2 (it could properly serve as an example to discuss
some concepts in the abstract, but it has no place in a more formal
proposal).

> and it would be nice that if we were to have it again at least we
> started with the correct facts.
Then let's start by taking *correct* facts. My original statement
about XHTML2's sectioning model was indeed a simplification, but the
goal of that was highlighting the best aspects of their approach, not
to degrade this into yet another XHTML2 vs. HTML5 discussion. On the
other hand, your statement:

> Which are that XHTML2 had exactly the same
> design as HTML5 has now
Is a blatant lie. The key difference between XHTML2's and HTML5's
approaches to sectioning (and the one my suggestion was based on) is
that XHTML2 defines *a single element* to mark up sections
(unsurprisingly named <section>), while HTML5 defines several
(<section>, <nav>, <article>, and so on). This is the root of the
issues I'm trying to get addressed; and it seems a lot saner to solve
them all at the root than to define some kind of esoteric workaround
separately for each.

> but did not solve the problem of mixing h1-h6 with
> section/h. HTML5 did.
I applaud HTML5's overall approach to how mixed implicit and explicit
sectioning will be handled. It's an amazing example of the good work
done in HTML5 on the field of compatibility. But the issues here are
about how explicit sectioning is implemented. It is a new feature that
introduces some unneeded issues, instead of leveraging existing
technologies (including pre-5 X/HTML, CSS, and so on). In other words,
while HTML5's approach to heading handling is good, sound, and
elegant, the approach to sectioning is bloated, ugly, and
revolutionary rather than evolutionary.

On a side note, I'd like to highlight a detail that might have gone
unnoticed. There are, IMO, two kinds (or rather, perspectives) of
"backwards compatibility":
The one you'll probably be more familiar with is the UA perspective:
new UAs must be able to handle old content: if a user's favorite sites
break on a new browser, the user won't want to use that browser.
Simetrically, there is a content authoring perspective: new content
needs to handle old UAs: if a new site or document breaks on the
user's favorite browser, the user won't use that content, even if they
want to.
For HTML5 (or any other "upgrade" to a web-related technology) to
succeed, both perspectives need to be observed. *This* is where XHTML2
most blatantly failed: it tried to avoid the UA perspective through
the assumption of mode-switching, and the features for the authoring
perspective (keeping elements that it was obsoleting, such as <h1-6>,
<img>, <a>, etc) didn't solve anything at all (due to the
mode-switching assumption).
HTML5 has done a great work to address the UA perspective of
compatibility; but there are some aspects, like the sectioning model,
that trigger serious issues on the authoring perspective.

Regards,
Eduard Pascual

From jgraham at opera.com  Sat May  1 12:49:25 2010
From: jgraham at opera.com (James Graham)
Date: Sat, 1 May 2010 21:49:25 +0200 (CEST)
Subject: [whatwg] keygen [was: Re:  Headings and sections, role of H2-H6]
In-Reply-To: <4BDBEFBF.8020107@ni-po.com>
References: <5A125DA3E79E424DBD735503F4D59039@p> <4BDAC6E3.2010302@ni-po.com>
	<4BDAE4FF.6070507@mit.edu> <4BDB1CB7.4080704@ni-po.com>
	<4BDB8B9B.9000300@mit.edu> <4BDBEFBF.8020107@ni-po.com>
Message-ID: <alpine.DEB.2.00.1005012146000.10238@sirus>



On Sat, 1 May 2010, Nikita Popov wrote:

> I do not deny, that keygen has it's use cases (the "nobody" was hyperbolic). 
> I only think, that the use cases are *very* rare. It is overkill to introduce 
> an HTML element therefore. It would be much more sane to provide a JS API (as 
> Janos proposed.) [I would do it myself, but I have only very little knowledge 
> on encryption.]

No one is "introducing" anything. It has already existed for years. We can 
either document it or force new entrants to the market to reverse engineer 
it on thier own. document reality rather than ignoring it is oe of the 
fundamental purposes of this effort.

From jackalmage at gmail.com  Sat May  1 17:27:47 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sat, 1 May 2010 17:27:47 -0700
Subject: [whatwg] Headings and sections, role of H2-H6
In-Reply-To: <4BDBEFBF.8020107@ni-po.com>
References: <5A125DA3E79E424DBD735503F4D59039@p> <4BDAC6E3.2010302@ni-po.com> 
	<4BDAE4FF.6070507@mit.edu> <4BDB1CB7.4080704@ni-po.com>
	<4BDB8B9B.9000300@mit.edu> <4BDBEFBF.8020107@ni-po.com>
Message-ID: <u2tdd0fbad1005011727t49c4fa2qb81b591d290c3ca8@mail.gmail.com>

On Sat, May 1, 2010 at 2:09 AM, Nikita Popov <privat at ni-po.com> wrote:
> I do not deny, that keygen has it's use cases (the "nobody" was hyperbolic).
> I only think, that the use cases are *very* rare. It is overkill to
> introduce an HTML element therefore. It would be much more sane to provide a
> JS API (as Janos proposed.) [I would do it myself, but I have only very
> little knowledge on encryption.]

We're getting off-topic here, but <keygen> wasn't created by HTML5.
It's an element that IE created, and which was used widely enough in
certain markets that some other browsers were forced to implement it
as well.  HTML5 is simply including it because it's apparently
important enough for the web for multiple browsers to implement.  It
does indeed suck as a solution, but we don't get to rewrite history.
^_^

~TJ

From ryan14 at mail.com  Sat May  1 20:25:10 2010
From: ryan14 at mail.com (ryan14 at mail.com)
Date: Sat, 01 May 2010 23:25:10 -0400
Subject: [whatwg] suggestion for HTML5 spec
Message-ID: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>


 My suggestion for the HTML5 spec is that the video tag should have a feature that can enable GPU acceleration on a user's graphics card, so it will take some stress off the CPU.

Do you like my suggestion?

 


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

From jackalmage at gmail.com  Sat May  1 20:55:16 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sat, 1 May 2010 20:55:16 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
Message-ID: <s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>

On Sat, May 1, 2010 at 8:25 PM,  <ryan14 at mail.com> wrote:
> My suggestion for the HTML5 spec is that the video tag should have a feature
> that can enable GPU acceleration on a user's graphics card, so it will take
> some stress off the CPU.
>
> Do you like my suggestion?

Nothing is stopping browsers from using the GPU to help speed up
<video> playback right now, and in fact I think that some browsers are
either already doing so, or are planning to do so in the relatively
near future.

~TJ

From ian at hixie.ch  Sat May  1 23:34:20 2010
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 2 May 2010 06:34:20 +0000 (UTC)
Subject: [whatwg] Headings and sections, role of H2-H6
In-Reply-To: <u2tdd0fbad1005011727t49c4fa2qb81b591d290c3ca8@mail.gmail.com>
References: <5A125DA3E79E424DBD735503F4D59039@p> <4BDAC6E3.2010302@ni-po.com>
	<4BDAE4FF.6070507@mit.edu> <4BDB1CB7.4080704@ni-po.com>
	<4BDB8B9B.9000300@mit.edu> <4BDBEFBF.8020107@ni-po.com>
	<u2tdd0fbad1005011727t49c4fa2qb81b591d290c3ca8@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1005020633420.8532@ps20323.dreamhostps.com>

On Sat, 1 May 2010, Tab Atkins Jr. wrote:
> On Sat, May 1, 2010 at 2:09 AM, Nikita Popov <privat at ni-po.com> wrote:
> > I do not deny, that keygen has it's use cases (the "nobody" was hyperbolic).
> > I only think, that the use cases are *very* rare. It is overkill to
> > introduce an HTML element therefore. It would be much more sane to provide a
> > JS API (as Janos proposed.) [I would do it myself, but I have only very
> > little knowledge on encryption.]
> 
> We're getting off-topic here, but <keygen> wasn't created by HTML5. It's 
> an element that IE created, and which was used widely enough in certain 
> markets that some other browsers were forced to implement it as well.  
> HTML5 is simply including it because it's apparently important enough 
> for the web for multiple browsers to implement.  It does indeed suck as 
> a solution, but we don't get to rewrite history. ^_^

If we're not rewriting history, let's make that Netscape, not IE. :-)

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

From jackalmage at gmail.com  Sat May  1 23:41:59 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sat, 1 May 2010 23:41:59 -0700
Subject: [whatwg] Headings and sections, role of H2-H6
In-Reply-To: <Pine.LNX.4.64.1005020633420.8532@ps20323.dreamhostps.com>
References: <5A125DA3E79E424DBD735503F4D59039@p> <4BDAC6E3.2010302@ni-po.com> 
	<4BDAE4FF.6070507@mit.edu> <4BDB1CB7.4080704@ni-po.com>
	<4BDB8B9B.9000300@mit.edu> <4BDBEFBF.8020107@ni-po.com>
	<u2tdd0fbad1005011727t49c4fa2qb81b591d290c3ca8@mail.gmail.com> 
	<Pine.LNX.4.64.1005020633420.8532@ps20323.dreamhostps.com>
Message-ID: <g2ldd0fbad1005012341o44c4b5b4qe2db52f4f8b60169@mail.gmail.com>

On Sat, May 1, 2010 at 11:34 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 1 May 2010, Tab Atkins Jr. wrote:
>> On Sat, May 1, 2010 at 2:09 AM, Nikita Popov <privat at ni-po.com> wrote:
>> > I do not deny, that keygen has it's use cases (the "nobody" was hyperbolic).
>> > I only think, that the use cases are *very* rare. It is overkill to
>> > introduce an HTML element therefore. It would be much more sane to provide a
>> > JS API (as Janos proposed.) [I would do it myself, but I have only very
>> > little knowledge on encryption.]
>>
>> We're getting off-topic here, but <keygen> wasn't created by HTML5. It's
>> an element that IE created, and which was used widely enough in certain
>> markets that some other browsers were forced to implement it as well.
>> HTML5 is simply including it because it's apparently important enough
>> for the web for multiple browsers to implement. ?It does indeed suck as
>> a solution, but we don't get to rewrite history. ^_^
>
> If we're not rewriting history, let's make that Netscape, not IE. :-)

Yeah, I got corrected offlist.  I misremembered.  ^_^

~TJ

From timeless at gmail.com  Sun May  2 01:45:48 2010
From: timeless at gmail.com (timeless)
Date: Sun, 2 May 2010 11:45:48 +0300
Subject: [whatwg] Headings and sections, role of H2-H6
In-Reply-To: <u2tdd0fbad1005011727t49c4fa2qb81b591d290c3ca8@mail.gmail.com>
References: <5A125DA3E79E424DBD735503F4D59039@p> <4BDAC6E3.2010302@ni-po.com>
	<4BDAE4FF.6070507@mit.edu> <4BDB1CB7.4080704@ni-po.com>
	<4BDB8B9B.9000300@mit.edu> <4BDBEFBF.8020107@ni-po.com>
	<u2tdd0fbad1005011727t49c4fa2qb81b591d290c3ca8@mail.gmail.com>
Message-ID: <i2nbb9848a71005020145l3c390942s6f2f55ca7606c4bd@mail.gmail.com>

I should have posted onlist.

MS's crime here was in trying to document netscape's extension:

http://msdn.microsoft.com/en-us/library/cc249768(PROT.13).aspx

From herenvardo at gmail.com  Sun May  2 02:20:35 2010
From: herenvardo at gmail.com (Eduard Pascual)
Date: Sun, 2 May 2010 11:20:35 +0200
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com> 
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
Message-ID: <y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>

On Sun, May 2, 2010 at 5:55 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Sat, May 1, 2010 at 8:25 PM, ?<ryan14 at mail.com> wrote:
>> My suggestion for the HTML5 spec is that the video tag should have a feature
>> that can enable GPU acceleration on a user's graphics card, so it will take
>> some stress off the CPU.
>>
>> Do you like my suggestion?
>
> Nothing is stopping browsers from using the GPU to help speed up
> <video> playback right now, and in fact I think that some browsers are
> either already doing so, or are planning to do so in the relatively
> near future.

As a matter of fact, Microsoft already announced that IE9's rendering
engine would use GPU acceleration as much as possible (leveraging MS
Windows' DirectX technolgies) [1]. Some benchmarking of the platform
preview vs. IE8 show a more than welcome improve on performance [2].
Thus, it's not a matter of accelerating just <video>. UA vendors are
allowed to use any available technology, such as GPU processing, to
improve the user experience on all aspects; and IE9's approach will
benefit not only <video>, but everything that the browser renders (for
example, heavy JS-based animations may take huge profit from this).
I'm not a big fan of Microsoft's IE software, but I must concede that
the Redmond guys have taken a step on the right direction with this.
Especially having seen how IE8 was painfully slower than its older
siblings (IE6 and 7). I wouldn't be surprised if other browsers follow
suit.

Regards,
Eduard Pascual

[1] http://channel9.msdn.com/posts/Charles/IE-9-Surfing-on-the-GPU-with-D2D/
[2] http://blogs.msdn.com/johnmullinax/archive/2010/04/02/nvidia-shows-off-ie9-gpu-accleration.aspx

From smfr at me.com  Sun May  2 20:36:43 2010
From: smfr at me.com (Simon Fraser)
Date: Sun, 02 May 2010 20:36:43 -0700
Subject: [whatwg] suggestion for HTML5 spec
In-Reply-To: <y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
References: <8CCB7BE346CD122-C7C-1272E@web-mmc-m06.sysops.aol.com>
	<s2zdd0fbad1005012055v63bef54auc73f1b872ed66afc@mail.gmail.com>
	<y2v6ea53251005020220r1dd92ebcta21ac75465a28600@mail.gmail.com>
Message-ID: <3307F29B-B708-42B3-8280-ECFAE53B6FE8@me.com>

On May 2, 2010, at 2:20 am, Eduard Pascual wrote:

> On Sun, May 2, 2010 at 5:55 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> On Sat, May 1, 2010 at 8:25 PM,  <ryan14 at mail.com> wrote:
>>> My suggestion for the HTML5 spec is that the video tag should have a feature
>>> that can enable GPU acceleration on a user's graphics card, so it will take
>>> some stress off the CPU.
>>> 
>>> Do you like my suggestion?
>> 
>> Nothing is stopping browsers from using the GPU to help speed up
>> <video> playback right now, and in fact I think that some browsers are
>> either already doing so, or are planning to do so in the relatively
>> near future.
> 
> As a matter of fact, Microsoft already announced that IE9's rendering
> engine would use GPU acceleration as much as possible (leveraging MS
> Windows' DirectX technolgies) [1]. Some benchmarking of the platform
> preview vs. IE8 show a more than welcome improve on performance [2].
> Thus, it's not a matter of accelerating just <video>. UA vendors are
> allowed to use any available technology, such as GPU processing, to
> improve the user experience on all aspects; and IE9's approach will
> benefit not only <video>, but everything that the browser renders (for
> example, heavy JS-based animations may take huge profit from this).
> I'm not a big fan of Microsoft's IE software, but I must concede that
> the Redmond guys have taken a step on the right direction with this.
> Especially having seen how IE8 was painfully slower than its older
> siblings (IE6 and 7). I wouldn't be surprised if other browsers follow
> suit.

WebKit already has a "fast path" for video on Mac, and it's being worked
on for Windows.

The only reason I can think of why this should be exposed to web authors
is if a browser is unable to use GPU accelerated for video without side
effects (like always rendering on top of the rest of the content). Such an option would
be similar to the "wmode" param on plugins, which is a huge mess, and should
be avoided at all costs. One of the benefits of video being a real HTML element
is that it respects CSS properties like any other element.

Simon




From chuck at jumis.com  Sun May  2 21:58:26 2010
From: chuck at jumis.com (Charles Pritchard)
Date: Sun, 02 May 2010 21:58:26 -0700
Subject: [whatwg] The Rapidly Approaching Dawn of data uri
Message-ID: <4BDE57F2.6050001@jumis.com>

Hello All,

Though this is more of an implementers discussion, it certainly has a place
amongst developers (users).

I've come to see that data-uri embedded resources will grow as a practice.
They're just plain handy. More, the Canvas standard really expands their 
usage.

At present, it's quite difficult to get the binary code for a jpg image; 
you must
first draw it to a Canvas and export it as a png. XmlHttpRequest with binary
support makes this a little easier -- but you still must run a 
window.btoa call,
something generally unsupported and prone to failure.

The localStorage API allows us to save dynamic image resources in a web 
application,
when they're not included by the applicationCache manifest. Again, we 
see data-uri
images coming into use.

And this is where my implementers note becomes distressing:

Currently, we're all copying these large binary objects as base64 strings.
There's nothing wrong with base64, but why in the world do we have so many
unnecessary memory copies?

I don't expect that DOMDataUri will become a primitive, but I do suggest
a closer look at the state of things.

With an opaque object, one which does have a simple toString() matching
current data-uri/base64 features, we could cut down tremendously on memory
copies and memory/disk usage.

The Blob API is very much intended to solve some of these issues, but I 
really
think that we need an intermediate step, to solve these issues prior to 
2012.

DOMDataUri {
  string toString, // returns a encoded in the current StringFormat setting.
  bool noPrefix, // skip the data:mime/type,encoding prefix when 
returning toString.
  string mime,
  string encoding
}

Something along those lines will allow some easy optimizations to our
current data uri/base64 string handling. Mainly, we won't need so many
data copies. But, as well, it could provide an easy transition to Blob 
interfaces in the future.


-Charles

From mark.frohnmayer at gmail.com  Mon May  3 14:59:19 2010
From: mark.frohnmayer at gmail.com (Mark Frohnmayer)
Date: Mon, 3 May 2010 14:59:19 -0700
Subject: [whatwg] Real-time networking in web applications and games
In-Reply-To: <bd73083b1003221716n25052fdcu5815eea43385883e@mail.gmail.com>
References: <bd73083b1003221716n25052fdcu5815eea43385883e@mail.gmail.com>
Message-ID: <g2obd73083b1005031459w5c4f8978w54e7765a03575d8a@mail.gmail.com>

Hey all,

In continuation of the effort to make browsers a home for real-time
peer to peer applications and games without a plugin, I've done a bit
of digging on the spec.  Currently the spec contains section 4.11.6.2
(Peer-to-peer connections) that appears to present a high-level
peer-to-peer api with separate functionality for peer connection and
transmission of text, images and streamed data interleaved in some
unspecified protocol.  Also referenced from the spec is WebSocket, a
thin-layer protocol presenting what amounts to a simple guaranteed
packet stream between client and server.

For the purposes of discussion there seem to be two distinct issues -
peer introduction, where two clients establish a direct connection via
some trusted third party, and data transmission protocol which could
range from raw UDP to higher-level protocols like XML-RPC over HTTP.

For real-time games, specific concerns include flow control, protocol
overhead and retransmission policy; thus most real-time games
implement custom network protocols atop UDP.  Peer introduction is
also important - responsiveness can often be improved and hosting
bandwidth costs reduced by having peers connect directly.  For other
p2p apps (chat, etc), specific control of flow and data retransmission
may be less (or not) important, but peer introduction is still
relevant.

In reading of the current state of the spec's p2p section, it appears
to be poorly suiting to real-time gaming applications, as well as
potentially over-scoped for specific p2p applications.  To demonstrate
an alternative approach, the initial prototype of the TorqueSocket
plugin now works (build script for OS X only).  The API as spec'd
here: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt
now actually functions in the form of an NPAPI plugin.  I recorded a
capture of the javascript test program here:
http://www.youtube.com/watch?v=HijKc5AwYHM if you want to see it in
action without actually building the example.

This leads me to wonder about (1) the viability of including peer
introduction into WebSocket as an alternative to a high-level peer to
peer interface in the spec, (2) including a lower-level unreliable
protocol mode, either as part or distinct from WebSocket, and (3) who,
if anyone, is currently driving the p2p section of the spec.

Any feedback welcome :).

Cheers,
Mark

From julien.cayzac at gmail.com  Mon May  3 19:01:14 2010
From: julien.cayzac at gmail.com (Julien Cayzac)
Date: Tue, 4 May 2010 11:01:14 +0900
Subject: [whatwg] Do we really need to introduce a <device> element for
	giving access to webcams and mikes?
Message-ID: <r2k8ac6caaf1005031901l88661783vc258369ff250929@mail.gmail.com>

Hi,

I've been reading lately about the new proposed <device> element, and
was wondering if it was needed at all.
IMHO, a video originating from an attached camera is not different
from a video originating from the network, so <video> could be used
here.
Displaying the webcam in a page could be done like this:

<video autoplay controls>
    <source src="webcam:640,480,25" /> <!-- 640x480, 25fps -->
    <source src="webcam:320,240,*" /> <!-- will be tried if the webcam
doesn't support the above settings -->
    <source src="mire.mp4" /> <!-- no webcam attached? show this video
instead -->
</video>

Same could be done with <audio> for adding microphone support, and in
both cases the browser should notify the user the page is requesting
permission to access these devices.

Now, I am aware HTMLMediaElement doesn't offer any methods to actually
query the data it serves or to get notified as more incoming data gets
received, which makes my proposal useless. Still, such methods could
be used in other scenarios, like a browser-based video editing app, so
adding them would make sense in my opinion.

Thanks,
Julien.
--
Julien Cayzac
http://julien.cayzac.name/
skype://jcayzac?chat

From annevk at opera.com  Mon May  3 19:13:48 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 04 May 2010 11:13:48 +0900
Subject: [whatwg] Do we really need to introduce a <device> element for
 giving access to webcams and mikes?
In-Reply-To: <r2k8ac6caaf1005031901l88661783vc258369ff250929@mail.gmail.com>
References: <r2k8ac6caaf1005031901l88661783vc258369ff250929@mail.gmail.com>
Message-ID: <op.vb5shauk64w2qv@annevk-t60>

On Tue, 04 May 2010 11:01:14 +0900, Julien Cayzac  
<julien.cayzac at gmail.com> wrote:
> I've been reading lately about the new proposed <device> element, and
> was wondering if it was needed at all.
> IMHO, a video originating from an attached camera is not different
> from a video originating from the network, so <video> could be used
> here.
> Displaying the webcam in a page could be done like this:
>
> <video autoplay controls>
>     <source src="webcam:640,480,25" /> <!-- 640x480, 25fps -->
>     <source src="webcam:320,240,*" /> <!-- will be tried if the webcam
> doesn't support the above settings -->
>     <source src="mire.mp4" /> <!-- no webcam attached? show this video
> instead -->
> </video>
>
> Same could be done with <audio> for adding microphone support, and in
> both cases the browser should notify the user the page is requesting
> permission to access these devices.
>
> Now, I am aware HTMLMediaElement doesn't offer any methods to actually
> query the data it serves or to get notified as more incoming data gets
> received, which makes my proposal useless. Still, such methods could
> be used in other scenarios, like a browser-based video editing app, so
> adding them would make sense in my opinion.

What is the model for protecting user privacy here?

Large part of the motivation for something like the <device> element is  
that the user is actively involved in giving the website the ability to  
access the user's camera stream and use it. (E.g. manipulate it through  
<canvas> or transmit it over the wire using WebSocket.)


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

From julien.cayzac at gmail.com  Mon May  3 19:37:44 2010
From: julien.cayzac at gmail.com (Julien Cayzac)
Date: Tue, 4 May 2010 11:37:44 +0900
Subject: [whatwg] Do we really need to introduce a <device> element for
	giving access to webcams and mikes?
In-Reply-To: <op.vb5shauk64w2qv@annevk-t60>
References: <r2k8ac6caaf1005031901l88661783vc258369ff250929@mail.gmail.com> 
	<op.vb5shauk64w2qv@annevk-t60>
Message-ID: <s2g8ac6caaf1005031937l93b0e61fo2348f9213687a0f2@mail.gmail.com>

(forgot to do a Reply to all on this one. Sorry, Anne, for the duplicate)

On Tue, May 4, 2010 at 11:13 AM, Anne van Kesteren <annevk at opera.com> wrote:
> What is the model for protecting user privacy here?

It was in my message: "in both cases the browser should notify the
user the page is requesting permission to access these devices". The
same is done today with the geolocation feature, for instance. The
user has to give access permission to the page, in a browser-dependent
way.

> Large part of the motivation for something like the <device> element is that
> the user is actively involved in giving the website the ability to access
> the user's camera stream and use it. (E.g. manipulate it through <canvas> or
> transmit it over the wire using WebSocket.)

I am not sure if I get your point here: are you saying that using the
webcam locally in a canvas and somehow transmitting the webcam video
over the network are two independent permissions to grant? If so, how
would you detect the latter, since by allowing the page to manipulate
the video in <canvas> you would give it permission to use toDataURL()
too, so it could still transmit frames to the server or to other party
if a ConnectionPeer is involved?

Julien.
-- 
Julien Cayzac
http://julien.cayzac.name/
skype://jcayzac?chat

From julien.cayzac at gmail.com  Mon May  3 19:40:40 2010
From: julien.cayzac at gmail.com (Julien Cayzac)
Date: Tue, 4 May 2010 11:40:40 +0900
Subject: [whatwg] Do we really need to introduce a <device> element for
	giving access to webcams and mikes?
In-Reply-To: <s2g8ac6caaf1005031937l93b0e61fo2348f9213687a0f2@mail.gmail.com>
References: <r2k8ac6caaf1005031901l88661783vc258369ff250929@mail.gmail.com> 
	<op.vb5shauk64w2qv@annevk-t60>
	<s2g8ac6caaf1005031937l93b0e61fo2348f9213687a0f2@mail.gmail.com>
Message-ID: <k2i8ac6caaf1005031940w84e78340va7f17de607f18f86@mail.gmail.com>

On Tue, May 4, 2010 at 11:37 AM, Julien Cayzac <julien.cayzac at gmail.com> wrote:
> I am not sure if I get your point here: are you saying that using the
> webcam locally in a canvas and somehow transmitting the webcam video
> over the network are two independent permissions to grant? If so, how
> would you detect the latter, since by allowing the page to manipulate
> the video in <canvas> you would give it permission to use toDataURL()
> too, so it could still transmit frames to the server or to other party
> if a ConnectionPeer is involved?

To answer my own question: by raising the origin-clean flags of the
<canvas> element the webcam was "attached" to.

Now, I see no reference to any interaction between <device> and
<canvas> mentionned in http://dev.w3.org/html5/html-device/

Julien.
-- 
Julien Cayzac
http://julien.cayzac.name/
skype://jcayzac?chat

From eitanadlerlist at gmail.com  Tue May  4 00:08:26 2010
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Tue, 4 May 2010 10:08:26 +0300
Subject: [whatwg] RFC: <input type="username">
Message-ID: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>

Use cases:
1) A screen reader that sees a form with a type=username and a
password field. The screen reader could just ask "Log in to this site?
[y/n]?". No further context would be needed.
2) UAs can more easily discover login forms and offer things such as
Firefox's Account Manager [1] or a "remember me" feature
3) Currently autofill for usernames looks for something like
id="username" or name="username". However on certain websites this
fails. Furthermore some websites offer a "find other members" feature
where you could type in a username. I've often seen these fields
filled in automatically with my name.
4) I'm sure there are others....

The proposal:
A type="username" is added to the input element. type="username" would
MUST only be used for the name that is used to log in to the site. It
MUST NOT be used for registration forms or anything else that requires
a username. A form MAY have up to one (but not more) type="username"
input field.

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

From emoller at opera.com  Tue May  4 00:57:32 2010
From: emoller at opera.com (=?iso-8859-15?Q?Erik_M=F6ller?=)
Date: Tue, 04 May 2010 09:57:32 +0200
Subject: [whatwg] Real-time networking in web applications and games
In-Reply-To: <g2obd73083b1005031459w5c4f8978w54e7765a03575d8a@mail.gmail.com>
References: <bd73083b1003221716n25052fdcu5815eea43385883e@mail.gmail.com>
	<g2obd73083b1005031459w5c4f8978w54e7765a03575d8a@mail.gmail.com>
Message-ID: <op.vb58d6f4r4mipi@emoller-pc.gothenburg.osa>

On Mon, 03 May 2010 23:59:19 +0200, Mark Frohnmayer  
<mark.frohnmayer at gmail.com> wrote:

> Hey all,
>
> In continuation of the effort to make browsers a home for real-time
> peer to peer applications and games without a plugin, I've done a bit
> of digging on the spec.  Currently the spec contains section 4.11.6.2
> (Peer-to-peer connections) that appears to present a high-level
> peer-to-peer api with separate functionality for peer connection and
> transmission of text, images and streamed data interleaved in some
> unspecified protocol.  Also referenced from the spec is WebSocket, a
> thin-layer protocol presenting what amounts to a simple guaranteed
> packet stream between client and server.
>
> For the purposes of discussion there seem to be two distinct issues -
> peer introduction, where two clients establish a direct connection via
> some trusted third party, and data transmission protocol which could
> range from raw UDP to higher-level protocols like XML-RPC over HTTP.
>
> For real-time games, specific concerns include flow control, protocol
> overhead and retransmission policy; thus most real-time games
> implement custom network protocols atop UDP.  Peer introduction is
> also important - responsiveness can often be improved and hosting
> bandwidth costs reduced by having peers connect directly.  For other
> p2p apps (chat, etc), specific control of flow and data retransmission
> may be less (or not) important, but peer introduction is still
> relevant.
>
> In reading of the current state of the spec's p2p section, it appears
> to be poorly suiting to real-time gaming applications, as well as
> potentially over-scoped for specific p2p applications.  To demonstrate
> an alternative approach, the initial prototype of the TorqueSocket
> plugin now works (build script for OS X only).  The API as spec'd
> here:  
> http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt
> now actually functions in the form of an NPAPI plugin.  I recorded a
> capture of the javascript test program here:
> http://www.youtube.com/watch?v=HijKc5AwYHM if you want to see it in
> action without actually building the example.
>
> This leads me to wonder about (1) the viability of including peer
> introduction into WebSocket as an alternative to a high-level peer to
> peer interface in the spec, (2) including a lower-level unreliable
> protocol mode, either as part or distinct from WebSocket, and (3) who,
> if anyone, is currently driving the p2p section of the spec.
>
> Any feedback welcome :).
>
> Cheers,
> Mark
>

I'm an old gamedev recently turned browserdev so this is of particular  
interest to me, especially as I'm currently working on WebSockets.
WebSockets is a nice step towards multiplayer games in browsers and will  
be even better once binary frames are speced out but as Mark says  
(depending on the nature of the game) gamedevs are most likely going to  
want to make their own UDP based protocol (in client-server models as  
well). Has there been any discussions on how this would fit under  
WebSockets?

Opera Unite can be mentioned as an interesting side note, it does peer  
introduction as well as subnet peer detection, but again that's TCP only.

-- 
Erik M?ller
Core Developer
Opera Software

From timeless at gmail.com  Tue May  4 01:07:21 2010
From: timeless at gmail.com (timeless)
Date: Tue, 4 May 2010 11:07:21 +0300
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
Message-ID: <j2rbb9848a71005040107z845e6a13ze22454a8040582c1@mail.gmail.com>

On Tue, May 4, 2010 at 10:08 AM, Eitan Adler <eitanadlerlist at gmail.com> wrote:
> 3) Currently autofill for usernames looks for something like
> id="username" or name="username". However on certain websites this
> fails.

Why would a site which doesn't cooperate with today's autofill
features choose to cooperate with your proposal?

sites typically are either stupid or evil, and neither are likely to
embrace new standards.

From admin at subcide.com  Tue May  4 01:54:52 2010
From: admin at subcide.com (Steve Dennis)
Date: Tue, 4 May 2010 09:54:52 +0100
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <j2rbb9848a71005040107z845e6a13ze22454a8040582c1@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<j2rbb9848a71005040107z845e6a13ze22454a8040582c1@mail.gmail.com>
Message-ID: <DFB02B95-D222-4F21-8420-333C7FB8C404@subcide.com>


On 4/05/2010, at 9:07 AM, timeless wrote:

> On Tue, May 4, 2010 at 10:08 AM, Eitan Adler <eitanadlerlist at gmail.com> wrote:
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails.
> 
> Why would a site which doesn't cooperate with today's autofill
> features choose to cooperate with your proposal?
> 
> sites typically are either stupid or evil, and neither are likely to
> embrace new standards.

Because id="username" isn't a standard as such.  Having it specified in a spec is likely to help people adopt it more quickly.  Saying "why bother?" about all the broken sites on the web totally defeats the purpose of what everyone here's trying to achieve.

--
Steve Dennis
www.subcide.com

From simonp at opera.com  Tue May  4 02:44:15 2010
From: simonp at opera.com (Simon Pieters)
Date: Tue, 04 May 2010 11:44:15 +0200
Subject: [whatwg] WebSockets cookies
Message-ID: <op.vb6db1qtidj3kv@simon-pieterss-macbook.local>

establish a WebSocket connection:
[[
15. If the client has any cookies that would be relevant to a resource  
accessed over HTTP, if secure is false, or HTTPS, if it is true, on host  
host, port port, with resource name as the path (and possibly query  
parameters), then add to fields any HTTP headers that would be appropriate  
for that information. [HTTP] [COOKIES]
]]

Adding an HTTP header seems to allow HTTP syntax that is incompatible with  
WebSocket fields syntax. For instance, whitespace before the colon,  
horizontal tab instead of space after the colon, continuation lines,  
comments, escapes...

Also, does it say to add a single entry to fields with all headers or one  
entry per header?

-- 
Simon Pieters
Opera Software

From kornel at geekhood.net  Tue May  4 04:01:01 2010
From: kornel at geekhood.net (Kornel Lesinski)
Date: Tue, 4 May 2010 12:01:01 +0100
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <j2rbb9848a71005040107z845e6a13ze22454a8040582c1@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<j2rbb9848a71005040107z845e6a13ze22454a8040582c1@mail.gmail.com>
Message-ID: <A4112D63-2B99-4EB0-A02B-982D14FE0EBC@geekhood.net>

On 4 May 2010, at 09:07, timeless wrote:

> On Tue, May 4, 2010 at 10:08 AM, Eitan Adler <eitanadlerlist at gmail.com> wrote:
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails.
> 
> Why would a site which doesn't cooperate with today's autofill
> features choose to cooperate with your proposal?

Sites may not work correctly with autofill because their login forms are too complex or confusing the auto-fill feature (and sometimes login forms are complex/unusual ? users may have option to log in to different sections of the site, with different security options).

I don't think type=username is good solution, but I agree that autofill needs help. Sites often use e-mail address as login. There would be conflict between type=email and type=username.

I have wiki that has password field on edit page (you don't log in before starting an edit, you simply type password before submitting the change). It completely confuses Opera's autofill which tries to save page title field as login name.

Perhaps new values for autocomplete attribute would do the trick? autocomplete=login, autocomplete=not-login? (latter meaning you can autocomplete, but don't autofill when logging in).

It would be nice to have autodiscovery for OpenID logins: <input type=url autocomplete=login>? autocomplete=openid?

Another problem is the same login form appearing in multiple places on the site (usually slighly different form is part of site's layout, and different one is presented when user is forced to log in). Sometimes autofill sees such forms as same, and sometimes it doesn't. Auto-fill information is often lost when sites are redesigned.

It would be nice if autofill could remember values from registration form and automatically use them for logging in. Users usually aren't asked to log in after registering, so there's no opportunity for the browser to save login details immediately.

For this something like "Realm" value in HTTP auth would be helpful (perhaps as an attribute on <form> or <input>). Same realm across different forms would allow browser to save same details for all of them.

-- 
regards, Kornel


From julian.reschke at gmx.de  Tue May  4 05:25:29 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 04 May 2010 14:25:29 +0200
Subject: [whatwg] Ping + Ping-prefix meta element.
In-Reply-To: <4BD5F4F4.2070809@emsai.net>
References: <4BD5F4F4.2070809@emsai.net>
Message-ID: <4BE01239.40503@gmx.de>

On 26.04.2010 22:17, Roger H?gensen wrote:
> ...
> Oh, and could someone on the HTML5 list poke some of the guys over there
> and
> see if a ping attribute for the body tag in a similar vein could be
> considered?
> ...

If by "HTML5 list" you happen to mean the mailing list of the W3C HTML 
WG...: the WG decided to remove the ping attribute earlier this year; 
it's gone from the W3C spec draft.

Best regards, Julian

From julian.reschke at gmx.de  Tue May  4 07:16:58 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 04 May 2010 16:16:58 +0200
Subject: [whatwg] why double downloading of ogg videos ?
In-Reply-To: <s2n11e306601004170036uc225f711i9a157782b952ab37@mail.gmail.com>
References: <o2ie3fb97f31004161348q7bc762c5k5b33ee2bd7a619e8@mail.gmail.com>	<8D048BE7-B7BB-4572-BA58-3B5A6BD64A2C@jrn.me.uk>	<u2re3fb97f31004161358lcf50955ev141625ae1eb0e39e@mail.gmail.com>
	<s2n11e306601004170036uc225f711i9a157782b952ab37@mail.gmail.com>
Message-ID: <4BE02C5A.20303@gmx.de>

On 17.04.2010 09:36, Robert O'Callahan wrote:
> This is an implementation issue rather than a spec issue. It's basically
> just because of the way the Firefox network cache works. When we play an
> Ogg video we generally don't download the data in a single continuous
> HTTP GET; if the server supports byte Range requests, we actually seek
> to various places in the stream at different times to fetch metadata
> etc. So the network cache never sees a request that returns the complete
> resource, and never caches it. We do have a special "media cache" that's
> good at caching fetched media data, but "Save As" doesn't know about the
> media cache. We could fix that, but it would be somewhat complex and to
> be honest it's probably not worth it.
 > ...

Rob,

related question: do you do the partial GET only for getting access to 
metadata, or are you also using it for seeking in the video? (As opposed 
to downloading it once into the media cache, and then use that content 
throughout?)

Best regards, Julian

From julian.reschke at gmx.de  Tue May  4 07:31:36 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 04 May 2010 16:31:36 +0200
Subject: [whatwg] why double downloading of ogg videos ?
In-Reply-To: <4BE02C5A.20303@gmx.de>
References: <o2ie3fb97f31004161348q7bc762c5k5b33ee2bd7a619e8@mail.gmail.com>	<8D048BE7-B7BB-4572-BA58-3B5A6BD64A2C@jrn.me.uk>	<u2re3fb97f31004161358lcf50955ev141625ae1eb0e39e@mail.gmail.com>
	<s2n11e306601004170036uc225f711i9a157782b952ab37@mail.gmail.com>
	<4BE02C5A.20303@gmx.de>
Message-ID: <4BE02FC8.9020707@gmx.de>

On 04.05.2010 16:16, Julian Reschke wrote:
> Rob,
>
> related question: do you do the partial GET only for getting access to
> metadata, or are you also using it for seeking in the video? (As opposed
> to downloading it once into the media cache, and then use that content
> throughout?)
>
> Best regards, Julian

I just managed to test with a larger, non-local OGV file, and Mozilla 
indeed seems to use partial GETs when seeking/skipping. Great.

Short question: is it intentional that the partial GETs do not use an 
If-Match: request header?

Best regards, Julian

From dzung.d.tran at intel.com  Tue May  4 08:58:57 2010
From: dzung.d.tran at intel.com (Tran, Dzung D)
Date: Tue, 4 May 2010 08:58:57 -0700
Subject: [whatwg] Do we really need to introduce a <device> element
	for	giving access to webcams and mikes?
In-Reply-To: <k2i8ac6caaf1005031940w84e78340va7f17de607f18f86@mail.gmail.com>
References: <r2k8ac6caaf1005031901l88661783vc258369ff250929@mail.gmail.com>
	<op.vb5shauk64w2qv@annevk-t60>
	<s2g8ac6caaf1005031937l93b0e61fo2348f9213687a0f2@mail.gmail.com>
	<k2i8ac6caaf1005031940w84e78340va7f17de607f18f86@mail.gmail.com>
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D32551A0B5DD@orsmsx501.amr.corp.intel.com>

The <device> was added by Ian Hickson in response to some of the work in the W3C DAP working group. The original intent was to make sure the user are actively grant permission to a particular device camera or microphone instead of just click okay since some malicious site can just capture and post it on the internet.

Here is a reference to the work in W3C DAP: http://dev.w3.org/2009/dap/camera/Overview.html

Some threads on the topic: 
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0248.html

http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0194.html


Thanks
Dzung Tran,

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Julien Cayzac
Sent: Monday, May 03, 2010 07:41 PM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Do we really need to introduce a <device> element for giving access to webcams and mikes?

On Tue, May 4, 2010 at 11:37 AM, Julien Cayzac <julien.cayzac at gmail.com> wrote:
> I am not sure if I get your point here: are you saying that using the
> webcam locally in a canvas and somehow transmitting the webcam video
> over the network are two independent permissions to grant? If so, how
> would you detect the latter, since by allowing the page to manipulate
> the video in <canvas> you would give it permission to use toDataURL()
> too, so it could still transmit frames to the server or to other party
> if a ConnectionPeer is involved?

To answer my own question: by raising the origin-clean flags of the
<canvas> element the webcam was "attached" to.

Now, I see no reference to any interaction between <device> and
<canvas> mentionned in http://dev.w3.org/html5/html-device/

Julien.
-- 
Julien Cayzac
http://julien.cayzac.name/
skype://jcayzac?chat

From eitanadlerlist at gmail.com  Tue May  4 12:30:44 2010
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Tue, 4 May 2010 22:30:44 +0300
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <A4112D63-2B99-4EB0-A02B-982D14FE0EBC@geekhood.net>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com> 
	<j2rbb9848a71005040107z845e6a13ze22454a8040582c1@mail.gmail.com> 
	<A4112D63-2B99-4EB0-A02B-982D14FE0EBC@geekhood.net>
Message-ID: <x2na0777e081005041230i15270e02p9be4ebe2b5c232c4@mail.gmail.com>

> I don't think type=username is good solution, but I agree that autofill needs help. Sites often use e-mail address as login. There would be conflict between type=email and type=username.

I could imagine one two solutions here. 1) Change type="username" to
role="username" which makes more sense anyway (a username field is
actually a text field)
2) Allow multiple types per input field. This IMHO is a bad idea.

> Another problem is the same login form appearing in multiple places on the site (usually slighly different form is part of site's layout, and different one is presented when user is forced to log in). Sometimes autofill sees such forms as same, and sometimes it doesn't. Auto-fill information is often lost when sites are redesigned.

The goal of type="username" is to indicate to the UA which form is the
login form. This would allow features such as "remember me" and
autofill to be done in the UA instead of in the browser.

> It would be nice if autofill could remember values from registration form and automatically use them for logging in. Users usually aren't asked to log in after registering, so there's no opportunity for the browser to save login details immediately.

Firefox is fairly good about this - asking me to remember passwords
from registrations forms.

The goal of my type="username" proposal was to provide some indication
to the UA that a particular form is a login form. Another idea is to
allow forms to have roles.
<form ... role="[register|login|search]">
would be a decent alternative to <input type="username">

There are two major places I could see this improving things. One was
already mentioned: autofill. The second is screen readers. Instead of
having to read out the entire form the UA could just ask "Register for
this site?" or "Log in now?".

-- 
Eitan Adler

From dpranke at chromium.org  Tue May  4 13:53:23 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Tue, 4 May 2010 13:53:23 -0700
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
Message-ID: <t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>

On Tue, May 4, 2010 at 12:08 AM, Eitan Adler <eitanadlerlist at gmail.com> wrote:
> Use cases:
> 1) A screen reader that sees a form with a type=username and a
> password field. The screen reader could just ask "Log in to this site?
> [y/n]?". No further context would be needed.
> 2) UAs can more easily discover login forms and offer things such as
> Firefox's Account Manager [1] or a "remember me" feature
> 3) Currently autofill for usernames looks for something like
> id="username" or name="username". However on certain websites this
> fails. Furthermore some websites offer a "find other members" feature
> where you could type in a username. I've often seen these fields
> filled in automatically with my name.
> 4) I'm sure there are others....
>
> The proposal:
> A type="username" is added to the input element. type="username" would
> MUST only be used for the name that is used to log in to the site. It
> MUST NOT be used for registration forms or anything else that requires
> a username. A form MAY have up to one (but not more) type="username"
> input field.
>
> [1] http://www.mozilla.com/en-US/firefox/accountmanager/
>

I think this idea is halfway to what I'd want to see. Namely, we
should add an <input type="login"> field that triggers a
powerbox/dialog (much like the <input type="file"> dialog) that can
collect whatever sort of credentials are needed (username / password,
two-factor auth, FB connect credentials, OpenID/OAuth credentials,
etc.). I agree that it should probably build on top of the Account
Manager spec.

I think the whole login process needs to be taken as out of page as
possible. Unfortunately, the auto-login mechanism in Mozilla's
prototype is probably too out of page, and so there should be a way to
trigger the login from an in-page element (hence the above).

-- Dirk

From jonas at sicking.cc  Tue May  4 14:02:38 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 4 May 2010 14:02:38 -0700
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com> 
	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>
Message-ID: <z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>

On Tue, May 4, 2010 at 1:53 PM, Dirk Pranke <dpranke at chromium.org> wrote:
> On Tue, May 4, 2010 at 12:08 AM, Eitan Adler <eitanadlerlist at gmail.com> wrote:
>> Use cases:
>> 1) A screen reader that sees a form with a type=username and a
>> password field. The screen reader could just ask "Log in to this site?
>> [y/n]?". No further context would be needed.
>> 2) UAs can more easily discover login forms and offer things such as
>> Firefox's Account Manager [1] or a "remember me" feature
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails. Furthermore some websites offer a "find other members" feature
>> where you could type in a username. I've often seen these fields
>> filled in automatically with my name.
>> 4) I'm sure there are others....
>>
>> The proposal:
>> A type="username" is added to the input element. type="username" would
>> MUST only be used for the name that is used to log in to the site. It
>> MUST NOT be used for registration forms or anything else that requires
>> a username. A form MAY have up to one (but not more) type="username"
>> input field.
>>
>> [1] http://www.mozilla.com/en-US/firefox/accountmanager/
>>
>
> I think this idea is halfway to what I'd want to see. Namely, we
> should add an <input type="login"> field that triggers a
> powerbox/dialog (much like the <input type="file"> dialog) that can
> collect whatever sort of credentials are needed (username / password,
> two-factor auth, FB connect credentials, OpenID/OAuth credentials,
> etc.). I agree that it should probably build on top of the Account
> Manager spec.
>
> I think the whole login process needs to be taken as out of page as
> possible. Unfortunately, the auto-login mechanism in Mozilla's
> prototype is probably too out of page, and so there should be a way to
> trigger the login from an in-page element (hence the above).

For what it's worth, I'm not terribly interested in adding more to the
patchwork that is the online login experience that is today. I'm much
more interested in something like this:

http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/

/ Jonas

From robert at ocallahan.org  Tue May  4 14:20:06 2010
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 5 May 2010 09:20:06 +1200
Subject: [whatwg] why double downloading of ogg videos ?
In-Reply-To: <4BE02FC8.9020707@gmx.de>
References: <o2ie3fb97f31004161348q7bc762c5k5b33ee2bd7a619e8@mail.gmail.com>
	<8D048BE7-B7BB-4572-BA58-3B5A6BD64A2C@jrn.me.uk>
	<u2re3fb97f31004161358lcf50955ev141625ae1eb0e39e@mail.gmail.com>
	<s2n11e306601004170036uc225f711i9a157782b952ab37@mail.gmail.com>
	<4BE02C5A.20303@gmx.de> <4BE02FC8.9020707@gmx.de>
Message-ID: <h2v11e306601005041420hb9fd5042md6b826a7ba8d7df1@mail.gmail.com>

On Wed, May 5, 2010 at 2:31 AM, Julian Reschke <julian.reschke at gmx.de>wrote:

> Short question: is it intentional that the partial GETs do not use an
> If-Match: request header?
>

No. I suppose we should, but honestly it's never come up.

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

From ian at hixie.ch  Tue May  4 15:00:33 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 4 May 2010 22:00:33 +0000 (UTC)
Subject: [whatwg] Ping + Ping-prefix meta element.
In-Reply-To: <4BE01239.40503@gmx.de>
References: <4BD5F4F4.2070809@emsai.net> <4BE01239.40503@gmx.de>
Message-ID: <Pine.LNX.4.64.1005042159060.8532@ps20323.dreamhostps.com>

On Tue, 4 May 2010, Julian Reschke wrote:
> On 26.04.2010 22:17, Roger H?gensen wrote:
> > ...
> > Oh, and could someone on the HTML5 list poke some of the guys over there
> > and
> > see if a ping attribute for the body tag in a similar vein could be
> > considered?
> > ...
> 
> If by "HTML5 list" you happen to mean the mailing list of the W3C HTML 
> WG...: the WG decided to remove the ping attribute earlier this year; 
> it's gone from the W3C spec draft.

It's still in the WHATWG draft, however.

Roger: Your input has been added to the list of proposals to consider. 
There's no ETA on how long that will take, sometimes it takes me many 
months to get to each last piece of feedback.

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

From dpranke at chromium.org  Tue May  4 18:27:18 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Tue, 4 May 2010 18:27:18 -0700
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>
	<z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>
Message-ID: <t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>

On Tue, May 4, 2010 at 2:02 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Tue, May 4, 2010 at 1:53 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>> On Tue, May 4, 2010 at 12:08 AM, Eitan Adler <eitanadlerlist at gmail.com> wrote:
>>> Use cases:
>>> 1) A screen reader that sees a form with a type=username and a
>>> password field. The screen reader could just ask "Log in to this site?
>>> [y/n]?". No further context would be needed.
>>> 2) UAs can more easily discover login forms and offer things such as
>>> Firefox's Account Manager [1] or a "remember me" feature
>>> 3) Currently autofill for usernames looks for something like
>>> id="username" or name="username". However on certain websites this
>>> fails. Furthermore some websites offer a "find other members" feature
>>> where you could type in a username. I've often seen these fields
>>> filled in automatically with my name.
>>> 4) I'm sure there are others....
>>>
>>> The proposal:
>>> A type="username" is added to the input element. type="username" would
>>> MUST only be used for the name that is used to log in to the site. It
>>> MUST NOT be used for registration forms or anything else that requires
>>> a username. A form MAY have up to one (but not more) type="username"
>>> input field.
>>>
>>> [1] http://www.mozilla.com/en-US/firefox/accountmanager/
>>>
>>
>> I think this idea is halfway to what I'd want to see. Namely, we
>> should add an <input type="login"> field that triggers a
>> powerbox/dialog (much like the <input type="file"> dialog) that can
>> collect whatever sort of credentials are needed (username / password,
>> two-factor auth, FB connect credentials, OpenID/OAuth credentials,
>> etc.). I agree that it should probably build on top of the Account
>> Manager spec.
>>
>> I think the whole login process needs to be taken as out of page as
>> possible. Unfortunately, the auto-login mechanism in Mozilla's
>> prototype is probably too out of page, and so there should be a way to
>> trigger the login from an in-page element (hence the above).
>
> For what it's worth, I'm not terribly interested in adding more to the
> patchwork that is the online login experience that is today. I'm much
> more interested in something like this:
>
> http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/
>

I did note that my proposal should build on top of the account manager
protocol referred to by that link.

The principal difference or change is that as far as I know, Mozilla's
account manager offers only an out-of-page experience for managing
your logged-in status. It remains to be seen how successful this would
be (will users even notice something that is only in the browser
chrome? Do they have to learn what the login mechanism is on every
different type of browser they use?, etc. Are site owners going to be
willing to give up that much control over the sign-in/sign-out
experience?). I am suggesting an in-page option that supplements
(complements?) the in-chrome, so that site owners that want to can
continue to promote sign-in/sign-out through in-page elements can do
so in a way that uses the same infrastructure and provides a more
secure and coherent experience across sites at the same time.

-- Dirk

From pedzsan at gmail.com  Tue May  4 19:06:03 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Tue, 4 May 2010 21:06:03 -0500
Subject: [whatwg] onshow event
Message-ID: <DF0B3926-9224-4742-9472-216CE66E96AE@gmail.com>

I see in the html5 spec an 'onshow' event but no text describing when the 'show' event is triggered.

I've poked at FF 3.5 and Opera and can not get it to fire.  But I may be completely confused on when it should fire.

It would be wonderful if an element had an event that would fire when that particular element is shown on the page.  This might be due to the display attribute changing or it might be due to it scrolling into view.  "onshow" appeared to be the closest match to this.

The case I'm trying to do is write a dodad which needs to be initialized but if I call the initialization method while it is hidden, the height and width come back 0 and the code doesn't work.  I could add a hook into the parent to call the init when the parent decides to show the element but it would be nicer if I didn't have to do that.  It would be nice if the element "knew" it was time to initialize itself based upon it being shown on the page.

Also, I can't temporarily change the elements display attribute because its display is not the one that is hiding it.  It is actually hidden (initially) but two of its parents.

It seems like this would be a fairly frequent desire.  Perhaps there is already an idiom for this.

Thank you,
Perry


From robert at ocallahan.org  Tue May  4 19:40:15 2010
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 5 May 2010 14:40:15 +1200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>
	<z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>
	<t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>
Message-ID: <h2v11e306601005041940o6cb93497w5b93d1b38e669243@mail.gmail.com>

On Wed, May 5, 2010 at 1:27 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> The principal difference or change is that as far as I know, Mozilla's
> account manager offers only an out-of-page experience for managing
> your logged-in status.


I don't think this is true. Sites can report user login status even if the
user logged in using in-page UI. See
https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest#Determining_the_Account_Session_Status

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

From dpranke at chromium.org  Tue May  4 19:56:13 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Tue, 4 May 2010 19:56:13 -0700
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <h2v11e306601005041940o6cb93497w5b93d1b38e669243@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>
	<z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>
	<t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>
	<h2v11e306601005041940o6cb93497w5b93d1b38e669243@mail.gmail.com>
Message-ID: <r2u3726d1bf1005041956k6773f927ld18c27a95360d870@mail.gmail.com>

On Tue, May 4, 2010 at 7:40 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Wed, May 5, 2010 at 1:27 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>>
>> The principal difference or change is that as far as I know, Mozilla's
>> account manager offers only an out-of-page experience for managing
>> your logged-in status.
>
> I don't think this is true. Sites can report user login status even if the
> user logged in using in-page UI. See
> https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest#Determining_the_Account_Session_Status
>

I'm sorry, I was unclear. What I meant was, as far as I know, the
Mozilla Account Manager extension offers a consistent UI for logging
in and logging out through the chrome of the page (i.e., out-of-page)
-- I haven't actually tried the extension lately. In addtiion, you can
presumably continue to do in-page login and logout (and display
status) using whatever existing mechanism you have, but that will
continue to be the same inconsistent UI we have today - every page can
do it a little differently.

I believe that site authors would like to control the look and feel of
the sign-in/sign-out process and offer some sort of in-page way of
displaying login status, but there is an obvious tradeoff between
control over the UX and creating security risks. They can continue to
use the mechanisms they are using today, of course, but that presents
the same sort of security issues we have today. What I would like to
offer is a way to control some amount of the sign-in/sign-out
experience while improving the security, by at least giving an in-page
way to trigger sign-in / sign-out (the actual mechanism of collecting
the credentials and performing the sign-in would be done by the
browser without page intervention, where possible, for security
reasons).

The Account Manager spec and extensions do not provide any such hooks,
as far as I know.

-- Dirk

From bzbarsky at MIT.EDU  Tue May  4 20:21:17 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 04 May 2010 23:21:17 -0400
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <r2u3726d1bf1005041956k6773f927ld18c27a95360d870@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>	<z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>	<t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>	<h2v11e306601005041940o6cb93497w5b93d1b38e669243@mail.gmail.com>
	<r2u3726d1bf1005041956k6773f927ld18c27a95360d870@mail.gmail.com>
Message-ID: <4BE0E42D.5080905@mit.edu>

On 5/4/10 10:56 PM, Dirk Pranke wrote:
> What I would like to offer is a way to control some amount of the sign-in/sign-out
> experience while improving the security, by at least giving an in-page
> way to trigger sign-in / sign-out (the actual mechanism of collecting
> the credentials and performing the sign-in would be done by the
> browser without page intervention, where possible, for security
> reasons).

So this would be something pages opt into?

If not, how would the following sign-in workflows (taken from two 
banking sites I've dealt with recently) work:

Workflow 1:

1)  Site prompts user for only a username.
2)  After user enters a username, site responds with a "Hello,
     __firstname__" (with either the first name corresponding to the
     username filled in or a random one generated if there's no such
     account) and two security questions.
3)  After the user correctly answers the two security questions, he is
     presented with a previously-agreed-on image and phrase (to convince
     the user that the bank is in fact the bank) and 9 clickable buttons
     numbered 0-9.
4a) If the user has a mouse, the user clicks the buttons in the right
     order to enter their PIN (I believe a 7-digit or more number).
     Else go to 4b.
4b) If the user cannot use the mouse for some reason, the user can
     follow a link which associates each of the 10 buttons with one
     of a randomly chosen (each time you hit this screen, as far as
     I can see) set of 10 letters.  The user can then type the
     letters that correspond to the desired numbers.

Workflow 2:

1)  Site prompts user for only a username.
2)  After user enters a username, site responds with a page that has a
     password field and a bunch of buttons in the general shape of a
     qwerty keyboard.
3)  The user enters a password in the password field.
4)  The user also enters a different password (the site enforces
     that they're different during account setup) by clicking the
     correct buttons on the "virtual keyboard".

Various other banking sites I've dealt with have the 
"previously-agree-on image and phrase" thing going on, but these two are 
the ones that are creative with password input.  In particular, the goal 
seems to be to defeat keyloggers by making replay of logged keystrokes 
be insufficient to log into the site.

-Boris

From ian at hixie.ch  Tue May  4 21:47:13 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 May 2010 04:47:13 +0000 (UTC)
Subject: [whatwg] onshow event
In-Reply-To: <DF0B3926-9224-4742-9472-216CE66E96AE@gmail.com>
References: <DF0B3926-9224-4742-9472-216CE66E96AE@gmail.com>
Message-ID: <Pine.LNX.4.64.1005050445430.8532@ps20323.dreamhostps.com>

On Tue, 4 May 2010, Perry Smith wrote:
>
> I see in the html5 spec an 'onshow' event but no text describing when 
> the 'show' event is triggered.

It's part of the context menu mechanism:

http://www.whatwg.org/specs/web-apps/current-work/complete.html#context-menus


> It would be wonderful if an element had an event that would fire when 
> that particular element is shown on the page.  This might be due to the 
> display attribute changing or it might be due to it scrolling into view.  

That's more of a presentation issue; I recommend raising this in the 
context of CSSOM. Anne, is there a bug database or issues list for CSSOM 
where things like this can be logged?

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

From dpranke at chromium.org  Tue May  4 23:20:09 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Tue, 4 May 2010 23:20:09 -0700
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <4BE0E42D.5080905@mit.edu>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>
	<z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>
	<t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>
	<h2v11e306601005041940o6cb93497w5b93d1b38e669243@mail.gmail.com>
	<r2u3726d1bf1005041956k6773f927ld18c27a95360d870@mail.gmail.com>
	<4BE0E42D.5080905@mit.edu>
Message-ID: <h2j3726d1bf1005042320s814497fuf4e163c5624b6bb0@mail.gmail.com>

On Tue, May 4, 2010 at 8:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/4/10 10:56 PM, Dirk Pranke wrote:
>>
>> What I would like to offer is a way to control some amount of the
>> sign-in/sign-out
>> experience while improving the security, by at least giving an in-page
>> way to trigger sign-in / sign-out (the actual mechanism of collecting
>> the credentials and performing the sign-in would be done by the
>> browser without page intervention, where possible, for security
>> reasons).
>
> So this would be something pages opt into?
>

Yes. I also imagine people submitting user scripts that could rewrite
existing login forms into forms using the new tags.

> If not, how would the following sign-in workflows (taken from two banking
> sites I've dealt with recently) work:
>
> Workflow 1:
>
> 1) ?Site prompts user for only a username.
> 2) ?After user enters a username, site responds with a "Hello,
> ? ?__firstname__" (with either the first name corresponding to the
> ? ?username filled in or a random one generated if there's no such
> ? ?account) and two security questions.
> 3) ?After the user correctly answers the two security questions, he is
> ? ?presented with a previously-agreed-on image and phrase (to convince
> ? ?the user that the bank is in fact the bank) and 9 clickable buttons
> ? ?numbered 0-9.
> 4a) If the user has a mouse, the user clicks the buttons in the right
> ? ?order to enter their PIN (I believe a 7-digit or more number).
> ? ?Else go to 4b.
> 4b) If the user cannot use the mouse for some reason, the user can
> ? ?follow a link which associates each of the 10 buttons with one
> ? ?of a randomly chosen (each time you hit this screen, as far as
> ? ?I can see) set of 10 letters. ?The user can then type the
> ? ?letters that correspond to the desired numbers.
>
> Workflow 2:
>
> 1) ?Site prompts user for only a username.
> 2) ?After user enters a username, site responds with a page that has a
> ? ?password field and a bunch of buttons in the general shape of a
> ? ?qwerty keyboard.
> 3) ?The user enters a password in the password field.
> 4) ?The user also enters a different password (the site enforces
> ? ?that they're different during account setup) by clicking the
> ? ?correct buttons on the "virtual keyboard".
>
> Various other banking sites I've dealt with have the "previously-agree-on
> image and phrase" thing going on, but these two are the ones that are
> creative with password input. ?In particular, the goal seems to be to defeat
> keyloggers by making replay of logged keystrokes be insufficient to log into
> the site.

There is no question that people have dreamt up a large variety of
mechanisms for logging into web sites. It would be difficult to
support all of them out of the box, and certainly we would need to
eventually extend the specs that Mozilla has defined to talk about how
to support two-factor auth and other schemes like the ones you
describe, if we can't figure out how to move them to more secure
mechanisms. In particular, allowing a safe login from a compromised
machine is, to say the least, somewhat challenging :(

Both the Mozilla Account Manager and the scheme I'm talking about --
which again, builds on top of the account manager -- at least have the
advantages that (a) they take the actual typing in of the password out
of page and (b) they make the job of password managers far more
reliable. Those alone should deliver enough benefit to make these
ideas interesting, in my opinion.

-- Dirk

From julien.cayzac at gmail.com  Tue May  4 23:44:17 2010
From: julien.cayzac at gmail.com (Julien Cayzac)
Date: Wed, 5 May 2010 15:44:17 +0900
Subject: [whatwg] aspect-ratio CSS rule?
Message-ID: <z2m8ac6caaf1005042344wacb91588p6449075783193604@mail.gmail.com>

It would be very sweet if you could actually enforce an element's
aspect ratio using CSS, so you wouldn't have to rely on hacks in the
line of http://lab.veille.jp/aspectratio/ anymore.

This is especially useful when designing elastic interfaces that display videos.
Example: Right column at http://www.veille.jp/

Julien
--
Julien Cayzac
http://julien.cayzac.name/
skype://jcayzac?chat

From ian at hixie.ch  Wed May  5 00:26:24 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 May 2010 07:26:24 +0000 (UTC)
Subject: [whatwg] aspect-ratio CSS rule?
In-Reply-To: <z2m8ac6caaf1005042344wacb91588p6449075783193604@mail.gmail.com>
References: <z2m8ac6caaf1005042344wacb91588p6449075783193604@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1005050725300.8532@ps20323.dreamhostps.com>

On Wed, 5 May 2010, Julien Cayzac wrote:
>
> It would be very sweet if you could actually enforce an element's aspect 
> ratio using CSS, so you wouldn't have to rely on hacks in the line of 
> http://lab.veille.jp/aspectratio/ anymore.
> 
> This is especially useful when designing elastic interfaces that display 
> videos. Example: Right column at http://www.veille.jp/

I recommend bringing this up with the CSS working group at 
www-style at w3.org. At this time, the WHATWG is only working on HTML.

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

From chuck at jumis.com  Wed May  5 04:58:51 2010
From: chuck at jumis.com (Charles Pritchard)
Date: Wed, 05 May 2010 04:58:51 -0700
Subject: [whatwg] Input URL State and Files object
Message-ID: <4BE15D7B.7060009@jumis.com>

Hi all,

Awhile ago, it appears, the "files" object was removed from <input 
type="url">

Is there currently a method for allowing cross-domain access to
an image based on user input? At present, it seems a user must first 
download an
image to their desktop, then drag the image into an HTML 5 host.

Is this something that's intended to be handled in the future via 
event.dataTransfer?


-Charles

From eitanadlerlist at gmail.com  Wed May  5 06:58:26 2010
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Wed, 5 May 2010 16:58:26 +0300
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <4BE0E42D.5080905@mit.edu>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com> 
	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com> 
	<z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com> 
	<t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com> 
	<h2v11e306601005041940o6cb93497w5b93d1b38e669243@mail.gmail.com> 
	<r2u3726d1bf1005041956k6773f927ld18c27a95360d870@mail.gmail.com> 
	<4BE0E42D.5080905@mit.edu>
Message-ID: <AANLkTimuGwbaJ2lzHddsMVH91aEbyCwtYeUjr2dR7C0H@mail.gmail.com>

> So this would be something pages opt into?

This is how it is currently done with the account manager. Each site
needs to have a metadata file to tell AM that it is possible to log
into this site.

>
> If not, how would the following sign-in workflows (taken from two banking
> sites I've dealt with recently) work:

These are special cases to which the user brower would "opt out" of
using the browser by not using <input type="login">

From Yael.Aharon at nokia.com  Wed May  5 11:32:04 2010
From: Yael.Aharon at nokia.com (Yael.Aharon at nokia.com)
Date: Wed, 5 May 2010 20:32:04 +0200
Subject: [whatwg] Questions about meter element
Message-ID: <B9B55EB1B426EA479A5B5EE9B292A675531CB05411@NOK-EUMSG-05.mgdnok.nokia.com>

Hi all,
I have a couple of questions regarding the meter element.

1. I could not find the meter element in the tables in http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria. What is the ARIA role for the meter element?

2. From UA requirements for showing the gauge: When representing a meter element to the user, the UA should indicate the relative position of the actual value to the minimum and maximum values, and the relationship between the actual value and the three regions of the gauge.
Considering that the default size of this element is 5em width and 1em height, how should the 3 regions be represented by the UA?

thanks, Yael

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

From ian at hixie.ch  Wed May  5 12:42:50 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 May 2010 19:42:50 +0000 (UTC)
Subject: [whatwg] Input URL State and Files object
In-Reply-To: <4BE15D7B.7060009@jumis.com>
References: <4BE15D7B.7060009@jumis.com>
Message-ID: <Pine.LNX.4.64.1005051942080.8532@ps20323.dreamhostps.com>

On Wed, 5 May 2010, Charles Pritchard wrote:
> 
> Awhile ago, it appears, the "files" object was removed from <input 
> type="url">

"files" doesn't really make much sense for type=url... Do you mean 
type=file?


> Is there currently a method for allowing cross-domain access to an image 
> based on user input?

XMLHttpRequest is the intended way to do this.

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

From chuck at jumis.com  Wed May  5 12:54:01 2010
From: chuck at jumis.com (Charles Pritchard)
Date: Wed, 05 May 2010 12:54:01 -0700
Subject: [whatwg] Input URL State and Files object
In-Reply-To: <Pine.LNX.4.64.1005051942080.8532@ps20323.dreamhostps.com>
References: <4BE15D7B.7060009@jumis.com>
	<Pine.LNX.4.64.1005051942080.8532@ps20323.dreamhostps.com>
Message-ID: <4BE1CCD9.1030005@jumis.com>

On 5/5/2010 12:42 PM, Ian Hickson wrote:
> On Wed, 5 May 2010, Charles Pritchard wrote:
>    
>> Awhile ago, it appears, the "files" object was removed from<input
>> type="url">
>>      
> "files" doesn't really make much sense for type=url... Do you mean
> type=file?
>    
Sorry, it didn't make much sense: I meant a FileList object which 
FileReader would use.
>> Is there currently a method for allowing cross-domain access to an image
>> based on user input?
>>      
> XMLHttpRequest is the intended way to do this.
>    
XMLHttpRequest relies upon CORS headers from the server; failing that..

Should a user intentional drag an image or URL object, or otherwise 
select one
from their browser UI, the interaction is quite similar to the <input 
type="file"> object.
Only, with a remote resource.

I'm sorry to have approached this so poorly; what I'm looking for is a 
solution to the following use case:

A person is assembling a digital scrap-book, using a web application, of 
pictures they've found
related to their love of kittens. Those that they've downloaded to their 
computer, they simply drag
and drop into the application -- (File API, FileReader, ondrop). Those 
that they find on the internet,
they drag their bookmark onto the application, drag the image onto the 
application, or simply,
copy and paste the URL into an <input type="url"> box.







From christoph.paeper at crissov.de  Wed May  5 13:09:52 2010
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Wed, 5 May 2010 22:09:52 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
Message-ID: <2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>

Eitan Adler:
> 
> A type="username" is added to the input element. type="username" would MUST only be used for the name that is used to log in to the site. It MUST NOT be used for registration forms or anything else that requires a username. A form MAY have up to one (but not more) type="username" input field.

I agree with whomever mentioned that 

  <form role=login>

seems more appropriate. Anyhow, I wondered whether it makes sense to apply microformats to such forms, perhaps reusing ?hcard?:

  <form class=vcard role=login method=post action="./">
    <input type=text name=username class=nickname>
    <input type=password name=password>
    <input type=submit>
  </form>

Nick and user name are probably not the same all that often and differ by site, so this probably doesn?t make sense at all. Still, form field semantics (?name?/?id? and ?class? or ?role?) may improve through some kind of standardization, although names shouldn?t be as clumsy as in RFC 3106 (ECML: Field Specifications for E-Commerce) when applied to HTML forms.

  <form action="http://ecom.example.com" method=post class=Ecom> 
  <fieldset class=Payment-Card>
    <legend>Please enter card information</legend>
    <label class=Name>Your name on the card 
      <input type=text name="Ecom_Payment_Card_Name" size=40>
    </label>
    <label class=Number>The card number 
      <input type=text name="Ecom_Payment_Card_Number" size=19>
    </label>
    <label class=ExpDate>Expiration date (MM YY) 
      <input type=month class=Month name="Ecom_Payment_Card_ExpDate_Month" size=2> 
      <input type=year class=Year name="Ecom_Payment_Card_ExpDate_Year" size=4>
    </label>
    <input type=hidden class=Protocol name="Ecom_Payment_Card_Protocol">
  </fieldset>
  <input type=hidden class=SchemaVersion name="Ecom_SchemaVersion" value="http://www.ecml.org/version/1.1">
  <input type=submit> <input type=reset>
  </form>


From schalk at ossreleasefeed.com  Wed May  5 13:15:18 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Wed, 5 May 2010 22:15:18 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <h2j3726d1bf1005042320s814497fuf4e163c5624b6bb0@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	<t2k3726d1bf1005041353gbec9edd3ke2e89c35797a7598@mail.gmail.com>	<z2o63df84f1005041402h140e3606q27041cb053575ba7@mail.gmail.com>	<t2o3726d1bf1005041827s955234c9pa9e3786b46968266@mail.gmail.com>	<h2v11e306601005041940o6cb93497w5b93d1b38e669243@mail.gmail.com>	<r2u3726d1bf1005041956k6773f927ld18c27a95360d870@mail.gmail.com>	<4BE0E42D.5080905@mit.edu>
	<h2j3726d1bf1005042320s814497fuf4e163c5624b6bb0@mail.gmail.com>
Message-ID: <009b01caec8f$b1c274b0$15475e10$@com>

I personally like the idea of having a type of username for an input field, makes sense based on the use case.

Kind Regards,
Schalk Neethling

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dirk Pranke
Sent: Wednesday, May 05, 2010 8:20 AM
To: Boris Zbarsky
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] RFC: <input type="username">

On Tue, May 4, 2010 at 8:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/4/10 10:56 PM, Dirk Pranke wrote:
>>
>> What I would like to offer is a way to control some amount of the 
>> sign-in/sign-out experience while improving the security, by at least 
>> giving an in-page way to trigger sign-in / sign-out (the actual 
>> mechanism of collecting the credentials and performing the sign-in 
>> would be done by the browser without page intervention, where 
>> possible, for security reasons).
>
> So this would be something pages opt into?
>

Yes. I also imagine people submitting user scripts that could rewrite existing login forms into forms using the new tags.

> If not, how would the following sign-in workflows (taken from two 
> banking sites I've dealt with recently) work:
>
> Workflow 1:
>
> 1)  Site prompts user for only a username.
> 2)  After user enters a username, site responds with a "Hello,
>    __firstname__" (with either the first name corresponding to the
>    username filled in or a random one generated if there's no such
>    account) and two security questions.
> 3)  After the user correctly answers the two security questions, he is
>    presented with a previously-agreed-on image and phrase (to convince
>    the user that the bank is in fact the bank) and 9 clickable buttons
>    numbered 0-9.
> 4a) If the user has a mouse, the user clicks the buttons in the right
>    order to enter their PIN (I believe a 7-digit or more number).
>    Else go to 4b.
> 4b) If the user cannot use the mouse for some reason, the user can
>    follow a link which associates each of the 10 buttons with one
>    of a randomly chosen (each time you hit this screen, as far as
>    I can see) set of 10 letters.  The user can then type the
>    letters that correspond to the desired numbers.
>
> Workflow 2:
>
> 1)  Site prompts user for only a username.
> 2)  After user enters a username, site responds with a page that has a
>    password field and a bunch of buttons in the general shape of a
>    qwerty keyboard.
> 3)  The user enters a password in the password field.
> 4)  The user also enters a different password (the site enforces
>    that they're different during account setup) by clicking the
>    correct buttons on the "virtual keyboard".
>
> Various other banking sites I've dealt with have the 
> "previously-agree-on image and phrase" thing going on, but these two 
> are the ones that are creative with password input.  In particular, 
> the goal seems to be to defeat keyloggers by making replay of logged 
> keystrokes be insufficient to log into the site.

There is no question that people have dreamt up a large variety of mechanisms for logging into web sites. It would be difficult to support all of them out of the box, and certainly we would need to eventually extend the specs that Mozilla has defined to talk about how to support two-factor auth and other schemes like the ones you describe, if we can't figure out how to move them to more secure mechanisms. In particular, allowing a safe login from a compromised machine is, to say the least, somewhat challenging :(

Both the Mozilla Account Manager and the scheme I'm talking about -- which again, builds on top of the account manager -- at least have the advantages that (a) they take the actual typing in of the password out of page and (b) they make the job of password managers far more reliable. Those alone should deliver enough benefit to make these ideas interesting, in my opinion.

-- Dirk


From admin at subcide.com  Wed May  5 13:39:35 2010
From: admin at subcide.com (Steve Dennis)
Date: Wed, 5 May 2010 21:39:35 +0100
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
Message-ID: <0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>


On 5/05/2010, at 9:09 PM, Christoph P?per wrote:

> Eitan Adler:
>> 
>> A type="username" is added to the input element. type="username" would MUST only be used for the name that is used to log in to the site. It MUST NOT be used for registration forms or anything else that requires a username. A form MAY have up to one (but not more) type="username" input field.
> 
> I agree with whomever mentioned that 
> 
>  <form role=login>
> 
> seems more appropriate. Anyhow, I wondered whether it makes sense to apply microformats to such forms, perhaps reusing ?hcard?:
> 
>  <form class=vcard role=login method=post action="./">
>    <input type=text name=username class=nickname>
>    <input type=password name=password>
>    <input type=submit>
>  </form>
> 
> Nick and user name are probably not the same all that often and differ by site, so this probably doesn?t make sense at all. Still, form field semantics (?name?/?id? and ?class? or ?role?) may improve through some kind of standardization, although names shouldn?t be as clumsy as in RFC 3106 (ECML: Field Specifications for E-Commerce) when applied to HTML forms.
> 
>  <form action="http://ecom.example.com" method=post class=Ecom> 
>  <fieldset class=Payment-Card>
>    <legend>Please enter card information</legend>
>    <label class=Name>Your name on the card 
>      <input type=text name="Ecom_Payment_Card_Name" size=40>
>    </label>
>    <label class=Number>The card number 
>      <input type=text name="Ecom_Payment_Card_Number" size=19>
>    </label>
>    <label class=ExpDate>Expiration date (MM YY) 
>      <input type=month class=Month name="Ecom_Payment_Card_ExpDate_Month" size=2> 
>      <input type=year class=Year name="Ecom_Payment_Card_ExpDate_Year" size=4>
>    </label>
>    <input type=hidden class=Protocol name="Ecom_Payment_Card_Protocol">
>  </fieldset>
>  <input type=hidden class=SchemaVersion name="Ecom_SchemaVersion" value="http://www.ecml.org/version/1.1">
>  <input type=submit> <input type=reset>
>  </form>

I don't know if it's relevant, but if we're thinking backwards compatibility, keep in mind earlier versions of ASP.NET only allow one form per page, so wrapping a login in a form tag isn't really an option.  Someone tell me if I'm wrong on that though, I'm just a designer :)

--
Steve Dennis
www.subcide.com

From schalk at ossreleasefeed.com  Wed May  5 14:06:47 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Wed, 5 May 2010 23:06:47 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
Message-ID: <001d01caec96$e3116ce0$a93446a0$@com>

The way I see it is that instead of browsers traversing the DOM looking for
an input field of either id=username or name=username or even
class=username, they now only have to look for an input of type username.
Makes it a lot easier for both developers and browser vendors as they now
only have to look for an input of type username and gives developers the
freedom to use any name, id or class.

Kind Regards,
Schalk

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Steve Dennis
Sent: Wednesday, May 05, 2010 10:40 PM
To: Christoph P?per
Cc: WHATWG List
Subject: Re: [whatwg] RFC: <input type="username">


On 5/05/2010, at 9:09 PM, Christoph P?per wrote:

> Eitan Adler:
>> 
>> A type="username" is added to the input element. type="username" would
MUST only be used for the name that is used to log in to the site. It MUST
NOT be used for registration forms or anything else that requires a
username. A form MAY have up to one (but not more) type="username" input
field.
> 
> I agree with whomever mentioned that
> 
>  <form role=login>
> 
> seems more appropriate. Anyhow, I wondered whether it makes sense to apply
microformats to such forms, perhaps reusing ?hcard?:
> 
>  <form class=vcard role=login method=post action="./">
>    <input type=text name=username class=nickname>
>    <input type=password name=password>
>    <input type=submit>
>  </form>
> 
> Nick and user name are probably not the same all that often and differ by
site, so this probably doesn?t make sense at all. Still, form field
semantics (?name?/?id? and ?class? or ?role?) may improve through some kind
of standardization, although names shouldn?t be as clumsy as in RFC 3106
(ECML: Field Specifications for E-Commerce) when applied to HTML forms.
> 
>  <form action="http://ecom.example.com" method=post class=Ecom>  
> <fieldset class=Payment-Card>
>    <legend>Please enter card information</legend>
>    <label class=Name>Your name on the card 
>      <input type=text name="Ecom_Payment_Card_Name" size=40>
>    </label>
>    <label class=Number>The card number 
>      <input type=text name="Ecom_Payment_Card_Number" size=19>
>    </label>
>    <label class=ExpDate>Expiration date (MM YY) 
>      <input type=month class=Month name="Ecom_Payment_Card_ExpDate_Month"
size=2> 
>      <input type=year class=Year name="Ecom_Payment_Card_ExpDate_Year"
size=4>
>    </label>
>    <input type=hidden class=Protocol 
> name="Ecom_Payment_Card_Protocol">
>  </fieldset>
>  <input type=hidden class=SchemaVersion name="Ecom_SchemaVersion" 
> value="http://www.ecml.org/version/1.1">
>  <input type=submit> <input type=reset>  </form>

I don't know if it's relevant, but if we're thinking backwards
compatibility, keep in mind earlier versions of ASP.NET only allow one form
per page, so wrapping a login in a form tag isn't really an option.  Someone
tell me if I'm wrong on that though, I'm just a designer :)

--
Steve Dennis
www.subcide.com=


From glsimpso at indiana.edu  Wed May  5 19:43:37 2010
From: glsimpso at indiana.edu (Simpson, Grant Leyton)
Date: Wed, 5 May 2010 22:43:37 -0400
Subject: [whatwg] Expanding the cite element
Message-ID: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>

Dear WHATWG list participants,

Forgive me if this conversation has been had before; I've just recently joined the list.

Is there any value in adding an "href" or "uri" or similar attribute to the <cite> element to indicate a location for a work (or information about the work) or, in the case of a URI, an indicator that can be used as a reference programmatically?

<q> has a "cite" attribute, so it seems to me that if we have a place to link to further information in <q> it makes sense to do so in <cite>.  After all, whether an author quotes from a reference (<q>) or merely discusses it without quoting (<cite>), both of these would end up in a works cited in a traditional paper.  Therefore, I think both should link (or refer) to somewhere.

If it were a URI (and therefore not necessarily retrievable), it would help in cases where the same work gets referenced in slightly different ways:

<p>As Ashley Crandall Amos says in <cite uri="http://example.com/books/crandall/linguisticmeans">Linguistic Means of Determining the Dates of Old English Literary Texts</cite> ... Amos also mentions in <cite uri="http://example.com/books/crandall/linguisticmeans">Linguistic Means</cite></p>

?
Best,

Grant Simpson
? Senior Analyst/Programmer, Office of the Registrar
? Doctoral Student, Department of English
? Representative, IU Bloomington Professional Council
Indiana University Bloomington



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

From schalk at ossreleasefeed.com  Thu May  6 01:06:19 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 10:06:19 +0200
Subject: [whatwg] Expanding the cite element
In-Reply-To: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
References: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
Message-ID: <006701caecf3$043d3a50$0cb7aef0$@com>

Hi all,

 

I really like this idea, how would this be handled from a presentational point of view? I guess it will be a CSS style issue but, will browsers implement some standard way of displaying these cite elements if it has the uri attribute?

 

Schalk Neethling

 

From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Simpson, Grant Leyton
Sent: Thursday, May 06, 2010 4:44 AM
To: whatwg at lists.whatwg.org
Subject: [whatwg] Expanding the cite element

 

Dear WHATWG list participants,

 

Forgive me if this conversation has been had before; I've just recently joined the list.  

 

Is there any value in adding an "href" or "uri" or similar attribute to the <cite> element to indicate a location for a work (or information about the work) or, in the case of a URI, an indicator that can be used as a reference programmatically?

 

<q> has a "cite" attribute, so it seems to me that if we have a place to link to further information in <q> it makes sense to do so in <cite>.  After all, whether an author quotes from a reference (<q>) or merely discusses it without quoting (<cite>), both of these would end up in a works cited in a traditional paper.  Therefore, I think both should link (or refer) to somewhere.

 

If it were a URI (and therefore not necessarily retrievable), it would help in cases where the same work gets referenced in slightly different ways:

 

<p>As Ashley Crandall Amos says in <cite uri="http://example.com/books/crandall/linguisticmeans">Linguistic Means of Determining the Dates of Old English Literary Texts</cite> ... Amos also mentions in <cite uri="http://example.com/books/crandall/linguisticmeans">Linguistic Means</cite></p> 

 

?

Best, 

 

Grant Simpson
? Senior Analyst/Programmer, Office of the Registrar

? Doctoral Student, Department of English

? Representative, IU Bloomington Professional Council

Indiana University Bloomington

 

 

 

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

From annevk at opera.com  Thu May  6 01:19:49 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 06 May 2010 17:19:49 +0900
Subject: [whatwg] onshow event
In-Reply-To: <Pine.LNX.4.64.1005050445430.8532@ps20323.dreamhostps.com>
References: <DF0B3926-9224-4742-9472-216CE66E96AE@gmail.com>
	<Pine.LNX.4.64.1005050445430.8532@ps20323.dreamhostps.com>
Message-ID: <op.vb9yrbrf64w2qv@annevk-t60>

On Wed, 05 May 2010 13:47:13 +0900, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 4 May 2010, Perry Smith wrote:
>> It would be wonderful if an element had an event that would fire when
>> that particular element is shown on the page.  This might be due to the
>> display attribute changing or it might be due to it scrolling into view.
>
> That's more of a presentation issue; I recommend raising this in the
> context of CSSOM. Anne, is there a bug database or issues list for CSSOM
> where things like this can be logged?

No. I suppose new ideas could be added here (under CSSOM):

   http://wiki.whatwg.org/wiki/Companion_specifications

Issues with the current specification I mostly track through email.


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

From derernst at gmx.ch  Thu May  6 02:51:28 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 06 May 2010 11:51:28 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <001d01caec96$e3116ce0$a93446a0$@com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
	<001d01caec96$e3116ce0$a93446a0$@com>
Message-ID: <4BE29120.70800@gmx.ch>

Am 05.05.2010 23:06 schrieb Schalk Neethling:
> The way I see it is that instead of browsers traversing the DOM looking for
> an input field of either id=username or name=username or even
> class=username, they now only have to look for an input of type username.
> Makes it a lot easier for both developers and browser vendors as they now
> only have to look for an input of type username and gives developers the
> freedom to use any name, id or class.

But in many cases the username is an e-mail address, then you get a 
conflict with type="email".

From t.broyer at gmail.com  Thu May  6 03:09:22 2010
From: t.broyer at gmail.com (Thomas Broyer)
Date: Thu, 6 May 2010 12:09:22 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <4BE29120.70800@gmx.ch>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch>
Message-ID: <q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>

On Thu, May 6, 2010 at 11:51 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Am 05.05.2010 23:06 schrieb Schalk Neethling:
>>
>> The way I see it is that instead of browsers traversing the DOM looking
>> for
>> an input field of either id=username or name=username or even
>> class=username, they now only have to look for an input of type username.
>> Makes it a lot easier for both developers and browser vendors as they now
>> only have to look for an input of type username and gives developers the
>> freedom to use any name, id or class.
>
> But in many cases the username is an e-mail address, then you get a conflict
> with type="email".

type=email is expected to (depending on the browser) allow you to
search into/autocomplete from your address book. I really don't see a
conflict here, it's not about syntax, it's about "semantics"
(otherwise, just use a pattern="" constraint).

But actually, I'm not convinced type=username is required (or even
useful). We're told that Cookies are bad for security and shouldn't be
used for authentication (or other sensible data), so spec'ing this in
HTML, which is expected to live for tens of years, would really be a
Bad Thing (tm).

It has been proposed earlier (a year and a half ago, at least) to
reconcile Cookie-based auth with HTTP-auth, and that could be a way to
tell the browser "which form" and/or "which fields" in the page are
related to login.
I posted a first draft of such a thing more than a year ago:
http://tools.ietf.org/html/draft-broyer-http-cookie-auth
I worked a bit on it since then to answer the feedback but I'm far
from an -01 draft (I'd like to rewrite it from scratch actually...)
http://github.com/tbroyer/http-cookie-auth

-- 
Thomas Broyer
/t?.ma.b?wa.je/

From mounir.lamouri at gmail.com  Thu May  6 03:12:55 2010
From: mounir.lamouri at gmail.com (Mounir Lamouri)
Date: Thu, 06 May 2010 12:12:55 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>	<001d01caec96$e3116ce0$a93446a0$@com>
	<4BE29120.70800@gmx.ch>
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
Message-ID: <4BE29627.4000308@gmail.com>

On 05/06/2010 12:09 PM, Thomas Broyer wrote:
> On Thu, May 6, 2010 at 11:51 AM, Markus Ernst <derernst at gmx.ch> wrote:
>> Am 05.05.2010 23:06 schrieb Schalk Neethling:
>>>
>>> The way I see it is that instead of browsers traversing the DOM looking
>>> for
>>> an input field of either id=username or name=username or even
>>> class=username, they now only have to look for an input of type username.
>>> Makes it a lot easier for both developers and browser vendors as they now
>>> only have to look for an input of type username and gives developers the
>>> freedom to use any name, id or class.
>>
>> But in many cases the username is an e-mail address, then you get a conflict
>> with type="email".
> 
> type=email is expected to (depending on the browser) allow you to
> search into/autocomplete from your address book. I really don't see a
> conflict here, it's not about syntax, it's about "semantics"
> (otherwise, just use a pattern="" constraint).

The input type='email' isn't only about semantic. The browser has to
check if the email is valid according to HTML5 specifications. Please,
have a look at:
http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address

If the entered email address is invalid, the element will suffer from a
type mismatch.

--
Mounir

From eitanadlerlist at gmail.com  Thu May  6 03:56:12 2010
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Thu, 6 May 2010 13:56:12 +0300
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <4BE29627.4000308@gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com> 
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com> 
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch> 
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com> 
	<4BE29627.4000308@gmail.com>
Message-ID: <k2va0777e081005060356wca0085cdm54e170fb2f34cf73@mail.gmail.com>

>>>> The way I see it is that instead of browsers traversing the DOM looking
>>>> for
>>>> an input field of either id=username or name=username or even
>>>> class=username, they now only have to look for an input of type username.
>>>> Makes it a lot easier for both developers and browser vendors as they now
>>>> only have to look for an input of type username and gives developers the
>>>> freedom to use any name, id or class.
>>>
>>> But in many cases the username is an e-mail address, then you get a conflict
>>> with type="email".
>>
>> type=email is expected to (depending on the browser) allow you to
>> search into/autocomplete from your address book. I really don't see a
>> conflict here, it's not about syntax, it's about "semantics"
>> (otherwise, just use a pattern="" constraint).
>
> The input type='email' isn't only about semantic. The browser has to
> check if the email is valid according to HTML5 specifications. Please,
> have a look at:
> http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address
>
> If the entered email address is invalid, the element will suffer from a
> type mismatch.

Here are some possible solutions to allow the use of something like
<input type="login/username"> along with an email
1) change type="login" to role="login" (and thus allow a
text/selec/email/whatever). Based on the feedback so far this is now
my preferred solution.
2) add a role to form element and have the browsers continue to rely
on id/name/class

From schalk at ossreleasefeed.com  Thu May  6 04:35:25 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 13:35:25 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>	
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>	
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch>
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
Message-ID: <00f401caed10$3ae49900$b0adcb00$@com>

Your suggestion sounds really interesting Thomas, I will have a read over it. I agree that if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Not sure if that is really even needed at that point anyway because you are not really concerned over a well formed email address.

If that was a problem, it would have been detected during registration.

Schalk Neethling

-----Original Message-----
From: Thomas Broyer [mailto:t.broyer at gmail.com] 
Sent: Thursday, May 06, 2010 12:09 PM
To: Markus Ernst
Cc: Schalk Neethling; WHATWG List; Steve Dennis
Subject: Re: [whatwg] RFC: <input type="username">

On Thu, May 6, 2010 at 11:51 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Am 05.05.2010 23:06 schrieb Schalk Neethling:
>>
>> The way I see it is that instead of browsers traversing the DOM 
>> looking for an input field of either id=username or name=username or 
>> even class=username, they now only have to look for an input of type 
>> username.
>> Makes it a lot easier for both developers and browser vendors as they 
>> now only have to look for an input of type username and gives 
>> developers the freedom to use any name, id or class.
>
> But in many cases the username is an e-mail address, then you get a 
> conflict with type="email".

type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about "semantics"
(otherwise, just use a pattern="" constraint).

But actually, I'm not convinced type=username is required (or even useful). We're told that Cookies are bad for security and shouldn't be used for authentication (or other sensible data), so spec'ing this in HTML, which is expected to live for tens of years, would really be a Bad Thing (tm).

It has been proposed earlier (a year and a half ago, at least) to reconcile Cookie-based auth with HTTP-auth, and that could be a way to tell the browser "which form" and/or "which fields" in the page are related to login.
I posted a first draft of such a thing more than a year ago:
http://tools.ietf.org/html/draft-broyer-http-cookie-auth
I worked a bit on it since then to answer the feedback but I'm far from an -01 draft (I'd like to rewrite it from scratch actually...) http://github.com/tbroyer/http-cookie-auth

--
Thomas Broyer
/t?.ma.b?wa.je/


From juuso_html5 at tele3d.net  Thu May  6 05:44:18 2010
From: juuso_html5 at tele3d.net (juuso_html5 at tele3d.net)
Date: Thu, 06 May 2010 12:44:18 +0000
Subject: [whatwg] meta="encrypt" tag is needed
Message-ID: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>

<meta="encrypt" pubkey="ABABAEFEF2626EFEFEF"  
pubtool="EC256-AES|RSA2048-AES" passsalt="no|domainname"  
auth="verisign">

Please try to fully decrypt the above meta-encrypt tag and *see* how  
the browser-server communication could utilize it. (HINT: browser  
submits a (session specific) 256bit elliptic curve public key to the  
server inside every URI-request AND if the target page has  
meta-encrypt tag, the server uses the  browser's elliptic curve key  
and encrypts the page content with that.) It is very simple, doable  
and STATELESS. And in html5 it would eliminate some of the biggest  
real life security threats at the internet. If you *could* learn and  
instinctly use the above meta-encrypt tag then it should be enough  
simple for actual usage.

yes, this suggestion maybe a bit radical, so lets try to find the  
positive things first. Meaning if you don't understand or like the  
structure immediately shut up and let those who see the light to  
express themselves first.

Ok, let me start with the passsalt:

passsalt => salts the password-field value into => SHA-256($password) format

I think the passsalt="(no|domainname)" attribute should also be added  
as a form parameter (with a default value lowercase domain name).  
Passsalt attribute would prevent the site getting a plain text  
password as the browser would 'salt' it by default with a domain name  
string. Thus when internet users anyway
use the same passwords on multiple sites, the passsalt will eliminate  
hacking into various online accounts user has.
Real life examples & reasons for adding passsalt to html5
1) A finnish site alypaa.com got hacked a month ago. The hacker stole  
some 100,000 (unencrypted) user passwords from their database. But  
what media noticed first were that many leading politicians had got  
their blogs, home pages and Facebook pages defaced.
2) Couple of weeks ago a Russian hacker was selling his user names &  
passwords for 1.5 million Facebook accounts.
3) a week ago a new data protection law for Massachusetts was  
suggested, basically it says personally identifiable information (that  
is usable for identity theft crimes) about Massachusetts residents may  
not be stolen or _you_ will get a fine of $5,000 per breach or lost  
record.

http://www.mass.gov/Eoca/docs/idtheft/201CMR1700reg.pdf

It can be expected that the laws around the world will be going to  
that direction as the identity theft problem keeps getting worse. That  
passsalt attribute alone would eliminate LOTS of identity thefts and  
it is easily doable.

Ok, try to hack the rest of that *beautiful* <meta="encrypt" tag, and  
please don't say you instead you can use https / JS or some other  
thing that JUST DOESN'T WORK in real life.

Juuso Hukkanen
www.colordev.com


From t.broyer at gmail.com  Thu May  6 05:54:25 2010
From: t.broyer at gmail.com (Thomas Broyer)
Date: Thu, 6 May 2010 14:54:25 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <4BE29627.4000308@gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch>
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
	<4BE29627.4000308@gmail.com>
Message-ID: <j2wa9699fd21005060554ia3ed6a43r82d7ead1331cd62e@mail.gmail.com>

On Thu, May 6, 2010 at 12:12 PM, Mounir Lamouri wrote:
> On 05/06/2010 12:09 PM, Thomas Broyer wrote:
>> On Thu, May 6, 2010 at 11:51 AM, Markus Ernst <derernst at gmx.ch> wrote:
>>> Am 05.05.2010 23:06 schrieb Schalk Neethling:
>>>>
>>>> The way I see it is that instead of browsers traversing the DOM looking
>>>> for
>>>> an input field of either id=username or name=username or even
>>>> class=username, they now only have to look for an input of type username.
>>>> Makes it a lot easier for both developers and browser vendors as they now
>>>> only have to look for an input of type username and gives developers the
>>>> freedom to use any name, id or class.
>>>
>>> But in many cases the username is an e-mail address, then you get a conflict
>>> with type="email".
>>
>> type=email is expected to (depending on the browser) allow you to
>> search into/autocomplete from your address book. I really don't see a
>> conflict here, it's not about syntax, it's about "semantics"
>> (otherwise, just use a pattern="" constraint).
>
> The input type='email' isn't only about semantic. The browser has to
> check if the email is valid according to HTML5 specifications. Please,
> have a look at:
> http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address
>
> If the entered email address is invalid, the element will suffer from a
> type mismatch.

Of course, just like type=url requires the URL to be a valid absolute
URL, while hinting browsers to autocomplete based on your bookmarks
and/or search history (note: not your "account manager").

Would you use a type=number (that some browsers would present as a
spinner box) if the usernames were only digits?

(BTW, the syntax for an e-mail address to be considered valid is quite
lax, and can be easily reproduced using a pattern="" constraint, as I
already said)

-- 
Thomas Broyer
/t?.ma.b?wa.je/

From ash at ashleysheridan.co.uk  Thu May  6 05:53:49 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Thu, 06 May 2010 13:53:49 +0100
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <j2wa9699fd21005060554ia3ed6a43r82d7ead1331cd62e@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch>
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
	<4BE29627.4000308@gmail.com>
	<j2wa9699fd21005060554ia3ed6a43r82d7ead1331cd62e@mail.gmail.com>
Message-ID: <1273150429.2214.10.camel@localhost>

On Thu, 2010-05-06 at 14:54 +0200, Thomas Broyer wrote:

> On Thu, May 6, 2010 at 12:12 PM, Mounir Lamouri wrote:
> > On 05/06/2010 12:09 PM, Thomas Broyer wrote:
> >> On Thu, May 6, 2010 at 11:51 AM, Markus Ernst <derernst at gmx.ch> wrote:
> >>> Am 05.05.2010 23:06 schrieb Schalk Neethling:
> >>>>
> >>>> The way I see it is that instead of browsers traversing the DOM looking
> >>>> for
> >>>> an input field of either id=username or name=username or even
> >>>> class=username, they now only have to look for an input of type username.
> >>>> Makes it a lot easier for both developers and browser vendors as they now
> >>>> only have to look for an input of type username and gives developers the
> >>>> freedom to use any name, id or class.
> >>>
> >>> But in many cases the username is an e-mail address, then you get a conflict
> >>> with type="email".
> >>
> >> type=email is expected to (depending on the browser) allow you to
> >> search into/autocomplete from your address book. I really don't see a
> >> conflict here, it's not about syntax, it's about "semantics"
> >> (otherwise, just use a pattern="" constraint).
> >
> > The input type='email' isn't only about semantic. The browser has to
> > check if the email is valid according to HTML5 specifications. Please,
> > have a look at:
> > http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address
> >
> > If the entered email address is invalid, the element will suffer from a
> > type mismatch.
> 
> Of course, just like type=url requires the URL to be a valid absolute
> URL, while hinting browsers to autocomplete based on your bookmarks
> and/or search history (note: not your "account manager").
> 
> Would you use a type=number (that some browsers would present as a
> spinner box) if the usernames were only digits?
> 
> (BTW, the syntax for an e-mail address to be considered valid is quite
> lax, and can be easily reproduced using a pattern="" constraint, as I
> already said)
> 


I wouldn't say the syntax is lax, just that it allows a lot of
variation. 

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


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

From Smylers at stripey.com  Thu May  6 06:18:24 2010
From: Smylers at stripey.com (Smylers)
Date: Thu, 6 May 2010 14:18:24 +0100
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <00f401caed10$3ae49900$b0adcb00$@com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch>
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
	<00f401caed10$3ae49900$b0adcb00$@com>
Message-ID: <20100506131824.GE7644@stripey.com>

Schalk Neethling writes:

> if your username field will be in the form of an email address, then
> simply use type=username with a pattern to facilitate email
> validation.

Surely a major reason for having standard validation types is so web
developers don't need to come up with patterns for these common things?

It also avoids lots of different authors coming up with something
different, and not getting it right. The validation needed to accurately
match a valid e-mail address is surprisingly convoluted -- see for
example the regular expression on this page:
http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html

> Not sure if that is really even needed at that point anyway because
> you are not really concerned over a well formed email address.  If
> that was a problem, it would have been detected during registration.

Sure, you aren't concerned that a user's correct username might not be a
valid e-mail address.

But if a user tries to submit something that isn't a syntactically
correct e-mail address, then he must have mis-typed his username.  Using
type=email allows the browser to alert him to this, so he can fix it.
Without that, he has to wait for server-side validation.

Smylers

From pedzsan at gmail.com  Thu May  6 06:18:43 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Thu, 6 May 2010 08:18:43 -0500
Subject: [whatwg] onshow event
In-Reply-To: <op.vb9yrbrf64w2qv@annevk-t60>
References: <DF0B3926-9224-4742-9472-216CE66E96AE@gmail.com>
	<Pine.LNX.4.64.1005050445430.8532@ps20323.dreamhostps.com>
	<op.vb9yrbrf64w2qv@annevk-t60>
Message-ID: <38D08519-0133-46F5-B177-1290BB09D29C@gmail.com>


On May 6, 2010, at 3:19 AM, Anne van Kesteren wrote:

> On Wed, 05 May 2010 13:47:13 +0900, Ian Hickson <ian at hixie.ch> wrote:
>> On Tue, 4 May 2010, Perry Smith wrote:
>>> It would be wonderful if an element had an event that would fire when
>>> that particular element is shown on the page.  This might be due to the
>>> display attribute changing or it might be due to it scrolling into view.
>> 
>> That's more of a presentation issue; I recommend raising this in the
>> context of CSSOM. Anne, is there a bug database or issues list for CSSOM
>> where things like this can be logged?
> 
> No. I suppose new ideas could be added here (under CSSOM):
> 
>  http://wiki.whatwg.org/wiki/Companion_specifications
> 
> Issues with the current specification I mostly track through email.
> 


I sent an email on the www-style list.

Thanks,
Perry


From schalk at ossreleasefeed.com  Thu May  6 07:13:37 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 16:13:37 +0200
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <20100506131824.GE7644@stripey.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>	<001d01caec96$e3116ce0$a93446a0$@com>
	<4BE29120.70800@gmx.ch>	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>	<00f401caed10$3ae49900$b0adcb00$@com>
	<20100506131824.GE7644@stripey.com>
Message-ID: <018501caed26$544aaa40$fcdffec0$@com>

Smylers,

I understand what you mean but, then I have to agree with Thomas that you
can then use an input of type username and use the pattern to validate the
email address.

Schalk

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Smylers
Sent: Thursday, May 06, 2010 3:18 PM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] RFC: <input type="username">

Schalk Neethling writes:

> if your username field will be in the form of an email address, then 
> simply use type=username with a pattern to facilitate email 
> validation.

Surely a major reason for having standard validation types is so web
developers don't need to come up with patterns for these common things?

It also avoids lots of different authors coming up with something different,
and not getting it right. The validation needed to accurately match a valid
e-mail address is surprisingly convoluted -- see for example the regular
expression on this page:
http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html

> Not sure if that is really even needed at that point anyway because 
> you are not really concerned over a well formed email address.  If 
> that was a problem, it would have been detected during registration.

Sure, you aren't concerned that a user's correct username might not be a
valid e-mail address.

But if a user tries to submit something that isn't a syntactically correct
e-mail address, then he must have mis-typed his username.  Using type=email
allows the browser to alert him to this, so he can fix it.
Without that, he has to wait for server-side validation.

Smylers


From derernst at gmx.ch  Thu May  6 08:10:27 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 06 May 2010 17:10:27 +0200
Subject: [whatwg] Keywords for the pattern attribute [was: RFC: <input
	type="username">]
In-Reply-To: <20100506131824.GE7644@stripey.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>	<001d01caec96$e3116ce0$a93446a0$@com>
	<4BE29120.70800@gmx.ch>	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>	<00f401caed10$3ae49900$b0adcb00$@com>
	<20100506131824.GE7644@stripey.com>
Message-ID: <4BE2DBE3.7090106@gmx.ch>

Am 06.05.2010 15:18 schrieb Smylers:
> Schalk Neethling writes:
> 
>> if your username field will be in the form of an email address, then
>> simply use type=username with a pattern to facilitate email
>> validation.
> 
> Surely a major reason for having standard validation types is so web
> developers don't need to come up with patterns for these common things?

Maybe it is a problem to have several functionalities mixed up in the 
type attribute, such as control display, autofill and validation 
functionalities. OTOH there are validation hints both in the type and 
pattern attributes.

Maybe keywords could be added as possible values of the pattern 
attribute, in order to provide standard validation types such as e-mail, 
numeric, or maybe also date and datetime.

<input type="text" pattern="email">
<input type="username" pattern="email">

From hober0 at gmail.com  Thu May  6 08:14:53 2010
From: hober0 at gmail.com (Edward O'Connor)
Date: Thu, 6 May 2010 08:14:53 -0700
Subject: [whatwg] Expanding the cite element
In-Reply-To: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
References: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
Message-ID: <m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>

> Is there any value in adding an "href" or "uri" or similar attribute
> to the <cite> element to indicate a location for a work (or
> information about the work) or, in the case of a URI, an indicator
> that can be used as a reference programmatically?

<cite uri> has a much worse fallback story than simply embedding a link
in <cite>.

> <p>As Ashley Crandall Amos says in <cite
> uri="http://example.com/books/crandall/linguisticmeans">Linguistic Means of
> Determining the Dates of Old English Literary Texts</cite> ... Amos also
> mentions in <cite
> uri="http://example.com/books/crandall/linguisticmeans">Linguistic
> Means</cite></p>

Consider how the above would work in legacy browsers, and then consider
how this would work in them:

<p>As Ashley Crandall Amos says in <cite><a
href="http://example.com/books/crandall/linguisticmeans">Linguistic Means of
Determining the Dates of Old English Literary Texts</a></cite> ... Amos also
mentions in <cite><a
href="http://example.com/books/crandall/linguisticmeans">Linguistic
Means</a></cite></p>


Ted

From simonp at opera.com  Thu May  6 08:20:41 2010
From: simonp at opera.com (Simon Pieters)
Date: Thu, 06 May 2010 17:20:41 +0200
Subject: [whatwg] WebSocket: garbage collection
In-Reply-To: <op.vbgrvaofidj3kv@simon-pieterss-macbook.local>
References: <op.vbgrvaofidj3kv@simon-pieterss-macbook.local>
Message-ID: <op.vcah8rk9idj3kv@simon-pieterss-macbook.local>

On Tue, 20 Apr 2010 16:00:36 +0200, Simon Pieters <simonp at opera.com> wrote:

> [[
> WebSocket object with an open connection must not be garbage collected  
> if there are any event listeners registered for message events.
> ]]
>
> Shouldn't it also not be garbage collected if there are listeners for  
> open, error and close? What about when the connection is not yet  
> established?

I think the policy should be:

if readyState is CONNECTING:
   has 'open' event listener: don't collect
   has 'message' event listener: don't collect
   has 'error' event listener: don't collect
   has 'close' event listener: don't collect

if readyState is OPEN:
   has 'open' event listener: OK to collect
   has 'message' event listener: don't collect
   has 'error' event listener: don't collect
   has 'close' event listener: don't collect

if readyState is CLOSING:
   has 'open' event listener: OK to collect
   has 'message' event listener: OK to collect
   has 'error' event listener: OK to collect
   has 'close' event listener: don't collect

if readyState is CLOSED:
   has 'open' event listener: OK to collect
   has 'message' event listener: OK to collect
   has 'error' event listener: OK to collect
   has 'close' event listener: OK to collect

-- 
Simon Pieters
Opera Software

From eitanadlerlist at gmail.com  Thu May  6 10:01:58 2010
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Thu, 6 May 2010 20:01:58 +0300
Subject: [whatwg] Keywords for the pattern attribute [was: RFC: <input
	type="username">]
In-Reply-To: <4BE2DBE3.7090106@gmx.ch>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com> 
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>
	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com> 
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch> 
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com> 
	<00f401caed10$3ae49900$b0adcb00$@com>
	<20100506131824.GE7644@stripey.com> <4BE2DBE3.7090106@gmx.ch>
Message-ID: <y2ua0777e081005061001r5a676b9ep11ad57563a3bfe6e@mail.gmail.com>

> <input type="text" pattern="email">
> <input type="username" pattern="email">

What if for some strange reason I wanted to only allow the text
e-m-a-i-l ? There would have to be some way to differentiate between a
keyword and a normal pattern.

From jackalmage at gmail.com  Thu May  6 10:10:57 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 6 May 2010 10:10:57 -0700
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
Message-ID: <i2pdd0fbad1005061010wf1b6a535y55bf219a3a6b06f9@mail.gmail.com>

On Thu, May 6, 2010 at 5:44 AM,  <juuso_html5 at tele3d.net> wrote:
> <meta="encrypt" pubkey="ABABAEFEF2626EFEFEF" pubtool="EC256-AES|RSA2048-AES"
> passsalt="no|domainname" auth="verisign">
>
> Please try to fully decrypt the above meta-encrypt tag and *see* how the
> browser-server communication could utilize it. (HINT: browser submits a
> (session specific) 256bit elliptic curve public key to the server inside
> every URI-request AND if the target page has meta-encrypt tag, the server
> uses the ?browser's elliptic curve key and encrypts the page content with
> that.) It is very simple, doable and STATELESS. And in html5 it would
> eliminate some of the biggest real life security threats at the internet. If
> you *could* learn and instinctly use the above meta-encrypt tag then it
> should be enough simple for actual usage.

Rather than ask us to figure it out ourselves, and possibly get it
wrong and have to be corrected, why don't you just tell us:

1) What the exact problem is you're trying to solve
2) What your suggestion is
3) How your suggestion solves the problem
4) How it is better than existing solutions to that problem

It's generally a much better use of my time to read something that's
well-thought out and explained than to try and decipher a clever idea
that someone had but doesn't want to fully explain.

~TJ

From and-py at doxdesk.com  Thu May  6 12:52:04 2010
From: and-py at doxdesk.com (And Clover)
Date: Thu, 06 May 2010 21:52:04 +0200
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
Message-ID: <4BE31DE4.6080600@doxdesk.com>

On 05/06/2010 02:44 PM, juuso_html5 at tele3d.net wrote:

> browser submits a (session specific) 256bit elliptic curve public key
> to the server inside every URI-request AND if the target page has
> meta-encrypt tag, the server uses the browser's elliptic curve key

The server has to read and correctly parse each HTML page to decide 
whether to encrypt it? (And how does the browser know that the page is 
encrypted, vs. a legacy server that doesn't encrypt?)

This proposal is tackling the problem of encryption at entirely the 
wrong level: it's nothing to do with HTML, it's to do with the 
connection between the browser and the server. It is very likely that 
sites would want to encrypt transfers of other files than HTML pages. 
This is something that should be tackled at the HTTP level, not in HTML5.

And lo, there is already a quite suitable mechanism for deploying 
encryption between the server and browser: HTTPS.

Whilst it is true that HTTPS has more organisational overhead in the 
form of CAs, and more server overhead in the form of making virtual 
hosting difficult, there are technical approaches to improve this 
situation (DNSSEC-based certs, SNI), and, notably, this overhead is 
*necessary*.

Otherwise HTTPS would be vulnerable to active man-in-the-middle attacks, 
just like your proposed protocol is. Without attestation that the site 
receiving the `pubkey` token is who it says it is, the encryption 
between the two is worthless. It would only protect against passive MitM 
attacks, but in reality if you are in a position to MitM passively you 
are very likely to be able to throw in an active attack just as easily.

> please don't say you instead you can use https / JS or some other thing
> that JUST DOESN'T WORK in real life.

HTTPS works fine. JS client-side-password-hashing approaches suffer from 
the same problem as your proposal: they can only ever protect against 
passive attacks.

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/

From schalk at ossreleasefeed.com  Thu May  6 13:30:33 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 22:30:33 +0200
Subject: [whatwg] Styling browser messages
In-Reply-To: <4BE31DE4.6080600@doxdesk.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com>
Message-ID: <00db01caed5a$fc7ed310$f57c7930$@com>

Hi there all,

I absolutely love the fact that browsers will have certain validation baked in like email addresses etc. With that, is there currently a way to, or plans to add a way, where the way the browser displays these errors can be styled with CSS?

Kind Regards,
Schalk


From schalk at ossreleasefeed.com  Thu May  6 13:45:03 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 22:45:03 +0200
Subject: [whatwg] Expanding the cite element
In-Reply-To: <m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>
References: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
	<m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>
Message-ID: <00dc01caed5d$0421b5e0$0c6521a0$@com>

I guess this is the 'Paving the cowpaths' situation. Is there a 'standard' where most developers do as in the sample by Ted? Also, I cannot see a backwards compatibility issue as the uri attribute on cite should be optional. So if a developer used cite and then wrapped the containing text in a link, that would work fine. 

Going forward, the same developer can opt into using the new uri attribute of cite as opposed to wrapping the text in a link.

Schalk Neethling

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Edward O'Connor
Sent: Thursday, May 06, 2010 5:15 PM
To: Simpson, Grant Leyton
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Expanding the cite element

> Is there any value in adding an "href" or "uri" or similar attribute 
> to the <cite> element to indicate a location for a work (or 
> information about the work) or, in the case of a URI, an indicator 
> that can be used as a reference programmatically?

<cite uri> has a much worse fallback story than simply embedding a link in <cite>.

> <p>As Ashley Crandall Amos says in <cite 
> uri="http://example.com/books/crandall/linguisticmeans">Linguistic 
> Means of Determining the Dates of Old English Literary Texts</cite> 
> ... Amos also mentions in <cite 
> uri="http://example.com/books/crandall/linguisticmeans">Linguistic
> Means</cite></p>

Consider how the above would work in legacy browsers, and then consider how this would work in them:

<p>As Ashley Crandall Amos says in <cite><a href="http://example.com/books/crandall/linguisticmeans">Linguistic Means of Determining the Dates of Old English Literary Texts</a></cite> ... Amos also mentions in <cite><a href="http://example.com/books/crandall/linguisticmeans">Linguistic
Means</a></cite></p>


Ted


From schalk at ossreleasefeed.com  Thu May  6 13:47:39 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 22:47:39 +0200
Subject: [whatwg] Keywords for the pattern attribute [was: RFC:
	<input	type="username">]
In-Reply-To: <y2ua0777e081005061001r5a676b9ep11ad57563a3bfe6e@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
	<2DAC479C-84A7-46A4-BA85-9C3A63629673@crissov.de>	<0241E0B7-13B1-46B5-BAB3-E598C5649394@subcide.com>
	<001d01caec96$e3116ce0$a93446a0$@com> <4BE29120.70800@gmx.ch>
	<q2qa9699fd21005060309u803b5b71oe70ca3591178147e@mail.gmail.com>
	<00f401caed10$3ae49900$b0adcb00$@com>	<20100506131824.GE7644@stripey.com>
	<4BE2DBE3.7090106@gmx.ch>
	<y2ua0777e081005061001r5a676b9ep11ad57563a3bfe6e@mail.gmail.com>
Message-ID: <00dd01caed5d$600e1ec0$202a5c40$@com>

If the pattern email will map to a default of evaluating the input as if you used type=email you may have a problem but, if you have the specific need mentioned, change your pattern?

Schalk Neethling

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Eitan Adler
Sent: Thursday, May 06, 2010 7:02 PM
To: Markus Ernst
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Keywords for the pattern attribute [was: RFC: <input type="username">]

> <input type="text" pattern="email">
> <input type="username" pattern="email">

What if for some strange reason I wanted to only allow the text e-m-a-i-l ? There would have to be some way to differentiate between a keyword and a normal pattern.


From schalk at ossreleasefeed.com  Thu May  6 13:50:40 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 22:50:40 +0200
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <4BE31DE4.6080600@doxdesk.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com>
Message-ID: <00de01caed5d$cbecddc0$63c69940$@com>

Might be a wrong assumption but, if you place those values into an HTML element, it is visible by simply doing a view source. I am jumping in the middle of the conversation here but, this strikes me as opening another problem.

Schalk

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of And Clover
Sent: Thursday, May 06, 2010 9:52 PM
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] meta="encrypt" tag is needed

On 05/06/2010 02:44 PM, juuso_html5 at tele3d.net wrote:

> browser submits a (session specific) 256bit elliptic curve public key 
> to the server inside every URI-request AND if the target page has 
> meta-encrypt tag, the server uses the browser's elliptic curve key

The server has to read and correctly parse each HTML page to decide whether to encrypt it? (And how does the browser know that the page is encrypted, vs. a legacy server that doesn't encrypt?)

This proposal is tackling the problem of encryption at entirely the wrong level: it's nothing to do with HTML, it's to do with the connection between the browser and the server. It is very likely that sites would want to encrypt transfers of other files than HTML pages. 
This is something that should be tackled at the HTTP level, not in HTML5.

And lo, there is already a quite suitable mechanism for deploying encryption between the server and browser: HTTPS.

Whilst it is true that HTTPS has more organisational overhead in the form of CAs, and more server overhead in the form of making virtual hosting difficult, there are technical approaches to improve this situation (DNSSEC-based certs, SNI), and, notably, this overhead is *necessary*.

Otherwise HTTPS would be vulnerable to active man-in-the-middle attacks, just like your proposed protocol is. Without attestation that the site receiving the `pubkey` token is who it says it is, the encryption between the two is worthless. It would only protect against passive MitM attacks, but in reality if you are in a position to MitM passively you are very likely to be able to throw in an active attack just as easily.

> please don't say you instead you can use https / JS or some other 
> thing that JUST DOESN'T WORK in real life.

HTTPS works fine. JS client-side-password-hashing approaches suffer from the same problem as your proposal: they can only ever protect against passive attacks.

--
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/


From Simetrical+w3c at gmail.com  Thu May  6 13:56:41 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 6 May 2010 16:56:41 -0400
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
Message-ID: <p2h7c2a12e21005061356lfbecd828n70e75c8e1e026483@mail.gmail.com>

On Thu, May 6, 2010 at 8:44 AM,  <juuso_html5 at tele3d.net> wrote:
> <meta="encrypt" pubkey="ABABAEFEF2626EFEFEF" pubtool="EC256-AES|RSA2048-AES"
> passsalt="no|domainname" auth="verisign">
>
> Please try to fully decrypt the above meta-encrypt tag and *see* how the
> browser-server communication could utilize it. (HINT: browser submits a
> (session specific) 256bit elliptic curve public key to the server inside
> every URI-request AND if the target page has meta-encrypt tag, the server
> uses the ?browser's elliptic curve key and encrypts the page content with
> that.) It is very simple, doable and STATELESS. And in html5 it would
> eliminate some of the biggest real life security threats at the internet. If
> you *could* learn and instinctly use the above meta-encrypt tag then it
> should be enough simple for actual usage.

To expand on the threat scenario And referred to: suppose I'm in a
position to tamper with your traffic.  For instance, I might have set
up a malicious free Wi-Fi hotspot that you're using (maybe even you
don't know you're using it).  So you submit your public key . . . then
I record the public key, alter your message to contain my own public
key, and send that.  The server returns the message encrypted with my
public key.  I decrypt it with my private key, re-encrypt it with your
public key, and send it back to you.  I'm reading all your messages
and you have no way to detect or prevent that.

Authentication is a necessary component of any usable public-key
encryption scheme for this reason.  If I can eavesdrop, I can very
likely tamper with the traffic too.

> Ok, let me start with the passsalt:
>
> passsalt => salts the password-field value into => SHA-256($password) format
>
> I think the passsalt="(no|domainname)" attribute should also be added as a
> form parameter (with a default value lowercase domain name). Passsalt
> attribute would prevent the site getting a plain text password as the
> browser would 'salt' it by default with a domain name string. Thus when
> internet users anyway
> use the same passwords on multiple sites, the passsalt will eliminate
> hacking into various online accounts user has.

A decently-written site should be doing this already on the server
side.  If the site isn't decently written, it probably won't use this
meta tag either, so what's the point?  Again, this doesn't hide
anything from a man-in-the-middle, because the attacker could just
remove the meta tag before passing the page on to you.

> Real life examples & reasons for adding passsalt to html5
> 1) A finnish site alypaa.com got hacked a month ago. The hacker stole some
> 100,000 (unencrypted) user passwords from their database. But what media
> noticed first were that many leading politicians had got their blogs, home
> pages and Facebook pages defaced.

If the site didn't hash its passwords in the database, why would it
use your meta tag?  The authors of the web app are obviously clueless
about security, after all.  This has to be done unconditionally on the
browser side to be useful, in which case HTML is irrelevant.  Indeed,
there are plenty of password managers that will autogenerate random
passwords for you for each site, solving this problem.

> 2) Couple of weeks ago a Russian hacker was selling his user names &
> passwords for 1.5 million Facebook accounts.

Doesn't tell us anything unless we know how he got them.  If they're
legitimate, he probably just got them via keyloggers, not
network-based attacks.

> That passsalt
> attribute alone would eliminate LOTS of identity thefts and it is easily
> doable.

No, it wouldn't.  The web page authors who would know enough to use it
are already protected against that kind of attack, by storing only
salted password hashes in the database.

> and please
> don't say you instead you can use https / JS or some other thing that JUST
> DOESN'T WORK in real life.

Well, HTTPS is too cumbersome to be deployed on most websites, yes.
Unlike your proposal, though, it has the advantage of actually
providing meaningful security.  :)  Your proposal really doesn't
improve anything.  If HTTPS had better (free) key certification and
played nicely with virtual hosts, it would be pretty much ideal except
for the performance hit, which is inevitable to some extent.  But if
SPDY gets deployed and only works over SSL, even that might be negated
for most users.

What particular parts of HTTPS do you object to?

On Thu, May 6, 2010 at 4:50 PM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Might be a wrong assumption but, if you place those values into an HTML element, it is visible by simply doing a view source. I am jumping in the middle of the conversation here but, this strikes me as opening another problem.

That's not a problem.  Public keys are expected to be available to
everyone in the world.

From schalk at ossreleasefeed.com  Thu May  6 14:19:34 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Thu, 6 May 2010 23:19:34 +0200
Subject: [whatwg] Type Date
In-Reply-To: <00db01caed5a$fc7ed310$f57c7930$@com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>	<4BE31DE4.6080600@doxdesk.com>
	<00db01caed5a$fc7ed310$f57c7930$@com>
Message-ID: <010501caed61$d618ca80$824a5f80$@com>

Greetings,

Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript?

Kind Regards,
Schalk Neethling


From jackalmage at gmail.com  Thu May  6 14:40:11 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 6 May 2010 14:40:11 -0700
Subject: [whatwg] Type Date
In-Reply-To: <010501caed61$d618ca80$824a5f80$@com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net> 
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com> 
	<010501caed61$d618ca80$824a5f80$@com>
Message-ID: <v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>

On Thu, May 6, 2010 at 2:19 PM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Greetings,
>
> Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript?

The purpose of <input type=date> is to allow the browser to supply the
user with a datepicker.  Opera, for example, already does this.

If you would like to show a datepicker to users of all browsers, use
feature detection (such as through the Modernizr script) to detect
whether or not the browser support date inputs, and if not, supply the
js version.

~TJ

From dhtmlkitchen at gmail.com  Thu May  6 14:41:11 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 6 May 2010 14:41:11 -0700
Subject: [whatwg] Type Date
In-Reply-To: <010501caed61$d618ca80$824a5f80$@com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
Message-ID: <o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>

On Thu, May 6, 2010 at 2:19 PM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Greetings,
>
> Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript?
>
Opera has native support that mostly works but failed with dates prior
to 1582, last I checked.

Demo with fallback:
http://dhtmlkitchen.com/ape/example/widget/Calendar/

Demo does not implement min/max and could probably take some advantage
of CSS transitions for show/hide effects.

Garrett

From schalk at ossreleasefeed.com  Thu May  6 15:30:23 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Fri, 7 May 2010 00:30:23 +0200
Subject: [whatwg] Type Date
In-Reply-To: <v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com>
	<00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
Message-ID: <013401caed6b$b9d97400$2d8c5c00$@com>

Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent talk I gave on HTML 5 the question arose that well, what if the user wants to have both options on the same field?

My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option?

Thanks,
Schalk

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage at gmail.com] 
Sent: Thursday, May 06, 2010 11:40 PM
To: Schalk Neethling
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Type Date

On Thu, May 6, 2010 at 2:19 PM, Schalk Neethling <schalk at ossreleasefeed.com> wrote:
> Greetings,
>
> Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript?

The purpose of <input type=date> is to allow the browser to supply the user with a datepicker.  Opera, for example, already does this.

If you would like to show a datepicker to users of all browsers, use feature detection (such as through the Modernizr script) to detect whether or not the browser support date inputs, and if not, supply the js version.

~TJ


From jackalmage at gmail.com  Thu May  6 15:36:00 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 6 May 2010 15:36:00 -0700
Subject: [whatwg] Type Date
In-Reply-To: <013401caed6b$b9d97400$2d8c5c00$@com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net> 
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com> 
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
	<013401caed6b$b9d97400$2d8c5c00$@com>
Message-ID: <x2hdd0fbad1005061536w852ffc3bo5bf2f725ff68c438@mail.gmail.com>

On Thu, May 6, 2010 at 3:30 PM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent talk I gave on HTML 5 the question arose that well, what if the user wants to have both options on the same field?
>
> My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option?

That's a browser UI issue, then.  File a bug on Opera suggesting that.

~TJ

From tkent at chromium.org  Thu May  6 18:30:19 2010
From: tkent at chromium.org (TAMURA, Kent)
Date: Fri, 7 May 2010 10:30:19 +0900
Subject: [whatwg] Type Date
In-Reply-To: <o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
Message-ID: <AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>



On Fri, May 7, 2010 at 06:41, Garrett Smith <dhtmlkitchen at gmail.com> wrote:

> Opera has native support that mostly works but failed with dates prior
> to 1582, last I checked.


This seems reasonable.  Gregorian calendar started in 1582.

-- 
TAMURA Kent
Software Engineer, Google



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

From dhtmlkitchen at gmail.com  Thu May  6 18:50:38 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 6 May 2010 18:50:38 -0700
Subject: [whatwg] Type Date
In-Reply-To: <AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
	<AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>
Message-ID: <v2tc9e12661005061850jad317242r9f15c28023fa9be9@mail.gmail.com>

On Thu, May 6, 2010 at 6:30 PM, TAMURA, Kent <tkent at chromium.org> wrote:
>
>
> On Fri, May 7, 2010 at 06:41, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>
>> Opera has native support that mostly works but failed with dates prior
>> to 1582, last I checked.
>
> This seems reasonable. ?Gregorian calendar started in 1582.

ISO 8601 requires Proleptic Gregorian, including year 0000.  Aside
from that, the implementation should follow the pertinent
specification.

That specification in this case is HTML 5 draft. Opera's
implementation of input type="date", should not, without good reason,
deviate from what is specified in the draft.

If what is specified needs changing, then the Opera folks should
(re)raise those issues.

The control itself is indeed buggy in Opera. Setting `value` does not
seem to work properly; typing a year with the "year" field focused
does nothing; hitting "delete" with year focused results in location
history navigation ("back").

Opera should fix that thing.

Garrett

From dhtmlkitchen at gmail.com  Thu May  6 18:52:15 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 6 May 2010 18:52:15 -0700
Subject: [whatwg] Type Date
In-Reply-To: <v2tc9e12661005061850jad317242r9f15c28023fa9be9@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
	<AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>
	<v2tc9e12661005061850jad317242r9f15c28023fa9be9@mail.gmail.com>
Message-ID: <z2mc9e12661005061852i7fbc5239r81f20e244412b86f@mail.gmail.com>

On Thu, May 6, 2010 at 6:50 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On Thu, May 6, 2010 at 6:30 PM, TAMURA, Kent <tkent at chromium.org> wrote:
>>
>>
>> On Fri, May 7, 2010 at 06:41, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>>
>>> Opera has native support that mostly works but failed with dates prior
>>> to 1582, last I checked.
>>
>> This seems reasonable. ?Gregorian calendar started in 1582.
>
> ISO 8601 requires Proleptic Gregorian, including year 0000. ?Aside
> from that, the implementation should follow the pertinent
> specification.
>

Disregard that: Proleptic Gregorian is not required, but optional for
ISO 8601. Regardless:-

> That specification in this case is HTML 5 draft. Opera's
> implementation of input type="date", should not, without good reason,
> deviate from what is specified in the draft.

Still stands.

From annevk at opera.com  Thu May  6 19:30:46 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 07 May 2010 11:30:46 +0900
Subject: [whatwg] Type Date
In-Reply-To: <z2mc9e12661005061852i7fbc5239r81f20e244412b86f@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
	<AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>
	<v2tc9e12661005061850jad317242r9f15c28023fa9be9@mail.gmail.com>
	<z2mc9e12661005061852i7fbc5239r81f20e244412b86f@mail.gmail.com>
Message-ID: <op.vcbc9kzv64w2qv@annevk-t60>

On Fri, 07 May 2010 10:52:15 +0900, Garrett Smith <dhtmlkitchen at gmail.com>  
wrote:
> On Thu, May 6, 2010 at 6:50 PM, Garrett Smith <dhtmlkitchen at gmail.com>  
> wrote:
> Disregard that: Proleptic Gregorian is not required, but optional for
> ISO 8601. Regardless:-
>
>> That specification in this case is HTML 5 draft. Opera's
>> implementation of input type="date", should not, without good reason,
>> deviate from what is specified in the draft.
>
> Still stands.

HTML5 makes no UI requirements. I agree we could (and definitely should in  
due course) improve our UI, but there is nothing in specification land  
that forces us too as far as I can tell.


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

From dhtmlkitchen at gmail.com  Thu May  6 19:58:08 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 6 May 2010 19:58:08 -0700
Subject: [whatwg] Type Date
In-Reply-To: <op.vcbc9kzv64w2qv@annevk-t60>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
	<AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>
	<v2tc9e12661005061850jad317242r9f15c28023fa9be9@mail.gmail.com>
	<z2mc9e12661005061852i7fbc5239r81f20e244412b86f@mail.gmail.com>
	<op.vcbc9kzv64w2qv@annevk-t60>
Message-ID: <x2ic9e12661005061958p5cf55952kf19d3b68a1f6396b@mail.gmail.com>

On Thu, May 6, 2010 at 7:30 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 07 May 2010 10:52:15 +0900, Garrett Smith <dhtmlkitchen at gmail.com>
> wrote:
>>
>> On Thu, May 6, 2010 at 6:50 PM, Garrett Smith <dhtmlkitchen at gmail.com>
>> wrote:
>> Disregard that: Proleptic Gregorian is not required, but optional for
>> ISO 8601. Regardless:-
>>
>>> That specification in this case is HTML 5 draft. Opera's
>>> implementation of input type="date", should not, without good reason,
>>> deviate from what is specified in the draft.
>>
>> Still stands.
>
> HTML5 makes no UI requirements. I agree we could (and definitely should in
> due course) improve our UI, but there is nothing in specification land that
> forces us too as far as I can tell.
>
I'm not sure how suitable this is for on-list, but I some may find it
of value...

U/X and usability issues aside, The date format and range is specified
in HTML5 and cited from rfc3339.

HTML 5[1] specifies:

| # a date-fullyear is defined as four or more digits
| representing a number greater than 0

I read that as "0000" to "9999". Is there a different interpretation of that?

HTML 5 cites RFC3339[2], which mentions proleptic greg dates, e.g.

| All dates and times are assumed to be in the "current era",
|      somewhere between 0000AD and 9999AD.

Nice to see native support of that control taking hold. I like to be
able to use websites when I need to but most calendars (and websites,
for that matter) fall somewhere in quality between awful and totally
broken. Take a look at any travel site. Those among the most popular
of travel sites are aware of four browsers (if your're lucky), fail
with js disabled, throw script errors when enabled, use (m)m/(d)d/yyyy
(or worse: yy). This sort of garbage will not stop, not so long as
these stupid and harmful trends in web development continue.

[1]http://dev.w3.org/html5/markup/datatypes.html#data-date-fullyear
[2] http://tools.ietf.org/html/rfc3339

From dolske at mozilla.com  Thu May  6 20:16:39 2010
From: dolske at mozilla.com (Justin Dolske)
Date: Thu, 06 May 2010 20:16:39 -0700
Subject: [whatwg] RFC: <input type="username">
In-Reply-To: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
References: <AANLkTim3yNlpOmt1SY2uzz6mqIKzzjLyFyEq3PC9NUBV@mail.gmail.com>
Message-ID: <4BE38617.10907@mozilla.com>

On 5/4/10 12:08 AM, Eitan Adler wrote:

> 3) Currently autofill for usernames looks for something like
> id="username" or name="username". However on certain websites this
> fails. Furthermore some websites offer a "find other members" feature
> where you could type in a username. I've often seen these fields
> filled in automatically with my name.

Firefox's existing password manager doesn't do this. Roughly, it assumes 
the username field is the first <input type="text"> before the first 
<input type="password"> in a form.

My previous thinking about this problem was to allow tagging the <form> 
element with the names of the inputs to be used for the login. For example:
   <form loginfields="abc,def">
       <input type="text"     name="abc">
       <input type="password" name="def">
   </form>

But I agree with what Jonas noted earlier in this thread; improving the 
login experience needs a broader solution than just tweaking HTML 
attributes. Additionally, I suspect that the sites with currently-broken 
login forms are the ones least likely to change... It's not hard to make 
existing sites work with existing password managers, so I don't think 
it's a problem more markup will solve.

Justin

From brucel at opera.com  Fri May  7 00:28:31 2010
From: brucel at opera.com (Bruce Lawson)
Date: Fri, 07 May 2010 08:28:31 +0100
Subject: [whatwg] Type Date
In-Reply-To: <x2hdd0fbad1005061536w852ffc3bo5bf2f725ff68c438@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
	<013401caed6b$b9d97400$2d8c5c00$@com>
	<x2hdd0fbad1005061536w852ffc3bo5bf2f725ff68c438@mail.gmail.com>
Message-ID: <op.vcbq1t1gh8on37@bruce-pc>

On Thu, 06 May 2010 23:36:00 +0100, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

>> My suggestion was to fall back to using a standard text input field and  
>> use JavaScript to add the date picker which will allow the user to  
>> enter the date manually if so desired. Are there any current plans to  
>> add this ability to type=date or is the fallback the best option?
>
> That's a browser UI issue, then.  File a bug on Opera suggesting that.

FYI, confirming I've filed a bug on that already.



-- 
Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)
www.twitter.com/brucel
Pre-order my HTML5 book www.introducinghtml5.com

From timeless at gmail.com  Fri May  7 00:30:17 2010
From: timeless at gmail.com (timeless)
Date: Fri, 7 May 2010 10:30:17 +0300
Subject: [whatwg] Type Date
In-Reply-To: <x2ic9e12661005061958p5cf55952kf19d3b68a1f6396b@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<o2gc9e12661005061441m7cde77c9o58d6a6b416950577@mail.gmail.com>
	<AANLkTilRKYfgEzr-X5b6lvO2W0n5UpKct5w8XtMrOuD5@mail.gmail.com>
	<v2tc9e12661005061850jad317242r9f15c28023fa9be9@mail.gmail.com>
	<z2mc9e12661005061852i7fbc5239r81f20e244412b86f@mail.gmail.com>
	<op.vcbc9kzv64w2qv@annevk-t60>
	<x2ic9e12661005061958p5cf55952kf19d3b68a1f6396b@mail.gmail.com>
Message-ID: <x2jbb9848a71005070030t1ef92b0keb97c97c322343@mail.gmail.com>

On Fri, May 7, 2010 at 5:58 AM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> | # a date-fullyear is defined as four or more digits
> | representing a number greater than 0
>
> I read that as "0000" to "9999". Is there a different interpretation of that?

Surely 0000 is not greater than 0?

From simonp at opera.com  Fri May  7 02:53:04 2010
From: simonp at opera.com (Simon Pieters)
Date: Fri, 07 May 2010 11:53:04 +0200
Subject: [whatwg] WebSocket handshake: 0x0D in first "line"
Message-ID: <op.vcbxqq16idj3kv@simon-pieterss-macbook.local>

establish a WebSocket connection

[[
28. Read bytes from the server until either the connection closes, or a  
0x0A byte is read. Let field be these bytes, including the 0x0A byte.

If field is not at least seven bytes long, or if the last two bytes aren't  
0x0D and 0x0A respectively, or if it does not contain at least two 0x20  
bytes, then fail the WebSocket connection and abort these steps.

User agents may apply a timeout to this step, failing the WebSocket  
connection if the server does not send back data in a suitable time period.

29. Let code be the substring of field that starts from the byte after the  
first 0x20 byte, and ends with the byte before the second 0x20 byte.
]]

This makes it possible for servers to include 0x0D bytes before and after  
the status code, and potentially trick broken clients that aren't so fuzzy  
with new lines to misinterpret the handshake. Maybe we should read ahead  
to the first 0x0D byte and check if the next byte is 0x0A instead.

-- 
Simon Pieters
Opera Software

From dvdgoss at googlemail.com  Fri May  7 03:07:06 2010
From: dvdgoss at googlemail.com (David Goss)
Date: Fri, 7 May 2010 11:07:06 +0100
Subject: [whatwg] RFC: <input type="username">
Message-ID: <y2peed7f4a91005070307n4fbea881y4ff879b7088aaa2e@mail.gmail.com>

I think using the role attribute is the best solution here:

<input type="text" role="username">
<input type="email" role="username">

This way we're using the type attribute to indicate what sort of data
is being entered, and the role attribute to indicate how it will be
used. I think the separation of these is sensible, although it's not
entirely consistent across the spec (in my model, "search" would be a
role on a type="text"). It's also backwards compatible with HTML4 and
with current implementations of HTML5, and could tie in with the rest
of ARIA's roles model.

The same concept could, for instance, also be applied to a signup form
where there is a check box for opting in to marketing:

<input type="checkbox" role="optin">

You'd need to use a role attribute of "login" or "signup" on the form
as well to give context to things like role="username" so the browser
would know what behaviour is appropriate. As someone pointed out, the
form element isn't always available if you're working with ASP.NET, so
it would seem right to make the roles legal for fieldset, section and
div as well. In fact, it would seem right anyway because you could have
something like an ecommerce site where there's a single form to place
an order which deals with payment for the current order as well as
signup for the account.

David Goss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100507/75b6384c/attachment.htm>

From derernst at gmx.ch  Fri May  7 04:24:11 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Fri, 07 May 2010 13:24:11 +0200
Subject: [whatwg] Type Date
In-Reply-To: <013401caed6b$b9d97400$2d8c5c00$@com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>	<4BE31DE4.6080600@doxdesk.com>	<00db01caed5a$fc7ed310$f57c7930$@com>	<010501caed61$d618ca80$824a5f80$@com>	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
	<013401caed6b$b9d97400$2d8c5c00$@com>
Message-ID: <4BE3F85B.3090103@gmx.ch>

Am 07.05.2010 00:30 schrieb Schalk Neethling:
> Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent talk I gave on HTML 5 the question arose that well, what if the user wants to have both options on the same field?
> 
> My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option?

If I understand your task correctly, I assume that changing the 
appearance of the date field via CSS would be the appropriate way:

http://www.w3.org/TR/2004/CR-css3-ui-20040511/#appearance0

Of course, this can't be done before the CSS appearance property is 
broadly supported, and the new HTML5 input types are reflected as 
possible values of this property.

Meanwhile, it might be easier to switch field types (and maybe patterns) 
via JS, than implementing a custom JS date picker.

From simonp at opera.com  Fri May  7 07:32:38 2010
From: simonp at opera.com (Simon Pieters)
Date: Fri, 07 May 2010 16:32:38 +0200
Subject: [whatwg] WebSocket set-cookie
Message-ID: <op.vccaoocoidj3kv@dyn105.gothenburg.osa>

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').

-- 
Simon Pieters
Opera Software

From fmigacz at gmail.com  Fri May  7 07:44:38 2010
From: fmigacz at gmail.com (Frank Migacz)
Date: Fri, 7 May 2010 09:44:38 -0500
Subject: [whatwg] meta="encrypt" tag is needed
Message-ID: <x2mf190e8841005070744h51102958kd61f04c2cbcdaf92@mail.gmail.com>

On Thu, May 6, 2010 at 8:44 AM,  <juuso_html5 at tele3d.net> wrote:
> <meta="encrypt" pubkey="ABABAEFEF2626EFEFEF"
pubtool="EC256-AES|RSA2048-AES"
> passsalt="no|domainname" auth="verisign">
>

I see a few shortcomings in this approach:
a) each document is encrypted asymmetrically, affecting performance.
b) there is no management of keys (expiration, revocation, trust, etc).
c) the values for the pubtool attribute (encryption algorithm) will need to
be spec'd, slowing the deployment of new encryption algorithms (or better
techniques altogether).
d) how to handle XMLHttpRequests? how to handle XHRs receiving JSON or text?
e) information from the UA to the server is plaintext (e.g.,
logon/passwords).  If, instead, authentication relies only on possession of
the user's private key; then, any human can sit at the user's console and
automatically authenticate to all HTTP servers.

I'd prefer a radically different approach (TLS = out of scope).

Frank Migacz
Technical Instructor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100507/38210303/attachment.htm>

From juuso_html5 at tele3d.net  Fri May  7 10:06:26 2010
From: juuso_html5 at tele3d.net (Juuso Hukkanen)
Date: Fri, 07 May 2010 17:06:26 +0000
Subject: [whatwg] meta="encrypt" tag is needed
Message-ID: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>

I was expecting criticism; as is unavoidable with all crypto issues.

You asked many questions, and unfortunately all you missed the  
auth="verisign" argument, which _is_ enough to prevent all practical  
(,even if they are all theoretical!,) man-in-the-middle attacks.

<html>
<head>
   <meta encrypt pubkey="ABABAEFEF2626EFEFEF" pubtool="EC256-AES"  
passsalt="colordev.com" auth="verisign"/>
</head>
<body>
   <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
   Username: <input type="text" name="user" /><br />
   Password: <input type="password" name="password" />
	<input type="submit" value="Submit" /><br />
   </form>
</body>
</html>

the above 'page' using the meta-encrypt tag, which is enough for a  
client browser to submit to site
a) a salted password
b) and a user name transported in encrypted form; over the internet

Maybe someone can show a _complete_ alternative Javascript & https  
solution about how those can be achieved in a computer or PDA-device  
without javascript support.

I am not suggesting replacing https with anything, government and  
business sites can and should keep on using it.  I am suggesting a  
small easy to use mini-encryption which would be enough for those 90%  
of sites should salt their passwords and encrypt sensitive data and  
but who currently aren't.

question 1:
> The server has to read and correctly parse each HTML page to decide
> whether to encrypt it? (And how does the browser know that the page is
> encrypted, vs. a legacy server that doesn't encrypt?)

answer 1:
Most servers are already configured to read the requested pages before  
submitting those over the internet. For example my above form-page has  
a small php-script inside which the server program must notice; as the  
PHP-program needs to compile the script. Client never sees the <?php  
echo $_SERVER['PHP_SELF']; ?> part but is instead shown an URL. To  
implement meta-encrypt tag would just require (on/off) configuring  
server program to read the header of requested page and see if there  
is a meta-encrypt tag in there the server calls a program which  
decrypts! the client submitted data.

Obviously you people will keep complaining, so what do you want to  
complain next
1) Man-in-the-middle problem; which doesn't exists because
	a) those are just academic mind games
	b) if auth="verisign" is used as external CA
2) HTTPS = good (even if it is typically NOT used with forms
3) password salting = webmasters duty to do it (which 50% forget),  
after using the HTTPS (which 90% forget)
4) Declaring encrypt action doesn't fit into HTML (; then why is there  
a form method get/post)


Juuso Hukkanen
www.colordev.com


From ash at ashleysheridan.co.uk  Fri May  7 10:18:14 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 07 May 2010 18:18:14 +0100
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
Message-ID: <1273252694.21168.18.camel@localhost>

On Fri, 2010-05-07 at 17:06 +0000, Juuso Hukkanen wrote:

> answer 1:
> Most servers are already configured to read the requested pages
> before  
> submitting those over the internet.

What do you base this on? I can't say I've ever seen a server set up to
parse HTML content

> For example my above form-page has  
> a small php-script inside which the server program must notice; as
> the  
> PHP-program needs to compile the script. Client never sees the <?php  
> echo $_SERVER['PHP_SELF']; ?> part but is instead shown an URL.

PHP is a server language, parsed by the PHP program not the server
software (i.e. Apache or IIS) and as such, only parse PHP code within
PHP tags, not the HTML.

> To  
> implement meta-encrypt tag would just require (on/off) configuring  
> server program to read the header of requested page and see if there  
> is a meta-encrypt tag in there the server calls a program which  
> decrypts! the client submitted data.


What you're suggesting is that web servers be set up to parse HTML
pages, or an extra server module (like PHP) to parse HTML content. Not
only would this impact on the speed of some sites, but it's likely going
to be harder to convince web hosting companies to update their web
server software than it is to convince offices to upgrade a browser (and
anyone who's ever worked in an office will know how hard it is to get
updates and new software installed)

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


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

From schalk at ossreleasefeed.com  Fri May  7 11:26:49 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Fri, 7 May 2010 20:26:49 +0200
Subject: [whatwg] Type Date
In-Reply-To: <v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com>
	<00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
Message-ID: <007b01caee12$dd263090$977291b0$@com>

On Thu, May 6, 2010 at 2:19 PM, Schalk Neethling <schalk at ossreleasefeed.com> wrote:
> Greetings,
>
> Are there any talks at the moment whether the type=date input will allow a user to enter a date manually or use the date picker or, should developers fall back to using a standard input field and add the date picker via JavaScript?

"The purpose of <input type=date> is to allow the browser to supply the user with a datepicker.  Opera, for example, already does this.

If you would like to show a datepicker to users of all browsers, use feature detection (such as through the Modernizr script) to detect whether or not the browser support date inputs, and if not, supply the js version."

Hey TJ, I understand what type=date is supposed to offer the user and agree that using Modernizr to detect whether the element is supported and provide a fallback but my more direct question is, would HTML 5 offer the ability to allow a user to use either the date picker or enter the date manually if the type=date attribute is specified. Something like for example <input type=date editable=true />

Thanks,
Schalk


From jackalmage at gmail.com  Fri May  7 11:28:19 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 7 May 2010 11:28:19 -0700
Subject: [whatwg] Type Date
In-Reply-To: <007b01caee12$dd263090$977291b0$@com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net> 
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com> 
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
	<007b01caee12$dd263090$977291b0$@com>
Message-ID: <j2jdd0fbad1005071128m3a73305crb928ec20f0e2bb40@mail.gmail.com>

On Fri, May 7, 2010 at 11:26 AM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Hey TJ, I understand what type=date is supposed to offer the user and agree that using Modernizr to detect whether the element is supported and provide a fallback but my more direct question is, would HTML 5 offer the ability to allow a user to use either the date picker or enter the date manually if the type=date attribute is specified. Something like for example <input type=date editable=true />

HTML5 doesn't specify anything about how the date input is presented.
It's entirely up to the browser to decide if they want to allow the
user to type a date in, or just use a datepicker, or what.

~TJ

From Simetrical+w3c at gmail.com  Fri May  7 13:18:58 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 7 May 2010 16:18:58 -0400
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
Message-ID: <g2r7c2a12e21005071318xbbcd307ala1b6cbc56b10802a@mail.gmail.com>

On Fri, May 7, 2010 at 1:06 PM, Juuso Hukkanen <juuso_html5 at tele3d.net> wrote:
> You asked many questions, and unfortunately all you missed the
> auth="verisign" argument, which _is_ enough to prevent all practical (,even
> if they are all theoretical!,) man-in-the-middle attacks.

You haven't explained what it does.  Did you mean that the <meta> tag
should include a certificate as well as a public key?  If so, how is
that better than HTTPS?

> Maybe someone can show a _complete_ alternative Javascript & https solution
> about how those can be achieved in a computer or PDA-device without
> javascript support.

Just serve the page using HTTPS, and have a normal HTML form.  It will
transmit the username, and the password.  The server can  salt and
hash the password.  (You could also easily have the client salt and
hash the password using JavaScript before submission, but this doesn't
improve security once you're using HTTPS.)

> I am not suggesting replacing https with anything, government and business
> sites can and should keep on using it. ?I am suggesting a small easy to use
> mini-encryption which would be enough for those 90% of sites should salt
> their passwords and encrypt sensitive data and but who currently aren't.

It is not sufficient, because it's trivially circumventable by a
man-in-the-middle attack.  It therefore provides no security against
any attacker.  It also provides no greater assurance of security on
the server side, because anyone who's competent enough to include this
meta tag will probably also be competent enough to hash and salt
passwords on their own.

> Most servers are already configured to read the requested pages before
> submitting those over the internet.

I'm not aware of any HTTP server that attempts to parse outgoing HTML
content.  Could you provide a specific example?  In particular, I'm
rather certain that neither Apache, nor IIS, nor lighttpd parse
outgoing HTML pages, and that accounts for most servers already.

> For example my above form-page has a
> small php-script inside which the server program must notice; as the
> PHP-program needs to compile the script. Client never sees the <?php echo
> $_SERVER['PHP_SELF']; ?> part but is instead shown an URL. To implement
> meta-encrypt tag would just require (on/off) configuring server program to
> read the header of requested page and see if there is a meta-encrypt tag in
> there the server calls a program which decrypts! the client submitted data.

This requires HTTP servers to implement an HTML parser, and to run it
every time a page is submitted.  They don't actually do this right
now.  HTML parsing is actually very complicated and slow -- have you
looked at the HTML parsing algorithm
<http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#parsing>?

> 1) Man-in-the-middle problem; which doesn't exists because
> ? ? ? ?a) those are just academic mind games

If so, there's no reason for encryption at all.  You can just send the
content unencrypted if no one is going to intercept it.

> ? ? ? ?b) if auth="verisign" is used as external CA

Saying who the CA is is not enough to certify it.  You need to provide
the actual certificate, e.g., in X.509 format
<http://en.wikipedia.org/wiki/X.509>.  To get a certificate, you will
typically have to pay a CA some sum of money, making it prohibitive
for casual sites.  What's the advantage over HTTPS at this point?

> 2) HTTPS = good (even if it is typically NOT used with forms

Many sites use HTTPS for everything, including login.  Most sites
don't, but that's mainly because 1) it's hard to get a certificate
(you don't solve this), and 2) it doesn't work well with shared
hosting (there are better solutions to this in progress).

> 3) password salting = webmasters duty to do it (which 50% forget), after

Then why will they remember to add the <meta> tag you suggest?
They'll just forget both.  This is a problem, but the only solution is
to have the browser act more securely by default, regardless of what
the webmaster does.

> 4) Declaring encrypt action doesn't fit into HTML (; then why is there a
> form method get/post)

HTML is the wrong place to do encryption, because once you receive the
page, it might have already been tampered with.  The entire connection
needs to be specified as secure-only from the beginning, such that the
client will abort if it receives unencrypted/unauthenticated content.
This is what HTTPS does.  By the time you get to the actual contents
of the document, it's impossible to know whether it's been secured.


You haven't explained yourself very clearly, but in summary, this is
what I think you're trying to do and why it doesn't work:

1) You're trying to provide protection against MITM attacks that's
easier to use than HTTPS.  This fails, because a) you still need a
certificate (the most annoying part of HTTPS), and b) an MITM could
just alter the outgoing HTTP request to remove the encryption request,
get the plaintext reply, and encrypt that itself, with the client none
the wiser.  (But you seem to say you don't think MITM is a serious
problem, so I don't know why your proposal includes encryption at
all.)

2) You're trying to provide a different way for authors to salt and
hash passwords.  This is a useful goal, but your proposal doesn't do
it, because there's no reason to believe authors will know to use the
<meta> tag if they don't already know to salt and hash on the server
side.  Mozilla's Account Manager
<https://mozillalabs.com/blog/2010/03/account-manager/> is a step in
this direction that aims to solve this problem and others, and
encourages webmasters to comply by making their non-compliance obvious
and (potentially) making their life easier.

You really need to explain 1) why your proposal is actually better
than HTTPS, and 2) why you think your tag will actually encourage more
authors to salt and hash their users' passwords.  Taking a defensive
or dismissive stance will not help your proposal.

From jackalmage at gmail.com  Fri May  7 13:21:35 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 7 May 2010 13:21:35 -0700
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
Message-ID: <s2ldd0fbad1005071321t23b6c148i3f1d64622485dd55@mail.gmail.com>

On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen <juuso_html5 at tele3d.net> wrote:
> 1) Man-in-the-middle problem; which doesn't exists because
> ? ? ? ?a) those are just academic mind games

You don't get to talk about security anymore.

~TJ

From glsimpso at indiana.edu  Fri May  7 13:33:07 2010
From: glsimpso at indiana.edu (Simpson, Grant Leyton)
Date: Fri, 7 May 2010 16:33:07 -0400
Subject: [whatwg] Expanding the cite element
In-Reply-To: <m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>
References: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
	<m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>
Message-ID: <A695BF56-E39E-4C65-B2B3-BDC14999F6F0@indiana.edu>


On May 6, 2010, at 11:14 AM, Edward O'Connor wrote:
> 
> Consider how the above would work in legacy browsers, and then consider
> how this would work in them:
> 
> <p>As Ashley Crandall Amos says in <cite><a
> href="http://example.com/books/crandall/linguisticmeans">Linguistic Means of
> Determining the Dates of Old English Literary Texts</a></cite> ... Amos also
> mentions in <cite><a
> href="http://example.com/books/crandall/linguisticmeans">Linguistic
> Means</a></cite></p>

Ted, 

I'm almost satisfied with your approach except for three things:

1. Referencing something in the href attributed of an <a> tag implies that the URI will resolve to a URL, that is, that it will be accessible on the web at that address. Not every URI is a URL, though. That's what I was trying to do with a "uri" attribute for the <cite> tag is to identify the resource, not necessarily link to it.

2. We would have to formally define what <a> within <cite> means, otherwise we would leave the pairing up for interpretation. 

3. Are there instances where tags that can be used separately take on a different meaning in relation to one another?  I know what <li> means in relation to <ol> and <ul>, but then again, I can't really use <li> outside of either of those two.

Best,
Grant

From ash at ashleysheridan.co.uk  Fri May  7 13:28:16 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 07 May 2010 21:28:16 +0100
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <s2ldd0fbad1005071321t23b6c148i3f1d64622485dd55@mail.gmail.com>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
	<s2ldd0fbad1005071321t23b6c148i3f1d64622485dd55@mail.gmail.com>
Message-ID: <1273264096.21168.30.camel@localhost>

On Fri, 2010-05-07 at 13:21 -0700, Tab Atkins Jr. wrote:

> On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen <juuso_html5 at tele3d.net> wrote:
> > 1) Man-in-the-middle problem; which doesn't exists because
> >        a) those are just academic mind games
> 
> You don't get to talk about security anymore.
> 
> ~TJ


+1

You only have to read a few XKCD comics to realise that
man-in-the-middle attacks are pretty easy to pull off!

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


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

From Simetrical+w3c at gmail.com  Fri May  7 13:40:59 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 7 May 2010 16:40:59 -0400
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <s2ldd0fbad1005071321t23b6c148i3f1d64622485dd55@mail.gmail.com>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
	<s2ldd0fbad1005071321t23b6c148i3f1d64622485dd55@mail.gmail.com>
Message-ID: <l2w7c2a12e21005071340g5e414cy6bdf573947677889@mail.gmail.com>

On Fri, May 7, 2010 at 4:21 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen <juuso_html5 at tele3d.net> wrote:
>> 1) Man-in-the-middle problem; which doesn't exists because
>> ? ? ? ?a) those are just academic mind games
>
> You don't get to talk about security anymore.

I don't think "academic" is an *entirely* unfair characterization of
MITM on the web, actually.  MITM is hard enough to pull off on the
open web that unless you're a bank or PayPal or something, it's
unlikely anyone would bother.  In practice, most web developers don't
have to worry about MITM.  By contrast, something like XSS or SQL
injection is often so easy to exploit when it exists that any site is
at risk, from botnet operators targeting their outdated software or
from script kiddies feeling bored or spiteful.

In fact, do you know of *any* examples of MITM attacks being
successfully used against a public website?  It's not that I doubt
that it's happened, but I don't actually know of any specific cases.
In principle, you should be able to harvest lots of passwords by
dropping some free wireless routers in strategic locations.

(There's still an entirely different fatal problem with what you
quoted, though: if you aren't worried about MITM, then encryption is
pointless to begin with.  I don't dispute your conclusion.  :) )

From ash at ashleysheridan.co.uk  Fri May  7 13:43:20 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Fri, 07 May 2010 21:43:20 +0100
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <l2w7c2a12e21005071340g5e414cy6bdf573947677889@mail.gmail.com>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
	<s2ldd0fbad1005071321t23b6c148i3f1d64622485dd55@mail.gmail.com>
	<l2w7c2a12e21005071340g5e414cy6bdf573947677889@mail.gmail.com>
Message-ID: <1273265000.21168.31.camel@localhost>

On Fri, 2010-05-07 at 16:40 -0400, Aryeh Gregor wrote:

> On Fri, May 7, 2010 at 4:21 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> > On Fri, May 7, 2010 at 10:06 AM, Juuso Hukkanen <juuso_html5 at tele3d.net> wrote:
> >> 1) Man-in-the-middle problem; which doesn't exists because
> >>        a) those are just academic mind games
> >
> > You don't get to talk about security anymore.
> 
> I don't think "academic" is an *entirely* unfair characterization of
> MITM on the web, actually.  MITM is hard enough to pull off on the
> open web that unless you're a bank or PayPal or something, it's
> unlikely anyone would bother.  In practice, most web developers don't
> have to worry about MITM.  By contrast, something like XSS or SQL
> injection is often so easy to exploit when it exists that any site is
> at risk, from botnet operators targeting their outdated software or
> from script kiddies feeling bored or spiteful.
> 
> In fact, do you know of *any* examples of MITM attacks being
> successfully used against a public website?  It's not that I doubt
> that it's happened, but I don't actually know of any specific cases.
> In principle, you should be able to harvest lots of passwords by
> dropping some free wireless routers in strategic locations.
> 
> (There's still an entirely different fatal problem with what you
> quoted, though: if you aren't worried about MITM, then encryption is
> pointless to begin with.  I don't dispute your conclusion.  :) )


http://xkcd.com/341/

Maybe not exactly what you had in mind, but it is a man-in-the-middle in
a sort of sense.

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


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

From juuso_html5 at tele3d.net  Fri May  7 14:46:55 2010
From: juuso_html5 at tele3d.net (Juuso Hukkanen)
Date: Fri, 07 May 2010 21:46:55 +0000
Subject: [whatwg] meta="encrypt" tag is needed
Message-ID: <20100507214655.16477kimmhf8h8pb@webmail-srv2.servage.net>

On Thu, May 6, 2010 at 8:44 AM,  <juuso_html5 at tele3d.net> wrote:
<meta="encrypt" pubkey="ABABAEFEF2626EFEFEF"
pubtool="EC256-AES|RSA2048-AES"
passsalt="no|domainname" auth="verisign">


Good observations Frank & Ash & Aryeh & others,

> I see a few shortcomings in this approach:
> a) each document is encrypted asymmetrically, affecting performance.
1) yes, that's partially true. What is asymmetrically encrypted is
the keys to symmetrical encryption; which is much faster

2) no, that is not required. if user agent stores the AES password
    e.g. inside a session cookie, "beyond the login page" the web-pages
    can have meta-encrypt-tag pubtool="cookie-AES".
        ==> thus when UA requests page, server requests a cookie named
	according to meta-encrypt pubkey="_value_".
        ==> that cookie named _value_ contains the symmetrical AES key
        ==> so, server sees the UA has a proper pubkey
        ==> server encrypts the page using symmetrical AES and sends it to UA

3) no, that's not required for the passsalt="no|domainname" argument.
    salting happens only in UAs, passsalt argument is a hint to browser
    to hash the password field before submitting it to server. server
    would treat the salted password as any normal 'properly randomized'
    password.


> b) there is no management of keys (expiration, revocation, trust, etc).
1) IF auth is used, CA can validate pubkey belonging to site until xx/yy/zzzz
    Browser can remember authentication and store
    'SHA256(domainname)','pubkey','validuntil'
2) IF external auth is not used site can generate it's own key pair ,  
using some
    w3c? accepted / authenticated key generator tool, and the  
webmaster then just
    puts the public key into meta-encrypt tag and the private key  
into... server
    accessable location maybe .htpasswd file
3) ...so Dear Watsons... as the browser sees the meta-encrypt tag it (*may* be
    configured) to contact CA and validate the pubkey belonging to site using
    all the formal https validation techniques... What is left to the webmaster
    is to insert a simple meta-encrypt tag

> c) the values for the pubtool attribute (encryption algorithm) will need to
be spec'd, slowing the deployment of new encryption algorithms (or better
techniques altogether).
1) yes, that's true, some specsing is needed as there are competing  
PKI technologies, with small key sizes, elliptic curves good  
candidates as they are well studied and at least to sufficient degree  
patent free. Initial specsing has also been done e.g. by "the OpenSSL  
team accepted an ECC patch in 2005", Also NSA may provide helpful  
'ideas'
	http://en.wikipedia.org/wiki/ECC_patents
	http://www.nsa.gov/business/programs/elliptic_curve.shtml

> d) how to handle XMLHttpRequests? how to handle XHRs receiving JSON or text?
1) I'm sure you'll find a solution ;)

> e) information from the UA to the server is plaintext (e.g.,
logon/passwords).  If, instead, authentication relies only on possession of
the user's private key; then, any human can sit at the user's console and
automatically authenticate to all HTTP servers.
1) 'meta-encrypt'- tag encrypts only from UA -> server. IF there is a
     meta-encrypt tag on a requested page, UA encrypts URI-request the form
     parameters it sends to server using the pubkey="" public key


2)  submits the browser's own pubkey to the server inside
    each page-request to the server. the 'UA-encrypt' field may be valid only
    for a session. if a page has a 'meta-encrypt'-tag and a browser has
    a 'UA-encrypt'-field, the server
     +) can generate a AES256 key and encrypt the page using it
     +) return the requested AES256 _encrypted_ page to UA, but the  
pages first line is a PKI encrypted message containing the AES256 key  
that opens the 'page'
     +) UA notices the BEGIN-ENC-MESSAGE......END-ENC-MESSAGE on the first line
     +) UA tries it's own session private key to ENC-MESSAGE, opens  
the message,
        reads the AES256 key
     +) UA opens the page using the AES256, and shows the page content  
as any web page

3)  UA gets all page content in from requested URL in fully encrypted  
form server gets all the POST/GET parameters (from UA) to the page in  
fully encrypted form

4)  if page had a passsalt="no|domainname" form-field with or without  
the 'meta-encrypt'-tag, UA hashes the password field with SHA256 and  
submits the SHA256(password+domainname) to the server instead of plain  
text password.


> I'd prefer a radically different approach (TLS = out of scope).

There certainly are many technically excellent solutions. My approach  
just focuses in and can
a) make it maximally easy and usable for 'typical' webmasters to use
b) and force the passwords salted; thus preemptively preventing id-thefts


Ash,

You're quite right, what I am suggesting is a server module which may  
be on/off.
- if the meta-encrypt module is off, server module doesn't read the  
page before submitting it.
- if the meta-encrypt module is off, the UA still sees e.g. <meta  
encrypt passsalt="no|domainname"/> and the UA can salt the  
form-password field
- if the meta-encrypt module is off, UA receives the page content without the
   BEGIN-ENC-MESSAGE......END-ENC-MESSAGE on the first line, and yet  
the UA *sees* the meta-encrypt-tag on page, thus the UA concludes  
server's meta-encrypt module is off. So if a page visitor wants to  
fill a form on a page, before submitting the GET/POST parameters to  
server, UA pops up a screen
	/////////////////////
	Receiving site has it's encryption engine
	turned off. Do you still want to submit
	data to that site, as unencrypted plain
	text data?
	|YES|        |NO|
	//////////////////////

- Obviously a server must read the data chunks from a hard disk or  
similar before it can submit those.
   A server _module_ would be given e.g. two first 4096 byte chunks  
from certain file types (html,htm,php). Module would check if there is  
meta-encrypt tag (or </head>).
	- if meta-encrypt was not found but </head> would be
	==> module would return 0,
	    and apache/IIS would submit the page unencrypted
	- if meta-encrypt was found
	==> module would return 1, and apache would hand over
	    the whole file to module as well as the UA's public key
	    ==> module would encrypt file and return it to apache
		so it could be sent to UA. Also the module
		would have parsed all the related file URLs that were
		included in that original page. And module would
		request apache to read the included file(s) and the
		module would would encrypt them all


> What you're suggesting is that web servers be set up to parse HTML  
> pages, or an extra server
> module (like PHP) to parse HTML content.

Yes, PHP and other scripting languages are popular. If a site or a  
server doesn't want to use PHP module (or meta-encrypt-module) they  
can choose not to install it or they may exclude files in  
(home)directories and all-subdirectories not to be using PHP-module  
(or meta-encrypt-module) just
by setting it off e.g. using .htaccess file of 'apache/ISS' settings file.


>>> 1) Man-in-the-middle problem; which doesn't exists because
>>>        a) those are just academic mind games
>>
>> You don't get to talk about security anymore.
>
> I don't think "academic" is an *entirely* unfair characterization of  
> MITM on the web, actually.
...
> In fact, do you know of *any* examples of MITM attacks being
> successfully used against a public website?

I double that question. And before I generalized the internet MITM  
attacks against PKIs being "academic mind game" (ok NSA & Co could  
prove other vice), I googled and checked the wikipedia, if there were  
any real life examples of internet MITM attacks against  
unauthenticated PKIs, but no all seems to be non-internet site like  
examples. Sure MITM can be done, but it's not the low hanging fruit;  
that concerns most ordinary websites. AND just to tackle that  
authentication problem I added the auth="verisign" parameter

We know hundred ways of how the HTTPS mediated security would easily  
fail, but almost all off those would be "hacker-at-the-other-end  
attacks". The real life data security problem is the identity thefts,  
espionage and frauds. Where the unsalted passwords and multi-use of  
same passwords play a key role as well as in minor degree, sniffing of  
unencrypted traffic. Why would anyone even consider cryptographic MITM  
attact for the purpose of achieving identity theft, as the  
hacker/keylogger-at-the-other-end can achieve the same goal with less  
effort. After all Internet is just a massive security hole, with of  
without the HTTPS.

see the article at http://xkcd.com/538/

Juuso Hukkanen
www.colordev.com



From mjs at apple.com  Sat May  8 02:31:03 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Sat, 08 May 2010 02:31:03 -0700
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <l2w7c2a12e21005071340g5e414cy6bdf573947677889@mail.gmail.com>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
	<s2ldd0fbad1005071321t23b6c148i3f1d64622485dd55@mail.gmail.com>
	<l2w7c2a12e21005071340g5e414cy6bdf573947677889@mail.gmail.com>
Message-ID: <2AD5ED01-A437-4D47-A930-883FECD00759@apple.com>


On May 7, 2010, at 1:40 PM, Aryeh Gregor wrote:

>
> In fact, do you know of *any* examples of MITM attacks being
> successfully used against a public website?  It's not that I doubt
> that it's happened, but I don't actually know of any specific cases.
> In principle, you should be able to harvest lots of passwords by
> dropping some free wireless routers in strategic locations.
>
> (There's still an entirely different fatal problem with what you
> quoted, though: if you aren't worried about MITM, then encryption is
> pointless to begin with.  I don't dispute your conclusion.  :) )

"Pharming" is effectively a man-in-the-middle, and in particular would  
be 100% effective at defeating the proposed security feature. It is  
extremely common, to the point that it is considered one of the major  
security risks on the Web.

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

Regards,
Maciej


From schalk at ossreleasefeed.com  Sat May  8 04:12:23 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Sat, 8 May 2010 13:12:23 +0200
Subject: [whatwg] Type Date
In-Reply-To: <j2jdd0fbad1005071128m3a73305crb928ec20f0e2bb40@mail.gmail.com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com>
	<00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
	<007b01caee12$dd263090$977291b0$@com>
	<j2jdd0fbad1005071128m3a73305crb928ec20f0e2bb40@mail.gmail.com>
Message-ID: <00e501caee9f$572231f0$056695d0$@com>

Ah, no that makes sense TJ, so Opera's current decision was to present the user with a Date picker and only allow this. Bruce or Anne, where does one file bug or enhancement reports for Opera?

Kind Regards,
Schalk Neethling

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage at gmail.com] 
Sent: Friday, May 07, 2010 8:28 PM
To: Schalk Neethling
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Type Date

On Fri, May 7, 2010 at 11:26 AM, Schalk Neethling <schalk at ossreleasefeed.com> wrote:
> Hey TJ, I understand what type=date is supposed to offer the user and 
> agree that using Modernizr to detect whether the element is supported 
> and provide a fallback but my more direct question is, would HTML 5 
> offer the ability to allow a user to use either the date picker or 
> enter the date manually if the type=date attribute is specified. 
> Something like for example <input type=date editable=true />

HTML5 doesn't specify anything about how the date input is presented.
It's entirely up to the browser to decide if they want to allow the user to type a date in, or just use a datepicker, or what.

~TJ


From brucel at opera.com  Sat May  8 04:16:58 2010
From: brucel at opera.com (Bruce Lawson)
Date: Sat, 08 May 2010 12:16:58 +0100
Subject: [whatwg] Type Date
In-Reply-To: <00e501caee9f$572231f0$056695d0$@com>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com> <00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
	<007b01caee12$dd263090$977291b0$@com>
	<j2jdd0fbad1005071128m3a73305crb928ec20f0e2bb40@mail.gmail.com>
	<00e501caee9f$572231f0$056695d0$@com>
Message-ID: <op.vcdwakxrh8on37@bruce-pc>

On Sat, 08 May 2010 12:12:23 +0100, Schalk Neethling  
<schalk at ossreleasefeed.com> wrote:

> Ah, no that makes sense TJ, so Opera's current decision was to present  
> the user with a Date picker and only allow this. Bruce or Anne, where  
> does one file bug or enhancement reports for Opera?

You can file bugs at http://bugs.opera.com/wizard and we're grateful if  
you do so.

I confirm that I have already filed a change request to this effect.

From schalk at ossreleasefeed.com  Sat May  8 04:20:40 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Sat, 8 May 2010 13:20:40 +0200
Subject: [whatwg] Type Date
In-Reply-To: <op.vcdwakxrh8on37@bruce-pc>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>
	<4BE31DE4.6080600@doxdesk.com>
	<00db01caed5a$fc7ed310$f57c7930$@com>
	<010501caed61$d618ca80$824a5f80$@com>
	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>
	<007b01caee12$dd263090$977291b0$@com>
	<j2jdd0fbad1005071128m3a73305crb928ec20f0e2bb40@mail.gmail.com>
	<00e501caee9f$572231f0$056695d0$@com> <op.vcdwakxrh8on37@bruce-pc>
Message-ID: <00fa01caeea0$7fbfba50$7f3f2ef0$@com>

Thanks Bruce, will have a read over yours before adding my own.

Kind Regards,
Schalk

-----Original Message-----
From: Bruce Lawson [mailto:brucel at opera.com] 
Sent: Saturday, May 08, 2010 1:17 PM
To: 'Tab Atkins Jr.'; Schalk Neethling
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Type Date

On Sat, 08 May 2010 12:12:23 +0100, Schalk Neethling <schalk at ossreleasefeed.com> wrote:

> Ah, no that makes sense TJ, so Opera's current decision was to present 
> the user with a Date picker and only allow this. Bruce or Anne, where 
> does one file bug or enhancement reports for Opera?

You can file bugs at http://bugs.opera.com/wizard and we're grateful if you do so.

I confirm that I have already filed a change request to this effect.


From bhawkeslewis at googlemail.com  Sat May  8 05:41:13 2010
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sat, 8 May 2010 13:41:13 +0100
Subject: [whatwg] Expanding the cite element
In-Reply-To: <A695BF56-E39E-4C65-B2B3-BDC14999F6F0@indiana.edu>
References: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
	<m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>
	<A695BF56-E39E-4C65-B2B3-BDC14999F6F0@indiana.edu>
Message-ID: <AANLkTimBOQZVVgaa6fTiUWFUm2cJf03-TA8Lpns6j-te@mail.gmail.com>

On Fri, May 7, 2010 at 9:33 PM, Simpson, Grant Leyton <glsimpso at indiana.edu>
wrote:
> 1. Referencing something in the href attributed of an <a> tag implies that
> the URI will resolve to a URL, that is, that it will be accessible on the web
> at that address. Not every URI is a URL, though. That's what I was trying to
> do with a "uri" attribute for the <cite> tag is to identify the resource, not
> necessarily link to it.

I'm not opposed to adding @cite to <cite> but note that when you are
identifying a resource rather than linking to a resource, you could use
microdata or RDFa.

For example:

   http://dev.w3.org/html5/md/#global-identifiers-for-items

   http://rdfa.info/wiki/Rdfa-microdata-markup-comparison#Book_markup_with_ISBN_and_description

> 2. We would have to formally define what <a> within <cite> means, otherwise
> we would leave the pairing up for interpretation.

You stated that you want to "indicate a location for a work (or information
about the work)".

A hyperlink indicates the location of an item or information about an item, and
"a href" creates a hyperlink.

What could be the other interpretations of <cite><a href="...">Work
title</a></cite> or <a href="..."><cite>Work title</cite></a> other than that
the hyperlink locates the work or information about the work?

> 3. Are there instances where tags that can be used separately take on a
> different meaning in relation to one another?  I know what <li> means in
> relation to <ol> and <ul>, but then again, I can't really use <li> outside of
> either of those two.

I think the combination of "cite" and "a" to indicate a work title and the
location of the work or information about the work does not involve changing
the meaning of either "cite" or "a". This is the markup equivalent of:

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

--
Benjamin Hawkes-Lewis

From schalk at ossreleasefeed.com  Sat May  8 06:46:54 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Sat, 8 May 2010 15:46:54 +0200
Subject: [whatwg] Type Date
In-Reply-To: <op.vcdwakxrh8on37@bruce-pc>
References: <20100506124418.503460tdnssh1pr6@webmail-srv2.servage.net>	<4BE31DE4.6080600@doxdesk.com>
	<00db01caed5a$fc7ed310$f57c7930$@com>	<010501caed61$d618ca80$824a5f80$@com>	<v2qdd0fbad1005061440hf39430dfxe05408b11ae48e08@mail.gmail.com>	<007b01caee12$dd263090$977291b0$@com>	<j2jdd0fbad1005071128m3a73305crb928ec20f0e2bb40@mail.gmail.com>	<00e501caee9f$572231f0$056695d0$@com>
	<op.vcdwakxrh8on37@bruce-pc>
Message-ID: <001901caeeb4$ed370390$c7a50ab0$@com>

On Sat, 08 May 2010 12:12:23 +0100, Schalk Neethling <schalk at ossreleasefeed.com> wrote:

> Ah, no that makes sense TJ, so Opera's current decision was to present 
> the user with a Date picker and only allow this. Bruce or Anne, where 
> does one file bug or enhancement reports for Opera?

> You can file bugs at http://bugs.opera.com/wizard and we're grateful if you do so.
> I confirm that I have already filed a change request to this effect.

Bug/Enhancement filed as Behavior of HTML type=date (DSK-298159)

Schalk


From juuso_html5 at tele3d.net  Sat May  8 09:31:37 2010
From: juuso_html5 at tele3d.net (Juuso Hukkanen)
Date: Sat, 08 May 2010 16:31:37 +0000
Subject: [whatwg] meta="encrypt" tag is needed
Message-ID: <20100508163137.117427i2mhxxh0ix@webmail-srv2.servage.net>

>> In fact, do you know of *any* examples of MITM attacks
>> being successfully used against a public website?
> "Pharming" is effectively a man-in-the-middle, and in
> particular would be 100% effective at defeating the proposed  
> security feature. http://en.wikipedia.org/wiki/Pharming


Good point,
I agree that *without* external authentication (see auth="verisign"),  
pharming, poisoned DNS router or various kinds of malicious software  
on users computer could lead UA into communicating with attackers site  
or allow MITM to open the
encryption. But if external authentication service is using the  
auth="verisign" parameter, practical MITM attacks can be prevented.  
Someone said auth="verisign" would not suffice. No it doesn't...  
alone. I wanted the meta-encrypt footpring on pages to be small. So  
the actual CA company signed sertificate, which confirms  
pubkey="FAFFFA262662EAEEA" belonging to mydomainZZZ.com would be found  
from
  https://www.verisign.com/certificates/FAFFFA262662EAEEA.sig AND
  http://www.mydomainZZZ.com/verisign.sig

As UA can verify the document's verisign signature and therefore  
observe site's certificate & public key being authentic and good for  
use.

I am not saying this meta-encrypt tag would solve *most* security /  
privacy problems. I am just saying it would eliminate some of serious  
ones. Like salting the multi-used passwords that easily facilitate  
identity theft.
For example a valid meta-encrypt tag could look like this:  <    />    
i.e. NOTHING no tag at all. Meaning if a html5.01 standard would  
require user agents to, by default, salt the passwords using the  
domain name.
	sha256(userpass+domainname);

Then all browsers that confirm to the html5.01 would submit the salted  
passwords. but if target website had for
some (compability) reason a following meta-encrypt-tag
	<meta encrypt passsalt="no"/>
Then a html5.01 conforming browser would submit the password in plain  
text as it was typed

And if a site would e.g. change name and they wanted to use the old  
user-password-DB salted using the previous
domain name, then the meta-encrypt-tag could be just...
	<meta encrypt passsalt="olddomain.com"/>

And if a site would e.g. change name and they wanted to use the old  
user-password-DB salted using the previous
domain name, then the meta-encrypt-tag could be just...
	<meta encrypt passsalt="olddomain.com"/>

Thus a html5.01 conforming webpage could choose to use...
	<meta encrypt passsalt="current_domain_name.com"/>
	<meta encrypt passsalt=""/>
	<meta encrypt passsalt="yes"/>


That password salting 'security feature' would not be threatened; no  
matter where a rogue DNS or pharming-tool would direct the UA. And as  
always there are still special threats against password salting, e.g.  
physical or software keyloggers. But hey nothing is perfect.

The meta-encrypt tag, the passsalt="" argument alone, would have  
prevented facebook accounts and blogs of some of the leading finnish  
politicians being spied and vandalized - as recently happened after  
alypaa.com was hacked and 100,000+ username+passes were stolen. Ok  
that's all I want to say. Be well.

Juuso Hukkanen
www.colordev.com


From jsalsman at gmail.com  Sat May  8 12:51:10 2010
From: jsalsman at gmail.com (James Salsman)
Date: Sat, 8 May 2010 12:51:10 -0700
Subject: [whatwg] syncronous device upload
Message-ID: <w2wa3c2bd6c1005081251hecb6134eqe22e5104bf256e0d@mail.gmail.com>

I propose including the specification at
http://www.w3.org/TR/device-upload in HTML5, provided that it is
updated to include Speex, Ogg Vorbis, and Ogg Theora.  If Google wants
to include their codec(s), I hope Ian or one of his colleagues will
say so.

Because both the Device API and Policy working group and the Web
Hypertext Application Technology HTML working group have both been
working only on asyncronous device communications as far as I can
tell, there is no overlap with that synchronous work done 11 years
ago.

Would someone at the W3C please replace my updated contact information
in http://www.w3.org/TR/device-upload ? I am no longer affiliated with
Cisco.  My new contact information which I would like included there
is:

James Salsman
device-upload at talknicer.com or jsalsman at gmail.com
http://talknicer.com

Thank you.

From pedzsan at gmail.com  Sun May  9 16:31:58 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Sun, 9 May 2010 18:31:58 -0500
Subject: [whatwg] Security thoughts
Message-ID: <FA5B25AB-E211-4724-B9C3-B7AFB5073AE0@gmail.com>

In HTML5 6.3.1 Relaxing The Same Origin Restriction [1] bullet 3, sub bullet 3 there is a clause that says that if the domain is reduced down to something that is on the Public Suffix List, the new value is rejected.  That phrase caused me to pause.

I was wondering about internal attacks.  First, we need to assume a couple of things but they are relatively easy to assume.  The first is that the relaxing of the restriction has a valid use.  This seems easy or it would not be in the spec.  The second is that an internal domain can effectively be a public suffix list to users on the internal intranet.  For example, at the place I work, I connect my laptop to the wifi, it grabs an address and also registers the name.  Even if the name was not registered, it would still have some DNS entry.  The point is that all DNS entries within this subdomain are not trusted.

If we have a site like official_site.area_subdomain.big.com which relaxes the restriction to area_subdomain.big.com, it is now exposed to the potential of an attack from any of the systems within the same area_subdomain including laptops connected via wifi.  The wifi is secure.  The place I work at trusts me to some degree but with a large corporation, they very often try to restrict information on the "need to know" basis.  And, corporate espionage is a real threat.

I don't know how common it is for internal corporate sites to relax the same origin restriction but I could see it becoming more and more common as they try to take advantage of various technologies.

The corporations could take steps of course to secure the sites.  They could put all official web sites in their own subdomain and then relax to this more trusted subdomain.

The purposed of this email is to ask if a warning should be added in the 3rd bullet to advise web developers of internal sites to be careful in assuming that all the hosts on their internal subdomain are trusted.

Thanks,
Perry

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#relaxing-the-same-origin-restriction

From timeless at gmail.com  Sun May  9 18:30:00 2010
From: timeless at gmail.com (timeless)
Date: Mon, 10 May 2010 04:30:00 +0300
Subject: [whatwg] Security thoughts
In-Reply-To: <FA5B25AB-E211-4724-B9C3-B7AFB5073AE0@gmail.com>
References: <FA5B25AB-E211-4724-B9C3-B7AFB5073AE0@gmail.com>
Message-ID: <AANLkTin_Ldw7gPkNrI7dtdNF5EdV4OM95v9n0O_yXqnO@mail.gmail.com>

On Mon, May 10, 2010 at 2:31 AM, Perry Smith <pedzsan at gmail.com> wrote:
> If we have a site like official_site.area_subdomain.big.com which relaxes the
> restriction to area_subdomain.big.com, it is now exposed to the potential of
> an attack from any of the systems within the same area_subdomain including
> laptops connected via wifi. ?The wifi is secure. ?The place I work at trusts me
> to some degree but with a large corporation, they very often try to restrict
> information on the "need to know" basis. ?And, corporate espionage is a real threat.

Sites shouldn't be configured this way.

They should have two domains, one used for corporate servers:
*.big.com
one used for untrustworthy systems:

<guest>.evil

There's no reason to stick computers into area_subdomain.big.com (if
you manage to get dns search right).

I've seen networks which are properly configured with a secondary domain.

But roughly speaking, if you're allowed to put a computer into
<host>.area_subdomain.big.com, your neighbors have already lost.

Where I work, we have hundreds of servers which pop up random dialogs
asking for my windows domain credentials. Some use HTTP Auth requests,
some use html forms to ask for it. There's no way for a user to
determine if a server is real or not, and most have expired or
otherwise invalid certificates, everyone has to trust all of them.
Thus we trust the network not to allow computers which don't belong
into the interesting subnets (and in theory there's something
patrolling those networks to guard against this problem).

From mozbugbox at yahoo.com.au  Sun May  9 21:34:56 2010
From: mozbugbox at yahoo.com.au (JustFillBug)
Date: Mon, 10 May 2010 04:34:56 +0000 (UTC)
Subject: [whatwg] Need document.available_fonts() call
Message-ID: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>



There should be a way to fetch available font to use in the document.
Currently, the only popular way is to use Flash calls.

document.available_fonts() or document.local_font_list() will be very
useful.





From brettz9 at yahoo.com  Sun May  9 22:08:42 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Mon, 10 May 2010 13:08:42 +0800
Subject: [whatwg] Avoiding new globals in HTML5 ECMAScript
Message-ID: <4BE794DA.6090108@yahoo.com>

Hello,

Although it seems a lot of attention has been given to ensuring 
backward-compatibility in HTML5, and while a kind of namespacing has 
been considered in use of data- attributes (over expando properties), it 
appears to my limited observations that global (window) properties are 
being added without sufficient regard for backward compatibility (and in 
any case limiting future variable naming by authors).

While I can understand the convenience of properties like 
window.localStorage or window.JSON, it seems to me that new global 
properties and methods (at least future ones!) should be added within 
some other reserved object container besides "window".

While I can appreciate that some would argue that the convenience of 
globals to authors outweighs potential conflict concerns (and I know I'm 
not offering this suggestion very early in the process), it seems to me 
that HTML5's client-side ECMAScript should model good practices in 
limiting itself as far as new globals perhaps similar to how XML 
reserved identifiers beginning with "xml", doing the same with allowing 
one "W3C" global or maybe "HTML{N}" globals or the like ("HTML" alone 
would no doubt be way too likely to conflict), allowing authors the 
assurance that they can name their properties freely within a given set 
of constraints without fear of being over-ridden later.

thank you,
Brett


From bijumaillist at gmail.com  Sun May  9 22:11:06 2010
From: bijumaillist at gmail.com (Biju)
Date: Mon, 10 May 2010 01:11:06 -0400
Subject: [whatwg] Request for new DOM property textarea.selectionText
Message-ID: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>

Can we have a new DOM property textarea.selectionText
which can be used to set/get selection text of a TEXTAREA/INPUT type=text.

Current method is complicated and varies between IE and Firefox


Thanks
BijuGC

PS,
I have already submitted https://bugzilla.mozilla.org/show_bug.cgi?id=404981
Trying to programmatically replace a small selection text in TEXTAREA
with a large text content is slow in Firefox due to
https://bugzilla.mozilla.org/show_bug.cgi?id=190147
But I know if we paste manually it works fast enough. So may be having
.selectionText helps

From brettz9 at yahoo.com  Sun May  9 22:34:29 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Mon, 10 May 2010 13:34:29 +0800
Subject: [whatwg] Avoiding new globals in HTML5 ECMAScript
In-Reply-To: <4BE794DA.6090108@yahoo.com>
References: <4BE794DA.6090108@yahoo.com>
Message-ID: <4BE79AE5.8040900@yahoo.com>

My apologies, it was brought to my attention that JSON was specified in 
ECMAScript 5, but the principle still applies (for ECMAScript as well I 
would say).

thank you,
Brett

On 5/10/2010 1:08 PM, Brett Zamir wrote:
> Hello,
>
> Although it seems a lot of attention has been given to ensuring 
> backward-compatibility in HTML5, and while a kind of namespacing has 
> been considered in use of data- attributes (over expando properties), 
> it appears to my limited observations that global (window) properties 
> are being added without sufficient regard for backward compatibility 
> (and in any case limiting future variable naming by authors).
>
> While I can understand the convenience of properties like 
> window.localStorage or window.JSON, it seems to me that new global 
> properties and methods (at least future ones!) should be added within 
> some other reserved object container besides "window".
>
> While I can appreciate that some would argue that the convenience of 
> globals to authors outweighs potential conflict concerns (and I know 
> I'm not offering this suggestion very early in the process), it seems 
> to me that HTML5's client-side ECMAScript should model good practices 
> in limiting itself as far as new globals perhaps similar to how XML 
> reserved identifiers beginning with "xml", doing the same with 
> allowing one "W3C" global or maybe "HTML{N}" globals or the like 
> ("HTML" alone would no doubt be way too likely to conflict), allowing 
> authors the assurance that they can name their properties freely 
> within a given set of constraints without fear of being over-ridden 
> later.
>
> thank you,
> Brett
>
>


From annevk at opera.com  Sun May  9 23:02:49 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 10 May 2010 08:02:49 +0200
Subject: [whatwg] Request for new DOM property textarea.selectionText
In-Reply-To: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>
References: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>
Message-ID: <op.vcg62zzc64w2qv@annevk-t60>

On Mon, 10 May 2010 07:11:06 +0200, Biju <bijumaillist at gmail.com> wrote:
> Can we have a new DOM property textarea.selectionText
> which can be used to set/get selection text of a TEXTAREA/INPUT  
> type=text.
>
> Current method is complicated and varies between IE and Firefox

How is it complicated? Also, bugs in a feature is not a good reason to add  
more features. It only increases the amount of bugs and complicates the  
overall platform.


> Thanks
> BijuGC
>
> PS,
> I have already submitted  
> https://bugzilla.mozilla.org/show_bug.cgi?id=404981
> Trying to programmatically replace a small selection text in TEXTAREA
> with a large text content is slow in Firefox due to
> https://bugzilla.mozilla.org/show_bug.cgi?id=190147
> But I know if we paste manually it works fast enough. So may be having
> .selectionText helps


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

From bijumaillist at gmail.com  Mon May 10 00:59:00 2010
From: bijumaillist at gmail.com (Biju)
Date: Mon, 10 May 2010 03:59:00 -0400
Subject: [whatwg] Request for new DOM property textarea.selectionText
In-Reply-To: <op.vcg62zzc64w2qv@annevk-t60>
References: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>
	<op.vcg62zzc64w2qv@annevk-t60>
Message-ID: <AANLkTinFcffemAo94FCkOwPdYq_DX2gi1e_Z_ZpLtCKt@mail.gmail.com>

Current way in firefox is to

1. OrigStart = textarea.selectionStart
2.  textarea.value = textarea.value.substr(0, OrigStart)
                          + new_text_to_replace
                          + textarea.value.substr(textarea.selectionEnd);
3. Now u loose original selection, so

4.  textarea.setSelectionRange(OrigStart,  OrigStart+new_text_to_replace.length)
5.  remember .scrollTop and reapply if needed

Now if we are only changing few selected characters in TEXTAREA with
big text content,
we are unnecessarily replacing entire content, which is inefficient.


On IE even though wierd you can do it simply by
   document.selection.createRange().text = new_text_to_replace;
BTW, you need to make sure the selection is currently on the
textarea/input form control.
IE is also very fast when doing that, when firefox hangs few second
using the other way

From mikko.rantalainen at peda.net  Mon May 10 02:34:49 2010
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Mon, 10 May 2010 12:34:49 +0300
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
Message-ID: <4BE7D339.3030807@peda.net>

Juuso Hukkanen wrote:
> I was expecting criticism; as is unavoidable with all crypto issues.
> 
> You asked many questions, and unfortunately all you missed the
> auth="verisign" argument, which _is_ enough to prevent all practical
> (,even if they are all theoretical!,) man-in-the-middle attacks.

You keep referring to the source code excerpt you posted. How about
explaining what those attributes do, WHY would you want to use those and
what are allowed values for each attribute.

Also note that because the attribute 'auth="verisign"' is sent without
encryption, it cannot be used for preventing MitM attack. This is
because MitM attacker would be able to strip out that attribute or
replace it with any other value he prefers.

> the above 'page' using the meta-encrypt tag, which is enough for a
> client browser to submit to site
> a) a salted password
> b) and a user name transported in encrypted form; over the internet

I understand that you believe that this is important. Could you explain
to us, why do you think so?

You referred to "alypaa.com" case in your original post. Could you
explain why do you think this would prevent from similar information
leak in the future?

As you haven't explained why your proposed scheme really works, I can
only guess that you intent that the server never gets the original
password, only the salted version. Are you trying to suggest an user
agent implementation of something similar to this:
http://angel.net/~nic/passwdlet.html
?

> I am not suggesting replacing https with anything, government and
> business sites can and should keep on using it.  I am suggesting a small
> easy to use mini-encryption which would be enough for those 90% of sites
> should salt their passwords and encrypt sensitive data and but who
> currently aren't.

What is the attack you're trying to avoid?

> Obviously you people will keep complaining, so what do you want to
> complain next
> 1) Man-in-the-middle problem; which doesn't exists because
>     a) those are just academic mind games

Huh?

What is the attack you're trying to avoid? (I'm repeating myself...)

>     b) if auth="verisign" is used as external CA

This cannot be used for authentication because it's part of the
non-encrypted and unsigned content. See above.

> 2) HTTPS = good (even if it is typically NOT used with forms

?? (Are you trying to make some point? Please, elaborate.)

> 3) password salting = webmasters duty to do it (which 50% forget), after
> using the HTTPS (which 90% forget)

Is this the problem you're trying to fix? You don't like the fact that
if the server software is able to know your password, it's able to store
it encrypted?

Why do you think your proposed feature would fix this?

> 4) Declaring encrypt action doesn't fit into HTML (; then why is there a
> form method get/post)

?? (Are you trying to make some point? Please, elaborate.)

-- 
Mikko


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100510/82bb6c59/attachment-0001.pgp>

From narendra at narendrasisodiya.com  Mon May 10 03:28:16 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Mon, 10 May 2010 15:58:16 +0530
Subject: [whatwg] E-learning content format
Message-ID: <AANLkTimY9OfTLZ54qIKHHNLTOpRdmdd3lxcTX82D605k@mail.gmail.com>

I am making a elearing tool for while i have trying to go with some xml
syntax.

The basic of this xml is to make a meta/wrapper format for e-learning
resource delivery. Resource can be html, images, odp , video , audio.

Here is the intuitive syntax.
*
*
<eduvid>
       <resource type="html" src="asd.html" x="50%"  y="50%"  width="10%"
height="10%" z="6" xpath="page1" tIn="5000ms" tOut="9400ms"
inEffect="fadein" outEffect="fadeout" inEffectDur="1000ms"
outEffectDur="3000ms"/>

       <resource type="html" src="asd.html" x="50%"  y="50%"  width="10%"
height="10%" z="6" xpath="page2" tIn="5000ms" tOut="9400ms"
inEffect="fadein" outEffect="fadeout" inEffectDur="1000ms"
outEffectDur="3000ms"/>
</eduvid>


Explanation -

<resource/>  node will paste asd.html on a some specified area. the html
page will be shown in rectangular area where x and y coordinate will be 50%
50% located and their height and width will be 10%.  the z order will define
the vertical order of loading. tIn and tOut will tell when to load. for
example, this page will appear on 5 sec to 9.4 seconds. When it will appear
at 5th second, It will appear with fadein effect with 1 second duration.
similarly at exit time, it will take 3 second to fadeout.
     You can load specific section of page using xpath expressions.



resource can be audio, video etc.

for example

<resource type="video" src="file1.ogg" x="50%"  y="50%"  width="10%"
height="10%" z="6"  tIn="0ms"  tOut="30000ms" tStart="65000ms"/>


This will load video file1.ogg at t= 0 second. will play this file for 30
second. Player will start steaming this file from t="65 second" and end at
65+30=95 second.


resource can be Images

       <resource type="image" src="mypic.jpg" x="0%"  y="0%"  width="100%"
height="100%" z="2" xpath="" tIn="5000ms" tOut="9400ms" inEffect="fadein"
outEffect="fadeout" inEffectDur="1000ms" outEffectDur="3000ms"/>

resource can be svg images.

resource can be pdf/odp files. A Javascript based code will convert pdf/odp
files html and paste inside Slideshow container.

 <resource type="odp" src="presentation.odp" x="10%"  y="10%"  width="90%"
height="90%" z="1" xpath="page2" tIn="5000ms" tOut="9400ms"
inEffect="fadein" outEffect="fadeout" inEffectDur="1000ms"
outEffectDur="3000ms"/>

You can put multiple resource.

This type of syntax/format can lead to

* image based slideshow.
* html presentations
* audio embedded presentation
* e-learning content

Its more like a meta format for content delivery. Use will be able to view
e-learning content over web Or they will allowed to download all files into
a single zip file.



-- 
???????????????????????????
?    Narendra Sisodiya ( ???????? ???????? )
?    Society for Knowledge Commons
?    Web : http://narendra.techfandu.org
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100510/6cea45d5/attachment.htm>

From mjs at apple.com  Mon May 10 04:07:09 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Mon, 10 May 2010 04:07:09 -0700
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100508163137.117427i2mhxxh0ix@webmail-srv2.servage.net>
References: <20100508163137.117427i2mhxxh0ix@webmail-srv2.servage.net>
Message-ID: <AF2516FB-10F7-4681-83F8-B2E251042934@apple.com>


On May 8, 2010, at 9:31 AM, Juuso Hukkanen wrote:

>>> In fact, do you know of *any* examples of MITM attacks
>>> being successfully used against a public website?
>> "Pharming" is effectively a man-in-the-middle, and in
>> particular would be 100% effective at defeating the proposed  
>> security feature. http://en.wikipedia.org/wiki/Pharming
>
>
> Good point,
> I agree that *without* external authentication (see  
> auth="verisign"), pharming, poisoned DNS router or various kinds of  
> malicious software on users computer could lead UA into  
> communicating with attackers site or allow MITM to open the
> encryption. But if external authentication service is using the  
> auth="verisign" parameter, practical MITM attacks can be prevented.  
> Someone said auth="verisign" would not suffice. No it doesn't...  
> alone. I wanted the meta-encrypt footpring on pages to be small. So  
> the actual CA company signed sertificate, which confirms  
> pubkey="FAFFFA262662EAEEA" belonging to mydomainZZZ.com would be  
> found from
> https://www.verisign.com/certificates/FAFFFA262662EAEEA.sig AND
> http://www.mydomainZZZ.com/verisign.sig

I have no idea what auth="verisign" is supposed to do, but I think we  
need to rewind this conversation a little.

When designing a security feature, it's important to understand the  
threat model - what kind of attacks it's supposed to defend against,  
and what kind of attacks may be staged against it. Here are some of  
the possible attacks against passwords sent as cleartext over non-SSL  
HTTP:

1) Passive network attacks
     1.a) Password sniffed from network traffic - use on same site.
     1.b) Password sniffed from network traffic - guess that user has  
the same password on another site.

2) Active network attacks
     2.a) IP-level man-in-the-middle attack, possibly alter content to  
obtain passwords.
     2.b) DNS-level man-in-the-middle attack ("Pharming")

3) Active attacks against origin server
     3.a) Break into server to steal password database - use passwords  
on same site.
     3.b) Break into server to steal password database -  guess that  
users have the same password on another site.
     3.c) Break into server and sabotage served content to steal user  
data.

4) Social engineering attacks
     4.a) Phishing
     4.b) Targeted Phishing (aka "Spear Phishing" or "Whaling")

To the best of my knowledge, exclusive use of HTTPS combined with  
Strict Transport Security will defend against all of the listed  
passive and active network attacks, barring a violation of SSL itself.

I'm not aware of a foolproof way to ensure the security of the origin  
server or to defend against social engineering attacks. Storing  
passwords only in a salted and hashed form may partially protect  
against reusing those passwords on another site, but is vulnerable to  
offline dictionary attack. Using a one-time password scheme with a  
physical authentication token is a better defense, but impractical for  
most use cases.

My understanding of the current proposal is that it hashes all  
passwords entered in a form using SHA-256, and optionally salts the  
password with the domain name of the site, as requested by a meta tag.  
Let's look at how it holds up against the various threat models above:

1) Passive network attacks
     1.a) Sniff password to use on same site - COMPLETELY INEFFECTIVE  
- the password hash has no defense against replay attacks.
     1.b) Sniff passwords to use on same site - PARTIALLY EFFECTIVE -  
still vulnerable to offline dictionary attacks.

2) Active network attacks
     2.a) IP-level man-in-the-middle attack - COMPLETELY INEFFECTIVE -  
attacker can modify the page to remove the meta tag.
     2.b) DNS-level man-in-the-middle attack - COMPLETELY INEFFECTIVE  
- attacker can modify the page to remove the meta tag.

3) Active attacks against origin server
     3.a) Break into server to steal password database for same site -  
COMPLETELY INEFFECTIVE - you get hashed passwords you can use directly.
     3.b) Break into server to steal password database for use on  
other sites - MOSTLY INEFFECTIVE - still vulnerable to offline  
dictionary attacks, which will be highly effective against a large  
password database.
     3.c) Break into server and sabotage served content to steal user  
data - COMPLETELY INEFFECTIVE - attacker can modify the page to remove  
the meta tag.

4) Social engineering attacks
     4.a) Phishing - COMPLETELY INEFFECTIVE - phishing attack sites  
wouldn't use the meta tag.
     4.b) Targeted Phishing (aka "Spear Phishing" or "Whaling") - same  
reason as 4.a.

In conclusion, it seems that the proposed mechanism is completely  
ineffective at protecting the site using it, and only marginally  
effective at protecting other sites where users may have used the same  
login info.

I may have misunderstood how the proposed mechanism is supposed to  
work, if so, please provide more detail than the original sketchy  
account.

Regards,
Maciej


From and-py at doxdesk.com  Mon May 10 04:08:21 2010
From: and-py at doxdesk.com (And Clover)
Date: Mon, 10 May 2010 13:08:21 +0200
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
References: <20100507170626.25195chb0dgppms2@webmail-srv2.servage.net>
Message-ID: <4BE7E925.6090505@doxdesk.com>

On 05/07/2010 07:06 PM, Juuso Hukkanen wrote:

> the auth="verisign" argument, which _is_ enough to prevent all practical
> (,even if they are all theoretical!,) man-in-the-middle attacks.

No it doesn't. The initial page load stage is by necessity unencrypted, 
and so an active MitM attack could simply remove the tag, or add a JS 
keylogged script to the page, or whatever other method an attacker might 
choose. Unless the user is expected to view source and check every last 
byte of the page and scripts used in it (which will never happen), they 
have no way to know their communications are secure.

In any case, if you add CAs, your proposal becomes just as 'heavy' as 
HTTPS. What advantage does your proposal have over HTTPS, then? Because 
it appears to have many disadvantages.

As for password 'salting', client-side challenge-response authentication 
is already addressed much more securely by Digest Authentication, 
Kerberos, or JS approaches. And if you have HTTPS, it's not really so 
bad to send a plain password to the server, which will hopefully 
hash/salt it itself. You have to send a plain password in order to set 
it in the first place anyway.

> <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">

Don't do that. That's a basic, beginner-author XSS vulnerability.

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/

From ash at ashleysheridan.co.uk  Mon May 10 04:22:15 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Mon, 10 May 2010 12:22:15 +0100
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
Message-ID: <1273490535.21168.70.camel@localhost>

On Mon, 2010-05-10 at 04:34 +0000, JustFillBug wrote:

> 
> There should be a way to fetch available font to use in the document.
> Currently, the only popular way is to use Flash calls.
> 
> document.available_fonts() or document.local_font_list() will be very
> useful.
> 
> 
> 
> 


Isn't this a little pointless? There are currently ways for the popular
browsers to have fonts embedded through CSS3. At the moment, there are a
couple of methods used by various browsers, but I see it being more
likely that font embedding will become unified than having a font list
functionality being built into the spec and then all the browsers. I'm
no expert on these things, but this would just seem more logical to me.

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


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

From glsimpso at indiana.edu  Mon May 10 05:59:06 2010
From: glsimpso at indiana.edu (Simpson, Grant Leyton)
Date: Mon, 10 May 2010 08:59:06 -0400
Subject: [whatwg] Expanding the cite element
In-Reply-To: <AANLkTimBOQZVVgaa6fTiUWFUm2cJf03-TA8Lpns6j-te@mail.gmail.com>
References: <4D1073C1-9C15-41D7-9301-4B4B723D1958@indiana.edu>
	<m2v3b31caf91005060814q2f76e1danef5c36b1eca07491@mail.gmail.com>
	<A695BF56-E39E-4C65-B2B3-BDC14999F6F0@indiana.edu>
	<AANLkTimBOQZVVgaa6fTiUWFUm2cJf03-TA8Lpns6j-te@mail.gmail.com>
Message-ID: <FD248B7D-9A28-4CD3-8915-CF0003E5B925@indiana.edu>

I was unaware of the Microdata spec.  Now that I have seen it, I think it offers a lot of power and flexibility.  I think it should adequately cover the use case I was thinking of.

I'm in favor of adding a non-normative note to the section of the HTML5 spec that discusses <cite> that demonstrates how Microdata or RDFa could be used for this purpose.  There will likely be other people like me who read the <cite> section of the spec and think "What? I can't actually make the citation point to something?"

On May 8, 2010, at 8:41 AM, Benjamin Hawkes-Lewis wrote:

I'm not opposed to adding @cite to <cite> but note that when you are
identifying a resource rather than linking to a resource, you could use
microdata or RDFa.

For example:

  http://dev.w3.org/html5/md/#global-identifiers-for-items

  http://rdfa.info/wiki/Rdfa-microdata-markup-comparison#Book_markup_with_ISBN_and_description

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

From ojan at chromium.org  Mon May 10 07:27:23 2010
From: ojan at chromium.org (Ojan Vafai)
Date: Mon, 10 May 2010 07:27:23 -0700
Subject: [whatwg] Request for new DOM property textarea.selectionText
In-Reply-To: <AANLkTinFcffemAo94FCkOwPdYq_DX2gi1e_Z_ZpLtCKt@mail.gmail.com>
References: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com> 
	<op.vcg62zzc64w2qv@annevk-t60>
	<AANLkTinFcffemAo94FCkOwPdYq_DX2gi1e_Z_ZpLtCKt@mail.gmail.com>
Message-ID: <w2q78dc8441005100727v5568d0a0jed02aa1b139a8c7c@mail.gmail.com>

In addition to selection and scroll issues, needing to replace the entire
textarea value doesn't scale and thus limits what sorts of things you can do
with textareas. A general way to set a sub-part of a textarea's value seems
useful to me. I don't think we should tie that to setting the selected text
though.

textarea.setRangeText(start, end, text);

It replaces the text between start and end, maintains current scroll
position and preserves the selection.

Ojan

On Mon, May 10, 2010 at 12:59 AM, Biju <bijumaillist at gmail.com> wrote:

> Current way in firefox is to
>
> 1. OrigStart = textarea.selectionStart
> 2.  textarea.value = textarea.value.substr(0, OrigStart)
>                          + new_text_to_replace
>                          + textarea.value.substr(textarea.selectionEnd);
> 3. Now u loose original selection, so
>
> 4.  textarea.setSelectionRange(OrigStart,
>  OrigStart+new_text_to_replace.length)
> 5.  remember .scrollTop and reapply if needed
>
> Now if we are only changing few selected characters in TEXTAREA with
> big text content,
> we are unnecessarily replacing entire content, which is inefficient.
>
>
> On IE even though wierd you can do it simply by
>   document.selection.createRange().text = new_text_to_replace;
> BTW, you need to make sure the selection is currently on the
> textarea/input form control.
> IE is also very fast when doing that, when firefox hangs few second
> using the other way
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100510/fb9d66da/attachment.htm>

From daniel.glazman at disruptive-innovations.com  Mon May 10 08:50:18 2010
From: daniel.glazman at disruptive-innovations.com (Daniel Glazman)
Date: Mon, 10 May 2010 17:50:18 +0200
Subject: [whatwg] Request for new DOM property textarea.selectionText
In-Reply-To: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>
References: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>
Message-ID: <4BE82B3A.9070508@disruptive-innovations.com>

Le 10/05/10 07:11, Biju a ?crit :

> Can we have a new DOM property textarea.selectionText
> which can be used to set/get selection text of a TEXTAREA/INPUT type=text.
>
> Current method is complicated and varies between IE and Firefox

Oh!!! As a read/write property, right?

With my editor implementor's hat on, that's a _very_ neat idea I must
say... I really like it. Probably one or two edge cases to document but
I definitely support this proposal.

</Daniel>

From connect2shashi at gmail.com  Mon May 10 08:53:57 2010
From: connect2shashi at gmail.com (Shashi)
Date: Mon, 10 May 2010 11:53:57 -0400
Subject: [whatwg] Request for new DOM property textarea.selectionText
In-Reply-To: <4BE82B3A.9070508@disruptive-innovations.com>
References: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>
	<4BE82B3A.9070508@disruptive-innovations.com>
Message-ID: <AANLkTikDWFcF3nxVwMjU74rFh7QyEXiNkq5NlkSjbdin@mail.gmail.com>

>> Can we have a new DOM property textarea.selectionText
> I definitely support this proposal.

Me too, if that counts. =)

--
Shashi - identi.ca/shashi

From jsalsman at gmail.com  Mon May 10 10:12:27 2010
From: jsalsman at gmail.com (James Salsman)
Date: Mon, 10 May 2010 10:12:27 -0700
Subject: [whatwg] E-learning content format
In-Reply-To: <AANLkTimY9OfTLZ54qIKHHNLTOpRdmdd3lxcTX82D605k@mail.gmail.com>
References: <AANLkTimY9OfTLZ54qIKHHNLTOpRdmdd3lxcTX82D605k@mail.gmail.com>
Message-ID: <n2ga3c2bd6c1005101012u89a570e9gaa3de28952e4edec@mail.gmail.com>

On Mon, May 10, 2010 at 3:28 AM, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
> I am making a elearing tool for while i have trying to go with some xml
> syntax.

Narenda,

Have you examined Moodle's xml format?

I also strongly recommend their GIFT picoformat:
http://microformats.org/wiki/gift

Regards,
James Salsman

From narendra at narendrasisodiya.com  Mon May 10 10:41:38 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Mon, 10 May 2010 23:11:38 +0530
Subject: [whatwg] E-learning content format
In-Reply-To: <n2ga3c2bd6c1005101012u89a570e9gaa3de28952e4edec@mail.gmail.com>
References: <AANLkTimY9OfTLZ54qIKHHNLTOpRdmdd3lxcTX82D605k@mail.gmail.com>
	<n2ga3c2bd6c1005101012u89a570e9gaa3de28952e4edec@mail.gmail.com>
Message-ID: <AANLkTikpKSmJuGqnuFWD_YSVyvu6duXyg3vKNbiHbxOe@mail.gmail.com>

On Mon, May 10, 2010 at 10:42 PM, James Salsman <jsalsman at gmail.com> wrote:

> On Mon, May 10, 2010 at 3:28 AM, narendra sisodiya
> <narendra at narendrasisodiya.com> wrote:
> > I am making a elearing tool for while i have trying to go with some xml
> > syntax.
>
> Narenda,
>
> Have you examined Moodle's xml format?
>
> I also strongly recommend their GIFT picoformat:
> http://microformats.org/wiki/gift
>
> Regards,
> James Salsman
>

Thanks , Let me check..

-- 
???????????????????????????
?    Narendra Sisodiya ( ???????? ???????? )
?    Society for Knowledge Commons
?    Web : http://narendra.techfandu.org
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100510/7ecb4ed1/attachment.htm>

From pedzsan at gmail.com  Mon May 10 11:10:45 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Mon, 10 May 2010 13:10:45 -0500
Subject: [whatwg] getElementById
Message-ID: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>

I see places that explicitly state that the same object is returned on some operations.  For example, the element.style has that clause.

I have not found in either html5 or the DOM documentation that is referenced an explicit statement to this effect for getElementById.

In FF 3.5, it seems to be true but it would be nice to know if it is or is not something that can be depended upon.

The other part to this that is not explicitly mentioned is if I attach a new javascript attribute to the object, is that legal?  Is it defined to work?  I have not found a statement one way or the other.

e.g.

foo = getElementById('foo');
foo.newAttr = true;

/* later */

foo = getElementById('foo');
if (foo.newAttr) {
  alert("happy happy joy joy");
}

Thank you,
Perry


From timeless at gmail.com  Mon May 10 13:06:09 2010
From: timeless at gmail.com (timeless)
Date: Mon, 10 May 2010 23:06:09 +0300
Subject: [whatwg] getElementById
In-Reply-To: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
Message-ID: <AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>

On Mon, May 10, 2010 at 9:10 PM, Perry Smith <pedzsan at gmail.com> wrote:
> I see places that explicitly state that the same object is returned on some operations. ?For example, the element.style has that clause.
>
> I have not found in either html5 or the DOM documentation that is referenced an explicit statement to this effect for getElementById.

if someone changes the id value on the node you used to think about
and assigns it to another node then it most certainly will not return
the same node.

From pedzsan at gmail.com  Mon May 10 14:27:07 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Mon, 10 May 2010 16:27:07 -0500
Subject: [whatwg] getElementById
In-Reply-To: <AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
	<AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
Message-ID: <357FA5BA-172F-4FCD-A55B-89A455C03C48@gmail.com>


On May 10, 2010, at 3:06 PM, timeless wrote:

> On Mon, May 10, 2010 at 9:10 PM, Perry Smith <pedzsan at gmail.com> wrote:
>> I see places that explicitly state that the same object is returned on some operations.  For example, the element.style has that clause.
>> 
>> I have not found in either html5 or the DOM documentation that is referenced an explicit statement to this effect for getElementById.
> 
> if someone changes the id value on the node you used to think about
> and assigns it to another node then it most certainly will not return
> the same node.

Yea, that is an interesting point.

I wonder also if I change the id for the node to 'dog' and then do getElementById('dog') if it will give me back the same javascript object with newAttr set.

I am not sure if I am making myself clear.  The question(s) boils down to, are these objects going to behave consistently as javascript objects.

There are different ways the browser could implement the mapping from DOM elements to javascript objects.

For example, the following code could fail and not give the alert box:

foo = getElementById('foo');
foo.newAttr = 1;
if (foo.newAttr)
  alert("hi");

The setting of newAttr could simply not work at all.  The browser could throw it away.  There is nothing I see that says that it must work.  I say this because there are particular methods and attributes defined.  No mention is made of other attributes.  They could do anything including throw an exception, silently fail, or randomly do something else.

I might have missed something obvious.

Perry




From juuso_html5 at tele3d.net  Mon May 10 15:40:58 2010
From: juuso_html5 at tele3d.net (Juuso Hukkanen)
Date: Mon, 10 May 2010 22:40:58 +0000
Subject: [whatwg] meta="encrypt" tag is needed
Message-ID: <20100510224058.88643zifc3q21unu@webmail-srv2.servage.net>

Thanks Mikko for linking to those passsalt generator tools. And thanks
Maciej for that analysis. Good that you at least see some benefit about
the passsalt parameter ;)

Good to know there are already tools that do the for of salting thing  
locally ( http://supergenpass.com/ ) I'd like nothing more than UAs to  
do the same and be guided to do that by HTML5.01.

Ok so I think passsalt is rather simple one, shouldn't have much complications

and as shown below site could choose to demand plain text passwords. Below

are the allowed values for passsalt. Unfortunately you all maybe right

that authenticated stateless active MITM attacks can't be avoided that  
simply -
Damn you Mallory. So that PKI could only protect against *most* cases  
of passive
listeners who the hell want's such, after all there might be some  
academic person next door playing with newest version PKI sniffing  
tools.


To me passalt is the important one. https can take care of  properly  
authenticated
  encryption,... but it sure would be nice if some PKI encryption

could be baked in HTML forms. help your self if you like that too.


> How about explaining what those attributes do, WHY would you want
> to use those and what are allowed values for each attribute.

PASSSALT:
^^^^^^^^^^
Attributes:
<meta encrypt <=> Identification tag for html 5.01 content for 5.01  
conforming UAs


passsalt="no|domainname"
^^^^^^^^^^^^^^^^^^^^^^^
1) no <=> UAs should send passwords unsalted (e.g. for the sake of  
compatibility)

2) yes <=> (default value, 5.01 conforming UAs will salt passwords  
using domain name)

3) domainname <=> domain(+TLD), if site wants hashes salted using it's  
current or some another domain name

4) in all other cases:
	a) empty string OR
	b) invalid domain name OR
	c) passsalt argument is not given at all
    <=> passwords are to be salted with domainname

5) passsalt argument could also be given as an argument of <form> -tag

how UAs should do the passsalt salting
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1) read the lowercase utf-8 string of domainname (e.g. mydomain.com)
2) read the users given password
3) calculate sha256(password+domainname)
4) take the first 24 chars of hex output and submit those as password

I have no opinion if HTML5.01 should define a minimum lenght to which salted
passwords would be truncated. Or should the password field lengths be as the
form defines them


Why passsalt in html5.xx specification
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1) multi-use of same passwords is a growing security problem. A  
successfull stealing single sites unencrypted real person names +  
passwords can lead to thousands of ID theft cases.
2) Voluntary salting of passwords has failed even on reputable sites.
3) Forcing the passwords salted is one solution. But the UA needs to  
know if it should send password salted or unsalted. Situation where  
one UA would send salted password and another unsalted is unacceptable
4) defining the salting requirement in html5.xx would tell to UAs  
about the sites readiness to accept salted passwords if the page would  
not be marked html5.xx+ (or passsalt="no") UA would send passwords  
unsalted


-----
> You referred to "alypaa.com" case in your original post. Could you
> explain why do you think this would prevent from similar information
> leak in the future?


1) Site had stored the it's email addresses and passwords in unsalted format.
And as often is the case, same password had been multi-used on many sites.
If the alypaa.com had only gotten salted passwords from UA, it could not have
leaked out the passwords to peoples email, blog and facebook accounts.

"I did a test around year 2001 when I stumbled upon a small but similar
list (200+) of email addresses and "forgotten passwords". So, I send  
emails to all saying hi email if this is your password change it where  
you use it, because
anyone could find it at the internet. about 70% replied back to me and  
of those about a third said it's a bogus password, only for bogus  
sites. about a third thanked and said to be changing the passwords  
where needed. and about a third were furious and threatening to sue me  
for hacking his/her important password."

2) do you multi-use same passwords? (yes)

3) do you expect all login-requiring internet sites to start using https? (no)

4) do you expect all login-requiring internet sites to start salting  
passwords? (no)


You all had a million good questions, sorry but I will not elaborate anything
anymore as I am already busy and leaving this mailing list now.  
Fortunately, I am sure you all can consider the benefits and risks(?)  
of forcing passwords salted. Nice if that can be somehow applied into  
HTML standard; with or without PKI encryption parameters.

Juuso


From pedzsan at gmail.com  Mon May 10 20:28:13 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Mon, 10 May 2010 22:28:13 -0500
Subject: [whatwg] getElementById
In-Reply-To: <AANLkTilgZAlHkkTxws7AdLLhEK5NDTMKCeI82iBiAo79@mail.gmail.com>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
	<AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
	<357FA5BA-172F-4FCD-A55B-89A455C03C48@gmail.com>
	<AANLkTimwFWcxF2nMtrzEUxSFNin_E1j_aMldUyXUQrnk@mail.gmail.com>
	<E3EB3EE2-5947-4B99-805F-CC185C38B934@gmail.com>
	<AANLkTilgZAlHkkTxws7AdLLhEK5NDTMKCeI82iBiAo79@mail.gmail.com>
Message-ID: <DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>


On May 10, 2010, at 7:04 PM, Garrett Smith wrote:

> On Mon, May 10, 2010 at 4:55 PM, Perry Smith <pedzsan at gmail.com> wrote:
>> 
>> On May 10, 2010, at 5:12 PM, Garrett Smith wrote:
>> 
>>> On Mon, May 10, 2010 at 2:27 PM, Perry Smith <pedzsan at gmail.com> wrote:
>>>> 
>>>> On May 10, 2010, at 3:06 PM, timeless wrote:
>>>> 
>>>>> On Mon, May 10, 2010 at 9:10 PM, Perry Smith <pedzsan at gmail.com> wrote:
>>>>>> I see places that explicitly state that the same object is returned on some operations.  For example, the element.style has that clause.
>>>>>> 
>>>>>> I have not found in either html5 or the DOM documentation that is referenced an explicit statement to this effect for getElementById.
>>>>> 
>>>>> if someone changes the id value on the node you used to think about
>>>>> and assigns it to another node then it most certainly will not return
>>>>> the same node.
>>>> 
>>>> Yea, that is an interesting point.
>>>> 
>>>> I wonder also if I change the id for the node to 'dog' and then do getElementById('dog') if it will give me back the same javascript object with newAttr set.
>>>> 
>>> 
>>> Careful, it might actually not be a native ECMAScript object that you
>>> get back. A host object could be implemented as a native ECMAScript
>>> object, as seen in many implementations, but, as seen in recent
>>> discussions, MSIE <= 8 has host objects that are not native objects
>>> and that do throw errors.
>> 
>> That is what I'm asking.  I can't find where that is allowed (in the spec) or not allowed in a conforming UA.
>> 
> 
> Any DOM object is a host object in ECMAScript parlance and host
> objects have great liberty.
> 
> Look how IE's shoddy catchall implementation of the styleSheets "dhtml
> collection" blows up on numeric [[Get]] access:
> 
> alert(document.styleSheets[99999]); // Boom.
> javascript: alert(document.styleSheets['a']); // OK
> 
> More indications on host objects in IE will show that they are not
> native ECMAScript objects.
> 
> javascript: alert(document.body.valueOf); // undefined.
> 
> javascript: alert([].slice.call(document.childNodes)); // Boom.
> 
>>> 
>>>> I am not sure if I am making myself clear.  The question(s) boils down to, are these objects going to behave consistently as javascript objects.
>>>> 
>>>> There are different ways the browser could implement the mapping from DOM elements to javascript objects.
>>>> 
>>>> For example, the following code could fail and not give the alert box:
>>>> 
>>>> foo = getElementById('foo');
>>>> foo.newAttr = 1;
>>>> if (foo.newAttr)
>>>>  alert("hi");
>>>> 
>>>> The setting of newAttr could simply not work at all.  The browser could throw it away.  There is nothing I see that says that it must work.  I say this because there are particular methods and attributes defined.  No mention is made of other attributes.  They could do anything including throw an exception, silently fail, or randomly do something else.
>>>> 
>>> 
>>> The code attempts to assign a property, not an attribute.
>>> 
>>> Setting a property such as newAttr is not specified. If it throws an
>>> error or does nothing, it is your fault.
>> 
>> Ok.  (Sorry for the incorrect use of terms.)  If setting a property is not specified, that means that a conforming UA can disallow setting properties.  Or it could silently ignore the attempt to set a property.  Is that what was intended?
>> 
> Yes. An implementation can also throw errors with that. Nothing in
> HTML 5 prevents that. Nothing in ECMAScript prevents that, for host
> objects.
> 
> The browser can do whatever it wants with that property. Take a look
> at MSIE document.expando.

Wow.  I happened to pull down the ECMAScript 5 doc this past weekend to understand exactly how an event handler is called.  html5 refers to functions defined in the ECMAScript doc.  But I've never heard of "host objects".  The first hit in the EMCAScript 5 doc for host object tells all.  These guys did not learn from the mistakes of Pascal.  An utterly hopeless feeling came over me.

So, how about this?

As part of HTMLElement, have a defined bucket, maybe call it elementObject which is defined to be a native ECMAScript object.  If X denotes a particular DOM element, then X.elementObject is defined to return the same native ECMAScript object each time.  More details could be added perhaps to define how the object is created (i.e. which prototype to use, etc).  I'm thinking making it the same as {}.




From derhoermi at gmx.net  Mon May 10 20:35:14 2010
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue, 11 May 2010 05:35:14 +0200
Subject: [whatwg] getElementById
In-Reply-To: <DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
	<AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
	<357FA5BA-172F-4FCD-A55B-89A455C03C48@gmail.com>
	<AANLkTimwFWcxF2nMtrzEUxSFNin_E1j_aMldUyXUQrnk@mail.gmail.com>
	<E3EB3EE2-5947-4B99-805F-CC185C38B934@gmail.com>
	<AANLkTilgZAlHkkTxws7AdLLhEK5NDTMKCeI82iBiAo79@mail.gmail.com>
	<DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>
Message-ID: <7tjhu5di7lk4teudliu4eaei9crh24g9jr@hive.bjoern.hoehrmann.de>

* Perry Smith wrote:
>As part of HTMLElement, have a defined bucket, maybe call it
>elementObject which is defined to be a native ECMAScript object.  If X
>denotes a particular DOM element, then X.elementObject is defined to
>return the same native ECMAScript object each time.  More details could
>be added perhaps to define how the object is created (i.e. which
>prototype to use, etc).  I'm thinking making it the same as {}.

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-getUserData allows
you to associate user data with a DOM Node object with gurantees about
the availability of the data when a node is eg. cloned if used properly.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From dhtmlkitchen at gmail.com  Mon May 10 20:54:14 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 10 May 2010 20:54:14 -0700
Subject: [whatwg] getElementById
In-Reply-To: <DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
	<AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
	<357FA5BA-172F-4FCD-A55B-89A455C03C48@gmail.com>
	<AANLkTimwFWcxF2nMtrzEUxSFNin_E1j_aMldUyXUQrnk@mail.gmail.com>
	<E3EB3EE2-5947-4B99-805F-CC185C38B934@gmail.com>
	<AANLkTilgZAlHkkTxws7AdLLhEK5NDTMKCeI82iBiAo79@mail.gmail.com>
	<DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>
Message-ID: <AANLkTikFunHjQksT3nBmi7Ob_BR5F5-vtdaQyf-1deb_@mail.gmail.com>

On Mon, May 10, 2010 at 8:28 PM, Perry Smith <pedzsan at gmail.com> wrote:
>
> On May 10, 2010, at 7:04 PM, Garrett Smith wrote:
>
>> On Mon, May 10, 2010 at 4:55 PM, Perry Smith <pedzsan at gmail.com> wrote:
>>>
>>> On May 10, 2010, at 5:12 PM, Garrett Smith wrote:
>>>
>>>> On Mon, May 10, 2010 at 2:27 PM, Perry Smith <pedzsan at gmail.com> wrote:
>>>>>
>>>>> On May 10, 2010, at 3:06 PM, timeless wrote:
>>>>>
>>>>>> On Mon, May 10, 2010 at 9:10 PM, Perry Smith <pedzsan at gmail.com> wrote:
>>>>>>> I see places that explicitly state that the same object is returned on some operations. ?For example, the element.style has that clause.

[...]

>> The browser can do whatever it wants with that property. Take a look
>> at MSIE document.expando.
>
> Wow. ?I happened to pull down the ECMAScript 5 doc this past weekend to understand exactly how an event handler is called. ?html5 refers to functions defined in the ECMAScript doc. ?But I've never heard of "host objects". ?The first hit in the EMCAScript 5 doc for host object tells all. ?These guys did not learn from the mistakes of Pascal. ?An utterly hopeless feeling came over me.
>

I see you've put our discussion back on list. I'm OK with that.

HTML 5 refers to ECMAScript for defining Function.

However ECMAScript does not specify anything about event handlers,
document, or any other host objects.  An addition to the 5th edition,
and a very good one, is the requirement for host objects to implement
many of the semantics defined in the specification (see table 8).

The ECMAScript committee has some incredibly smart and hard working
individuals for whom I have a good deal of respect.

One thing not specified yet in ECMAScript is catchalls, and that is
necessary to implement some existing browser behavior that is
partially specified by HTML 5. Catchalls is an active proposal.

To learn more about Ecmascript, the es-discuss mailing list and
comp.lang.javascript may be of interest.

The pertinent section of the FAQ:
http://www.jibbering.com/faq/#objects

> So, how about this?
>
> As part of HTMLElement, have a defined bucket, maybe call it elementObject which is defined to be a native ECMAScript object. ?If X denotes a particular DOM element, then X.elementObject is defined to return the same native ECMAScript object each time. ?More details could be added perhaps to define how the object is created (i.e. which prototype to use, etc). ?I'm thinking making it the same as {}.
>

WebIDL could require DOM objects to be implemented as native ECMAScript objects.

From dhtmlkitchen at gmail.com  Mon May 10 20:55:03 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 10 May 2010 20:55:03 -0700
Subject: [whatwg] getElementById
In-Reply-To: <7tjhu5di7lk4teudliu4eaei9crh24g9jr@hive.bjoern.hoehrmann.de>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
	<AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
	<357FA5BA-172F-4FCD-A55B-89A455C03C48@gmail.com>
	<AANLkTimwFWcxF2nMtrzEUxSFNin_E1j_aMldUyXUQrnk@mail.gmail.com>
	<E3EB3EE2-5947-4B99-805F-CC185C38B934@gmail.com>
	<AANLkTilgZAlHkkTxws7AdLLhEK5NDTMKCeI82iBiAo79@mail.gmail.com>
	<DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>
	<7tjhu5di7lk4teudliu4eaei9crh24g9jr@hive.bjoern.hoehrmann.de>
Message-ID: <AANLkTimd-HENeKE174oReLgj19m3YPj6cEqMWdJoOag8@mail.gmail.com>

On Mon, May 10, 2010 at 8:35 PM, Bjoern Hoehrmann <derhoermi at gmx.net> wrote:
> * Perry Smith wrote:
>
[...]

> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-getUserData allows
> you to associate user data with a DOM Node object with gurantees about
> the availability of the data when a node is eg. cloned if used properly.

Doesn't work cross browser.

From ian at hixie.ch  Mon May 10 21:25:12 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 11 May 2010 04:25:12 +0000 (UTC)
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
Message-ID: <Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>

On Mon, 10 May 2010, JustFillBug wrote:
> 
> There should be a way to fetch available font to use in the document. 
> Currently, the only popular way is to use Flash calls.
> 
> document.available_fonts() or document.local_font_list() will be very 
> useful.

Whether this would be useful or not I'm not sure, but in either case, 
that's a features for the CSSOM, not HTML. I recommend bringing this up on 
the CSS list (www-style at w3.org).

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

From hello at richclarkdesign.com  Tue May 11 01:06:11 2010
From: hello at richclarkdesign.com (Richard Clark)
Date: Tue, 11 May 2010 09:06:11 +0100
Subject: [whatwg] Paragraphs in blockquotes
Message-ID: <AANLkTikEQxBvKHmiLhuZ64z088skor2QcrUO-ufCU38K@mail.gmail.com>

Hi

We recently received an email from one of our readers on
html5doctor.com that went like this:


"Hi, in HTML 4.0 Strict & XHTML 1.0 Strict, text inside a blockquote
element is required to be nested inside another block-level element,
e.g. p.
In HTML5 that requirement seems to have been relaxed, as the following
element validates successfully:

<blockquote>This is a blockquote.</blockquote>

The HTML5 spec uses the p element in the usage examples, but does not
mention whether it is required.

Can you please confirm if this requirement has now been deprecated?"


We tested the below which successfully validated:

<!doctype html>
<meta charset=utf-8>
<title>blockquote test</title>
<blockquote>Tiger tiger burning bright</blockquote>

So the question is, are block level elements required in blockquotes
or can the p's be removed from the examples in the spec?

Regards

Rich

------------------------------------------
Twitter: http://twitter.com/rich_clark
http://html5doctor.com
http://html5gallery.com

From myakura.web at gmail.com  Tue May 11 01:37:19 2010
From: myakura.web at gmail.com (Masataka Yakura)
Date: Tue, 11 May 2010 17:37:19 +0900
Subject: [whatwg] Paragraphs in blockquotes
In-Reply-To: <AANLkTikEQxBvKHmiLhuZ64z088skor2QcrUO-ufCU38K@mail.gmail.com>
References: <AANLkTikEQxBvKHmiLhuZ64z088skor2QcrUO-ufCU38K@mail.gmail.com>
Message-ID: <AANLkTilfjxdLOi7nRevivBaGJnqRb7LNuRvmO01tggMW@mail.gmail.com>

Hello.

On Tue, May 11, 2010 at 5:06 PM, Richard Clark
<hello at richclarkdesign.com> wrote:
> Hi
>
> We recently received an email from one of our readers on
> html5doctor.com that went like this:
>
>
> "Hi, in HTML 4.0 Strict & XHTML 1.0 Strict, text inside a blockquote
> element is required to be nested inside another block-level element,
> e.g. p.
> In HTML5 that requirement seems to have been relaxed, as the following
> element validates successfully:
>
> <blockquote>This is a blockquote.</blockquote>
>
> The HTML5 spec uses the p element in the usage examples, but does not
> mention whether it is required.
>
> Can you please confirm if this requirement has now been deprecated?"
>
>
> We tested the below which successfully validated:
>
> <!doctype html>
> <meta charset=utf-8>
> <title>blockquote test</title>
> <blockquote>Tiger tiger burning bright</blockquote>
>
> So the question is, are block level elements required in blockquotes
> or can the p's be removed from the examples in the spec?
>
> Regards
>
> Rich
>
> ------------------------------------------
> Twitter: http://twitter.com/rich_clark
> http://html5doctor.com
> http://html5gallery.com
>

<blockquote> can take any flow content, which is defined as:

> Most elements that are used in the body of documents and applications are categorized as flow content.
>
> a abbr address area (if it is a descendant of a map element) article aside audio b bdo blockquote br button canvas cite code command datalist del details dfn div dl em embed fieldset figure footer form h1 h2 h3 h4 h5 h6 header hgroup hr i iframe img input ins kbd keygen label link (if the itemprop attribute is present) map mark math menu meta (if the itemprop attribute is present) meter nav noscript object ol output p pre progress q ruby samp script section select small span strong style (if the scoped attribute is present) sub sup svg table textarea time ul var video wbr text

<http://www.whatwg.org/html5#flow-content>

So in HTML5 <blockquote> doesn't require inline contents to be nested
inside another block elements (you may know but that was acceptable
too in HTML4 Transitional).


Regards,
--
Masataka Yakura
<myakura.web at gmail.com>

From jrn at jrn.me.uk  Tue May 11 01:43:37 2010
From: jrn at jrn.me.uk (J Ross Nicoll)
Date: Tue, 11 May 2010 09:43:37 +0100
Subject: [whatwg] New File attributes creationDate, modificationDate and size
Message-ID: <4BE918B9.5070906@jrn.me.uk>

Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file

There doesn't appear to be anyway of retrieving creation date, 
modification date or size of the file. Could I suggest adding attributes 
creationDate, modificationDate and size to provide this information?

For a use case; we're working an a student coursework submission system, 
where they'll be able to drag and drop files. It would be useful to show 
the student details of the file they're uploading (for example, 
modification date is useful to confirm they're uploading the most recent 
version). We do actually see a fairly large number of mis-uploads with 
the existing upload system, and are hoping exposing more information 
during the upload (rather than once the file is received) will help.

From info at html5.jp  Tue May 11 01:49:32 2010
From: info at html5.jp (Futomi Hatano)
Date: Tue, 11 May 2010 17:49:32 +0900
Subject: [whatwg] Paragraphs in blockquotes
In-Reply-To: <AANLkTikEQxBvKHmiLhuZ64z088skor2QcrUO-ufCU38K@mail.gmail.com>
References: <AANLkTikEQxBvKHmiLhuZ64z088skor2QcrUO-ufCU38K@mail.gmail.com>
Message-ID: <20100511174932.F253.C8DE7135@html5.jp>

On Tue, 11 May 2010 09:06:11 +0100
Richard Clark <hello at richclarkdesign.com> wrote:

> In HTML5 that requirement seems to have been relaxed, as the following
> element validates successfully:
> 
> <blockquote>This is a blockquote.</blockquote>
> 
> The HTML5 spec uses the p element in the usage examples, but does not
> mention whether it is required.
> 
> Can you please confirm if this requirement has now been deprecated?"

The content model for <blockquote> is Flow content.
Flow content includes "text".
So, the text as a child of <blockquote> is valid.

The spec says that a run of phrasing content (in this case, it is the text.) is a paragraph.
http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#paragraph
So, the examples below have same semantics.

<blockquote>This is a blockquote.</blockquote>
<blockquote><p>This is a blockquote.</p></blockquote>

The former is valid, but, of course, authers are encouraged the latter much more.

Regards
Futomi

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


From daniel.glazman at disruptive-innovations.com  Tue May 11 02:14:44 2010
From: daniel.glazman at disruptive-innovations.com (Daniel Glazman)
Date: Tue, 11 May 2010 11:14:44 +0200
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
Message-ID: <4BE92004.9080007@disruptive-innovations.com>

Le 11/05/10 06:25, Ian Hickson a ?crit :

>> document.available_fonts() or document.local_font_list() will be very
>> useful.
>
> Whether this would be useful or not I'm not sure, but in either case,
> that's a features for the CSSOM, not HTML. I recommend bringing this up on
> the CSS list (www-style at w3.org).

Hmmmm. Probably not. It's really a system/OS API.
I'm Cc:ing Robin Berjon here.

Please note there's a rather strong privacy issue here. I don't want a
web page to be able - without my prior consent - to query the list of
fonts available in my system.

</Daniel>


From ekilfeather at dmc.dit.ie  Tue May 11 02:17:38 2010
From: ekilfeather at dmc.dit.ie (Eoin Kilfeather)
Date: Tue, 11 May 2010 10:17:38 +0100
Subject: [whatwg] Audio Panning - Bump
Message-ID: <AANLkTinEL0akrqLg8DUM7IilLroYaBWwKCovGMEE7t6e@mail.gmail.com>

Hello,

A Google search on the discussion list returns the unanswered question
from Keith Bauer
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024340.html)
below. I'm working on an application which has two separate channels
of sound panned fully left and right in a stereo audio file. The
application is for language learners and it would be very useful to
set the audio pan position fully left or right to effectively "mute"
one speaker. As the draft spec stands the only solution that presents
itself is to split the stereo file into two and load two <audio>
elements in the HTML. I haven't tried this yet but I suspect it will
be a headache. Any chance of reviving panning?

Keith Bauer onesadcookie at gmail.com
Sat Dec 5 17:19:59 PST 2009

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

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

Or is WebGL to be followed shortly by WebAL ;)

-Keith

[see also - http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/010231.html]
-- 
Eoin Kilfeather
Digital Media Centre
Dublin Institute of Technology

From eitanadlerlist at gmail.com  Tue May 11 02:32:56 2010
From: eitanadlerlist at gmail.com (Eitan Adler)
Date: Tue, 11 May 2010 12:32:56 +0300
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <4BE92004.9080007@disruptive-innovations.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org> 
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com> 
	<4BE92004.9080007@disruptive-innovations.com>
Message-ID: <l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>

> Please note there's a rather strong privacy issue here. I don't want a
> web page to be able - without my prior consent - to query the list of
> fonts available in my system.

You already have this problem if a website were to create a list of
elements with a list of different fonts and use Javascript to
determine which font is being displayed. [1]

I'm not advocating opening another hole just because one already
exists - I'm just pointing this out.

[1] http://www.lalit.org/lab/javascript-css-font-detect

From ash at ashleysheridan.co.uk  Tue May 11 04:28:34 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 11 May 2010 12:28:34 +0100
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
Message-ID: <1273577314.21168.136.camel@localhost>

On Tue, 2010-05-11 at 12:32 +0300, Eitan Adler wrote:

> > Please note there's a rather strong privacy issue here. I don't want a
> > web page to be able - without my prior consent - to query the list of
> > fonts available in my system.
> 
> You already have this problem if a website were to create a list of
> elements with a list of different fonts and use Javascript to
> determine which font is being displayed. [1]
> 
> I'm not advocating opening another hole just because one already
> exists - I'm just pointing this out.
> 
> [1] http://www.lalit.org/lab/javascript-css-font-detect


It's not as clear cut as you make it sound. That script works on the
basis that the glyphs within a font have different widths compared to
the same glyph of another font. What happens when two fonts have exactly
the same dimensions for their glyphs? The script will register a false
positive. As such, I don't think its a security flaw or anything to
overly worry about.

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


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

From daniel.glazman at disruptive-innovations.com  Tue May 11 04:47:18 2010
From: daniel.glazman at disruptive-innovations.com (Daniel Glazman)
Date: Tue, 11 May 2010 13:47:18 +0200
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <1273577314.21168.136.camel@localhost>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>	
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>	
	<4BE92004.9080007@disruptive-innovations.com>	
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
Message-ID: <4BE943C6.4080008@disruptive-innovations.com>

Le 11/05/10 13:28, Ashley Sheridan a ?crit :

> It's not as clear cut as you make it sound. That script works on the
> basis that the glyphs within a font have different widths compared to
> the same glyph of another font. What happens when two fonts have exactly
> the same dimensions for their glyphs? The script will register a false
> positive. As such, I don't think its a security flaw or anything to
> overly worry about.

Another detection technique based on the computed style of the
'font-family' property would work much better.

</Daniel>

From bzbarsky at MIT.EDU  Tue May 11 06:33:29 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 11 May 2010 09:33:29 -0400
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <4BE943C6.4080008@disruptive-innovations.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>		<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>		<4BE92004.9080007@disruptive-innovations.com>		<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
Message-ID: <4BE95CA9.2010802@mit.edu>

On 5/11/10 7:47 AM, Daniel Glazman wrote:
> Another detection technique based on the computed style of the
> 'font-family' property would work much better.

Uh... the computed value of font-family is just the specified value (CSS 
2.1 section 15.3).  So no, you can't detect _used_ font-family values 
based on the computed value in this case.

-Boris


From ash at ashleysheridan.co.uk  Tue May 11 06:39:09 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 11 May 2010 14:39:09 +0100
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <4BE95CA9.2010802@mit.edu>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu>
Message-ID: <1273585149.21168.158.camel@localhost>

On Tue, 2010-05-11 at 09:33 -0400, Boris Zbarsky wrote:

> On 5/11/10 7:47 AM, Daniel Glazman wrote:
> > Another detection technique based on the computed style of the
> > 'font-family' property would work much better.
> 
> Uh... the computed value of font-family is just the specified value (CSS 
> 2.1 section 15.3).  So no, you can't detect _used_ font-family values 
> based on the computed value in this case.
> 
> -Boris
> 


Is there really much of a need for this though? CSS as it stands has
support for a list of fonts to be specified for an element, and a
browser can go through them until it finds one that is installed.

The only argument I've seen is that various fonts are obviously
different sizes, and so falling back to a different font might look best
if the font-size also changed with it. However, I don't think it's such
a great idea for fonts to be used as a layout tool. The layout should be
fluid enough for minor font differences. This is not forgetting that the
font a designer specifies for a page might be completely overridden by a
user for a variety of reasons (larger fonts for someone with a visual
disability, colour changes for someone with dyslexia, etc)

Lastly, if a designer really needs to specify the exact font used on a
page, then CSS3 has an area for embedded fonts (which are supported in
various forms on the major browsers)

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


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

From mikko.rantalainen at peda.net  Tue May 11 07:00:02 2010
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Tue, 11 May 2010 17:00:02 +0300
Subject: [whatwg] meta="encrypt" tag is needed
In-Reply-To: <20100510224058.88643zifc3q21unu@webmail-srv2.servage.net>
References: <20100510224058.88643zifc3q21unu@webmail-srv2.servage.net>
Message-ID: <4BE962E2.90103@peda.net>

Juuso Hukkanen wrote:
> Mikko Rantalainen wrote:
>> Are you trying to suggest an user agent implementation of something
>> similar to this: http://angel.net/~nic/passwdlet.html ?
> Thanks Mikko for linking to those passsalt generator tools.

In truth, I was asking to figure out if that's what you're aiming for.
If I've understood correctly, this is the feature that you think should
be implemented.

I'm afraid that such system would not be safe and would not give all the
protection you're looking for.

Basically if you have a function

f(x) = sha256(domain + userpassword)

in reality you just have a SHA256 of userpassword with a custom IV
(initialization vector). A more secure hashing method would be along the
lines

f2(x) = sha256(sha256(userpassword) + domain)

where the output of sha256 is hex in ascii and "+" is string
concatenating operator. This would effectively prevent use of rainbow
tables contrary to f(x) above.

However, it wouldn't still be safe to use the same password for multiple
sites because the attack could be implemented offline against the salted
hash. If one has possession of database of salted hashes, figuring out a
single password is roughly equivalent processing to figuring out
(almost) all of the passwords. The complexity of processing is only
dependent on the length and complexity of user's password (and if it's
something in a dictionary, it's way too simple here).

Notice that the salting method described and implemented in URL above is
safe only if it's not too widely used, or if the master password is
complex enough for offline brute force attack. As such, it's not
suitable for common implementation in user agents. Notice that it does
not matter if the hash algorithm is md5 or sha1 or whatever. The problem
is that the user's master password is the only secret and that's almost
always too weak secret for brute force offline attack.

> PASSSALT:
> ^^^^^^^^^^
> Attributes:
> <meta encrypt <=> Identification tag for html 5.01 content for 5.01
> conforming UAs

If something like this will be ever implemented, it should definitely be
a form input specific attribute, not a single meta element for the whole
page.


> passsalt="no|domainname"
> ^^^^^^^^^^^^^^^^^^^^^^^
> 1) no <=> UAs should send passwords unsalted (e.g. for the sake of
> compatibility)
> 
> 2) yes <=> (default value, 5.01 conforming UAs will salt passwords using
> domain name)
> 
> 3) domainname <=> domain(+TLD), if site wants hashes salted using it's
> current or some another domain name

How about just a simple extension to input type=password field instead?
Let's add a new attribute 'salt' with the following definition:

If 'salt' is defined for input element of type 'password', it will be
used as a string "domain" in the f2() function above. The output of that
function will be transferred as form data instead of real password.

This has all the security of your proposed scheme (because there's no
safety against MitM attack, there's no point to try to include any
external information into the hash -- including the domain name). The
server may use domain name as the salt or any random string it prefers.
If server uses the same salt every time, it does not ever need to know
the actual password. On the other hand, using the same salt makes the
database more vulnerable to offline attack if the database is ever leaked.

However, the server must be coded to accept BOTH salted password and
plain text password to support existing user agents.

It could be specified that entire ascii/UTF-8 (identical) hex encoded
sha256 output must be used as the form value. The length of inputted
password would then be a pretty good indicator of salted and hashed
password.


> Why passsalt in html5.xx specification
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 1) multi-use of same passwords is a growing security problem. A
> successfull stealing single sites unencrypted real person names +
> passwords can lead to thousands of ID theft cases.

It is not safe to use the same password on multiple sites, hashed or
not. The only safe method is to use random password for every site and
use (real, not obfuscated) encrypted local storage for real passwords.

I do understand that the secure scheme is hard to implement if you're
using multiple devices to access the service. In addition, it's not
usable or safe on untrusted devices (but neither is any other scheme).

Allowing a scheme suggested here would allow something slightly better
than the current situation but it should be said plain and clear in the
spec that this is not a replacement for real security.

> 2) Voluntary salting of passwords has failed even on reputable sites.

The server must have knowledge of real password to use powerful salt
(that is, the salt is not shared)

> 3) Forcing the passwords salted is one solution. But the UA needs to
> know if it should send password salted or unsalted. Situation where one
> UA would send salted password and another unsalted is unacceptable

Why do you think so? If the server knows only salted version and gets
unsalted version, it will be able to check that the password is the
correct one. It's only a issue for the user of such user agent (the user
agent just transferred the password in plain text).

>> You referred to "alypaa.com" case in your original post. Could you
>> explain why do you think this would prevent from similar information
>> leak in the future?
> 
> 1) Site had stored the it's email addresses and passwords in unsalted
> format.
> And as often is the case, same password had been multi-used on many sites.
> If the alypaa.com had only gotten salted passwords from UA, it could not
> have
> leaked out the passwords to peoples email, blog and facebook accounts.

The alypaa.com would have still leaked a database of hashed passwords.
If every password uses the same salt, it does not make offline attack
much harder if attacker accepts any broken password from database (as
opposed to some specific password).

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100511/313591e9/attachment.pgp>

From bzbarsky at MIT.EDU  Tue May 11 07:08:01 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 11 May 2010 10:08:01 -0400
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <1273585149.21168.158.camel@localhost>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>	<4BE92004.9080007@disruptive-innovations.com>	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>	<1273577314.21168.136.camel@localhost>	<4BE943C6.4080008@disruptive-innovations.com>	<4BE95CA9.2010802@mit.edu>
	<1273585149.21168.158.camel@localhost>
Message-ID: <4BE964C1.3050606@mit.edu>

On 5/11/10 9:39 AM, Ashley Sheridan wrote:
> Is there really much of a need for this though?

Good question.  What _is_ the use case here, exactly?

> The only argument I've seen is that various fonts are obviously
> different sizes, and so falling back to a different font might look best
> if the font-size also changed with it.

Sure, and CSS has provisions for this.  See 
http://www.w3.org/TR/css3-fonts/#relative-sizing-the-font-size-adjust-pro (also 
present in CSS2; removed from CSS2.1 due to poor UA support as far as I 
can tell, but the right solution to this problem).

-Boris

From annevk at opera.com  Tue May 11 07:14:53 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 11 May 2010 16:14:53 +0200
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <4BE964C1.3050606@mit.edu>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu>
	<1273585149.21168.158.camel@localhost> <4BE964C1.3050606@mit.edu>
Message-ID: <op.vcjoi3f864w2qv@annevk-t60>

On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/11/10 9:39 AM, Ashley Sheridan wrote:
>> Is there really much of a need for this though?
>
> Good question.  What _is_ the use case here, exactly?

E.g. allowing the user to select a font in a text editing or drawing  
application. However, for portability it would probably be better if these  
were limited to fonts already on the Web.


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

From ash at ashleysheridan.co.uk  Tue May 11 07:26:43 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 11 May 2010 15:26:43 +0100
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <op.vcjoi3f864w2qv@annevk-t60>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu>
	<1273585149.21168.158.camel@localhost> <4BE964C1.3050606@mit.edu>
	<op.vcjoi3f864w2qv@annevk-t60>
Message-ID: <1273588003.21168.166.camel@localhost>

On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote:

> On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > On 5/11/10 9:39 AM, Ashley Sheridan wrote:
> >> Is there really much of a need for this though?
> >
> > Good question.  What _is_ the use case here, exactly?
> 
> E.g. allowing the user to select a font in a text editing or drawing  
> application. However, for portability it would probably be better if these  
> were limited to fonts already on the Web.
> 
> 


I agree, portability dictates that they should stick to the few common
fonts, or we end up with the same situation I've had countless times
where someone sent an MSWord file with all the bullets as some character
from the Wingdings font then wonder why people complain that all their
bullets are letters.

Embedding the font isn't feasible in this case because you really can't
trust the end-user to observe the legal aspects of the fonts they have
on their system. The designer of a font may not have given user rights
to distribute the font in a document that is publically available like
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/20100511/d5a784bd/attachment.htm>

From joaoe at opera.com  Tue May 11 07:55:06 2010
From: joaoe at opera.com (=?utf-8?Q?Jo=C3=A3o_Eiras?=)
Date: Tue, 11 May 2010 16:55:06 +0200
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <1273588003.21168.166.camel@localhost>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu>
	<1273585149.21168.158.camel@localhost> <4BE964C1.3050606@mit.edu>
	<op.vcjoi3f864w2qv@annevk-t60> <1273588003.21168.166.camel@localhost>
Message-ID: <op.vcjqd4rm2q99of@id-c0981>

On Tue, 11 May 2010 16:26:43 +0200, Ashley Sheridan  
<ash at ashleysheridan.co.uk> wrote:

> On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote:
>
>> On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky <bzbarsky at mit.edu>  
>> wrote:
>> > On 5/11/10 9:39 AM, Ashley Sheridan wrote:
>> >> Is there really much of a need for this though?
>> >
>> > Good question.  What _is_ the use case here, exactly?
>>
>> E.g. allowing the user to select a font in a text editing or drawing
>> application. However, for portability it would probably be better if  
>> these
>> were limited to fonts already on the Web.
>>
>>
>
>
> I agree, portability dictates that they should stick to the few common
> fonts, or we end up with the same situation I've had countless times
> where someone sent an MSWord file with all the bullets as some character
> from the Wingdings font then wonder why people complain that all their
> bullets are letters.
>
> Embedding the font isn't feasible in this case because you really can't
> trust the end-user to observe the legal aspects of the fonts they have
> on their system. The designer of a font may not have given user rights
> to distribute the font in a document that is publically available like
> this.
>

I've suggested this back in 2007
http://lists.w3.org/Archives/Public/public-webapi/2007Jul/0021.html

Regarding filtering which fonts, do note that a web page is not the only  
place where web standards and APIs are used.


-- 

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

From pedzsan at gmail.com  Tue May 11 10:51:04 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Tue, 11 May 2010 12:51:04 -0500
Subject: [whatwg] New File attributes creationDate,
	modificationDate and size
In-Reply-To: <4BE918B9.5070906@jrn.me.uk>
References: <4BE918B9.5070906@jrn.me.uk>
Message-ID: <957380B3-3A1C-4B81-8047-805E9CAECB3C@gmail.com>


On May 11, 2010, at 3:43 AM, J Ross Nicoll wrote:

> Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file
> 
> There doesn't appear to be anyway of retrieving creation date, modification date or size of the file. Could I suggest adding attributes creationDate, modificationDate and size to provide this information?
> 
> For a use case; we're working an a student coursework submission system, where they'll be able to drag and drop files. It would be useful to show the student details of the file they're uploading (for example, modification date is useful to confirm they're uploading the most recent version). We do actually see a fairly large number of mis-uploads with the existing upload system, and are hoping exposing more information during the upload (rather than once the file is received) will help.

I was just going to ask the same question.  My use case is for a progress bar.  As I parse a file, it would be nice to have a progress bar based upon the file size and how much has been parsed.


From pedzsan at gmail.com  Tue May 11 11:09:23 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Tue, 11 May 2010 13:09:23 -0500
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <1273588003.21168.166.camel@localhost>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu> <1273585149.21168.158.camel@localhost>
	<4BE964C1.3050606@mit.edu> <op.vcjoi3f864w2qv@annevk-t60>
	<1273588003.21168.166.camel@localhost>
Message-ID: <1D6F3751-528F-491F-A37B-0D7607F955ED@gmail.com>


On May 11, 2010, at 9:26 AM, Ashley Sheridan wrote:

> On Tue, 2010-05-11 at 16:14 +0200, Anne van Kesteren wrote:
>> 
>> On Tue, 11 May 2010 16:08:01 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> > On 5/11/10 9:39 AM, Ashley Sheridan wrote:
>> >> Is there really much of a need for this though?
>> >
>> > Good question.  What _is_ the use case here, exactly?
>> 
>> E.g. allowing the user to select a font in a text editing or drawing  
>> application. However, for portability it would probably be better if these  
>> were limited to fonts already on the Web.
>> 
>> 
> 
> I agree, portability dictates that they should stick to the few common fonts, or we end up with the same situation I've had countless times where someone sent an MSWord file with all the bullets as some character from the Wingdings font then wonder why people complain that all their bullets are letters.
> 
> Embedding the font isn't feasible in this case because you really can't trust the end-user to observe the legal aspects of the fonts they have on their system. The designer of a font may not have given user rights to distribute the font in a document that is publically available like this.

Well, my take is just the opposite.  Portability should dictate only if the user wants portability.  I don't believe we confine what colors can be picked based upon what is portable.

People, users, authors, etc learn over time.

We are seeing with HTML5 and all of its capabilities a real working platform for almost anything.  I'm sure there will be ten times as many beasts created from it as beauties but I don't see that as a reason to constrain the possibilities.

pedz

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

From pedzsan at gmail.com  Tue May 11 11:22:11 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Tue, 11 May 2010 13:22:11 -0500
Subject: [whatwg] getElementById
In-Reply-To: <AANLkTikFunHjQksT3nBmi7Ob_BR5F5-vtdaQyf-1deb_@mail.gmail.com>
References: <E7E377A2-96CA-4B67-A2C8-39D9C2E995BC@gmail.com>
	<AANLkTinLruboqRHjC1Jt0c7_aLNm7tg26ntbu374cLro@mail.gmail.com>
	<357FA5BA-172F-4FCD-A55B-89A455C03C48@gmail.com>
	<AANLkTimwFWcxF2nMtrzEUxSFNin_E1j_aMldUyXUQrnk@mail.gmail.com>
	<E3EB3EE2-5947-4B99-805F-CC185C38B934@gmail.com>
	<AANLkTilgZAlHkkTxws7AdLLhEK5NDTMKCeI82iBiAo79@mail.gmail.com>
	<DAD1B86B-E7FC-42AC-8F52-9CC58BABCA82@gmail.com>
	<AANLkTikFunHjQksT3nBmi7Ob_BR5F5-vtdaQyf-1deb_@mail.gmail.com>
Message-ID: <C01E5911-2C58-4FF1-8AA4-6B57B43ADBED@gmail.com>


On May 10, 2010, at 10:54 PM, Garrett Smith wrote:

> On Mon, May 10, 2010 at 8:28 PM, Perry Smith <pedzsan at gmail.com> wrote:
> <snip>
>> So, how about this?
>> 
>> As part of HTMLElement, have a defined bucket, maybe call it elementObject which is defined to be a native ECMAScript object.  If X denotes a particular DOM element, then X.elementObject is defined to return the same native ECMAScript object each time.  More details could be added perhaps to define how the object is created (i.e. which prototype to use, etc).  I'm thinking making it the same as {}.
>> 
> 
> WebIDL could require DOM objects to be implemented as native ECMAScript objects.

To me, the "host objects" and the fact that they are mostly unspecified seems rather critical and limiting.  The getUserData seems terribly awkward and I guess it suffers from portability issues as well.

Is WebIDL the best place to address this?

Thanks,
pedz

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

From Olli.Pettay at helsinki.fi  Tue May 11 11:31:47 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Tue, 11 May 2010 21:31:47 +0300
Subject: [whatwg] New File attributes creationDate,
 modificationDate and size
In-Reply-To: <4BE918B9.5070906@jrn.me.uk>
References: <4BE918B9.5070906@jrn.me.uk>
Message-ID: <4BE9A293.8060004@helsinki.fi>

On 5/11/10 11:43 AM, J Ross Nicoll wrote:
> Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file
Note, discussion about FileAPI should happen in WebApps WG mailing list.


>
> There doesn't appear to be anyway of retrieving creation date,
> modification date or size of the file.
You can get the size from Blob. And File extends Blob.

-Olli


  Could I suggest adding attributes
> creationDate, modificationDate and size to provide this information?
>
> For a use case; we're working an a student coursework submission system,
> where they'll be able to drag and drop files. It would be useful to show
> the student details of the file they're uploading (for example,
> modification date is useful to confirm they're uploading the most recent
> version). We do actually see a fairly large number of mis-uploads with
> the existing upload system, and are hoping exposing more information
> during the upload (rather than once the file is received) will help.
>


From sswigart at google.com  Tue May 11 11:58:41 2010
From: sswigart at google.com (Sterling Swigart)
Date: Tue, 11 May 2010 11:58:41 -0700
Subject: [whatwg] Image resize API proposal
Message-ID: <AANLkTimipWsXnVqcNTD3vYTd9gSuLkWGeYnCtp0wYWIL@mail.gmail.com>

I'm working with David Levin, and based on the feedback received regarding
offscreen canvas, the proposal has been changed to address more specific
scenarios. The main use case was resizing images, so we are proposing an
asynchronous image resizing API. If you are curious about how we arrived at
our API below, take a look at the "appendix" to view the alternatives we
considered.

Let us know what you think. Thanks!
Sterling

Use Cases:

Begin with a user giving a local image file to a webpage. Then:

1. In real-time chat, quickly give other users a thumbnail view of the image
file.

2. Or, limit the size of an image file before uploading it to a web server.

Proposed Solution:

We propose adding image.getBlob. getBlob will be an instance function of the
javascript Image object which asynchronously gets a blob of the image,
resized to the given width and height, encoded into jpeg or png. The
function declaration will be:

getBlob(mimeType /* req */, width /* req */, height /* req */, successEvent
/* req */, errorEvent /* op */, qualityLevel /* op */, preserveAspectRatio
/* op */, rotateExif /* op */);

The blob will be passed as an argument to the success callback function, or
upon error, error data will be passed into the error callback function as an
argument. Quality level should be between 0.0 and 1.0, and any value outside
of that range will be reverted to the default, 0.85. If MIME type does not
equal "image/jpeg", then quality level is ignored. If null (or a negative
value) is passed in for the width or height, then the function will use the
source's measurement for that dimension. Default values for
preserveAspectRatio and rotateExif are true.

All EXIF metadata will be retained except for any saved thumbnails, and the
EXIF rotation property will be appropriately modified.

Security:

If the image source is of a different origin than the script context, then
getBlob raises a SECURITY_ERR exception.

Sample Code:

// url contains location of an image file

Image i = new Image();

i.src = url;

var successEvt = function (newBlob) { myDiv.innerHTML += "<img src='" +
newBlob.url + "' />"; };

var errEvt = function (err) { alert(err); };

i.getBlob("image/jpeg", 300, 350, successEvt, errEvt, .55);

// Image will retain aspect ratio and correct for EXIF rotation. If the
source image was 700x700,

// the blob will represent a new image that is 300x300.

That's all!Appendix: Alternatives considered

For reference, we've also included a list of other designs that we thought
of along with the reasons why they were dropped

Creating a new object for resizing

Summary of approach:

[NamedConstructor=ImageResizer(),

NamedConstructor=ImageResizer(blob, onsuccess),

NamedConstructor=ImageResizer(blob, onsuccess, onerror),

NamedConstructor=ImageResizer(blob, onsuccess, onerror, type),

NamedConstructor=ImageResizer(blob, onsuccess, onerror, type, width,
height)]

interface ImageResizer {

void start(); // starts resize operation

void abort(); // aborts operation

 attribute Blob blob;

attribute DOMString type; // default "image/png"

attribute unsigned long width;

attribute unsigned long height;

attribute float qualityLevel; // default 1.0, must be 0.0 to 1.0, else
reverts to default

 readonly attribute unsigned short started; // default 0

 attribute Function onsuccess;

attribute Function onerror;

};

Why it wasn't chosen:

Creating an entirely new object for this task made the task seem more
complicated and involved than necessary, and this problem could be solved
via modifications to the Image object.

Returning a SizelessBlob immediately from a method on image

Summary of approach:

var streamingBlob = image.toStreamingBlob(mimeType /* req */, width /* req
*/, height /* req */, qualityLevel /* op */, preserveAspectRatio /* op */,
rotateExif /* op */);

New Blob Interfaces:

interface SizelessBlob {

// moved from Blob

readonly attribute DOMString type;

readonly attribute DOMString url; // whatever name -- URL, urn, URN, etc.

}

interface StreamingBlob : SizelessBlob {

// at most one of the following functions will be called for a single
FutureBlob

attribute Function onblobready;

attribute Function onerror;

readyonly attribute blob; // throws an exception if accessed before
onblobready is called.

}

interface Blob : SizelessBlob {

readonly attribute unsigned long long size;

Blob slice(in long long start,

in long long length); // raises DOMException

};

Why it wasn't chosen:

   - the disconnect of the error from the thing that caused it making
   failures hard to understand (e.g. An image load may fail but that may not be
   detected until the xhr is done using the resized image.)
   - the issues that result from passing a SizelessBlob, which has a
   reference to a loading image, to another document and closing the original
   document (thus killing the image loader)
   - introduction of multiple blobs which may be confusing to developers
   - the need to change all existing specs to use SizelessBlob instead of
   Blob

Returning a Blob immediately from a method on image

Summary of approach:

var blob = image.toBlob(mimeType /* req */, width /* req */, height /* req
*/, qualityLevel /* op */, preserveAspectRatio /* op */, rotateExif /* op
*/);

blob.size and blob.slice throw until the blob is complete. There would need
to be a new event to say when the blob's size is ready.

Why it wasn't chosen:

It felt like it was changing how blobs worked to make the size throw. Also,
this has some of the same disadvantages of as the SizelessBlob approach.

Using CSS of Image to designate dimensions instead of putting it in the API

Summary of approach:

img.getBlob(mimeType /* req */, successEvent /* req */, errorEvent /* op */,
qualityLevel /* op */);

Why it wasn't chosen:

It would have been confusing to the user if getBlob took into account some
CSS attributes but not others, and using all CSS tags posed a lot of
unnecessary implementation complexity without any use cases.

Using the File object

Summary of approach:

FileReader readResized(). The result would be a data url with the resized
image.

Why it wasn't chosen:

We also examined making this function an instance method of the FileReader
object, but this function did not fit well in the context of the File
object. FileReader's result is a string, posing a problem for large results
as well as an unnecessary conversion. One way another this problem is to use
a URN (like File.urn), it would have prevented us from posting the result to
a server as well as having the lifetime issues that File.urn does.

Having a very specialized method on FormData to do the resize and allow
upload

Summary of approach:

FormData.appendResized(DOMString name, Blob value, mimeType /* req */, with
/* req */, height /* req */, qualityLevel /* op */, preserveAspectRatio /*
op */, rotateExif /* op */);

Why it wasn't chosen:

This approach was over specialized and didn't allow for using the result on
the web page at all which would be useful as a preview of exactly what is
being uploaded.

Using canvas in a worker

Summary of approach:

This is the OffscreenCanvas proposal which can be seen here:
h<http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>
ttp <http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>:<http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>
//www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html<http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>

Why it wasn't chosen:

Due to making it rather complicated for the javascript user to accomplish
their goal and the code complexity and the speed trade-offs that may change
due to gpu acceleration, this idea didn't get traction and many folks
suggested something simpler for the intended use cases. A few more drawbacks
are that this doesn't obey exif automatically and it doesn't preserve the
exif metadata.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100511/8ad42d3a/attachment-0001.htm>

From jat at google.com  Tue May 11 11:58:56 2010
From: jat at google.com (John Tamplin)
Date: Tue, 11 May 2010 14:58:56 -0400
Subject: [whatwg] New File attributes creationDate,
	modificationDate and 	size
In-Reply-To: <4BE918B9.5070906@jrn.me.uk>
References: <4BE918B9.5070906@jrn.me.uk>
Message-ID: <k2g3f94964f1005111158wd82dc8a4q1a7285665120d471@mail.gmail.com>

On Tue, May 11, 2010 at 4:43 AM, J Ross Nicoll <jrn at jrn.me.uk> wrote:

> Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file
>
> There doesn't appear to be anyway of retrieving creation date, modification
> date or size of the file. Could I suggest adding attributes creationDate,
> modificationDate and size to provide this information?
>

Note that not all filesystems the server might be using keep creation date,
and there are different granularities for modification date.

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

From jonas at sicking.cc  Tue May 11 13:24:39 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 11 May 2010 13:24:39 -0700
Subject: [whatwg] New File attributes creationDate,
	modificationDate and 	size
In-Reply-To: <4BE9A293.8060004@helsinki.fi>
References: <4BE918B9.5070906@jrn.me.uk> <4BE9A293.8060004@helsinki.fi>
Message-ID: <AANLkTinulN8n2O3auuc0nkgmdRIMDut4Hi5XZx7vtRMV@mail.gmail.com>

On Tue, May 11, 2010 at 11:31 AM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:
> On 5/11/10 11:43 AM, J Ross Nicoll wrote:
>>
>> Looking at http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-file
>
> Note, discussion about FileAPI should happen in WebApps WG mailing list.
>
>
>>
>> There doesn't appear to be anyway of retrieving creation date,
>> modification date or size of the file.
>
> You can get the size from Blob. And File extends Blob.

Indeed. A progress bar is implementable using the features already
specced in File and FileReader.

As for the creationDate and modificationDate, this seems ok to me. I'm
as always somewhat concerned about privacy, but I think on the whole
it would be ok.

/ Jonas

From jackalmage at gmail.com  Tue May 11 13:59:44 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 11 May 2010 13:59:44 -0700
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <1D6F3751-528F-491F-A37B-0D7607F955ED@gmail.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org> 
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com> 
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com> 
	<4BE95CA9.2010802@mit.edu> <1273585149.21168.158.camel@localhost> 
	<4BE964C1.3050606@mit.edu> <op.vcjoi3f864w2qv@annevk-t60> 
	<1273588003.21168.166.camel@localhost>
	<1D6F3751-528F-491F-A37B-0D7607F955ED@gmail.com>
Message-ID: <AANLkTimSoeEzEUUqaGXcnhL9HkHO4dhmCUWVdiGLL-EB@mail.gmail.com>

On Tue, May 11, 2010 at 11:09 AM, Perry Smith <pedzsan at gmail.com> wrote:
> Well, my take is just the opposite. ?Portability should dictate only if the
> user wants portability. ?I don't believe we confine what colors can be
> picked based upon what is portable.

Actually...  some machines can display colors with rgb values outside
of the [0,255] range.  But CSS clamps you to that range because it's
portable.

~TJ

From bzbarsky at MIT.EDU  Tue May 11 14:30:29 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 11 May 2010 17:30:29 -0400
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <AANLkTimSoeEzEUUqaGXcnhL9HkHO4dhmCUWVdiGLL-EB@mail.gmail.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu> <1273585149.21168.158.camel@localhost>
	<4BE964C1.3050606@mit.edu> <op.vcjoi3f864w2qv@annevk-t60>
	<1273588003.21168.166.camel@localhost>
	<1D6F3751-528F-491F-A37B-0D7607F955ED@gmail.com>
	<AANLkTimSoeEzEUUqaGXcnhL9HkHO4dhmCUWVdiGLL-EB@mail.gmail.com>
Message-ID: <4BE9CC75.9040408@mit.edu>

On 5/11/10 4:59 PM, Tab Atkins Jr. wrote:
> On Tue, May 11, 2010 at 11:09 AM, Perry Smith<pedzsan at gmail.com>  wrote:
>> Well, my take is just the opposite.  Portability should dictate only if the
>> user wants portability.  I don't believe we confine what colors can be
>> picked based upon what is portable.
>
> Actually...  some machines can display colors with rgb values outside
> of the [0,255] range.  But CSS clamps you to that range because it's
> portable.

CSS clamps to [0,255]?  Since when? 
http://www.w3.org/TR/css3-color/#rgb-color says:

   Values outside the device gamut should be clipped or mapped into
   the gamut when the gamut is known: the red, green, and blue values
   must be changed to fall within the range supported by the device.
   User agents may perform higher quality mapping of colors from one
   gamut to another. This specification does not define precise
   clipping behavior.
   ...
   Other devices, such as printers, have different gamuts than sRGB;
   some colors outside the 0..255 sRGB range will be representable
   (inside the device gamut), while other colors inside the 0..255
   sRGB range will be outside the device gamut and will thus be mapped.

There is then an example that says that on an sRGB device rgb(300,0,0) 
will be the same as rgb(255,0,0)... but on a non-sRGB device they may 
well not be.

-Boris

From pedzsan at gmail.com  Tue May 11 14:55:22 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Tue, 11 May 2010 16:55:22 -0500
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <AANLkTimSoeEzEUUqaGXcnhL9HkHO4dhmCUWVdiGLL-EB@mail.gmail.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu> <1273585149.21168.158.camel@localhost>
	<4BE964C1.3050606@mit.edu> <op.vcjoi3f864w2qv@annevk-t60>
	<1273588003.21168.166.camel@localhost>
	<1D6F3751-528F-491F-A37B-0D7607F955ED@gmail.com>
	<AANLkTimSoeEzEUUqaGXcnhL9HkHO4dhmCUWVdiGLL-EB@mail.gmail.com>
Message-ID: <3E49C6EB-7D90-4378-BDDC-729328E22DB8@gmail.com>


On May 11, 2010, at 3:59 PM, Tab Atkins Jr. wrote:

> On Tue, May 11, 2010 at 11:09 AM, Perry Smith <pedzsan at gmail.com> wrote:
>> Well, my take is just the opposite.  Portability should dictate only if the
>> user wants portability.  I don't believe we confine what colors can be
>> picked based upon what is portable.
> 
> Actually...  some machines can display colors with rgb values outside
> of the [0,255] range.  But CSS clamps you to that range because it's
> portable.

True, CSS restricts the color space to sRGB.  But CSS allows for 16 bit colors.  That is more what I was referring to.  The older machines can not display such subtleties so wise authors choose to confine their color choices but we are still allowed to pick the other colors.

Drifting off the topic a bit, has anyone suggested introducing the Lab color space to CSS and HTML?  It is a very nice for some applications.

pedz


From jackalmage at gmail.com  Tue May 11 15:37:29 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 11 May 2010 15:37:29 -0700
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <4BE9CC75.9040408@mit.edu>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org> 
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu> 
	<1273585149.21168.158.camel@localhost> <4BE964C1.3050606@mit.edu> 
	<op.vcjoi3f864w2qv@annevk-t60> <1273588003.21168.166.camel@localhost> 
	<1D6F3751-528F-491F-A37B-0D7607F955ED@gmail.com>
	<AANLkTimSoeEzEUUqaGXcnhL9HkHO4dhmCUWVdiGLL-EB@mail.gmail.com> 
	<4BE9CC75.9040408@mit.edu>
Message-ID: <AANLkTilelYMIJ37KR5sHKA_BQRR5LAnL-NZYDoldsyHK@mail.gmail.com>

On Tue, May 11, 2010 at 2:30 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/11/10 4:59 PM, Tab Atkins Jr. wrote:
>>
>> On Tue, May 11, 2010 at 11:09 AM, Perry Smith<pedzsan at gmail.com> ?wrote:
>>>
>>> Well, my take is just the opposite. ?Portability should dictate only if
>>> the
>>> user wants portability. ?I don't believe we confine what colors can be
>>> picked based upon what is portable.
>>
>> Actually... ?some machines can display colors with rgb values outside
>> of the [0,255] range. ?But CSS clamps you to that range because it's
>> portable.
>
> CSS clamps to [0,255]? ?Since when?
> http://www.w3.org/TR/css3-color/#rgb-color says:
>
> ?Values outside the device gamut should be clipped or mapped into
> ?the gamut when the gamut is known: the red, green, and blue values
> ?must be changed to fall within the range supported by the device.
> ?User agents may perform higher quality mapping of colors from one
> ?gamut to another. This specification does not define precise
> ?clipping behavior.
> ?...
> ?Other devices, such as printers, have different gamuts than sRGB;
> ?some colors outside the 0..255 sRGB range will be representable
> ?(inside the device gamut), while other colors inside the 0..255
> ?sRGB range will be outside the device gamut and will thus be mapped.
>
> There is then an example that says that on an sRGB device rgb(300,0,0) will
> be the same as rgb(255,0,0)... but on a non-sRGB device they may well not
> be.

This is why I should read more closely, dammit.

~TJ

From silvia at silvia-pfeiffer.de  Tue May 11 16:18:17 2010
From: silvia at silvia-pfeiffer.de (Silvia Pfeiffer)
Date: Wed, 12 May 2010 09:18:17 +1000
Subject: [whatwg] [ogg-dev] HTML5 audio tag
In-Reply-To: <AANLkTimZFwtO-Ud7Z9Lph-LOsu7q23DPwW-ndjxP_j_l@mail.gmail.com>
References: <AANLkTilb0uMcDqLSWUq0oUxIqyR29MTlFAcYTHKSHvg6@mail.gmail.com> 
	<4BE93017.5010901@double.co.nz>
	<AANLkTinZSGcaKi1YeqZy6VaNNgPuju70wAQ7BmA6qF9K@mail.gmail.com> 
	<AANLkTim4xxSg-ImAu7wHWUV5cfUiHkIyUZK_wuIpLBct@mail.gmail.com> 
	<AANLkTimZFwtO-Ud7Z9Lph-LOsu7q23DPwW-ndjxP_j_l@mail.gmail.com>
Message-ID: <AANLkTilomSJ18awbgi3GCXp9TTmfCwXAzTSKqU8XOxNF@mail.gmail.com>

Yeah, the track attribute of the media fragments specification that
Ralph links will in theory allow to just download the track-related
data. But it still requires implementation - either in the browser,
which will somehow need to identify which bytes belong to which track
and just request those byte ranges that are relevant, or on the
server, which will only deliver the relevant bytes when asked for the
audio track only.

None of this is implemented yet. In fact, the discovery of which bytes
in a Ogg stream belong to which track is a challenge. I am not sure
whether the new Skeleton Index format might actually allow for that...

Cheers,
Silvia.

On Wed, May 12, 2010 at 3:32 AM, Frank Barchard <fbarchard at google.com> wrote:
> FWIW chromium does client side range requests that in theory would request
> only the audio. ?But. the ogg demux reads the other tracks and discards
> them.
> A use case I've heard is listening to music videos and discard the video...
> bit of a bandwidth waste.
>
> On Tue, May 11, 2010 at 10:17 AM, Ralph Giles <giles at thaumas.net> wrote:
>>
>> On 11 May 2010 04:24, narendra sisodiya <narendra.sisodiya at gmail.com>
>> wrote:
>>
>> > ???? It will be very good if HTML5 API specify this. I mean, Say, If we
>> > use
>> > <audio> tag , then It must stream only audio part of the file
>> > irrespective
>> > of the fact that the src field contains a video file.
>>
>> I don't think that's a practical option, since the server must
>> manipulate the file to return an audio-only subset of the data for
>> there to be any bandwidth advantage. That's not something that the
>> HTML5 specification, which documents browser behaviour, can describe.
>>
>> Note that it's completely possible to use a server-size module or
>> script to do this, using a query url in the HTML5 media element's src
>> attribute. It's just part of a custom server config rather than the
>> HTML5 API. The Media Fragments Working Group at the W3C is currently
>> working on a standardized syntax for this. See
>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if
>> you're interested.
>>
>> FWIW,
>> ?-r
>> _______________________________________________
>> ogg-dev mailing list
>> ogg-dev at xiph.org
>> http://lists.xiph.org/mailman/listinfo/ogg-dev
>
>
> _______________________________________________
> ogg-dev mailing list
> ogg-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>
>

From chris at pearce.org.nz  Tue May 11 17:19:36 2010
From: chris at pearce.org.nz (Chris Pearce)
Date: Wed, 12 May 2010 12:19:36 +1200
Subject: [whatwg] [ogg-dev] HTML5 audio tag
In-Reply-To: <AANLkTilomSJ18awbgi3GCXp9TTmfCwXAzTSKqU8XOxNF@mail.gmail.com>
References: <AANLkTilb0uMcDqLSWUq0oUxIqyR29MTlFAcYTHKSHvg6@mail.gmail.com>
	<4BE93017.5010901@double.co.nz>	<AANLkTinZSGcaKi1YeqZy6VaNNgPuju70wAQ7BmA6qF9K@mail.gmail.com>
	<AANLkTim4xxSg-ImAu7wHWUV5cfUiHkIyUZK_wuIpLBct@mail.gmail.com>
	<AANLkTimZFwtO-Ud7Z9Lph-LOsu7q23DPwW-ndjxP_j_l@mail.gmail.com>
	<AANLkTilomSJ18awbgi3GCXp9TTmfCwXAzTSKqU8XOxNF@mail.gmail.com>
Message-ID: <4BE9F418.7080906@pearce.org.nz>

In order to do this you'd need to know /in advance/ exactly which Ogg 
pages were audio and which were video so you could choose to only 
download the vorbis pages. The upcoming Ogg Skeleton index does not 
index pages at a high enough granularity to facilitate this. It could, 
but then the index would be a lot bigger. I also wonder if the 
time/server overhead of setting up new HTTP byte-range request for each 
~4KB Ogg vorbis page wouldn't make this worth while. Especially over a 
high latency connection. You'd be best to oggz-rip the streams you want 
out in advance and serving them statically, as Conrad suggested.

It's /impossible/ to determine in advance which byte ranges to download 
in order to download only one stream. You simply don't know which stream 
a page belongs to or what size it is until you've downloaded the page.

Chris P.

On 12/05/2010 11:18 a.m., Silvia Pfeiffer wrote:
> Yeah, the track attribute of the media fragments specification that
> Ralph links will in theory allow to just download the track-related
> data. But it still requires implementation - either in the browser,
> which will somehow need to identify which bytes belong to which track
> and just request those byte ranges that are relevant, or on the
> server, which will only deliver the relevant bytes when asked for the
> audio track only.
>
> None of this is implemented yet. In fact, the discovery of which bytes
> in a Ogg stream belong to which track is a challenge. I am not sure
> whether the new Skeleton Index format might actually allow for that...
>
> Cheers,
> Silvia.
>
> On Wed, May 12, 2010 at 3:32 AM, Frank Barchard<fbarchard at google.com>  wrote:
>    
>> FWIW chromium does client side range requests that in theory would request
>> only the audio.  But. the ogg demux reads the other tracks and discards
>> them.
>> A use case I've heard is listening to music videos and discard the video...
>> bit of a bandwidth waste.
>>
>> On Tue, May 11, 2010 at 10:17 AM, Ralph Giles<giles at thaumas.net>  wrote:
>>      
>>> On 11 May 2010 04:24, narendra sisodiya<narendra.sisodiya at gmail.com>
>>> wrote:
>>>
>>>        
>>>>       It will be very good if HTML5 API specify this. I mean, Say, If we
>>>> use
>>>> <audio>  tag , then It must stream only audio part of the file
>>>> irrespective
>>>> of the fact that the src field contains a video file.
>>>>          
>>> I don't think that's a practical option, since the server must
>>> manipulate the file to return an audio-only subset of the data for
>>> there to be any bandwidth advantage. That's not something that the
>>> HTML5 specification, which documents browser behaviour, can describe.
>>>
>>> Note that it's completely possible to use a server-size module or
>>> script to do this, using a query url in the HTML5 media element's src
>>> attribute. It's just part of a custom server config rather than the
>>> HTML5 API. The Media Fragments Working Group at the W3C is currently
>>> working on a standardized syntax for this. See
>>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if
>>> you're interested.
>>>
>>> FWIW,
>>>   -r
>>> _______________________________________________
>>> ogg-dev mailing list
>>> ogg-dev at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/ogg-dev
>>>        
>>
>> _______________________________________________
>> ogg-dev mailing list
>> ogg-dev at xiph.org
>> http://lists.xiph.org/mailman/listinfo/ogg-dev
>>
>>
>>      
>    

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

From silvia at silvia-pfeiffer.de  Tue May 11 17:43:07 2010
From: silvia at silvia-pfeiffer.de (Silvia Pfeiffer)
Date: Wed, 12 May 2010 10:43:07 +1000
Subject: [whatwg] [ogg-dev] HTML5 audio tag
In-Reply-To: <4BE9F418.7080906@pearce.org.nz>
References: <AANLkTilb0uMcDqLSWUq0oUxIqyR29MTlFAcYTHKSHvg6@mail.gmail.com> 
	<4BE93017.5010901@double.co.nz>
	<AANLkTinZSGcaKi1YeqZy6VaNNgPuju70wAQ7BmA6qF9K@mail.gmail.com> 
	<AANLkTim4xxSg-ImAu7wHWUV5cfUiHkIyUZK_wuIpLBct@mail.gmail.com> 
	<AANLkTimZFwtO-Ud7Z9Lph-LOsu7q23DPwW-ndjxP_j_l@mail.gmail.com> 
	<AANLkTilomSJ18awbgi3GCXp9TTmfCwXAzTSKqU8XOxNF@mail.gmail.com> 
	<4BE9F418.7080906@pearce.org.nz>
Message-ID: <AANLkTinBYYG1yrnv4VpIqORjC2opDGcClOvgLCzpE6vg@mail.gmail.com>

I've heard it is easier with MP4 to do byte-range requests for a track
only. Thanks for clarifying that index won't have any of this
information! Indeed, providing an audio file on the server is the
simplest solution to this (follow the KISS-principle :).

Cheers,
Silvia.

On Wed, May 12, 2010 at 10:19 AM, Chris Pearce <chris at pearce.org.nz> wrote:
> In order to do this you'd need to know in advance exactly which Ogg pages
> were audio and which were video so you could choose to only download the
> vorbis pages. The upcoming Ogg Skeleton index does not index pages at a high
> enough granularity to facilitate this. It could, but then the index would be
> a lot bigger. I also wonder if the time/server overhead of setting up new
> HTTP byte-range request for each ~4KB Ogg vorbis page wouldn't make this
> worth while. Especially over a high latency connection. You'd be best to
> oggz-rip the streams you want out in advance and serving them statically, as
> Conrad suggested.
>
> It's impossible to determine in advance which byte ranges to download in
> order to download only one stream. You simply don't know which stream a page
> belongs to or what size it is until you've downloaded the page.
>
> Chris P.
>
> On 12/05/2010 11:18 a.m., Silvia Pfeiffer wrote:
>
> Yeah, the track attribute of the media fragments specification that
> Ralph links will in theory allow to just download the track-related
> data. But it still requires implementation - either in the browser,
> which will somehow need to identify which bytes belong to which track
> and just request those byte ranges that are relevant, or on the
> server, which will only deliver the relevant bytes when asked for the
> audio track only.
>
> None of this is implemented yet. In fact, the discovery of which bytes
> in a Ogg stream belong to which track is a challenge. I am not sure
> whether the new Skeleton Index format might actually allow for that...
>
> Cheers,
> Silvia.
>
> On Wed, May 12, 2010 at 3:32 AM, Frank Barchard <fbarchard at google.com>
> wrote:
>
>
> FWIW chromium does client side range requests that in theory would request
> only the audio. ?But. the ogg demux reads the other tracks and discards
> them.
> A use case I've heard is listening to music videos and discard the video...
> bit of a bandwidth waste.
>
> On Tue, May 11, 2010 at 10:17 AM, Ralph Giles <giles at thaumas.net> wrote:
>
>
> On 11 May 2010 04:24, narendra sisodiya <narendra.sisodiya at gmail.com>
> wrote:
>
>
>
> ???? It will be very good if HTML5 API specify this. I mean, Say, If we
> use
> <audio> tag , then It must stream only audio part of the file
> irrespective
> of the fact that the src field contains a video file.
>
>
> I don't think that's a practical option, since the server must
> manipulate the file to return an audio-only subset of the data for
> there to be any bandwidth advantage. That's not something that the
> HTML5 specification, which documents browser behaviour, can describe.
>
> Note that it's completely possible to use a server-size module or
> script to do this, using a query url in the HTML5 media element's src
> attribute. It's just part of a custom server config rather than the
> HTML5 API. The Media Fragments Working Group at the W3C is currently
> working on a standardized syntax for this. See
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/ if
> you're interested.
>
> FWIW,
> ?-r
> _______________________________________________
> ogg-dev mailing list
> ogg-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>
>
> _______________________________________________
> ogg-dev mailing list
> ogg-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>
>
>
>
>
>

From mozbugbox at yahoo.com.au  Tue May 11 19:37:33 2010
From: mozbugbox at yahoo.com.au (JustFillBug)
Date: Wed, 12 May 2010 02:37:33 +0000 (UTC)
Subject: [whatwg] Need document.available_fonts() call
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu>
	<1273585149.21168.158.camel@localhost> <4BE964C1.3050606@mit.edu>
Message-ID: <slrnhuk53d.2aa.mozbugbox@mozbugbox.somehost.org>

On 2010-05-11, Boris Zbarsky <bzbarsky at MIT.EDU> wrote:
> On 5/11/10 9:39 AM, Ashley Sheridan wrote:
>> Is there really much of a need for this though?
>
> Good question.  What _is_ the use case here, exactly?
>

How about cloud computing? Gimp or CorelDraw like applications.  There
are already bitmap and vector editors in html5 using javascript. A user
should be allowed to make use of the large amount of fonts site on his
hard disk. Especially desktop publishing applications.

Legal embeding of font is not a specific problem to cloud computing.
Desktop applications had that problem since day one. So it is not like
suddenly this is a problem. Just solve it like it's always been, through
legal system.

I think that HTML5 aims more than just web browsering anymore. There
are much broader vision ahead.



From bijumaillist at gmail.com  Tue May 11 20:47:42 2010
From: bijumaillist at gmail.com (Biju)
Date: Tue, 11 May 2010 23:47:42 -0400
Subject: [whatwg] Request for new DOM property textarea.selectionText
In-Reply-To: <4BE82B3A.9070508@disruptive-innovations.com>
References: <w2s4a27dd81005092211k2fa9725bz8ee35d813793795f@mail.gmail.com>
	<4BE82B3A.9070508@disruptive-innovations.com>
Message-ID: <AANLkTiktqHgB0lw_PgUJk9n096APjczLNhn1UU7MCQPo@mail.gmail.com>

On Mon, May 10, 2010 at 11:50 AM, Daniel Glazman
<daniel.glazman at disruptive-innovations.com> wrote:
> Le 10/05/10 07:11, Biju a ?crit :
>
>> Can we have a new DOM property textarea.selectionText
>> which can be used to set/get selection text of a TEXTAREA/INPUT type=text.
>>
>> Current method is complicated and varies between IE and Firefox
>
> Oh!!! As a read/write property, right?

Yes,
But Ojan suggested another option, I liked that too.

Both have advantages

Option 1 (textobj.selectionText) advantages
* No need for web developer to provide selection start/end
* Automatically select the newly inserted text,
   (as most time that is what you want)
* No need for web developer to calculate selection start/end for
setting it after text insert
* preserve scroll
* Has both Getter and Setter

Option 2 (textobj.setRangeText(start, end, text)); advantages
* Independent of selection, web developer can change text at any range
   with out affecting selection
* Web developer has more options with it.
* preserve scroll


So I want to merge both suggestion, with a new signature,
also trying to reduce coding for web developer "less code less bug"

textobj.setRangeText(newtext, start, end, cursorpos)

parameters:
newtext
 - optional parameter
 - new text that will replace existing
 - if missing/null/undefined/NaN then default to ""

start
 - optional parameter
 - starting position of the original textobj text that need to be replaced
 - if missing/null/undefined/NaN then default to textobj.selectionStart
 - negative value make start position from last character in the text content

end
 - optional parameter
 - ending position of the original textobj text that need to be replaced
 - if missing/null/undefined/NaN then default to textobj.selectionEnd
 - negative value make end position from last character

cursorpos
 - optional parameter
 - if missing/null/undefined/NaN then default to 0
 - what should happen to cursor/selection after text insert, its values are
 - - 0 - select the newly inserted text
 - - 1 - place cursor at beginning of inserted text
 - - 2 - place cursor at the end of inserted text
 - - 3 - keep selection unaffected
* issue, when value is 3 what should we do when setRangeText is replacing text
which has some parts selected and some other parts unselected


so if somebody want replace selection text it is just
     textobj.setRangeText(newtext);
which is almost same as my original proposal, and
     textobj.setRangeText();
will blank a selection

We could also add a getter method, also with optional parameters
     textobj.getRangeText(start, end)
so,
textobj.getRangeText() gives current selection
textobj.getRangeText(0) gives from start of text to current selection end
textobj.getRangeText(null, -1) gives from current selection start to end of text

From bijumaillist at gmail.com  Tue May 11 21:05:04 2010
From: bijumaillist at gmail.com (Biju)
Date: Wed, 12 May 2010 00:05:04 -0400
Subject: [whatwg] New File attributes creationDate,
	modificationDate and 	size
In-Reply-To: <AANLkTinulN8n2O3auuc0nkgmdRIMDut4Hi5XZx7vtRMV@mail.gmail.com>
References: <4BE918B9.5070906@jrn.me.uk> <4BE9A293.8060004@helsinki.fi>
	<AANLkTinulN8n2O3auuc0nkgmdRIMDut4Hi5XZx7vtRMV@mail.gmail.com>
Message-ID: <AANLkTik43By8vGeoNOHZenyEYo_AMkt2tHu7f4zvncYP@mail.gmail.com>

It would be good if we can also get the same at server side when user
upload a file using form with file controls
ie, like the suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=549253
(it works even with javascript disabled)

Also remember modificationDate can be a time before creationDate on windows.
This is because modificationDate get copied when you copy a file,
hence it almost shows modificationDate of the actual content.

creationDate on other hand is file creation time on the
folder/directory and when you copy a file to a new directory, it will
be showing the coping time.

PS, for JS option there is mozilla bug 390776

From timeless at gmail.com  Tue May 11 23:30:55 2010
From: timeless at gmail.com (timeless)
Date: Wed, 12 May 2010 09:30:55 +0300
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <slrnhuk53d.2aa.mozbugbox@mozbugbox.somehost.org>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu> <1273585149.21168.158.camel@localhost>
	<4BE964C1.3050606@mit.edu>
	<slrnhuk53d.2aa.mozbugbox@mozbugbox.somehost.org>
Message-ID: <AANLkTikhPAe1ST4iUDZkpCKz4XpmKPbwvaai_n3UWsn_@mail.gmail.com>

On Wed, May 12, 2010 at 5:37 AM, JustFillBug <mozbugbox at yahoo.com.au> wrote:
> How about cloud computing? Gimp or CorelDraw like applications. ?There
> are already bitmap and vector editors in html5 using javascript. A user
> should be allowed to make use of the large amount of fonts site on his
> hard disk. Especially desktop publishing applications.
>
> Legal embeding of font is not a specific problem to cloud computing.
> Desktop applications had that problem since day one. So it is not like
> suddenly this is a problem. Just solve it like it's always been, through
> legal system.

This is a bad argument.

Traditional desktop publishing applications (especially CorelDraw)
included licenses for a large set of fonts because they needed
reliable fonts and a large set and user systems had neither.

Modern browsers have support for downloadable fonts. Let these
applications license and host their own downloadable fonts, just as
they did in the "good old days".

From ash at ashleysheridan.co.uk  Wed May 12 04:25:00 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Wed, 12 May 2010 12:25:00 +0100
Subject: [whatwg] New File attributes creationDate,
 modificationDate and size
In-Reply-To: <AANLkTik43By8vGeoNOHZenyEYo_AMkt2tHu7f4zvncYP@mail.gmail.com>
References: <4BE918B9.5070906@jrn.me.uk> <4BE9A293.8060004@helsinki.fi>
	<AANLkTinulN8n2O3auuc0nkgmdRIMDut4Hi5XZx7vtRMV@mail.gmail.com>
	<AANLkTik43By8vGeoNOHZenyEYo_AMkt2tHu7f4zvncYP@mail.gmail.com>
Message-ID: <1273663500.21168.199.camel@localhost>

On Wed, 2010-05-12 at 00:05 -0400, Biju wrote:

> It would be good if we can also get the same at server side when user
> upload a file using form with file controls
> ie, like the suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=549253
> (it works even with javascript disabled)
> 
> Also remember modificationDate can be a time before creationDate on windows.
> This is because modificationDate get copied when you copy a file,
> hence it almost shows modificationDate of the actual content.
> 
> creationDate on other hand is file creation time on the
> folder/directory and when you copy a file to a new directory, it will
> be showing the coping time.
> 
> PS, for JS option there is mozilla bug 390776


You can get the same on the server side. how you get it just varies from
language to language though, and obviously the exact file information
available is dependant on the file system in use, i.e. fat32, ntfs,
ext3, reiserfs, etc.

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


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

From simonp at opera.com  Wed May 12 04:31:54 2010
From: simonp at opera.com (Simon Pieters)
Date: Wed, 12 May 2010 13:31:54 +0200
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
Message-ID: <op.vclbngugidj3kv@simon-pieterss-macbook.local>

establishing a WebSocket connection:

[[
Note: There is no limit to the number of established WebSocket connections  
a user agent can have with a single remote host. Servers can refuse to  
connect users with an excessive number of connections, or disconnect  
resource-hogging users when suffering high load.
]]

Still, it seems likely that user agents will want to have limits on the  
number of established WebSocket connections, whether to a single remote  
host or multiple remote hosts, in a single tab or overall. The question is  
what should be done when the user agent-defined limit of established  
connections has been reached and a page tries to open another WebSocket.

I think just waiting for other WebSockets to close is not good. It just  
means that newly loaded pages don't work.

If there are any WebSockets in CLOSING state, then I think we should wait  
until they have closed. Otherwise, I think we should force close the  
oldest WebSocket.

-- 
Simon Pieters
Opera Software

From ash at ashleysheridan.co.uk  Wed May 12 04:31:21 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Wed, 12 May 2010 12:31:21 +0100
Subject: [whatwg] Need document.available_fonts() call
In-Reply-To: <AANLkTikhPAe1ST4iUDZkpCKz4XpmKPbwvaai_n3UWsn_@mail.gmail.com>
References: <slrnhuf37f.acr.mozbugbox@mozbugbox.somehost.org>
	<Pine.LNX.4.64.1005110424310.8532@ps20323.dreamhostps.com>
	<4BE92004.9080007@disruptive-innovations.com>
	<l2ha0777e081005110232r4a01c6ddl2103d08f1152c2e9@mail.gmail.com>
	<1273577314.21168.136.camel@localhost>
	<4BE943C6.4080008@disruptive-innovations.com>
	<4BE95CA9.2010802@mit.edu>
	<1273585149.21168.158.camel@localhost> <4BE964C1.3050606@mit.edu>
	<slrnhuk53d.2aa.mozbugbox@mozbugbox.somehost.org>
	<AANLkTikhPAe1ST4iUDZkpCKz4XpmKPbwvaai_n3UWsn_@mail.gmail.com>
Message-ID: <1273663881.21168.205.camel@localhost>

On Wed, 2010-05-12 at 09:30 +0300, timeless wrote:

> On Wed, May 12, 2010 at 5:37 AM, JustFillBug <mozbugbox at yahoo.com.au> wrote:
> > How about cloud computing? Gimp or CorelDraw like applications.  There
> > are already bitmap and vector editors in html5 using javascript. A user
> > should be allowed to make use of the large amount of fonts site on his
> > hard disk. Especially desktop publishing applications.
> >
> > Legal embeding of font is not a specific problem to cloud computing.
> > Desktop applications had that problem since day one. So it is not like
> > suddenly this is a problem. Just solve it like it's always been, through
> > legal system.
> 
> This is a bad argument.
> 
> Traditional desktop publishing applications (especially CorelDraw)
> included licenses for a large set of fonts because they needed
> reliable fonts and a large set and user systems had neither.
> 
> Modern browsers have support for downloadable fonts. Let these
> applications license and host their own downloadable fonts, just as
> they did in the "good old days".


I agree, it's a completely different argument. Desktop applications are
on a single computer, which is often covered by the license. Cloud
computing, but its very nature, spans more than one, at which point a
lot of licenses would fail.

Users cannot be trusted in this case to check the license which would
apply to every font they might want to use, and that's not even
considering how infeasible this would actually be (you'd first have to
determine where you got the font from, and then find the license that
applied to that font)

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


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

From annevk at opera.com  Wed May 12 04:39:33 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 12 May 2010 13:39:33 +0200
Subject: [whatwg] Directory upload via <input type="file" directory>
In-Reply-To: <k2p78dc8441004240858x95b5006ax1f69d8174b4f2896@mail.gmail.com>
References: <r2m5ce7a0db1004011553o5ffe5db4y9339b4e79bfb9c9c@mail.gmail.com>
	<x2m78dc8441004061238uae868197of81be4d684f0950c@mail.gmail.com>
	<z2n5ce7a0db1004061253r68543f3fh42706b7ba2f50491@mail.gmail.com>
	<v2q78dc8441004061418u1096fe9fzb26032923fdfca63@mail.gmail.com>
	<h2y5ce7a0db1004061428v4dafbed7m8b0a6f2627e2561e@mail.gmail.com>
	<v2w78dc8441004221511h2c53542q15f1b000183763d9@mail.gmail.com>
	<op.vbndv9de64w2qv@annevk-t60>
	<k2p78dc8441004240858x95b5006ax1f69d8174b4f2896@mail.gmail.com>
Message-ID: <op.vclbz7wk64w2qv@annevk-t60>

On Sat, 24 Apr 2010 17:58:10 +0200, Ojan Vafai <ojan at chromium.org> wrote:
> On Fri, Apr 23, 2010 at 8:41 PM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> On Fri, 23 Apr 2010 07:11:08 +0900, Ojan Vafai <ojan at chromium.org>  
>> wrote:
>>> But there is already a default UI that lets you select a folder, a  
>>> file or both (drag-drop). I don't see why this forces the UA to do  
>>> anything. Just because you can select both folders and files doesn't  
>>> mean the UA needs to expose extra UI on top of drag-drop to let you do  
>>> so. Again, no more so than they already have to expose extra UI to  
>>> deal with multiple inputs.
>>
>> How does the drag & drop API support this use case?
>
> I'm not sure I understand the question. Are you suggesting that for cases
> where people want to support directory+file drops they should use  
> drag-drop instead of an input element?

I thought by drag-drop you meant the drag-and-drop API rather than a  
drag-drop operation on the <input type=file multiple> element.


> My point is more that input elements currently support dropping files  
> onto them in multiple browsers. It's confusing for "multiple" that  
> dropping
> directories+files doesn't upload said directories+files, or at least give
> some sort of indication to the user that some of them are being not  
> allowed.
>
> We should leave it up to UAs to figure out what the right UI should be,  
> but adding input "directory" seems to me like it will confuse the UI  
> more.
> Ideally users can drop whatever they want onto a file input that has
> "multiple" and it can be up to the web page to remove entries it doesn't
> allow. The web page is in a much better position to give user feedback  
> (e.g. a photo site can warn that only image uploads are allowed and that
> non-images won't get uploaded).

Even if we allow this we would still need to define the semantics. I.e.  
what the file names end up being, if the API supports hierarchical access,  
etc. Or am I missing something?


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

From ojan at chromium.org  Wed May 12 08:33:15 2010
From: ojan at chromium.org (Ojan Vafai)
Date: Wed, 12 May 2010 08:33:15 -0700
Subject: [whatwg] Directory upload via <input type="file" directory>
In-Reply-To: <op.vclbz7wk64w2qv@annevk-t60>
References: <r2m5ce7a0db1004011553o5ffe5db4y9339b4e79bfb9c9c@mail.gmail.com> 
	<x2m78dc8441004061238uae868197of81be4d684f0950c@mail.gmail.com> 
	<z2n5ce7a0db1004061253r68543f3fh42706b7ba2f50491@mail.gmail.com> 
	<v2q78dc8441004061418u1096fe9fzb26032923fdfca63@mail.gmail.com> 
	<h2y5ce7a0db1004061428v4dafbed7m8b0a6f2627e2561e@mail.gmail.com> 
	<v2w78dc8441004221511h2c53542q15f1b000183763d9@mail.gmail.com> 
	<op.vbndv9de64w2qv@annevk-t60>
	<k2p78dc8441004240858x95b5006ax1f69d8174b4f2896@mail.gmail.com>
	<op.vclbz7wk64w2qv@annevk-t60>
Message-ID: <w2u78dc8441005120833y3da038e4k479e355cead9199c@mail.gmail.com>

On Wed, May 12, 2010 at 4:39 AM, Anne van Kesteren <annevk at opera.com> wrote:

> On Sat, 24 Apr 2010 17:58:10 +0200, Ojan Vafai <ojan at chromium.org> wrote:
>
>> My point is more that input elements currently support dropping files onto
>> them in multiple browsers. It's confusing for "multiple" that dropping
>
>  directories+files doesn't upload said directories+files, or at least give
>> some sort of indication to the user that some of them are being not
>> allowed.
>>
>> We should leave it up to UAs to figure out what the right UI should be,
>> but adding input "directory" seems to me like it will confuse the UI more.
>> Ideally users can drop whatever they want onto a file input that has
>> "multiple" and it can be up to the web page to remove entries it doesn't
>> allow. The web page is in a much better position to give user feedback
>> (e.g. a photo site can warn that only image uploads are allowed and that
>> non-images won't get uploaded).
>>
>
> Even if we allow this we would still need to define the semantics. I.e.
> what the file names end up being, if the API supports hierarchical access,
> etc. Or am I missing something?
>

Correct. We should try to solve that problem. I was just voicing my distaste
for the solution to that problem being adding a new input type that
exclusively works on directories.

So far, the best solution I've heard is adding partial path information
(e.g. a "paths" property that parallels the "files" property). That has it's
short-comings as well, but it works for the majority of use-cases.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100512/6fb5eb59/attachment.htm>

From ojan at chromium.org  Wed May 12 11:01:11 2010
From: ojan at chromium.org (Ojan Vafai)
Date: Wed, 12 May 2010 11:01:11 -0700
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
Message-ID: <g2t78dc8441005121101h12f95fbdp4ec01e742eff3370@mail.gmail.com>

On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <simonp at opera.com> wrote:

> establishing a WebSocket connection:
>
> [[
> Note: There is no limit to the number of established WebSocket connections
> a user agent can have with a single remote host. Servers can refuse to
> connect users with an excessive number of connections, or disconnect
> resource-hogging users when suffering high load.
> ]]
>
> Still, it seems likely that user agents will want to have limits on the
> number of established WebSocket connections, whether to a single remote host
> or multiple remote hosts, in a single tab or overall.


Why? Is the concern that we'd run out of memory? Overload the user's network
connection?

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100512/0090c504/attachment.htm>

From ash at ashleysheridan.co.uk  Wed May 12 11:06:51 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Wed, 12 May 2010 19:06:51 +0100
Subject: [whatwg] WebSockets: what to do when there are too many open
 connections
In-Reply-To: <g2t78dc8441005121101h12f95fbdp4ec01e742eff3370@mail.gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<g2t78dc8441005121101h12f95fbdp4ec01e742eff3370@mail.gmail.com>
Message-ID: <1273687611.21168.243.camel@localhost>

On Wed, 2010-05-12 at 11:01 -0700, Ojan Vafai wrote:
> On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <simonp at opera.com>
> wrote:
> 
>         establishing a WebSocket connection:
>         
>         [[
>         Note: There is no limit to the number of established WebSocket
>         connections a user agent can have with a single remote host.
>         Servers can refuse to connect users with an excessive number
>         of connections, or disconnect resource-hogging users when
>         suffering high load.
>         ]]
>         
>         Still, it seems likely that user agents will want to have
>         limits on the number of established WebSocket connections,
>         whether to a single remote host or multiple remote hosts, in a
>         single tab or overall. 
>         
> 
> 
> Why? Is the concern that we'd run out of memory? Overload the user's
> network connection?
> 
> 
> Ojan

I would imagine primarily it's out of concern for the remote host.

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


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

From michaeln at google.com  Wed May 12 11:51:59 2010
From: michaeln at google.com (Michael Nordman)
Date: Wed, 12 May 2010 11:51:59 -0700
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
Message-ID: <AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>

On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <simonp at opera.com> wrote:

> establishing a WebSocket connection:
>
> [[
> Note: There is no limit to the number of established WebSocket connections
> a user agent can have with a single remote host. Servers can refuse to
> connect users with an excessive number of connections, or disconnect
> resource-hogging users when suffering high load.
> ]]
>
> Still, it seems likely that user agents will want to have limits on the
> number of established WebSocket connections, whether to a single remote host
> or multiple remote hosts, in a single tab or overall. The question is what
> should be done when the user agent-defined limit of established connections
> has been reached and a page tries to open another WebSocket.
>
> I think just waiting for other WebSockets to close is not good. It just
> means that newly loaded pages don't work.
>
>
Agreed, not good. The intent of the api is to start opening a socket now,
not at some undefined point in the future after the user has taken some
undefined action (hey user... please close a tab that has a socket open...
not particularly user actionable).


> If there are any WebSockets in CLOSING state, then I think we should wait
> until they have closed. Otherwise, I think we should force close the oldest
> WebSocket.
>

Force closing the oldest is not good. A malicious site could cause all open
sockets to be closed. Also this would have nasty side effects. Consider a
memory allocator that just deleted the oldest allocation to make room for
new allocations, far removed things just start failing on odd ways... no
thank you.

An obvious way to handle this condition of "too many sockets are open" is to
fail to open the new socket with an exception/error which indicates that
condition.


>
> --
> Simon Pieters
> Opera Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100512/c4add750/attachment-0001.htm>

From simonp at opera.com  Thu May 13 07:47:34 2010
From: simonp at opera.com (Simon Pieters)
Date: Thu, 13 May 2010 16:47:34 +0200
Subject: [whatwg] WebSockets: what to do when there are too many open
 connections
In-Reply-To: <g2t78dc8441005121101h12f95fbdp4ec01e742eff3370@mail.gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<g2t78dc8441005121101h12f95fbdp4ec01e742eff3370@mail.gmail.com>
Message-ID: <op.vcnfdk1oidj3kv@simon-pieterss-macbook.local>

On Wed, 12 May 2010 20:01:11 +0200, Ojan Vafai <ojan at chromium.org> wrote:

> On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <simonp at opera.com> wrote:
>
>> establishing a WebSocket connection:
>>
>> [[
>> Note: There is no limit to the number of established WebSocket  
>> connections
>> a user agent can have with a single remote host. Servers can refuse to
>> connect users with an excessive number of connections, or disconnect
>> resource-hogging users when suffering high load.
>> ]]
>>
>> Still, it seems likely that user agents will want to have limits on the
>> number of established WebSocket connections, whether to a single remote  
>> host
>> or multiple remote hosts, in a single tab or overall.
>
>
> Why? Is the concern that we'd run out of memory? Overload the user's  
> network
> connection?

If nothing else, the underlying OS might have a limit on the number of  
open connections.

-- 
Simon Pieters
Opera Software

From simonp at opera.com  Thu May 13 08:05:19 2010
From: simonp at opera.com (Simon Pieters)
Date: Thu, 13 May 2010 17:05:19 +0200
Subject: [whatwg] WebSockets: what to do when there are too many open
 connections
In-Reply-To: <AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
Message-ID: <op.vcnf65zvidj3kv@simon-pieterss-macbook.local>

On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman <michaeln at google.com>  
wrote:

> On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <simonp at opera.com> wrote:
>
>> establishing a WebSocket connection:
>>
>> [[
>> Note: There is no limit to the number of established WebSocket  
>> connections
>> a user agent can have with a single remote host. Servers can refuse to
>> connect users with an excessive number of connections, or disconnect
>> resource-hogging users when suffering high load.
>> ]]
>>
>> Still, it seems likely that user agents will want to have limits on the
>> number of established WebSocket connections, whether to a single remote  
>> host
>> or multiple remote hosts, in a single tab or overall. The question is  
>> what
>> should be done when the user agent-defined limit of established  
>> connections
>> has been reached and a page tries to open another WebSocket.
>>
>> I think just waiting for other WebSockets to close is not good. It just
>> means that newly loaded pages don't work.
>>
>>
> Agreed, not good. The intent of the api is to start opening a socket now,
> not at some undefined point in the future after the user has taken some
> undefined action (hey user... please close a tab that has a socket  
> open...
> not particularly user actionable).
>
>
>> If there are any WebSockets in CLOSING state, then I think we should  
>> wait
>> until they have closed. Otherwise, I think we should force close the  
>> oldest
>> WebSocket.
>>
>
> Force closing the oldest is not good. A malicious site could cause all  
> open
> sockets to be closed. Also this would have nasty side effects. Consider a
> memory allocator that just deleted the oldest allocation to make room for
> new allocations, far removed things just start failing on odd ways... no
> thank you.
>
> An obvious way to handle this condition of "too many sockets are open"  
> is to
> fail to open the new socket with an exception/error which indicates that
> condition.

But then to make the page work the user still has to close a tab that has  
a socket open. But maybe just firing a 'close' event and logging in the  
error console is the best thing to do.

-- 
Simon Pieters
Opera Software

From derernst at gmx.ch  Thu May 13 09:56:00 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 13 May 2010 18:56:00 +0200
Subject: [whatwg] Image resize API proposal
In-Reply-To: <AANLkTimipWsXnVqcNTD3vYTd9gSuLkWGeYnCtp0wYWIL@mail.gmail.com>
References: <AANLkTimipWsXnVqcNTD3vYTd9gSuLkWGeYnCtp0wYWIL@mail.gmail.com>
Message-ID: <4BEC2F20.1010006@gmx.ch>

Am 11.05.2010 20:58 schrieb Sterling Swigart:
> I'm working with David Levin, and based on the feedback received 
> regarding offscreen canvas, the proposal has been changed to address 
> more specific scenarios. The main use case was resizing images, so we 
> are proposing an asynchronous image resizing API. If you are curious 
> about how we arrived at our API below, take a look at the "appendix" to 
> view the alternatives we considered.
> 
> Let us know what you think. Thanks!
> Sterling
> 
> 
>   Use Cases:
> 
> Begin with a user giving a local image file to a webpage. Then:
> 
> 1. In real-time chat, quickly give other users a thumbnail view of the 
> image file.
> 
> 2. Or, limit the size of an image file before uploading it to a web server.
> 
> Proposed Solution:
> 
> We propose adding image.getBlob. getBlob will be an instance function of 
> the javascript Image object which asynchronously gets a blob of the 
> image, resized to the given width and height, encoded into jpeg or png. 
> The function declaration will be:
> 
> getBlob(mimeType /* req */, width /* req */, height /* req */, 
> successEvent /* req */, errorEvent /* op */, qualityLevel /* op */, 
> preserveAspectRatio /* op */, rotateExif /* op */);

I am a web author with limited scripting knowledge, so I apologize I 
can't give a qualified feedback to your proposal in detail.

Generally I consider client side image resizing a very good idea; 
currently I use a Java applet for this purpose, and of course it would 
be nice to have this functionality natively in browsers. Anyway, for 
submitting the image in a form (which both your use cases are about), I 
would not primarily expect a function that returns a blob, but rather 
one that modifies the image data. E.g.:

function resize(mimeType, width, height, keepAspectRatio, qualityLevel)

For the image upload use case, calling the function via event-handler in 
the file input control affects the image data in the form data:

<input type="file" onSubmit="resize('image/jpeg', 300, 350, true)">

I do not understand what use cases could be other than modifying images 
for form upload, but if there are any, the same method could be applied 
to the image object (given that the method waits for the image data to 
be completely loaded):

var i = document.getElementById("myImg");
i.resize('image/png', 300, 350, true, .95);

This would have mainly the same effect as changing i.style.width and 
i.style.height, except you can specify the quality level. (Maybe the 
argument order should be changed the way that the mime type can be 
optional, as in this case most authors would not really care about the 
mime type - except that it might be nice to convert a gif with 
transparency into a png to get the transparency edges antialiased.)

If you need the blob data for further processing, a separate getBlob() 
function would be needed.

var i = new Image();
i.src = "my/img/url.jpg";
i.resize('image/jpeg', 300, 350, true, .55);
var blobData = i.getBlob();


From pedzsan at gmail.com  Thu May 13 10:19:31 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Thu, 13 May 2010 12:19:31 -0500
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
Message-ID: <638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>

On May 13, 2010, at 10:05 AM, Simon Pieters wrote:

> On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman <michaeln at google.com> wrote:
> 
>> On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <simonp at opera.com> wrote:
>> 
>>> establishing a WebSocket connection:
>>> 
>>> [[
>>> Note: There is no limit to the number of established WebSocket connections
>>> a user agent can have with a single remote host. Servers can refuse to
>>> connect users with an excessive number of connections, or disconnect
>>> resource-hogging users when suffering high load.
>>> ]]
>>> 
>>> Still, it seems likely that user agents will want to have limits on the
>>> number of established WebSocket connections, whether to a single remote host
>>> or multiple remote hosts, in a single tab or overall. The question is what
>>> should be done when the user agent-defined limit of established connections
>>> has been reached and a page tries to open another WebSocket.
>>> 
>>> I think just waiting for other WebSockets to close is not good. It just
>>> means that newly loaded pages don't work.

Hosts have limits on open file descriptors but they are usually in the ten's of thousands (per process) on today's OSs.

I don't think this is an area for the spec.  The open must be allowed to fail if something goes wrong.  The OS might reject it and the browser might reject it too.  Aside from that, I don't think the spec should dictate what to do here.

A nice UA, I think, would monitor a particular tab or browsing context for being out of control.  This might be opening an infinite number of sockets or running infinite threads to bog the user's system down (or it might be because I forgot a semicolon :-).  There are countless ways for nasty javascript to upset the user.  A nice UA from a nice group would learn these new ways and adapt to them over time.  When detected, the UA could ask the user if they want this mayhem to continue or not.  I think rampant socket abuse is just one of countless places nasty javascript is going to exploit the user.  I don't see how the spec can foresee all of them nor should a "complaint UA" be required to detect all of them.

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

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


From jat at google.com  Thu May 13 10:35:03 2010
From: jat at google.com (John Tamplin)
Date: Thu, 13 May 2010 13:35:03 -0400
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local> 
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com> 
	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
Message-ID: <k2v3f94964f1005131035r2ab79a60m98320a6fde6f49cc@mail.gmail.com>

On Thu, May 13, 2010 at 1:19 PM, Perry Smith <pedzsan at gmail.com> wrote:

> >>> [[
> >>> Note: There is no limit to the number of established WebSocket
> connections
> >>> a user agent can have with a single remote host. Servers can refuse to
> >>> connect users with an excessive number of connections, or disconnect
> >>> resource-hogging users when suffering high load.
> >>> ]]
> >>>I don't think this is an area for the spec.  The open must be allowed to
> fail if something goes wrong.  The OS might reject it and the browser might
> reject it too.  Aside from that, I don't think the spec should dictate what
> to do here.
>
> A nice UA, I think, would monitor a particular tab or browsing context for
> being out of control.  This might be opening an infinite number of sockets
> or running infinite threads to bog the user's system down (or it might be
> because I forgot a semicolon :-).  There are countless ways for nasty
> javascript to upset the user.  A nice UA from a nice group would learn these
> new ways and adapt to them over time.  When detected, the UA could ask the
> user if they want this mayhem to continue or not.  I think rampant socket
> abuse is just one of countless places nasty javascript is going to exploit
> the user.  I don't see how the spec can foresee all of them nor should a
> "complaint UA" be required to detect all of them.
>

 I think simply saying that a user agent may restrict the number of
connections like the server might is sufficient.  As written, it implies the
number is actually unlimited.

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

From mike.shaver at gmail.com  Thu May 13 10:40:09 2010
From: mike.shaver at gmail.com (Mike Shaver)
Date: Thu, 13 May 2010 13:40:09 -0400
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
Message-ID: <AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>

On Thu, May 13, 2010 at 1:19 PM, Perry Smith <pedzsan at gmail.com> wrote:
> Hosts have limits on open file descriptors but they are usually in the ten's of thousands (per process) on today's OSs.

I have to admit, I'd be a little surprised (I think pleasantly, but
maybe not) if I could open ten thousand file descriptors on the latest
shipping Windows CE, or for that matter on an iPhone.

The question is whether you queue or give an error.  When hitting the
RFC-ish per-host connection limits, browsers queue additional requests
from <img> or such, rather than erroring them out.  Not sure that's
the right model here, but I worry about how much boilerplate code
there will need to be to retry the connection (asynchronously) to
handle failures, and whether people will end up writing it or just
hoping for the best.

Mike

From mart at degeneration.co.uk  Thu May 13 11:31:58 2010
From: mart at degeneration.co.uk (Martin Atkins)
Date: Thu, 13 May 2010 11:31:58 -0700
Subject: [whatwg] Changing punctuation value of input element in
 telephone state
In-Reply-To: <4BBC6340.3070804@peda.net>
References: <4BBBA3CE.1020606@gmail.com>	<Pine.LNX.4.64.1004062236100.4065@ps20323.dreamhostps.com>	<4BBBBABC.5040909@gmail.com>	<t2oad2fe68c1004061604lad64a2a2rfb6ee798a494020b@mail.gmail.com>	<Pine.LNX.4.64.1004062309480.4065@ps20323.dreamhostps.com>	<g2s6ea53251004061628s19e2b05bh27f5f89279c06ba8@mail.gmail.com>	<1270596699.13157.61.camel@localhost>
	<4BBC6340.3070804@peda.net>
Message-ID: <4BEC459E.2000003@degeneration.co.uk>

On 04/07/2010 03:49 AM, Mikko Rantalainen wrote:
>
> And nowadays you will see stuff like this:
> +358 (012) 1234 567
> This contains the area code for Finland "+358" in addition to the
> Finnish "local distance number".
> However, there's a catch! When dialing, you must press +358121234567
> because the first zero of area code is dropped if there's a country
> code. As a result, it's not safe to blindly drop the parenthesis from
> user inputted phone number.
>

This is the case in the UK too.

While in the US phone users tend to realise that the "1" on the front of 
the number is the national dialling prefix, in the UK the "0" that 
signals national dialling is always quoted as part of the dialling code, 
and phone users who don't use international numbers frequently don't 
realize that it's not strictly part of the telephone number.

A common notation for UK numbers with an international prefix is:
     +44 (0)1206 123456

...which, just as in your Finnish example, is either dialled as 
+441206123456 or as 01206123456 (were + stands in for your country's 
international dialling prefix.). Dialling +4401206123456 doesn't work.

So with all that said, I don't think dropping punctuation is an adequate 
solution. Cellphones I've had both the US and the UK seem to be able to 
recognize the local conventions and normalize them to the correct form 
for number recognition, so perhaps browsers could adopt the same 
appraoch but this assumes that they would be able to detect what 
geographical area they are being used in and have support for various 
international numbering schemes, which seems like a big burden to put on 
a browser when dealing with telephone numbers is not its core concern.


From Simetrical+w3c at gmail.com  Thu May 13 12:23:52 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 13 May 2010 15:23:52 -0400
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
	<AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
Message-ID: <AANLkTik6yjXN5JPcp3LvwpwtgVyje6YvFBeekI_myBVT@mail.gmail.com>

On Thu, May 13, 2010 at 1:40 PM, Mike Shaver <mike.shaver at gmail.com> wrote:
> I have to admit, I'd be a little surprised (I think pleasantly, but
> maybe not) if I could open ten thousand file descriptors on the latest
> shipping Windows CE, or for that matter on an iPhone.

ulimit -n tells me I can only open 1024 per process on my desktop and
server Linux machines.  Actually, I had to configure lighttpd on my
server to raise its max file descriptors to 4096 to make sure it could
handle all my keepalive connections (although maybe it could have
anyway).

From levin at google.com  Thu May 13 12:43:33 2010
From: levin at google.com (David Levin)
Date: Thu, 13 May 2010 12:43:33 -0700
Subject: [whatwg] Image resize API proposal
In-Reply-To: <4BEC2F20.1010006@gmx.ch>
References: <AANLkTimipWsXnVqcNTD3vYTd9gSuLkWGeYnCtp0wYWIL@mail.gmail.com>
	<4BEC2F20.1010006@gmx.ch>
Message-ID: <AANLkTilXB_qtkjkHdrKAFaSOJfKBdsk6nUz2uxdbuGQY@mail.gmail.com>

On Thu, May 13, 2010 at 9:56 AM, Markus Ernst <derernst at gmx.ch> wrote:

>
>>
> I am a web author with limited scripting knowledge, so I apologize I can't
> give a qualified feedback to your proposal in detail.
>
> Generally I consider client side image resizing a very good idea; currently
> I use a Java applet for this purpose, and of course it would be nice to have
> this functionality natively in browsers. Anyway, for submitting the image in
> a form (which both your use cases are about), I would not primarily expect a
> function that returns a blob, but rather one that modifies the image data.
> E.g.:
>
> function resize(mimeType, width, height, keepAspectRatio, qualityLevel)
>
> For the image upload use case, calling the function via event-handler in
> the file input control affects the image data in the form data:
>
> <input type="file" onSubmit="resize('image/jpeg', 300, 350, true)">
>

Thanks Markus for the feedback.

A few things that may not have been made clear in the proposal:
1. It important that the method be asynchronous to avoid the web page
hanging while waiting for a result. (If you wanted a sync resize, you could
use canvas for example.)
2. The use cases didn't touch on the desire to display the image being
uploaded (especially useful for use case #2, limiting the size of an
uploaded image).

As I read this line <input type="file" onSubmit="resize('image/jpeg', 300,
350, true)">, you've suggesting adding a resize method on the file object
that modifies the file in memory. I'm not sure how that would work because
Files are immutable in memory. In addition, we'd need to add a resize method
to image which modifies it in memory and a getBlob() method.

I like the fact that your proposal results in much simpler code overall, but
it seems like there may be a number of problems with this approach.

fwiw, here's a more complete sample (using the img.getBlob method) which
gives a preview of the upload, does the upload to the server, or shows an
error if appropriate.


var upload = function (newBlob) {
  // Show a preview of the image.
  document.getElementById("uploadPreview").src = newBlob.url;

  // Upload it to our server.
  var formData = new FormData();
  formData.append(newBlob);
  var xhr = new XMLHttpRequest();
  xhr.open("POST", "http://example.com/");
  xhr.send(formData);
}

var resizeFailed = function (newBlob) {
  document.getElementById("status").innerText = "Oops. Unable to...";
}

Image i = new Image();
var file = document.forms['uploadData']['fileChooser'].files[0];
i.src = file.url;
i.getBlob('image/png', 300, 350, upload, resizeFailed, .55);

Thanks, dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100513/dae9f404/attachment.htm>

From gman at google.com  Thu May 13 15:32:27 2010
From: gman at google.com (Gregg Tavares)
Date: Thu, 13 May 2010 15:32:27 -0700
Subject: [whatwg] Image resize API proposal
In-Reply-To: <AANLkTimipWsXnVqcNTD3vYTd9gSuLkWGeYnCtp0wYWIL@mail.gmail.com>
References: <AANLkTimipWsXnVqcNTD3vYTd9gSuLkWGeYnCtp0wYWIL@mail.gmail.com>
Message-ID: <k2ude4bd3191005131532k433a11arbc1bd5a4914438d@mail.gmail.com>

This really seems like the wrong solution. Taken to an extreme next you'll
need to add VideoRisizer, AudioRecompresser, and any thing else JavaScript
can't do without freezing the browser.

It seems like it would be better to figure out a way to get Web Workers to
be able to do this. Even if they have to XHR the binary down, decompress
into a TypeArray (see WebGL) and read the data themsevles so they can keep
the EXIF stuff, bloating the browser for one small use doesn't seem like the
right solution.

You can post an open source library and the usage can be as simple as this
proposal.


On Tue, May 11, 2010 at 11:58 AM, Sterling Swigart <sswigart at google.com>wrote:

> I'm working with David Levin, and based on the feedback received regarding
> offscreen canvas, the proposal has been changed to address more specific
> scenarios. The main use case was resizing images, so we are proposing an
> asynchronous image resizing API. If you are curious about how we arrived at
> our API below, take a look at the "appendix" to view the alternatives we
> considered.
>
> Let us know what you think. Thanks!
> Sterling
>
> Use Cases:
>
> Begin with a user giving a local image file to a webpage. Then:
>
> 1. In real-time chat, quickly give other users a thumbnail view of the
> image file.
>
> 2. Or, limit the size of an image file before uploading it to a web server.
>

This use case is already handled (minus the EXIF).

> Proposed Solution:
>
> We propose adding image.getBlob. getBlob will be an instance function of
> the javascript Image object which asynchronously gets a blob of the image,
> resized to the given width and height, encoded into jpeg or png. The
> function declaration will be:
>
> getBlob(mimeType /* req */, width /* req */, height /* req */, successEvent
> /* req */, errorEvent /* op */, qualityLevel /* op */, preserveAspectRatio
> /* op */, rotateExif /* op */);
>
> The blob will be passed as an argument to the success callback function, or
> upon error, error data will be passed into the error callback function as an
> argument. Quality level should be between 0.0 and 1.0, and any value outside
> of that range will be reverted to the default, 0.85. If MIME type does not
> equal "image/jpeg", then quality level is ignored. If null (or a negative
> value) is passed in for the width or height, then the function will use the
> source's measurement for that dimension. Default values for
> preserveAspectRatio and rotateExif are true.
>
> All EXIF metadata will be retained except for any saved thumbnails, and the
> EXIF rotation property will be appropriately modified.
>
> Security:
>
> If the image source is of a different origin than the script context, then
> getBlob raises a SECURITY_ERR exception.
>
> Sample Code:
>
> // url contains location of an image file
>
> Image i = new Image();
>
> i.src = url;
>
> var successEvt = function (newBlob) { myDiv.innerHTML += "<img src='" +
> newBlob.url + "' />"; };
>
> var errEvt = function (err) { alert(err); };
>
> i.getBlob("image/jpeg", 300, 350, successEvt, errEvt, .55);
>
> // Image will retain aspect ratio and correct for EXIF rotation. If the
> source image was 700x700,
>
> // the blob will represent a new image that is 300x300.
>
> That's all!Appendix: Alternatives considered
>
> For reference, we've also included a list of other designs that we thought
> of along with the reasons why they were dropped
>
> Creating a new object for resizing
>
> Summary of approach:
>
> [NamedConstructor=ImageResizer(),
>
> NamedConstructor=ImageResizer(blob, onsuccess),
>
> NamedConstructor=ImageResizer(blob, onsuccess, onerror),
>
> NamedConstructor=ImageResizer(blob, onsuccess, onerror, type),
>
> NamedConstructor=ImageResizer(blob, onsuccess, onerror, type, width,
> height)]
>
> interface ImageResizer {
>
> void start(); // starts resize operation
>
> void abort(); // aborts operation
>
>  attribute Blob blob;
>
> attribute DOMString type; // default "image/png"
>
> attribute unsigned long width;
>
> attribute unsigned long height;
>
> attribute float qualityLevel; // default 1.0, must be 0.0 to 1.0, else
> reverts to default
>
>  readonly attribute unsigned short started; // default 0
>
>  attribute Function onsuccess;
>
> attribute Function onerror;
>
> };
>
> Why it wasn't chosen:
>
> Creating an entirely new object for this task made the task seem more
> complicated and involved than necessary, and this problem could be solved
> via modifications to the Image object.
>
> Returning a SizelessBlob immediately from a method on image
>
> Summary of approach:
>
> var streamingBlob = image.toStreamingBlob(mimeType /* req */, width /* req
> */, height /* req */, qualityLevel /* op */, preserveAspectRatio /* op */,
> rotateExif /* op */);
>
> New Blob Interfaces:
>
> interface SizelessBlob {
>
> // moved from Blob
>
> readonly attribute DOMString type;
>
> readonly attribute DOMString url; // whatever name -- URL, urn, URN, etc.
>
> }
>
> interface StreamingBlob : SizelessBlob {
>
> // at most one of the following functions will be called for a single
> FutureBlob
>
> attribute Function onblobready;
>
> attribute Function onerror;
>
> readyonly attribute blob; // throws an exception if accessed before
> onblobready is called.
>
> }
>
> interface Blob : SizelessBlob {
>
> readonly attribute unsigned long long size;
>
> Blob slice(in long long start,
>
> in long long length); // raises DOMException
>
> };
>
> Why it wasn't chosen:
>
>    - the disconnect of the error from the thing that caused it making
>    failures hard to understand (e.g. An image load may fail but that may not be
>    detected until the xhr is done using the resized image.)
>    - the issues that result from passing a SizelessBlob, which has a
>    reference to a loading image, to another document and closing the original
>    document (thus killing the image loader)
>    - introduction of multiple blobs which may be confusing to developers
>    - the need to change all existing specs to use SizelessBlob instead of
>    Blob
>
> Returning a Blob immediately from a method on image
>
> Summary of approach:
>
> var blob = image.toBlob(mimeType /* req */, width /* req */, height /* req
> */, qualityLevel /* op */, preserveAspectRatio /* op */, rotateExif /* op
> */);
>
> blob.size and blob.slice throw until the blob is complete. There would need
> to be a new event to say when the blob's size is ready.
>
> Why it wasn't chosen:
>
> It felt like it was changing how blobs worked to make the size throw.
> Also, this has some of the same disadvantages of as the SizelessBlobapproach.
>
> Using CSS of Image to designate dimensions instead of putting it in the API
>
> Summary of approach:
>
> img.getBlob(mimeType /* req */, successEvent /* req */, errorEvent /* op
> */, qualityLevel /* op */);
>
> Why it wasn't chosen:
>
> It would have been confusing to the user if getBlob took into account some
> CSS attributes but not others, and using all CSS tags posed a lot of
> unnecessary implementation complexity without any use cases.
>
> Using the File object
>
> Summary of approach:
>
> FileReader readResized(). The result would be a data url with the resized
> image.
>
> Why it wasn't chosen:
>
> We also examined making this function an instance method of the FileReader
> object, but this function did not fit well in the context of the File
> object. FileReader's result is a string, posing a problem for large results
> as well as an unnecessary conversion. One way another this problem is to use
> a URN (like File.urn), it would have prevented us from posting the result to
> a server as well as having the lifetime issues that File.urn does.
>
> Having a very specialized method on FormData to do the resize and allow
> upload
>
> Summary of approach:
>
> FormData.appendResized(DOMString name, Blob value, mimeType /* req */,
> with /* req */, height /* req */, qualityLevel /* op */,
> preserveAspectRatio /* op */, rotateExif /* op */);
>
> Why it wasn't chosen:
>
> This approach was over specialized and didn't allow for using the result on
> the web page at all which would be useful as a preview of exactly what is
> being uploaded.
>
> Using canvas in a worker
>
> Summary of approach:
>
> This is the OffscreenCanvas proposal which can be seen here: h<http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>
> ttp <http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>:<http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>
> //www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html<http://www.mail-archive.com/whatwg at lists.whatwg.org/msg20297.html>
>
> Why it wasn't chosen:
>
> Due to making it rather complicated for the javascript user to accomplish
> their goal and the code complexity and the speed trade-offs that may change
> due to gpu acceleration, this idea didn't get traction and many folks
> suggested something simpler for the intended use cases. A few more drawbacks
> are that this doesn't obey exif automatically and it doesn't preserve the
> exif metadata.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100513/e8215ffd/attachment-0001.htm>

From levin at google.com  Thu May 13 15:53:25 2010
From: levin at google.com (David Levin)
Date: Thu, 13 May 2010 15:53:25 -0700
Subject: [whatwg] Image resize API proposal
In-Reply-To: <k2ude4bd3191005131532k433a11arbc1bd5a4914438d@mail.gmail.com>
References: <AANLkTimipWsXnVqcNTD3vYTd9gSuLkWGeYnCtp0wYWIL@mail.gmail.com>
	<k2ude4bd3191005131532k433a11arbc1bd5a4914438d@mail.gmail.com>
Message-ID: <AANLkTilVdoySWvGmHQ114WHcNACm34UIOW3z_7n13EEd@mail.gmail.com>

Thanks for your feedback Gregg.

On Thu, May 13, 2010 at 3:32 PM, Gregg Tavares <gman at google.com> wrote:

> This really seems like the wrong solution. Taken to an extreme next you'll
> need to add VideoRisizer, AudioRecompresser, and any thing else JavaScript
> can't do without freezing the browser.
>
> It seems like it would be better to figure out a way to get Web Workers to
> be able to do this.


This has been explored. See "Alternatives considered" in the original
proposal.


> Even if they have to XHR the binary down, decompress into a TypeArray (see
> WebGL) and read the data themsevles so they can keep the EXIF stuff,
> bloating the browser for one small use doesn't seem like the right solution.
>

"Small use" is a relative term. In that there are a lot of web properties
that either do this or want to do this right now.



> You can post an open source library and the usage can be as simple as this
> proposal.
>

Then you would have to include the open source library as part of your web
application which is suboptimal.



>
> On Tue, May 11, 2010 at 11:58 AM, Sterling Swigart <sswigart at google.com>wrote:
>
>> 2. Or, limit the size of an image file before uploading it to a web
>> server.
>>
>
> This use case is already handled (minus the EXIF).
>

How? (Note "limit the size". If you mean using canvas, it may hang the UI
for the user which is a really bad experience.

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

From pedzsan at gmail.com  Thu May 13 16:55:08 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Thu, 13 May 2010 18:55:08 -0500
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
	<AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
Message-ID: <77A04419-F45F-4845-BE6F-D9E26FEAA28B@gmail.com>


On May 13, 2010, at 12:40 PM, Mike Shaver wrote:

> The question is whether you queue or give an error.  When hitting the
> RFC-ish per-host connection limits, browsers queue additional requests
> from <img> or such, rather than erroring them out.  Not sure that's
> the right model here, but I worry about how much boilerplate code
> there will need to be to retry the connection (asynchronously) to
> handle failures, and whether people will end up writing it or just
> hoping for the best.

Ah.  Thats a good question.  (Maybe that was the original question.)

Since web sockets is the topic and as far as I know web sockets are only used by javascript, I would prefer an error over queuing them up.

I think javascript and browser facilities have what is needed to create its own retry mechanism if that is what a particular situation wants.  I don't see driving the retry via a scripting language to be bad.  Its not that hard and it won't happen that often.  And it gives the javascript authors more control and choices.

Thats my vote...

pedz


From dimich at chromium.org  Thu May 13 17:36:31 2010
From: dimich at chromium.org (Dmitry Titov)
Date: Thu, 13 May 2010 17:36:31 -0700
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <77A04419-F45F-4845-BE6F-D9E26FEAA28B@gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
	<AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
	<77A04419-F45F-4845-BE6F-D9E26FEAA28B@gmail.com>
Message-ID: <AANLkTinhPlrh2deZcIxXcHWK7wHwPCSDneMnNs-VdSy8@mail.gmail.com>

As an example from a bit different area, in Chrome the Web Workers today
require a separate process per worker. It's not good to create too many
processes so there is a relatively low limit per origin and higher total
limit. Two limits help avoid situation when 1 bad page affects others. Once
limit is reached, the worker objects are created but queued, on a theory
that pages of the same origin could cooperate, while if a total limit is
blown then hopefully it's a temporary condition. Not ideal but if there
should be a limit we thought having 2 limits (origin/total) is better then
have only a total one.


On Thu, May 13, 2010 at 4:55 PM, Perry Smith <pedzsan at gmail.com> wrote:

>
> On May 13, 2010, at 12:40 PM, Mike Shaver wrote:
>
> > The question is whether you queue or give an error.  When hitting the
> > RFC-ish per-host connection limits, browsers queue additional requests
> > from <img> or such, rather than erroring them out.  Not sure that's
> > the right model here, but I worry about how much boilerplate code
> > there will need to be to retry the connection (asynchronously) to
> > handle failures, and whether people will end up writing it or just
> > hoping for the best.
>
> Ah.  Thats a good question.  (Maybe that was the original question.)
>
> Since web sockets is the topic and as far as I know web sockets are only
> used by javascript, I would prefer an error over queuing them up.
>
> I think javascript and browser facilities have what is needed to create its
> own retry mechanism if that is what a particular situation wants.  I don't
> see driving the retry via a scripting language to be bad.  Its not that hard
> and it won't happen that often.  And it gives the javascript authors more
> control and choices.
>
> Thats my vote...
>
> pedz
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100513/2e0d5ed9/attachment.htm>

From mounir.lamouri at gmail.com  Thu May 13 17:53:36 2010
From: mounir.lamouri at gmail.com (Mounir Lamouri)
Date: Fri, 14 May 2010 02:53:36 +0200
Subject: [whatwg] The form attribute (Association of controls and forms)
Message-ID: <4BEC9F10.3060300@gmail.com>

Hi,

"4.10.18 Association of controls and forms" explains the link between
forms and form-associated elements (and the form attribute). However,
I've the feeling the specifications go far over what should be done and
force the implementor how to do it.
What I mean is, this could be summarized like this: "If the form
attribute is specified, the form owner of the element is the first form
in the Document with the id corresponding of the form attribute value,
if any. If the form attribute content is not a form element id, the
element has no form owner. If the form attribute isn't specificed, the
element form owner is the nearest ancestor form."

However, the specification say (not only):
"When a form-associated element's ancestor chain changes, e.g. because
it or one of its ancestors was inserted or removed from a Document, then
the user agent must reset the form owner of that element.

When a form-associated element's form attribute is added, removed, or
has its value changed, then the user agent must reset the form owner of
that element.

When a form-associated element has a form attribute and the ID of any of
the elements in the Document changes, then the user agent must reset the
form owner of that form-associated element.

When a form-associated element has a form attribute and an element with
an ID is inserted into or removed from the Document, then the user agent
must reset the form owner of that form-associated element."

These sentences explain more than "what should be the form owner" but
explain how to implement it. It seems useless and maybe not needed
sometimes (I'm wondering if checking for the ID wouldn't be better than
observing all the element's ID change and insertion/removal).

In my opinion, the form attribute behaves more or less like the for
attribute for the label element so I'm wondering why the specification
is so different. Is there a reason I'm missing ?

Thanks,
--
Mounir

From michaeln at google.com  Thu May 13 18:20:57 2010
From: michaeln at google.com (Michael Nordman)
Date: Thu, 13 May 2010 18:20:57 -0700
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <AANLkTinhPlrh2deZcIxXcHWK7wHwPCSDneMnNs-VdSy8@mail.gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>
	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>
	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>
	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>
	<AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
	<77A04419-F45F-4845-BE6F-D9E26FEAA28B@gmail.com>
	<AANLkTinhPlrh2deZcIxXcHWK7wHwPCSDneMnNs-VdSy8@mail.gmail.com>
Message-ID: <AANLkTikOmzN2RCygEyP54upgosr_ZkgY-85S8YpWyQ-K@mail.gmail.com>

I think that queuing in chrome bends the intent of the createWorker api just
a little too far and will be happy to see it go away. I'd rather it failed
outright then pretend to succeed when it really hasn't.

(Actually that queuing code complicates the impl somewhat too... can you
tell its been annoying me recently ;)

On Thu, May 13, 2010 at 5:36 PM, Dmitry Titov <dimich at chromium.org> wrote:

> As an example from a bit different area, in Chrome the Web Workers today
> require a separate process per worker. It's not good to create too many
> processes so there is a relatively low limit per origin and higher total
> limit. Two limits help avoid situation when 1 bad page affects others. Once
> limit is reached, the worker objects are created but queued, on a theory
> that pages of the same origin could cooperate, while if a total limit is
> blown then hopefully it's a temporary condition. Not ideal but if there
> should be a limit we thought having 2 limits (origin/total) is better then
> have only a total one.


>
> On Thu, May 13, 2010 at 4:55 PM, Perry Smith <pedzsan at gmail.com> wrote:
>
>>
>> On May 13, 2010, at 12:40 PM, Mike Shaver wrote:
>>
>> > The question is whether you queue or give an error.  When hitting the
>> > RFC-ish per-host connection limits, browsers queue additional requests
>> > from <img> or such, rather than erroring them out.  Not sure that's
>> > the right model here, but I worry about how much boilerplate code
>> > there will need to be to retry the connection (asynchronously) to
>> > handle failures, and whether people will end up writing it or just
>> > hoping for the best.
>>
>> Ah.  Thats a good question.  (Maybe that was the original question.)
>>
>> Since web sockets is the topic and as far as I know web sockets are only
>> used by javascript, I would prefer an error over queuing them up.
>>
>> I think javascript and browser facilities have what is needed to create
>> its own retry mechanism if that is what a particular situation wants.  I
>> don't see driving the retry via a scripting language to be bad.  Its not
>> that hard and it won't happen that often.  And it gives the javascript
>> authors more control and choices.
>>
>> Thats my vote...
>>
>> pedz
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100513/0d7a9f02/attachment-0001.htm>

From bzbarsky at MIT.EDU  Thu May 13 19:00:25 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 13 May 2010 22:00:25 -0400
Subject: [whatwg] WebSockets: what to do when there are too many open
 connections
In-Reply-To: <77A04419-F45F-4845-BE6F-D9E26FEAA28B@gmail.com>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>	<AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
	<77A04419-F45F-4845-BE6F-D9E26FEAA28B@gmail.com>
Message-ID: <4BECAEB9.3080609@mit.edu>

On 5/13/10 7:55 PM, Perry Smith wrote:
> Its not that hard and it won't happen that often.  And it gives
> the javascript authors more control and choices.

If a situation doesn't happen often, then historically speaking most 
authors will have no provisions to handle it.  Try browsing the web with 
non-default colors set in your browser, with a default font size that's 
not 16px, or with a 13px minimum font size set.  These aren't exactly 
hard things to deal with, but authors just don't deal with them.  I 
sincerely doubt they'd deal with the possibility of a websocket not 
actually opening unless is was _very_ common.

Maybe the spec should say that attempts to open a websocket should have 
a 50% chance of failing even if there's no good reason for it, just so 
it is in fact common for opening to fail?  ;)  (No, that's not a 
completely serious proposal, but it's not completely facetious either; 
it would take something like that for authors to handle failure properly.)

-Boris

From thiel.alexandre at gmail.com  Fri May 14 02:51:45 2010
From: thiel.alexandre at gmail.com (Alexandre Thiel)
Date: Fri, 14 May 2010 11:51:45 +0200
Subject: [whatwg] HTML5 Offline web applications & file upload
Message-ID: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>

Hi,

I was wondering if HTML5 Offline mode and file upload can work together ?
I can't find any reference in the online draft which covers only server
resource caching.
Let's imagine you're writing some kind of data editor that works in offline
mode, can you ask the user to select a file to import from his filesystem
that can be processed with javascript or directly transfered to the
localStorage while being offline ?

Alexandre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100514/821a57a1/attachment.htm>

From jorlow at chromium.org  Fri May 14 03:19:32 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Fri, 14 May 2010 11:19:32 +0100
Subject: [whatwg] HTML5 Offline web applications & file upload
In-Reply-To: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>
References: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>
Message-ID: <AANLkTinVlpQUEtKYoPpeP8--hsywJHySGtFS1urcqQPP@mail.gmail.com>

There's a bunch of work currently happening on public-webapps and
public-device-apis @w3.org to enable many offline use cases like this.  The
most closely related specs are probably the FileSystem API and/or the
LocalStorage/IndexedDB APIs + FileReader.

Unfortunately these use cases are not very well supported in browser quite
yet.  (No one is shipping FileSystem or LocalStorage+StructuredClone or
FileReader+StructuredClone as far as I know.)

J

On Fri, May 14, 2010 at 10:51 AM, Alexandre Thiel <thiel.alexandre at gmail.com
> wrote:

> Hi,
>
> I was wondering if HTML5 Offline mode and file upload can work together ?
> I can't find any reference in the online draft which covers only server
> resource caching.
> Let's imagine you're writing some kind of data editor that works in offline
> mode, can you ask the user to select a file to import from his filesystem
> that can be processed with javascript or directly transfered to the
> localStorage while being offline ?
>
> Alexandre
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100514/2c0783c2/attachment.htm>

From and-py at doxdesk.com  Fri May 14 05:50:10 2010
From: and-py at doxdesk.com (And Clover)
Date: Fri, 14 May 2010 14:50:10 +0200
Subject: [whatwg] HTML5 Offline web applications & file upload
In-Reply-To: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>
References: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>
Message-ID: <4BED4702.3040108@doxdesk.com>

On 05/14/2010 11:51 AM, Alexandre Thiel wrote:

> can you ask the user to select a file to import from his filesystem
> that can be processed with javascript or directly transfered to the
> localStorage while being offline ?

Yes. See http://www.w3.org/TR/file-upload/

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/

From chaals at opera.com  Fri May 14 06:22:30 2010
From: chaals at opera.com (Charles McCathieNevile)
Date: Fri, 14 May 2010 15:22:30 +0200
Subject: [whatwg] HTML5 Offline web applications & file upload
In-Reply-To: <AANLkTinVlpQUEtKYoPpeP8--hsywJHySGtFS1urcqQPP@mail.gmail.com>
References: <AANLkTikOb5_WCyKj9k9oZQcSh4c28Z1XmTnzEICKrwgv@mail.gmail.com>
	<AANLkTinVlpQUEtKYoPpeP8--hsywJHySGtFS1urcqQPP@mail.gmail.com>
Message-ID: <op.vco53sfxwxe0ny@widsith.local>

On Fri, 14 May 2010 12:19:32 +0200, Jeremy Orlow <jorlow at chromium.org>  
wrote:

> There's a bunch of work currently happening on public-webapps and
> public-device-apis @w3.org to enable many offline use cases like this.   
> The most closely related specs are probably the FileSystem API and/or
> the LocalStorage/IndexedDB APIs + FileReader.
>
> Unfortunately these use cases are not very well supported in browser  
> quite yet.  (No one is shipping FileSystem or
> LocalStorage+StructuredClone or FileReader+StructuredClone as far as
> I know.)

We (Opera) have been shipping a filesystem API since 10.10, although it is  
only enabled for widgets and Opera Unite applications at the moment.

cheers

Chaals

> J
>
> On Fri, May 14, 2010 at 10:51 AM, Alexandre Thiel  
> <thiel.alexandre at gmail.com
>> wrote:
>
>> Hi,
>>
>> I was wondering if HTML5 Offline mode and file upload can work together  
>> ?
>> I can't find any reference in the online draft which covers only server
>> resource caching.
>> Let's imagine you're writing some kind of data editor that works in  
>> offline
>> mode, can you ask the user to select a file to import from his  
>> filesystem
>> that can be processed with javascript or directly transfered to the
>> localStorage while being offline ?
>>
>> Alexandre
>>


-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

From pedzsan at gmail.com  Fri May 14 07:59:33 2010
From: pedzsan at gmail.com (Perry Smith)
Date: Fri, 14 May 2010 09:59:33 -0500
Subject: [whatwg] WebSockets: what to do when there are too many open
	connections
In-Reply-To: <4BECAEB9.3080609@mit.edu>
References: <op.vclbngugidj3kv@simon-pieterss-macbook.local>	<AANLkTikCV9eOoFpP_QjWjcyuW_h16h3IREOIBmpQ1OBd@mail.gmail.com>	<op.vcnf65zvidj3kv@simon-pieterss-macbook.local>	<638E8E26-5DA1-4AE6-9DB8-C8E4DDBF174A@gmail.com>	<AANLkTingO-fxFHQAqFX-Bdx3xZQplmKyTKoFU3YlWGJ4@mail.gmail.com>
	<77A04419-F45F-4845-BE6F-D9E26FEAA28B@gmail.com>
	<4BECAEB9.3080609@mit.edu>
Message-ID: <5A39AE3F-D9F7-420F-A4D1-6699B7231235@gmail.com>


On May 13, 2010, at 9:00 PM, Boris Zbarsky wrote:

> On 5/13/10 7:55 PM, Perry Smith wrote:
>> Its not that hard and it won't happen that often.  And it gives
>> the javascript authors more control and choices.
> 
> If a situation doesn't happen often, then historically speaking most authors will have no provisions to handle it.  Try browsing the web with non-default colors set in your browser, with a default font size that's not 16px, or with a 13px minimum font size set.  These aren't exactly hard things to deal with, but authors just don't deal with them.  I sincerely doubt they'd deal with the possibility of a websocket not actually opening unless is was _very_ common.
> 
> Maybe the spec should say that attempts to open a websocket should have a 50% chance of failing even if there's no good reason for it, just so it is in fact common for opening to fail?  ;)  (No, that's not a completely serious proposal, but it's not completely facetious either; it would take something like that for authors to handle failure properly.)

That wasn't what I meant.  "it won't happen often" I meant, the need to have a queueing mechanism written in Javascript.  i.e. most applications of web sockets would want to just fail.  The few that do not, can roll their own.


From arun at mozilla.com  Fri May 14 17:05:23 2010
From: arun at mozilla.com (Arun Ranganathan)
Date: Fri, 14 May 2010 17:05:23 -0700
Subject: [whatwg] New File attributes creationDate,
 modificationDate  and size
In-Reply-To: <1273663500.21168.199.camel@localhost>
References: <4BE918B9.5070906@jrn.me.uk> <4BE9A293.8060004@helsinki.fi>	
	<AANLkTinulN8n2O3auuc0nkgmdRIMDut4Hi5XZx7vtRMV@mail.gmail.com>	
	<AANLkTik43By8vGeoNOHZenyEYo_AMkt2tHu7f4zvncYP@mail.gmail.com>
	<1273663500.21168.199.camel@localhost>
Message-ID: <4BEDE543.4020204@mozilla.com>

On 5/12/10 4:25 AM, Ashley Sheridan wrote:
> On Wed, 2010-05-12 at 00:05 -0400, Biju wrote:
>
>    
>> It would be good if we can also get the same at server side when user
>> upload a file using form with file controls
>> ie, like the suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=549253
>> (it works even with javascript disabled)
>>
>> Also remember modificationDate can be a time before creationDate on windows.
>> This is because modificationDate get copied when you copy a file,
>> hence it almost shows modificationDate of the actual content.
>>
>> creationDate on other hand is file creation time on the
>> folder/directory and when you copy a file to a new directory, it will
>> be showing the coping time.
>>
>> PS, for JS option there is mozilla bug 390776
>>      
>    

I intend to update the File API so that the File object exposes 
creationDate and modificationDate.

-- A*

From jimjjewett at gmail.com  Fri May 14 17:20:13 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Fri, 14 May 2010 20:20:13 -0400
Subject: [whatwg] Element-related feedback; attribution element
Message-ID: <AANLkTikZMYV8zvlSkANFKL0DUZ5VEIghKhH9YQqtsbfv@mail.gmail.com>

In http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025549.html
with a subject of "Element-related feedback", Ian Hixie quoted me and
asked:

>On Fri, 1 Jan 2010, Jim Jewett wrote:
>>
>>     Evil Lawyer:  So, when did you stop beating your wife?
>>     Defendant:  Never!
>>
>> "Evil Lawyer" and "Defendant" aren't pronounced.  Their meanings (and
>> silence) are deduced from English conventions about punctuation.  I
>> would prefer a semantic tag.

Hixie:
> Why? What problem would a semantic tag solve? The default styling here
> seems to not need any particular element; the above is perfectly
> understandable as is as far as I can tell.

For written output, yes, the convention works.

Ideally, a screen reader should *not* read the attribution labels --
but it should use them to switch voices.

>> I'm expecting [scripts] to do something like increase the font size or
>> change the background for lines *I* have to memorize for *my* character
>> [based on the semantic marked in the page identifying the character], or
>> for cue lines that I have to recognize.

> Are there any examples of this in the wild? Since this is technically
> possible today, if it's a use case important enough that we should address
> it, it should be easy enough to find examples of this.

> I'm very reluctant to provide features for hypothetical problems that
> don't stem from a real market need. (If we start solving such problems, we
> would fast find ourselves on the path to feature bloat.)

I haven't acted much since finding the internet.  I have seen plenty
of printed scripts in which this was done manually with a highlighter
for rehearsals.  I would expect today's equivalent to be done at time
of printing, rather than by a helpful web site.

So the need is there; the question is whether the need is too
specialized (like the various poetry elements) ... if the only use
were scripts, I would say that it was too specialized, but I would
also use it for photo credits (the italicized captions), etc.  Whether
that then makes it too much of a catchall element -- maybe.



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

(Per above, the UI would change voices in a screen  reader, and could
be used as a hook for user style sheets in scripts.)

>> I would expect it to be used in License checkers that some organizations
>> would deploy to ensure they aren't violating copyright.

> Wouldn't the Work microdata vocabulary be a better solution to this
> problem?

Possibly.  I find that more complicated, but the precision may be
worth the complication.

>> I would expect it to be used by some scrapers looking for stock photos.

> I'm not sure what you mean. Wouldn't fingerprinting the photos be more
> effective?

I was thinking of scrapers acting on behalf of a consumer --
collecting a bunch of photos that you would be allowed to use.

>> I would expect it to be used with custom CSS for some users, who are
>> really looking for a model or photographer rather than an existing
>> photograph.

> I don't understand this case. Can you elaborate? Maybe an example of this
> use in the wild would help.

Some of the original <cite> examples from the wild were really credits
-- they listed the photographer and the model.  Plenty of model and
photographer websites are largely devoted to finding each other; I
assume that this is because photographers are looking to find (and
then contact) models with a particular look, while models are looking
to be photographed by photographers skilled in a certain style.
Again, this seems like a fairly specialized need, but I've seen in on
several sites, and it again gets met by an attribution or credits
element.

[On why <cite> should really be read as <title_of_work>, but still
called <cite> for historical reasons]

> > > Why would it be wrong to have an element to style titles [for titles
>> > of works]?

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

> It provides a way to have appropriate default styling (italics, in the
> visual medium) for a typographic feature that is widely used, while
> allowing it to be easily restyled independent of other uses of italics.
> This is the same benefit <em>, <strong>, <mark>, etc, have.

I think "title of work" is itself a fairly rare case.  Normally, it is
enough to just put it in quotes or italics.  The times when you care
that it is a title aren't really more common than the times that you
care about attribution.

-jJ

From wo.kuehn at enbw.com  Mon May 17 02:27:01 2010
From: wo.kuehn at enbw.com (=?utf-8?B?S8O8aG4gV29sZmdhbmc=?=)
Date: Mon, 17 May 2010 11:27:01 +0200
Subject: [whatwg] Java language bindings for HTML5
Message-ID: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>

Hi,

I was wondering if there are any precompiled Java language bindings for HTML5?
Earlier specs had them included, for example http://www.w3.org/TR/DOM-Level-3-Core/java-binding.htmlbinding.html

Are there any tools to generate Java interfaces from WebIDL?

As it is, i can't figure package names, for example for the WebSocket API.
According the WebIDL specs, it should be org.w3c.WebSocket, right?

As for the html5 elements, will there be a new package org.w3c.dom.html5?

Many greetings, Wolfgang Kuhn

-------------------------
IT-Strategie & Prozesse
Office: +49 (0) 721 63 15480
Mobile: +49 (0) 160 97621841
Durlacher Allee 93
76131 Karlsruhe

EnBW Trading GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim ? HRB 108013
Gesch?ftsf?hrer: Ralf Kl?pfer, Dr. Dirk Mausbeck




From bringert at google.com  Mon May 17 06:05:22 2010
From: bringert at google.com (Bjorn Bringert)
Date: Mon, 17 May 2010 14:05:22 +0100
Subject: [whatwg] Speech input element
Message-ID: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>

Back in December there was a discussion about web APIs for speech
recognition and synthesis that saw a decent amount of interest
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
Based on that discussion, we would like to propose a simple API for
speech recognition, using a new <input type="speech"> element. An
informal spec of the new API, along with some sample apps and use
cases can be found at:
http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en.

It would be very helpful if you could take a look and share your
comments. Our next steps will be to implement the current design, get
some feedback from web developers, continue to tweak, and seek
standardization as soon it looks mature enough and/or other vendors
become interested in implementing it.

-- 
Bjorn Bringert & Satish Sampath

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

From Olli.Pettay at helsinki.fi  Mon May 17 07:00:27 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Mon, 17 May 2010 17:00:27 +0300
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
Message-ID: <4BF14BFB.4090904@helsinki.fi>

On 5/17/10 4:05 PM, Bjorn Bringert wrote:
> Back in December there was a discussion about web APIs for speech
> recognition and synthesis that saw a decent amount of interest
> (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
> Based on that discussion, we would like to propose a simple API for
> speech recognition, using a new<input type="speech">  element. An
> informal spec of the new API, along with some sample apps and use
> cases can be found at:
> http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en.
>
> It would be very helpful if you could take a look and share your
> comments. Our next steps will be to implement the current design, get
> some feedback from web developers, continue to tweak, and seek
> standardization as soon it looks mature enough and/or other vendors
> become interested in implementing it.
>

After a quick read I, in general, like the proposal.

Few comments though.

- What should happen if for example
   What happens to the events which are fired during that time?
   Or should recognition stop?

- What exactly are grammars builtin:dictation and builtin:search?
   Especially the latter one is not at all clear to me

- When does recognitionState change? Before which events?

- It is not quite clear how SGRS works with <input type="speech">

- I believe there is no need for
   DOMImplementation.hasFeature("SpeechInput", "1.0")

And I think we really need to define something for TTS.
Not every web developers have servers for text -> <audio>.


-Olli

From bringert at google.com  Mon May 17 08:55:53 2010
From: bringert at google.com (Bjorn Bringert)
Date: Mon, 17 May 2010 16:55:53 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <4BF14BFB.4090904@helsinki.fi>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
Message-ID: <AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>

On Mon, May 17, 2010 at 3:00 PM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:
> On 5/17/10 4:05 PM, Bjorn Bringert wrote:
>>
>> Back in December there was a discussion about web APIs for speech
>> recognition and synthesis that saw a decent amount of interest
>>
>> (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
>> Based on that discussion, we would like to propose a simple API for
>> speech recognition, using a new<input type="speech"> ?element. An
>> informal spec of the new API, along with some sample apps and use
>> cases can be found at:
>>
>> http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en.
>>
>> It would be very helpful if you could take a look and share your
>> comments. Our next steps will be to implement the current design, get
>> some feedback from web developers, continue to tweak, and seek
>> standardization as soon it looks mature enough and/or other vendors
>> become interested in implementing it.
>>
>
> After a quick read I, in general, like the proposal.

It's pretty underspecified still, as you can see. Thanks for pointing
out some missing pieces.


> Few comments though.
>
> - What should happen if for example
> ?What happens to the events which are fired during that time?
> ?Or should recognition stop?

(Looks like half of the first question is missing, so I'm guessing
here) If you are asking about when the web app loses focus (e.g. the
user switches to a different tab or away from the browser), I think
the recognition should be cancelled. I've added this to the spec.


> - What exactly are grammars builtin:dictation and builtin:search?
> ?Especially the latter one is not at all clear to me

They are intended to be implementation-dependent large language
models, for dictation (e.g. e-mail writing) and search queries
respectively. I've tried to clarify them a bit in the spec now. There
should perhaps be more of these (e.g. builtin:address), maybe with
some optional, mapping to builtin:dictation if not available.


> - When does recognitionState change? Before which events?

Thanks, that was very underspecified. I've added a diagram to clarify it.


> - It is not quite clear how SGRS works with <input type="speech">

The grammar specifies the set of utterances that the speech recognizer
should match against. The grammar may be annotated with SISR, which
will be used to populate the 'interpretation' field in ListenResult.

Since grammars may be protected by cookies etc that are only available
in the browsing session, I think the user agent will have to fetch the
grammar and the pass it to the speech recognizer, rather than the
recognizer accessing it directly.

I'm not sure if any of that answers your question though.


> - I believe there is no need for
> ?DOMImplementation.hasFeature("SpeechInput", "1.0")

The intention was that apps could use this to conditionally enable
features that require speech input support. Is there some other
mechanism that should be used instead?


> And I think we really need to define something for TTS.
> Not every web developers have servers for text -> <audio>.

Yes, I agree. We intend to work on that next, but didn't include it in
this proposal since they are pretty separate features from the browser
point of view.


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

From Olli.Pettay at helsinki.fi  Mon May 17 13:23:12 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Mon, 17 May 2010 23:23:12 +0300
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>	
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
Message-ID: <4BF1A5B0.3020307@helsinki.fi>

On 5/17/10 6:55 PM, Bjorn Bringert wrote:

> (Looks like half of the first question is missing, so I'm guessing
> here) If you are asking about when the web app loses focus (e.g. the
> user switches to a different tab or away from the browser), I think
> the recognition should be cancelled. I've added this to the spec.
>

Oh, where did the rest of the question go.

I was going to ask about alert()s.
What happens if alert() pops up while recognition is on?
Which events should fire and when?


> The grammar specifies the set of utterances that the speech recognizer
> should match against. The grammar may be annotated with SISR, which
> will be used to populate the 'interpretation' field in ListenResult.
I know what grammars are :)
What I meant that it is not very well specified that the result is 
actually put to .value etc.


And still, I'm still not quite sure what builtin:search actually
is. What kind of grammar would that be? How is that different from
builtin:dictation?



-Olli

From odin.omdal at gmail.com  Mon May 17 14:31:41 2010
From: odin.omdal at gmail.com (=?ISO-8859-1?Q?Odin_Omdal_H=F8rthe?=)
Date: Mon, 17 May 2010 23:31:41 +0200
Subject: [whatwg] Timestamp from video source in order to sync (e.g. expose
	OGG timestamp to javascript)
In-Reply-To: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com>
References: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com>
Message-ID: <AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>

Hello!

I filed bugs at mozilla and in chromium because I want to sync real
time data stream to live video. Some of them told me to send it here
as well. :-)

It's only possible to get relative playtime with html5 in javascript. I
want absolute timestamp that's embeded in OGG.

The spec only deals with relative times, and not getting out
information from the

Here's the deal:
I stream conferences using Ogg Theora+Vorbis using Icecast2. I have built a
site that shows the video and then automatically shows the slides (as PNG
files) as well. I use orbited (COMET) to have the server PUSH my ?next?
presses on my keyboard.

The problem is that icecast does heavy buffering, and also the client, so
that while I switch the slides, the browser will go from slide 3 to 4 WAY
too early (from 10 second to 1 minute).

If I could get the timestamp OR time-since-started-sending/recording from
the ogg file in javascript, I'd be able to sync everything.

There are multiple way to sync this, may even an stream with the slide-data
INSIDE the ogg file, however, AFAIK there's also no way of getting out such
arbitrary streams.

(PS: I had some problems, so sorry if you get this email many times! :-S)

--
Beste helsing,
Odin H?rthe Omdal <odin.omdal at gmail.com>
http://velmont.no

From jsalsman at gmail.com  Mon May 17 14:55:00 2010
From: jsalsman at gmail.com (James Salsman)
Date: Mon, 17 May 2010 14:55:00 -0700
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
Message-ID: <AANLkTin6D8GAr7Shsl1ikyUgiT6X_FszwRiTOF4WBmny@mail.gmail.com>

On Mon, May 17, 2010 at 8:55 AM, Bjorn Bringert <bringert at google.com> wrote:
>
>> - What exactly are grammars builtin:dictation and builtin:search?
>
> They are intended to be implementation-dependent large language
> models, for dictation (e.g. e-mail writing) and search queries
> respectively. I've tried to clarify them a bit in the spec now. There
> should perhaps be more of these (e.g. builtin:address), maybe with
> some optional, mapping to builtin:dictation if not available.

Bjorn, are you interested in including speech recognition support for
pronunciation assessment such as is done by http://englishcentral.com/
, http://www.scilearn.com/products/reading-assistant/ ,
http://www.eyespeakenglish.com/ , and http://wizworldonline.com/ ,
http://www.8dworld.com/en/home.html ?

Those would require different sorts of language models and grammars
such as those described in
http://www.springerlink.com/content/l0385t6v425j65h7/

Please let me know your thoughts.

Best regards,
James Salsman - http://talknicer.com/

From david at davidflanagan.com  Mon May 17 15:07:29 2010
From: david at davidflanagan.com (David Flanagan)
Date: Mon, 17 May 2010 15:07:29 -0700
Subject: [whatwg] Window events that bubble?
Message-ID: <4BF1BE21.8000601@davidflanagan.com>

Section 6.5.9 "History Traversal" defines popstate and hashchange events 
  that are fired on the Window object. It specifies that these events 
*must* bubble.  Where should they bubble to?  What does it mean to 
bubble up from a Window?  These events aren't going across frames, are they?

Is the specification that they must bubble a formality because existing 
implementations set the bubbles property of the Event object to true? 
Or does it actually have some impact on event propagation?

Thanks,

	David

From jonas at sicking.cc  Mon May 17 15:12:02 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 17 May 2010 15:12:02 -0700
Subject: [whatwg] Window events that bubble?
In-Reply-To: <4BF1BE21.8000601@davidflanagan.com>
References: <4BF1BE21.8000601@davidflanagan.com>
Message-ID: <AANLkTik7OtQec-EMya1bcmWPyXjzQCQJFfqZV3vd32BC@mail.gmail.com>

On Mon, May 17, 2010 at 3:07 PM, David Flanagan <david at davidflanagan.com> wrote:
> Section 6.5.9 "History Traversal" defines popstate and hashchange events
> ?that are fired on the Window object. It specifies that these events *must*
> bubble. ?Where should they bubble to? ?What does it mean to bubble up from a
> Window? ?These events aren't going across frames, are they?
>
> Is the specification that they must bubble a formality because existing
> implementations set the bubbles property of the Event object to true? Or
> does it actually have some impact on event propagation?

My understanding is that the only noticable effect of defining that
these effects bubble is that their bubbles property is set to true.
Same thing happens to bubbling events fired at an XMLHttpRequest
object.

Of course, in a theoretical future where we'd add an object "above"
the Window object, these events would bubble to that object. But
that's not the case today as no such object exists.

/ Jonas

From singer at apple.com  Mon May 17 15:44:12 2010
From: singer at apple.com (David Singer)
Date: Mon, 17 May 2010 15:44:12 -0700
Subject: [whatwg] Timestamp from video source in order to sync (e.g.
	expose	OGG timestamp to javascript)
In-Reply-To: <AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>
References: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com>
	<AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>
Message-ID: <BDD38428-C03F-4289-A2A3-95B9E9CFB3F5@apple.com>


On May 17, 2010, at 14:31 , Odin Omdal H?rthe wrote:

> Hello!
> 
> I filed bugs at mozilla and in chromium because I want to sync real
> time data stream to live video. Some of them told me to send it here
> as well. :-)
> 
> It's only possible to get relative playtime with html5 in javascript. I
> want absolute timestamp that's embeded in OGG.
> 
> The spec only deals with relative times, and not getting out
> information from the
> 
> Here's the deal:
> I stream conferences using Ogg Theora+Vorbis using Icecast2. I have built a
> site that shows the video and then automatically shows the slides (as PNG
> files) as well. I use orbited (COMET) to have the server PUSH my ?next?
> presses on my keyboard.
> 
> The problem is that icecast does heavy buffering, and also the client, so
> that while I switch the slides, the browser will go from slide 3 to 4 WAY
> too early (from 10 second to 1 minute).

Buffering should not make any difference to how far into a stream a time means.  If the transition from slide 3 to slide 4 happens at 10 minutes in, then as the presentation time ticks from 9:59 to 10:00 you should flip the slide.  It doesn't matter how much data is in any buffers, does it?

> 
> If I could get the timestamp OR time-since-started-sending/recording from
> the ogg file in javascript, I'd be able to sync everything.
> 
> There are multiple way to sync this, may even an stream with the slide-data
> INSIDE the ogg file, however, AFAIK there's also no way of getting out such
> arbitrary streams.
> 
> (PS: I had some problems, so sorry if you get this email many times! :-S)
> 
> --
> Beste helsing,
> Odin H?rthe Omdal <odin.omdal at gmail.com>
> http://velmont.no

David Singer
Multimedia and Software Standards, Apple Inc.


From neelen at amvonet.com  Mon May 17 16:00:21 2010
From: neelen at amvonet.com (Nikita Eelen)
Date: Mon, 17 May 2010 19:00:21 -0400
Subject: [whatwg] Timestamp from video source in order to sync (e.g.
	expose	OGG timestamp to javascript)
In-Reply-To: <BDD38428-C03F-4289-A2A3-95B9E9CFB3F5@apple.com>
References: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com>
	<AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>
	<BDD38428-C03F-4289-A2A3-95B9E9CFB3F5@apple.com>
Message-ID: <D03AA749-2689-4AA7-AAFD-7021D0BBEC6E@amvonet.com>

I think he means something similar to what QuickTime broadcaster and quicktime streaming server does with a delay on a live stream or wowza media server with flash media encoder when using h.264, unless I am misunderstanding something. Is that correct Odin? Not sure how ice cast deals with it but I bet it's a similar issue,

Nikita

Sent from my iPad

On May 17, 2010, at 6:44 PM, David Singer <singer at apple.com> wrote:

> 
> On May 17, 2010, at 14:31 , Odin Omdal H?rthe wrote:
> 
>> Hello!
>> 
>> I filed bugs at mozilla and in chromium because I want to sync real
>> time data stream to live video. Some of them told me to send it here
>> as well. :-)
>> 
>> It's only possible to get relative playtime with html5 in javascript. I
>> want absolute timestamp that's embeded in OGG.
>> 
>> The spec only deals with relative times, and not getting out
>> information from the
>> 
>> Here's the deal:
>> I stream conferences using Ogg Theora+Vorbis using Icecast2. I have built a
>> site that shows the video and then automatically shows the slides (as PNG
>> files) as well. I use orbited (COMET) to have the server PUSH my ?next?
>> presses on my keyboard.
>> 
>> The problem is that icecast does heavy buffering, and also the client, so
>> that while I switch the slides, the browser will go from slide 3 to 4 WAY
>> too early (from 10 second to 1 minute).
> 
> Buffering should not make any difference to how far into a stream a time means.  If the transition from slide 3 to slide 4 happens at 10 minutes in, then as the presentation time ticks from 9:59 to 10:00 you should flip the slide.  It doesn't matter how much data is in any buffers, does it?
> 
>> 
>> If I could get the timestamp OR time-since-started-sending/recording from
>> the ogg file in javascript, I'd be able to sync everything.
>> 
>> There are multiple way to sync this, may even an stream with the slide-data
>> INSIDE the ogg file, however, AFAIK there's also no way of getting out such
>> arbitrary streams.
>> 
>> (PS: I had some problems, so sorry if you get this email many times! :-S)
>> 
>> --
>> Beste helsing,
>> Odin H?rthe Omdal <odin.omdal at gmail.com>
>> http://velmont.no
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

From silviapfeiffer1 at gmail.com  Mon May 17 18:56:55 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 18 May 2010 11:56:55 +1000
Subject: [whatwg] Timestamp from video source in order to sync (e.g.
	expose OGG timestamp to javascript)
In-Reply-To: <AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>
References: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com> 
	<AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>
Message-ID: <AANLkTim2Efxw1tGh9kkiVLllo6pyCrMkVKThwVOR1cOT@mail.gmail.com>

On Tue, May 18, 2010 at 7:31 AM, Odin Omdal H?rthe <odin.omdal at gmail.com> wrote:
> Hello!
>
> I filed bugs at mozilla and in chromium because I want to sync real
> time data stream to live video. Some of them told me to send it here
> as well. :-)
>
> It's only possible to get relative playtime with html5 in javascript. I
> want absolute timestamp that's embeded in OGG.
>
> The spec only deals with relative times, and not getting out
> information from the
>
> Here's the deal:
> I stream conferences using Ogg Theora+Vorbis using Icecast2. I have built a
> site that shows the video and then automatically shows the slides (as PNG
> files) as well. I use orbited (COMET) to have the server PUSH my ?next?
> presses on my keyboard.
>
> The problem is that icecast does heavy buffering, and also the client, so
> that while I switch the slides, the browser will go from slide 3 to 4 WAY
> too early (from 10 second to 1 minute).
>
> If I could get the timestamp OR time-since-started-sending/recording from
> the ogg file in javascript, I'd be able to sync everything.
>
> There are multiple way to sync this, may even an stream with the slide-data
> INSIDE the ogg file, however, AFAIK there's also no way of getting out such
> arbitrary streams.

There is a Multitrack API proposal at
http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI to make the
tracks of a media resource available to the browser. But it hasn't
progressed into the spec yet.

Cheers,
Silvia.

From shiki at google.com  Mon May 17 19:38:21 2010
From: shiki at google.com (Shiki Okasaka)
Date: Tue, 18 May 2010 11:38:21 +0900
Subject: [whatwg] Java language bindings for HTML5
In-Reply-To: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>
References: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>
Message-ID: <AANLkTimXkjI5eDqDTD4Z82ZwL_jD9WzpleoyMsRbxwZS@mail.gmail.com>

Hi,

On Mon, May 17, 2010 at 6:27 PM, K?hn Wolfgang <wo.kuehn at enbw.com> wrote:
> Hi,
>
> I was wondering if there are any precompiled Java language bindings for HTML5?

The Java files generated from a set of Web IDL files with our esidl
Web IDL compiler are available at,

  http://es-operating-system.googlecode.com/files/java-binding.1714.zip

This zip file contains ###_Constructor interfaces, but those are only
our experimental ones.

The W3C specifications used for this are summarised at the end of this page,

  http://code.google.com/p/es-operating-system/wiki/CplusplusDOM

Note this page describes about C++ bindings, but esidl can generate
Java bindings, too.

> Earlier specs had them included, for example http://www.w3.org/TR/DOM-Level-3-Core/java-binding.htmlbinding.html
>
> Are there any tools to generate Java interfaces from WebIDL?

To use esidl, please install bison, yacc, and ant, then follow the steps below:

$ mkdir esidl
$ svn checkout http://es-operating-system.googlecode.com/svn/trunk/esidl src
$ mkdir obj
$ cd obj
$ ../src/configure
$ make
$ cd java
$ ant

This leaves .java and .class files under esidl/obj/java/org/w3c/.

> As it is, i can't figure package names, for example for the WebSocket API.
> According the WebIDL specs, it should be org.w3c.WebSocket, right?
>
> As for the html5 elements, will there be a new package org.w3c.dom.html5?

This is our concern, too. Historically each W3C specification
introduced its own module name. However, the recent specifications
tend to omit the module specification in the IDL definition.

    cf. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html

In the IDL files we used above, we chose module names that seem to be
practical, but those are not part of the standard. Hopefully more
people will revisit this issue sometime soon.

FYI, public-script-coord at w3.org would be a good place to discuss about
Web IDL specific issues.

Best,

 - Shiki


>
> Many greetings, Wolfgang Kuhn
>
> -------------------------
> IT-Strategie & Prozesse
> Office: +49 (0) 721 63 15480
> Mobile: +49 (0) 160 97621841
> Durlacher Allee 93
> 76131 Karlsruhe
>
> EnBW Trading GmbH
> Sitz der Gesellschaft: Karlsruhe
> Handelsregister: Amtsgericht Mannheim ? HRB 108013
> Gesch?ftsf?hrer: Ralf Kl?pfer, Dr. Dirk Mausbeck
>
>
>
>

From annevk at opera.com  Mon May 17 23:27:49 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 18 May 2010 08:27:49 +0200
Subject: [whatwg] Java language bindings for HTML5
In-Reply-To: <AANLkTimXkjI5eDqDTD4Z82ZwL_jD9WzpleoyMsRbxwZS@mail.gmail.com>
References: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>
	<AANLkTimXkjI5eDqDTD4Z82ZwL_jD9WzpleoyMsRbxwZS@mail.gmail.com>
Message-ID: <op.vcv1kne764w2qv@annevk-t60>

On Tue, 18 May 2010 04:38:21 +0200, Shiki Okasaka <shiki at google.com> wrote:
> On Mon, May 17, 2010 at 6:27 PM, K?hn Wolfgang <wo.kuehn at enbw.com> wrote:
>> Hi,
>> As for the html5 elements, will there be a new package  
>> org.w3c.dom.html5?
>
> This is our concern, too. Historically each W3C specification
> introduced its own module name. However, the recent specifications
> tend to omit the module specification in the IDL definition.
>
>     cf.  
> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html
>
> In the IDL files we used above, we chose module names that seem to be
> practical, but those are not part of the standard. Hopefully more
> people will revisit this issue sometime soon.

Can't they all just use org.w3c.dom? We cannot make the interface names  
overlap anyway.


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

From annevk at opera.com  Tue May 18 00:02:23 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 18 May 2010 09:02:23 +0200
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
Message-ID: <op.vcv259qm64w2qv@annevk-t60>

On Mon, 17 May 2010 15:05:22 +0200, Bjorn Bringert <bringert at google.com>  
wrote:
> Back in December there was a discussion about web APIs for speech
> recognition and synthesis that saw a decent amount of interest
> (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
> Based on that discussion, we would like to propose a simple API for
> speech recognition, using a new <input type="speech"> element. An
> informal spec of the new API, along with some sample apps and use
> cases can be found at:
> http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en.
>
> It would be very helpful if you could take a look and share your
> comments. Our next steps will be to implement the current design, get
> some feedback from web developers, continue to tweak, and seek
> standardization as soon it looks mature enough and/or other vendors
> become interested in implementing it.

I wonder how it relates to the <device> proposal already in the draft. In  
theory that supports microphone input too.


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

From odin.omdal at gmail.com  Tue May 18 01:23:34 2010
From: odin.omdal at gmail.com (=?ISO-8859-1?Q?Odin_Omdal_H=F8rthe?=)
Date: Tue, 18 May 2010 10:23:34 +0200
Subject: [whatwg] Timestamp from video source in order to sync (e.g.
	expose OGG timestamp to javascript)
In-Reply-To: <D03AA749-2689-4AA7-AAFD-7021D0BBEC6E@amvonet.com>
References: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com>
	<AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>
	<BDD38428-C03F-4289-A2A3-95B9E9CFB3F5@apple.com>
	<D03AA749-2689-4AA7-AAFD-7021D0BBEC6E@amvonet.com>
Message-ID: <AANLkTilWVQPyqjqQP_zq_QDym7Rf4IkulSxLLGsH8IDP@mail.gmail.com>

On Tue, May 18, 2010 at 1:00 AM, Nikita Eelen <neelen at amvonet.com> wrote:
> I think he means something similar to what QuickTime broadcaster and quicktime streaming
> server does with a delay on a live stream or wowza media server with flash media encoder
> when using h.264, unless I am misunderstanding something. Is that correct Odin? Not sure
> how ice cast deals with it but I bet it's a similar issue,

Yes, I initially used Darwin Streaming Server, but found Icecast2 much
better for *my use*. So I use it in the same way. I'm having Icecast
buffer 1MB worth of data so that it can burst all that to the client
(the browser in this case) so that its own buffering can go faster. So
even there we're quite far behind.

And also, the browsers often stops up a few seconds, and buffers a bit
more, and then continue playing (although they have buffered more than
a few seconds ahead already!), so then they are drifting even further
away from real time.



But I have important news, my bug at Mozilla was closed because they
mean it's actually in the spec already. Because:

> The startTime  attribute must, on getting, return the earliest possible position, expressed in seconds.

And they mean that in a live stream, that would be when I started the
stream (like VLC does). So that the stream in-browser already shows
00:31:30 if we're 31 minutes and 30 seconds into the live stream.

So actually, then the spec is good enough for my uses for synchronising.

You may watch this mozilla bug here:
<https://bugzilla.mozilla.org/show_bug.cgi?id=498253>


However, I think that it's rather hard to find out what the spec
means. Because *earliest POSSIBLE*. What is meant by possible? With
live streaming it is not possible to go further back in the stream.
What do you think? What is meant by this? If it does not help me, then
adding a field for getting the _real_ time code data from the video
would be very usable.

It's talked about in this example:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-starttime>

> For example, if two clips have been concatenated into one video file, but the video format
> exposes the original times for the two clips, the video data might expose a timeline that
> goes, say, 00:15..00:29 and then 00:05..00:38. However, the user agent would not expose
> those times; it would instead expose the times as 00:15..00:29 and 00:29..01:02, as a
> single video.

That's well and good, but it would be nice to get the actual time code
data for live streaming and these syncing uses if startTime is not the
earliest time that exists.


Justin Dolske's idea looks rather nice:
> This seems like a somewhat unfortunate thing for the spec, I bet everyone's
> going to get it wrong because it won't be common. :( I can't help but wonder if
> it would be better to have a startTimeOffset property, so that .currentTime et
> al are all still have a timeline starting from 0, and if you want the "real"
> time you'd use .currentTime + .startTimeOffset.
>
> I'd also suspect we'll want the default video controls to normalize everything
> to 0 (.currentTime - .startTime), since it would be really confusing otherwise.

from <https://bugzilla.mozilla.org/show_bug.cgi?id=498253#c3>

-- 
Beste helsing,
Odin H?rthe Omdal <odin.omdal at gmail.com>
http://velmont.no

From bringert at google.com  Tue May 18 01:27:45 2010
From: bringert at google.com (Bjorn Bringert)
Date: Tue, 18 May 2010 09:27:45 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <4BF1A5B0.3020307@helsinki.fi>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
	<4BF1A5B0.3020307@helsinki.fi>
Message-ID: <AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>

On Mon, May 17, 2010 at 9:23 PM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:
> On 5/17/10 6:55 PM, Bjorn Bringert wrote:
>
>> (Looks like half of the first question is missing, so I'm guessing
>> here) If you are asking about when the web app loses focus (e.g. the
>> user switches to a different tab or away from the browser), I think
>> the recognition should be cancelled. I've added this to the spec.
>>
>
> Oh, where did the rest of the question go.
>
> I was going to ask about alert()s.
> What happens if alert() pops up while recognition is on?
> Which events should fire and when?

Hmm, good question. I think that either the recognition should be
cancelled, like when the web app loses focus, or it should continue
just as if there was no alert. Are there any browser implementation
reasons to do one or the other?


>> The grammar specifies the set of utterances that the speech recognizer
>> should match against. The grammar may be annotated with SISR, which
>> will be used to populate the 'interpretation' field in ListenResult.
>
> I know what grammars are :)

Yeah, sorry about my silly reply there, I just wasn't sure exactly
what you were asking.


> What I meant that it is not very well specified that the result is actually
> put to .value etc.

Yes, good point. The alternatives would be to use either the
'utterance' or the 'interpretation' value from the most likely
recognition result. If the grammar does not contain semantics, those
are identical, so it doesn't matter in that case. If the developer has
added semantics to the grammar, the interpretation is probably more
interesting than the utterance. So my conclusion is that it would make
most sense to store the interpretation in @value. I've updated the
spec with better definitions of @value and @results.


> And still, I'm still not quite sure what builtin:search actually
> is. What kind of grammar would that be? How is that different from
> builtin:dictation?

To be useful, those should probably be large statistical language
models (e.g. n-gram models) trained on different corpora. So
"builtin:dictation" might be trained on a corpus containing e-mails,
SMS messages and news text, and "builtin:search" might be trained on
query strings from a search engine. I've updated the spec to make
"builtin:search" optional, mapping to "builtin:dictation" if not
implemented. The exact language matched by these models would be
implementation dependent, and implementations may choose to be clever
about them. For example by:

- Dynamic tweaking for different web apps based on the user's previous
inputs and the text contained in the web app.

- Adding the names of all contacts from the user's address book to the
dictation model.

- Weighting place names based on geographic proximity (in an
implementation that has access to the user's location).


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

From bringert at google.com  Tue May 18 01:36:01 2010
From: bringert at google.com (Bjorn Bringert)
Date: Tue, 18 May 2010 09:36:01 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTin6D8GAr7Shsl1ikyUgiT6X_FszwRiTOF4WBmny@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
	<AANLkTin6D8GAr7Shsl1ikyUgiT6X_FszwRiTOF4WBmny@mail.gmail.com>
Message-ID: <AANLkTimeMylOtmaSCILDzqVruTwgPH_9WPyQJBdhh2wk@mail.gmail.com>

On Mon, May 17, 2010 at 10:55 PM, James Salsman <jsalsman at gmail.com> wrote:
> On Mon, May 17, 2010 at 8:55 AM, Bjorn Bringert <bringert at google.com> wrote:
>>
>>> - What exactly are grammars builtin:dictation and builtin:search?
>>
>> They are intended to be implementation-dependent large language
>> models, for dictation (e.g. e-mail writing) and search queries
>> respectively. I've tried to clarify them a bit in the spec now. There
>> should perhaps be more of these (e.g. builtin:address), maybe with
>> some optional, mapping to builtin:dictation if not available.
>
> Bjorn, are you interested in including speech recognition support for
> pronunciation assessment such as is done by http://englishcentral.com/
> , http://www.scilearn.com/products/reading-assistant/ ,
> http://www.eyespeakenglish.com/ , and http://wizworldonline.com/ ,
> http://www.8dworld.com/en/home.html ?
>
> Those would require different sorts of language models and grammars
> such as those described in
> http://www.springerlink.com/content/l0385t6v425j65h7/
>
> Please let me know your thoughts.

I don't have SpringerLink access, so I couldn't read that article. As
far as I could tell from the abstract, they use phoneme-level speech
recognition and then calculate the edit distance to the "correct"
phoneme sequences. Do you have a concrete proposal for how this could
be supported? Would support for PLS
(http://www.w3.org/TR/pronunciation-lexicon/) links in SRGS be enough
(the SRGS spec already includes that)?

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

From bringert at google.com  Tue May 18 01:52:53 2010
From: bringert at google.com (Bjorn Bringert)
Date: Tue, 18 May 2010 09:52:53 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <op.vcv259qm64w2qv@annevk-t60>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<op.vcv259qm64w2qv@annevk-t60>
Message-ID: <AANLkTimXfRGorcSaO9mhta1YzA2tU7jIAlkFR8jvlqI1@mail.gmail.com>

On Tue, May 18, 2010 at 8:02 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Mon, 17 May 2010 15:05:22 +0200, Bjorn Bringert <bringert at google.com>
> wrote:
>>
>> Back in December there was a discussion about web APIs for speech
>> recognition and synthesis that saw a decent amount of interest
>>
>> (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
>> Based on that discussion, we would like to propose a simple API for
>> speech recognition, using a new <input type="speech"> element. An
>> informal spec of the new API, along with some sample apps and use
>> cases can be found at:
>>
>> http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en.
>>
>> It would be very helpful if you could take a look and share your
>> comments. Our next steps will be to implement the current design, get
>> some feedback from web developers, continue to tweak, and seek
>> standardization as soon it looks mature enough and/or other vendors
>> become interested in implementing it.
>
> I wonder how it relates to the <device> proposal already in the draft. In
> theory that supports microphone input too.

It would be possible to implement speech recognition on top of a
microphone input API. The most obvious approach would be to use
<device> to get an audio stream, and send that audio stream to a
server (e.g. using WebSockets). The server runs a speech recognizer
and returns the results.

Advantages of the speech input element:

- Web app developers do not need to build and maintain a speech
recognition service.

- Implementations can choose to use client-side speech recognition.
This could give reduced network traffic and latency (but probably also
reduced recognition accuracy and language support). Implementations
could also use server-side recognition by default, switching to local
recognition in offline or low bandwidth situations.

- Using a general audio capture API would require APIs for things like
audio encoding and audio streaming. Judging from the past results of
specifying media features, this may be non-trivial. The speech input
element turns all audio processing concerns into implementation
details.

- Implementations can have special UI treatment for speech input,
which may be different from that for general audio capture.


Advantages of using a microphone API:

- Web app developers get complete control over the quality and
features of the speech recognizer. This is a moot point for most
developers though, since they do not have the resources to run their
own speech recognition service.

- Fewer features to implement in browsers (assuming that a microphone
API would be added anyway).

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

From Olli.Pettay at helsinki.fi  Tue May 18 02:19:13 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Tue, 18 May 2010 12:19:13 +0300
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>	
	<4BF14BFB.4090904@helsinki.fi>	
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>	
	<4BF1A5B0.3020307@helsinki.fi>
	<AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>
Message-ID: <4BF25B91.9070308@helsinki.fi>

On 5/18/10 11:27 AM, Bjorn Bringert wrote:
> On Mon, May 17, 2010 at 9:23 PM, Olli Pettay<Olli.Pettay at helsinki.fi>  wrote:
>> On 5/17/10 6:55 PM, Bjorn Bringert wrote:
>>
>>> (Looks like half of the first question is missing, so I'm guessing
>>> here) If you are asking about when the web app loses focus (e.g. the
>>> user switches to a different tab or away from the browser), I think
>>> the recognition should be cancelled. I've added this to the spec.
>>>
>>
>> Oh, where did the rest of the question go.
>>
>> I was going to ask about alert()s.
>> What happens if alert() pops up while recognition is on?
>> Which events should fire and when?
>
> Hmm, good question. I think that either the recognition should be
> cancelled, like when the web app loses focus, or it should continue
> just as if there was no alert. Are there any browser implementation
> reasons to do one or the other?


Well, the problem with alert is that the assumption (which may or may 
not always hold) is that when alert() is opened, web page shouldn't run
any scripts. So should <input type="speech"> fire some events when the
recognition is canceled (if alert cancels recognition), and if yes,
when? Or if recognition is not canceled, and something is recognized
(so "input" event should be dispatched), when should the event actually 
fire? The problem is pretty much the same with synchronous XMLHttpRequest.


-Olli

From satish at google.com  Tue May 18 02:27:29 2010
From: satish at google.com (Satish Sampath)
Date: Tue, 18 May 2010 10:27:29 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <4BF25B91.9070308@helsinki.fi>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
	<4BF1A5B0.3020307@helsinki.fi>
	<AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>
	<4BF25B91.9070308@helsinki.fi>
Message-ID: <AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>

>
> Well, the problem with alert is that the assumption (which may or may not
> always hold) is that when alert() is opened, web page shouldn't run
> any scripts. So should <input type="speech"> fire some events when the
> recognition is canceled (if alert cancels recognition), and if yes,
> when? Or if recognition is not canceled, and something is recognized
> (so "input" event should be dispatched), when should the event actually
> fire? The problem is pretty much the same with synchronous XMLHttpRequest.
>

In my opinion, once the speech input element has started recording any event
which takes the user's focus away from actually speaking should ideally stop
the speech recognition. This would include switching to a new window, a new
tab or modal/alert dialogs, submitting a form or navigating to a new page in
the same tab/window.

--
Cheers
Satish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100518/d81caf0b/attachment.htm>

From robert at ocallahan.org  Tue May 18 02:28:10 2010
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 18 May 2010 21:28:10 +1200
Subject: [whatwg] Timestamp from video source in order to sync (e.g.
	expose OGG timestamp to javascript)
In-Reply-To: <AANLkTilWVQPyqjqQP_zq_QDym7Rf4IkulSxLLGsH8IDP@mail.gmail.com>
References: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com>
	<AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com>
	<BDD38428-C03F-4289-A2A3-95B9E9CFB3F5@apple.com>
	<D03AA749-2689-4AA7-AAFD-7021D0BBEC6E@amvonet.com>
	<AANLkTilWVQPyqjqQP_zq_QDym7Rf4IkulSxLLGsH8IDP@mail.gmail.com>
Message-ID: <AANLkTikPoce2Hh1dAqZbVNiC2qldtUqNE58sIfXs7yOZ@mail.gmail.com>

On Tue, May 18, 2010 at 8:23 PM, Odin Omdal H?rthe <odin.omdal at gmail.com>wrote:

> Justin Dolske's idea looks rather nice:
> > This seems like a somewhat unfortunate thing for the spec, I bet
> everyone's
> > going to get it wrong because it won't be common. :( I can't help but
> wonder if
> > it would be better to have a startTimeOffset property, so that
> .currentTime et
> > al are all still have a timeline starting from 0, and if you want the
> "real"
> > time you'd use .currentTime + .startTimeOffset.
> >
> > I'd also suspect we'll want the default video controls to normalize
> everything
> > to 0 (.currentTime - .startTime), since it would be really confusing
> otherwise.
>

That's exactly what I've advocated before. I lost the argument, but I forget
why, probably because I didn't understand the reasons.

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

From bringert at google.com  Tue May 18 02:30:01 2010
From: bringert at google.com (Bjorn Bringert)
Date: Tue, 18 May 2010 10:30:01 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
	<4BF1A5B0.3020307@helsinki.fi>
	<AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>
	<4BF25B91.9070308@helsinki.fi>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
Message-ID: <AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>

On Tue, May 18, 2010 at 10:27 AM, Satish Sampath <satish at google.com> wrote:
>> Well, the problem with alert is that the assumption (which may or may not
>> always hold) is that when alert() is opened, web page shouldn't run
>> any scripts. So should <input type="speech"> fire some events when the
>> recognition is canceled (if alert cancels recognition), and if yes,
>> when? Or if recognition is not canceled, and something is recognized
>> (so "input" event should be dispatched), when should the event actually
>> fire? The problem is pretty much the same with synchronous XMLHttpRequest.
>
> In my opinion, once the speech input element has started recording any event
> which takes the user's focus away from actually speaking should ideally stop
> the speech recognition. This would include switching to a new window, a new
> tab or modal/alert dialogs, submitting a form or navigating to a new page in
> the same tab/window.

Yes, I agree with that. The tricky issue, as Olli points out, is
whether and when the 'error' event should fire when recognition is
aborted because the user moves away or gets an alert. What does
XMLHttpRequest do?

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

From silviapfeiffer1 at gmail.com  Tue May 18 02:46:42 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 18 May 2010 19:46:42 +1000
Subject: [whatwg] Timestamp from video source in order to sync (e.g.
	expose OGG timestamp to javascript)
In-Reply-To: <AANLkTikPoce2Hh1dAqZbVNiC2qldtUqNE58sIfXs7yOZ@mail.gmail.com>
References: <AANLkTil5XbmIKkG3dobYH4o5DgfcP0PGgaifjyL6sDGv@mail.gmail.com> 
	<AANLkTimc8yt5bm8teHXZeHSyb9kEWdB0gtWOF2ejuhWT@mail.gmail.com> 
	<BDD38428-C03F-4289-A2A3-95B9E9CFB3F5@apple.com>
	<D03AA749-2689-4AA7-AAFD-7021D0BBEC6E@amvonet.com> 
	<AANLkTilWVQPyqjqQP_zq_QDym7Rf4IkulSxLLGsH8IDP@mail.gmail.com> 
	<AANLkTikPoce2Hh1dAqZbVNiC2qldtUqNE58sIfXs7yOZ@mail.gmail.com>
Message-ID: <AANLkTilAIBO5MVjaNPER_PlIOTrxkxMcK0srOzK8FhH7@mail.gmail.com>

On Tue, May 18, 2010 at 7:28 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Tue, May 18, 2010 at 8:23 PM, Odin Omdal H?rthe <odin.omdal at gmail.com>
> wrote:
>>
>> Justin Dolske's idea looks rather nice:
>> > This seems like a somewhat unfortunate thing for the spec, I bet
>> > everyone's
>> > going to get it wrong because it won't be common. :( I can't help but
>> > wonder if
>> > it would be better to have a startTimeOffset property, so that
>> > .currentTime et
>> > al are all still have a timeline starting from 0, and if you want the
>> > "real"
>> > time you'd use .currentTime + .startTimeOffset.
>> >
>> > I'd also suspect we'll want the default video controls to normalize
>> > everything
>> > to 0 (.currentTime - .startTime), since it would be really confusing
>> > otherwise.
>
>
> That's exactly what I've advocated before. I lost the argument, but I forget
> why, probably because I didn't understand the reasons.


To be honest, it doesn't make much sense to display the "wrong" time
in a player. If a video stream starts at 10:30am and goes for 30 min,
then a person joining the stream 10 min in should see a time of 10min
- or better even 10:40am - which is in sync with what others see that
joined at the start. It would be rather confusing if the same position
in a video would be linked by one person as "at offset 10min" while
another would say "at offset 0min". And since the W3C Media Fragments
WG is defining temporal addressing, such diverging pointers will even
end up in a URL and how should that be interpreted then?

Cheers,
Silvia.

From ashimura at w3.org  Tue May 18 03:54:18 2010
From: ashimura at w3.org (Kazuyuki Ashimura)
Date: Tue, 18 May 2010 19:54:18 +0900
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
Message-ID: <4BF271DA.80304@w3.org>

Hi Bjorn,

Thank you for your bringing this topic (again :) to the WHAT WG list.
I'd like to bring this to the W3C Voice Browser Working Group (and
maybe the Multimodal Interaction Working Group as well) and ask
the group participants for opinion.

As you might know, the group recently created a task force named
"Voice on the Web" and work hard to promote voice technology on
various possible Web applications.

Regards,

Kazuyuki


Bjorn Bringert wrote:
> Back in December there was a discussion about web APIs for speech
> recognition and synthesis that saw a decent amount of interest
> (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
> Based on that discussion, we would like to propose a simple API for
> speech recognition, using a new <input type="speech"> element. An
> informal spec of the new API, along with some sample apps and use
> cases can be found at:
> http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en.
> 
> It would be very helpful if you could take a look and share your
> comments. Our next steps will be to implement the current design, get
> some feedback from web developers, continue to tweak, and seek
> standardization as soon it looks mature enough and/or other vendors
> become interested in implementing it.
> 

-- 
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura at w3.org
voice: +81.466.49.1170 / fax: +81.466.49.1171

From svartman95 at gmail.com  Tue May 18 04:11:08 2010
From: svartman95 at gmail.com (bjartur)
Date: Tue, 18 May 2010 11:11:08 +0000
Subject: [whatwg] <INCLUDE> and links with @rel=embed
Message-ID: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>

--------

This is yet another proposal to replace <video>, <audio>, <model> etc with a single element: <include>.
Example says more than a hundred words:
<include>
	<a rel="alternate embed" src="./video" type="video/mpeg" media="visual" title="[insert title here]">A video recording of the conference</a>
	<a rel="alternate embed" src="./audio" type="audio/speex" media="aural" title="An informational title...">A sound recording of the conference</a>
</include>
Change @rel=embed to some better name if you want and correct the media query which may be wrong but you should get the general idea.
This seems backwards compatible and I'd argue that it's more semantic, even to unsupporting browsers, than wrapping it up in Flash (though authors can add an <object> after the <a>s if they want).
Also it's possible to group elements similiar to alternate stylesheets with the same title, or by nesting <includes>. We just have to standardize on either one.
<include>
	<a rel="alternate embed" src="./video+audio" type="video/x-matroska" ...>...</a>
	<include rel="alternate" title="Seperate tracks if you can't open matroskas"> <!-- Either mark the include as alternate or make all elements inside an <include> alternatives -->
		<a rel="embed" href="./video" ...>Video track</a>
		<a rel="embed" href="./audio" ...>Audio track</a>
	</include>
</include>

And some quotes from Tim Berners-Lee who thought of the issue of <audio>, <IMG> and <video> in '93.

timbl:
>I had imagined that figues would be reprented as
>
><a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
>
>where the relation ship values mean
>
>EMBED	 Embed this here when presenting it
>PRESENT	 Present this whenever the source document is presented
>Note that you can have various combinations of these, and if the browser doesn???t support either one, it doesn???t break.
I'm not quite sure how PRESENT is useful, though.

timbl:
>Let the IMG tag be INCLUDE and let it refer to an arbitrary document type. Or EMBED if INCLUDE sounds like a cpp include which people will expect to provide SGML source code to be parsed inline ??? not what was intended.
s/IMG/video and audio/

From ashimura at w3.org  Tue May 18 04:13:06 2010
From: ashimura at w3.org (Kazuyuki Ashimura)
Date: Tue, 18 May 2010 20:13:06 +0900
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTimeMylOtmaSCILDzqVruTwgPH_9WPyQJBdhh2wk@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>	<4BF14BFB.4090904@helsinki.fi>	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>	<AANLkTin6D8GAr7Shsl1ikyUgiT6X_FszwRiTOF4WBmny@mail.gmail.com>
	<AANLkTimeMylOtmaSCILDzqVruTwgPH_9WPyQJBdhh2wk@mail.gmail.com>
Message-ID: <4BF27642.4080602@w3.org>

Hi Bjorn and James,

Just FYI, W3C is organizing a workshop on Conversational Applications.
The main goal of the workshop is collecting use cases and requirements
for new models of human language to support mobile conversational
systems.  The workshop will be held on June 18-19 in Somerset, NJ, US.

The detailed call for participation is available at:
  http://www.w3.org/2010/02/convapps/cfp.html

I think there may be some discussion during the workshop about a
possible multimodal e-learning system as a use case.  Is either of you
by chance interested in the workshop?

Regards,

Kazuyuki


Bjorn Bringert wrote:
> On Mon, May 17, 2010 at 10:55 PM, James Salsman <jsalsman at gmail.com> wrote:
>> On Mon, May 17, 2010 at 8:55 AM, Bjorn Bringert <bringert at google.com> wrote:
>>>> - What exactly are grammars builtin:dictation and builtin:search?
>>> They are intended to be implementation-dependent large language
>>> models, for dictation (e.g. e-mail writing) and search queries
>>> respectively. I've tried to clarify them a bit in the spec now. There
>>> should perhaps be more of these (e.g. builtin:address), maybe with
>>> some optional, mapping to builtin:dictation if not available.
>> Bjorn, are you interested in including speech recognition support for
>> pronunciation assessment such as is done by http://englishcentral.com/
>> , http://www.scilearn.com/products/reading-assistant/ ,
>> http://www.eyespeakenglish.com/ , and http://wizworldonline.com/ ,
>> http://www.8dworld.com/en/home.html ?
>>
>> Those would require different sorts of language models and grammars
>> such as those described in
>> http://www.springerlink.com/content/l0385t6v425j65h7/
>>
>> Please let me know your thoughts.
> 
> I don't have SpringerLink access, so I couldn't read that article. As
> far as I could tell from the abstract, they use phoneme-level speech
> recognition and then calculate the edit distance to the "correct"
> phoneme sequences. Do you have a concrete proposal for how this could
> be supported? Would support for PLS
> (http://www.w3.org/TR/pronunciation-lexicon/) links in SRGS be enough
> (the SRGS spec already includes that)?
> 

-- 
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura at w3.org
voice: +81.466.49.1170 / fax: +81.466.49.1171


From jackalmage at gmail.com  Tue May 18 08:41:00 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 18 May 2010 08:41:00 -0700
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>
Message-ID: <AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com>

On Tue, May 18, 2010 at 4:11 AM, bjartur <svartman95 at gmail.com> wrote:
> --------
>
> This is yet another proposal to replace <video>, <audio>, <model> etc with a single element: <include>.

You indicate that you are aware of the previous proposals to provide a
single element for all media resources.  Are you aware of the
counter-arguments against them?  If so, what is your answer to them?
At the moment all you've done is provide a marginally different syntax
than what's come before, but syntax was never an issue with previous
unified-media elements.

~TJ

From ojan at chromium.org  Tue May 18 10:35:44 2010
From: ojan at chromium.org (Ojan Vafai)
Date: Tue, 18 May 2010 10:35:44 -0700
Subject: [whatwg] Should scripts and plugins in contenteditable content
	be enabled or disabled?
In-Reply-To: <g2t11e306601004230234vfd4b68aey32566940d2aa0b20@mail.gmail.com>
References: <v2o11e306601004221628o52abccf1kab707de85fbb9b28@mail.gmail.com> 
	<op.vblr1rmoidj3kv@simon-pieterss-macbook.local>
	<g2t11e306601004230234vfd4b68aey32566940d2aa0b20@mail.gmail.com>
Message-ID: <AANLkTinTBbfeB-sAGjlguVHoM0TH5iww_RBpAqBg9x07@mail.gmail.com>

On Fri, Apr 23, 2010 at 2:34 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Apr 23, 2010 at 6:52 PM, Simon Pieters <simonp at opera.com> wrote:
>
>> It seems Hixie has decided to go back to the WebKit behavior in the spec
>> for designMode.
>>
>> http://html5.org/tools/web-apps-tracker?from=2817&to=2818
>>
>
>  It's certainly the easiest to implement, but you can see feedback in
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928 that this makes life
> difficult for people writing editors.
>
> Thanks for the links.
>

The webkit behavior of allowing all scripts makes the most sense to me. It
should be possible to disable scripts, but that capability shouldn't be tied
to editability. The clean solution for the CKEditor developer is to use a
sandboxed iframe.

I don't see a security benefit for disabling script as you'd have all the
same issues with loading any user-content in a non-editable area. The only
catch is that you *do* need to disable script from pasted and drag-dropped
content (see http://trac.webkit.org/changeset/53442). Basically, any site
serving user-content will already need to mitigate XSS some other way, so
disabling script in editable areas is not necessary, but paste/drag-drop
can't reasonably rely on server-side solutions, so must be done by the UA.

Putting my developer hat on, trying to make Google Gadgets work in Google's
rich text editor inside Firefox designMode was awful due to
https://bugzilla.mozilla.org/show_bug.cgi?id=519928. A large percentage of
Google Gadgets load as iframes and require javascript onload. We had to play
tricks with turning off designMode, appending the iframe and turning
designMode back on. It was an awful solution that never worked very well.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100518/0bf4f109/attachment.htm>

From doug at schepers.cc  Tue May 18 10:44:42 2010
From: doug at schepers.cc (Doug Schepers)
Date: Tue, 18 May 2010 13:44:42 -0400
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
Message-ID: <4BF2D20A.1090202@schepers.cc>

Hi, Bjorn-

Bjorn Bringert wrote (on 5/17/10 9:05 AM):
> Back in December there was a discussion about web APIs for speech
> recognition and synthesis that saw a decent amount of interest
> (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24281).
> Based on that discussion, we would like to propose a simple API for
> speech recognition, using a new<input type="speech">  element. An
> informal spec of the new API, along with some sample apps and use
> cases can be found at:
> http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhx&hl=en.
>
> It would be very helpful if you could take a look and share your
> comments. Our next steps will be to implement the current design, get
> some feedback from web developers, continue to tweak, and seek
> standardization as soon it looks mature enough and/or other vendors
> become interested in implementing it.

This is important work, thanks for taking it on and bringing it to a 
wider discussion forum.  Here's a couple of other venues you might also 
consider discussing it, above and beyond discussion on the WHATWG list:

* W3C just launched a new Audio Incubator Group (Audio XG), as a forum 
to discuss various aspects of audio on the Web.  The Audio XG is not 
intended to produce Recommendation-track specifications like this 
(though they will likely prototype and write a draft spec for a 
read-write audio API), but it could serve a role in helping work out use 
cases and requirements, reviewing specs, and so forth.  I'm not totally 
sure that this is relevant to your interests, but I thought I would 
bring it up.

* The Voice Browser Working Group is very interested in bringing their 
work and experience into the graphical browser world, so you should work 
with them or get their input.  As I understand it, some of them plan to 
join the Audio XG, too (specifically to talk about speech synthesis in 
the larger context), so that might be one forum to have some 
conversations.  VoiceXML is rather different than X/HTML or the browser 
DOM, and the participants in the VBWG don't necessarily have the right 
experience in graphical browser approaches, so I think there's an 
opportunity for good conversation and cross-pollination here.

[1] http://www.w3.org/2005/Incubator/audio/
[2] http://www.w3.org/Voice/

Regards-
-Doug

From svartman95 at gmail.com  Tue May 18 11:20:10 2010
From: svartman95 at gmail.com (bjartur)
Date: Tue, 18 May 2010 18:20:10 +0000
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com>
	<AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com>
Message-ID: <4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>

--------

First of all I think we should use <a rel="embed" href="uri-ref"> instead of <source>. I'm not aware of previous proposals of that on this list. Feel free to provide links if it's already been proposed.

Second, all the responses I've seen so far have been along the lines of "it's the HTML5 way" (implying it's more of an XHTML 1 way, or [insert unfashionable tech here] way) or that video is so important that it deserves first-class treatment, and for the sake of completeness <audio> has to be included as well (though interactive content, text and 3D models don't deserve to be "first-class").

Isn't interactive content not important enaugh? What about text? What if one want's to link to interactive maps? svg at src? <a class="embed"..> with .embed {content: url(attr(href)) }? AFAIK CSS doesn't support it, and if it does <a rel="embed"..> could be used as well, even without explicit browser support.

Also someone wrote that one should use <object> for media-types that aren't supported in HTML yet. If you insist on keeping <video> and <audio>, think of this as a way for second-class media-types WHATWG hasn't approved/haven't been implemented to use some of the features of <video> and <audio>.

It's possible to specify the media type with attributes like @media for media queries and @type for the type of specific resources. That way media queries and MIME media types like audio, video, model and text can be reused, and all types IANA might add in the future.

IMO multimedia should be "first-class". And embedding more information than necessary in tag names is just /wrong/ and hampers compatibility and exensibility.

From jackalmage at gmail.com  Tue May 18 11:38:35 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 18 May 2010 11:38:35 -0700
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com> 
	<AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com> 
	<4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
Message-ID: <AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com>

On Tue, May 18, 2010 at 11:20 AM, bjartur <svartman95 at gmail.com> wrote:
> --------
>
> First of all I think we should use <a rel="embed" href="uri-ref"> instead of <source>. I'm not aware of previous proposals of that on this list. Feel free to provide links if it's already been proposed.

That's syntax; like I said, syntax has never been a problem.

> Second, all the responses I've seen so far have been along the lines of "it's the HTML5 way" (implying it's more of an XHTML 1 way, or [insert unfashionable tech here] way) or that video is so important that it deserves first-class treatment, and for the sake of completeness <audio> has to be included as well (though interactive content, text and 3D models don't deserve to be "first-class").

Then you haven't looked into it enough.

The reason why a single inclusive multimedia element is bad is because
different types of media have different requirements.  The javascript
API that makes sense to expose for audio is different than the one you
want to expose for video.  Video needs subtitles, audio doesn't (it
needs transcription, but that's something different entirely, and can
be handled with a simple link).  Etc.

Theoretically, you can swap out what type of api you expose based on
what the currently active media is.  In practice, that's a horrible
idea and no one wants to try to do it again.  It's even harder to try
and sort out multiple additional resources that should be attached to
particular media, but not others, like subtitle tracks that should be
attached to a video but shouldn't be exposed to an audio, etc.


> Isn't interactive content not important enaugh? What about text? What if one want's to link to interactive maps? svg at src? <a class="embed"..> with .embed {content: url(attr(href)) }? AFAIK CSS doesn't support it, and if it does <a rel="embed"..> could be used as well, even without explicit browser support.

SVG can be embedded directly in HTML.  Otherwise, you can use <object>
or <iframe> as the generic handlers.  Note, though, that these latter
methods deal with their contents in an agnostic way.  You don't get
special apis exposed on <iframe> if you link to an SVG file, frex.  If
you want special handling of certain types of media, though, you
really want a specialized element like <audio> and <video> get.

~TJ

From robert at ocallahan.org  Tue May 18 12:35:00 2010
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 19 May 2010 07:35:00 +1200
Subject: [whatwg] Should scripts and plugins in contenteditable content
	be enabled or disabled?
In-Reply-To: <AANLkTinTBbfeB-sAGjlguVHoM0TH5iww_RBpAqBg9x07@mail.gmail.com>
References: <v2o11e306601004221628o52abccf1kab707de85fbb9b28@mail.gmail.com>
	<op.vblr1rmoidj3kv@simon-pieterss-macbook.local>
	<g2t11e306601004230234vfd4b68aey32566940d2aa0b20@mail.gmail.com>
	<AANLkTinTBbfeB-sAGjlguVHoM0TH5iww_RBpAqBg9x07@mail.gmail.com>
Message-ID: <AANLkTimrncs-ixibdeRA3g-GjW_eFI4Udxcw1GbRPpfv@mail.gmail.com>

On Wed, May 19, 2010 at 5:35 AM, Ojan Vafai <ojan at chromium.org> wrote:

> The webkit behavior of allowing all scripts makes the most sense to me. It
> should be possible to disable scripts, but that capability shouldn't be tied
> to editability. The clean solution for the CKEditor developer is to use a
> sandboxed iframe.
>
> I don't see a security benefit for disabling script as you'd have all the
> same issues with loading any user-content in a non-editable area. The only
> catch is that you *do* need to disable script from pasted and drag-dropped
> content (see http://trac.webkit.org/changeset/53442). Basically, any site
> serving user-content will already need to mitigate XSS some other way, so
> disabling script in editable areas is not necessary, but paste/drag-drop
> can't reasonably rely on server-side solutions, so must be done by the UA.
>
> Putting my developer hat on, trying to make Google Gadgets work in Google's
> rich text editor inside Firefox designMode was awful due to
> https://bugzilla.mozilla.org/show_bug.cgi?id=519928. A large percentage of
> Google Gadgets load as iframes and require javascript onload. We had to play
> tricks with turning off designMode, appending the iframe and turning
> designMode back on. It was an awful solution that never worked very well.
>

That makes sense to me. I'll see what the other editor developers think.

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

From pmuellr at muellerware.org  Tue May 18 12:36:51 2010
From: pmuellr at muellerware.org (Patrick Mueller)
Date: Tue, 18 May 2010 15:36:51 -0400
Subject: [whatwg] ProgressEvent for appcache - loadedItems vs loaded
Message-ID: <hsuq8k$q78$1@dough.gmane.org>

under 6.6.4 "Downloading or updating an application cache"
under "The application cache download process steps are as follows:"
under step 17: "The application cache download process steps are as
follows:"
under sub-step 2: "For each cache host associated with an application cache"

Discussion about using "lengthComputable", "total", and "loaded"
attributes of the ProgressEvent interface.

There is a new draft of the Progress events spec here:

    http://dev.w3.org/2006/webapi/progress/Progress.html

In this draft, two new attributes of the ProgressEvent interface have
been added: "loadedItems" and "totalItems". These attributes might be
better suited to be used rather than the "total" and "loaded" attributes.

Same for step 18, which indicates a final ProgressEvent should be sent
at the completion of the cache download process.

-- 
Patrick Mueller - http://muellerware.org


From ericu at google.com  Tue May 18 14:45:14 2010
From: ericu at google.com (Eric Uhrhane)
Date: Tue, 18 May 2010 14:45:14 -0700
Subject: [whatwg] New File attributes creationDate,
	modificationDate and 	size
In-Reply-To: <4BEDE543.4020204@mozilla.com>
References: <4BE918B9.5070906@jrn.me.uk> <4BE9A293.8060004@helsinki.fi> 
	<AANLkTinulN8n2O3auuc0nkgmdRIMDut4Hi5XZx7vtRMV@mail.gmail.com> 
	<AANLkTik43By8vGeoNOHZenyEYo_AMkt2tHu7f4zvncYP@mail.gmail.com> 
	<1273663500.21168.199.camel@localhost> <4BEDE543.4020204@mozilla.com>
Message-ID: <AANLkTilgnNSFsWUDKWLMpSZM4AKHRJRERS5a_ZJ3beEM@mail.gmail.com>

On Fri, May 14, 2010 at 5:05 PM, Arun Ranganathan <arun at mozilla.com> wrote:
> On 5/12/10 4:25 AM, Ashley Sheridan wrote:
>>
>> On Wed, 2010-05-12 at 00:05 -0400, Biju wrote:
>>
>>
>>>
>>> It would be good if we can also get the same at server side when user
>>> upload a file using form with file controls
>>> ie, like the suggestion at
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=549253
>>> (it works even with javascript disabled)
>>>
>>> Also remember modificationDate can be a time before creationDate on
>>> windows.
>>> This is because modificationDate get copied when you copy a file,
>>> hence it almost shows modificationDate of the actual content.
>>>
>>> creationDate on other hand is file creation time on the
>>> folder/directory and when you copy a file to a new directory, it will
>>> be showing the coping time.
>>>
>>> PS, for JS option there is mozilla bug 390776
>>>
>>
>>
>
> I intend to update the File API so that the File object exposes creationDate
> and modificationDate.

You might want to consider making an async getMetadata function; see
discussion ending at [1].  Async because the modification time can
change often, and as a generic all-metadata function because it's easy
to expand and experiment with.  And if you put that right in the File
API, then I can inherit it from the FileSystem API instead of having
to spec it myself ;'>.

      Eric

[1] http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0054.html

From silviapfeiffer1 at gmail.com  Tue May 18 15:21:01 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 19 May 2010 08:21:01 +1000
Subject: [whatwg] <INCLUDE> and links with @rel=embed
In-Reply-To: <AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com>
References: <4bf275d3.8995d80a.52e1.fffff237@mx.google.com> 
	<AANLkTilCGd-AfK7manhPQ3InIyHFRLY5lH48A5wzYajR@mail.gmail.com> 
	<4bf2da61.0a41df0a.28b5.ffff9a5c@mx.google.com>
	<AANLkTimxaDX5LuuYRg0mz9NJRO_3aAAfB5SpwZfySXyX@mail.gmail.com>
Message-ID: <AANLkTin1ptQnk0ZyHyEjH0VBm_uvo-hvUxhtemvNBBgg@mail.gmail.com>

On Wed, May 19, 2010 at 4:38 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, May 18, 2010 at 11:20 AM, bjartur <svartman95 at gmail.com> wrote:
>> --------
>>
>> First of all I think we should use <a rel="embed" href="uri-ref"> instead of <source>. I'm not aware of previous proposals of that on this list. Feel free to provide links if it's already been proposed.
>
> That's syntax; like I said, syntax has never been a problem.
>
>> Second, all the responses I've seen so far have been along the lines of "it's the HTML5 way" (implying it's more of an XHTML 1 way, or [insert unfashionable tech here] way) or that video is so important that it deserves first-class treatment, and for the sake of completeness <audio> has to be included as well (though interactive content, text and 3D models don't deserve to be "first-class").
>
> Then you haven't looked into it enough.
>
> The reason why a single inclusive multimedia element is bad is because
> different types of media have different requirements. ?The javascript
> API that makes sense to expose for audio is different than the one you
> want to expose for video. ?Video needs subtitles, audio doesn't (it
> needs transcription, but that's something different entirely, and can
> be handled with a simple link). ?Etc.
>
> Theoretically, you can swap out what type of api you expose based on
> what the currently active media is. ?In practice, that's a horrible
> idea and no one wants to try to do it again. ?It's even harder to try
> and sort out multiple additional resources that should be attached to
> particular media, but not others, like subtitle tracks that should be
> attached to a video but shouldn't be exposed to an audio, etc.

I disagree with that last statement - audio does need subtitle-like
constructs, too. For example, if you want lyrics to be displayed in
sync with the audio, then it can be done with the same construct as
captions or subtitles work for video.


But I do agree with the need to keep audio and video as different
resource types with their own APIs. This far, in the life of HTML,
text has been the main driver of the Web, interspersed with images and
formatting instructions for text. By treating video and audio as their
own elements in their own right, we can finally move on into a world
of multimedia where audio and video can have their own formatting
instructions and their own JavaScript API - none of this would e
possible by leaving them hidden in an <a> element, or even in an
<embed> element, where it is totally unclear what the content will be.

Bjartur, I do wonder what exactly your motivation is in suggesting
audio and video be degraded back to undetermined embedded outside
content. What would be won by going back to that way? Lots will be
lost though - if you have ever developed a Website with Flash video,
you will know how much work is involved in creating a specific
JavaScript API to the Flash video player so that you can have some
interaction between the rest of the Webpage and the video or audio
resource. We honestly don't ever want to go back to that way.

Cheers,
Silvia.

From arun at mozilla.com  Tue May 18 16:05:02 2010
From: arun at mozilla.com (Arun Ranganathan)
Date: Tue, 18 May 2010 16:05:02 -0700
Subject: [whatwg] New File attributes creationDate,
 modificationDate and 	size
In-Reply-To: <AANLkTilgnNSFsWUDKWLMpSZM4AKHRJRERS5a_ZJ3beEM@mail.gmail.com>
References: <4BE918B9.5070906@jrn.me.uk> <4BE9A293.8060004@helsinki.fi>
	<AANLkTinulN8n2O3auuc0nkgmdRIMDut4Hi5XZx7vtRMV@mail.gmail.com>
	<AANLkTik43By8vGeoNOHZenyEYo_AMkt2tHu7f4zvncYP@mail.gmail.com>
	<1273663500.21168.199.camel@localhost>
	<4BEDE543.4020204@mozilla.com>
	<AANLkTilgnNSFsWUDKWLMpSZM4AKHRJRERS5a_ZJ3beEM@mail.gmail.com>
Message-ID: <4BF31D1E.4010205@mozilla.com>

On 5/18/10 2:45 PM, Eric Uhrhane wrote:
> On Fri, May 14, 2010 at 5:05 PM, Arun Ranganathan<arun at mozilla.com>  wrote:
>    
>> On 5/12/10 4:25 AM, Ashley Sheridan wrote:
>>      
>>> On Wed, 2010-05-12 at 00:05 -0400, Biju wrote:
>>>
>>>
>>>        
>>>> It would be good if we can also get the same at server side when user
>>>> upload a file using form with file controls
>>>> ie, like the suggestion at
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=549253
>>>> (it works even with javascript disabled)
>>>>
>>>> Also remember modificationDate can be a time before creationDate on
>>>> windows.
>>>> This is because modificationDate get copied when you copy a file,
>>>> hence it almost shows modificationDate of the actual content.
>>>>
>>>> creationDate on other hand is file creation time on the
>>>> folder/directory and when you copy a file to a new directory, it will
>>>> be showing the coping time.
>>>>
>>>> PS, for JS option there is mozilla bug 390776
>>>>
>>>>          
>>>
>>>        
>> I intend to update the File API so that the File object exposes creationDate
>> and modificationDate.
>>      
> You might want to consider making an async getMetadata function; see
> discussion ending at [1].  Async because the modification time can
> change often, and as a generic all-metadata function because it's easy
> to expand and experiment with.  And if you put that right in the File
> API, then I can inherit it from the FileSystem API instead of having
> to spec it myself ;'>.
>
>    

Right now in our implementation (Fx 3.6.3), we work with files as 
copies, so if the underlying file changes, the case isn't handled.  But 
I agree that having an asynchronous API that is exposed to web content 
will allow more graceful behavior.

I'll take a look at the generic asynchronous "all-metatdata" function 
and consider adding it to the File object.

-- A*


From shiki at google.com  Tue May 18 23:40:16 2010
From: shiki at google.com (Shiki Okasaka)
Date: Wed, 19 May 2010 15:40:16 +0900
Subject: [whatwg] Java language bindings for HTML5
In-Reply-To: <op.vcv1kne764w2qv@annevk-t60>
References: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>
	<AANLkTimXkjI5eDqDTD4Z82ZwL_jD9WzpleoyMsRbxwZS@mail.gmail.com>
	<op.vcv1kne764w2qv@annevk-t60>
Message-ID: <AANLkTimddDEpzaBM19wAZOsUHJQrtrmqLyM8NemcYm9l@mail.gmail.com>

On Tue, May 18, 2010 at 3:27 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Tue, 18 May 2010 04:38:21 +0200, Shiki Okasaka <shiki at google.com> wrote:
>>
>> On Mon, May 17, 2010 at 6:27 PM, K?hn Wolfgang <wo.kuehn at enbw.com> wrote:
>>>
>>> Hi,
>>> As for the html5 elements, will there be a new package org.w3c.dom.html5?
>>
>> This is our concern, too. Historically each W3C specification
>> introduced its own module name. However, the recent specifications
>> tend to omit the module specification in the IDL definition.
>>
>> ? ?cf.
>> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1380.html
>>
>> In the IDL files we used above, we chose module names that seem to be
>> practical, but those are not part of the standard. Hopefully more
>> people will revisit this issue sometime soon.
>
> Can't they all just use org.w3c.dom? We cannot make the interface names
> overlap anyway.

I think one module name for all of the Web platform would work fine
for programming languages joining to the Web platform only recently.
But for languages like Java, I guess it would be nice to have a rule
for obtaining module names.

I'm curious how directory name (cssom, workers, postmsg, etc.) is
assigned for each specification today. Can we use the same name as a
module name in most of the cases? It wouldn't work for cssom,
cssom-vew, though.

 - Shiki


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

From annevk at opera.com  Wed May 19 00:04:42 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 19 May 2010 09:04:42 +0200
Subject: [whatwg] Java language bindings for HTML5
In-Reply-To: <AANLkTimddDEpzaBM19wAZOsUHJQrtrmqLyM8NemcYm9l@mail.gmail.com>
References: <A7F2D3FDA66AAB46B3CF87F5BBE06CD888C7A266A5@S3Q2154.enbw.net>
	<AANLkTimXkjI5eDqDTD4Z82ZwL_jD9WzpleoyMsRbxwZS@mail.gmail.com>
	<op.vcv1kne764w2qv@annevk-t60>
	<AANLkTimddDEpzaBM19wAZOsUHJQrtrmqLyM8NemcYm9l@mail.gmail.com>
Message-ID: <op.vcxxx4i464w2qv@annevk-t60>

On Wed, 19 May 2010 08:40:16 +0200, Shiki Okasaka <shiki at google.com> wrote:
> On Tue, May 18, 2010 at 3:27 PM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> Can't they all just use org.w3c.dom? We cannot make the interface names
>> overlap anyway.
>
> I think one module name for all of the Web platform would work fine
> for programming languages joining to the Web platform only recently.
> But for languages like Java, I guess it would be nice to have a rule
> for obtaining module names.
>
> I'm curious how directory name (cssom, workers, postmsg, etc.) is
> assigned for each specification today. Can we use the same name as a
> module name in most of the cases? It wouldn't work for cssom,
> cssom-vew, though.

Usually the WG working on the specifications comes up with a shorthand and  
proposes this to the W3C Team. Very ad-hoc. But they are unique in a way  
so I suppose they could be used. The thing I would like to avoid is having  
to put module {} around most interface definitions because it is not  
useful for most of the target audience.


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

From annevk at opera.com  Wed May 19 00:50:36 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 19 May 2010 09:50:36 +0200
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTimXfRGorcSaO9mhta1YzA2tU7jIAlkFR8jvlqI1@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<op.vcv259qm64w2qv@annevk-t60>
	<AANLkTimXfRGorcSaO9mhta1YzA2tU7jIAlkFR8jvlqI1@mail.gmail.com>
Message-ID: <op.vcxz2mrg64w2qv@annevk-t60>

On Tue, 18 May 2010 10:52:53 +0200, Bjorn Bringert <bringert at google.com>  
wrote:
> On Tue, May 18, 2010 at 8:02 AM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> I wonder how it relates to the <device> proposal already in the draft.  
>> In theory that supports microphone input too.
>
> It would be possible to implement speech recognition on top of a
> microphone input API. The most obvious approach would be to use
> <device> to get an audio stream, and send that audio stream to a
> server (e.g. using WebSockets). The server runs a speech recognizer
> and returns the results.
>
> Advantages of the speech input element:
>
> - Web app developers do not need to build and maintain a speech
> recognition service.
>
> - Implementations can choose to use client-side speech recognition.
> This could give reduced network traffic and latency (but probably also
> reduced recognition accuracy and language support). Implementations
> could also use server-side recognition by default, switching to local
> recognition in offline or low bandwidth situations.
>
> - Using a general audio capture API would require APIs for things like
> audio encoding and audio streaming. Judging from the past results of
> specifying media features, this may be non-trivial. The speech input
> element turns all audio processing concerns into implementation
> details.
>
> - Implementations can have special UI treatment for speech input,
> which may be different from that for general audio capture.

I guess I don't really see why this cannot be added on top of the <device>  
element. Maybe it is indeed better though to separate the too. The reason  
I'm mostly asking is that one reason we went with <device> rather than  
<input> is that the result of the user operation is not something that  
will partake in form submission. Now obviously a lot of use cases today  
for form controls do not partake in form submission but are handled by  
script, but all the controls that are there can be used as part of form  
submission. <input type=speech> does not seem like it can.


> Advantages of using a microphone API:
>
> - Web app developers get complete control over the quality and
> features of the speech recognizer. This is a moot point for most
> developers though, since they do not have the resources to run their
> own speech recognition service.
>
> - Fewer features to implement in browsers (assuming that a microphone
> API would be added anyway).

Right, and I am pretty positive we will add a microphone API. What e.g.  
could be done is that you have a speech recognition object of some sorts  
that you can feed the audio stream that comes out of <device>. (Or indeed  
you feed the stream to a server via WebSocket.)


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

From annevk at opera.com  Wed May 19 01:17:19 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 19 May 2010 10:17:19 +0200
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
	<4BF1A5B0.3020307@helsinki.fi>
	<AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>
	<4BF25B91.9070308@helsinki.fi>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
	<AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>
Message-ID: <op.vcx1a5o664w2qv@annevk-t60>

On Tue, 18 May 2010 11:30:01 +0200, Bjorn Bringert <bringert at google.com>  
wrote:
> Yes, I agree with that. The tricky issue, as Olli points out, is
> whether and when the 'error' event should fire when recognition is
> aborted because the user moves away or gets an alert. What does
> XMLHttpRequest do?

I don't really see how the problem is the same as with synchronous  
XMLHttpRequest. When you do a synchronous request nothing happens to the  
event loop so an alert() dialog could never happen. I think you want  
recording to continue though. Having a simple dialog stop video  
conferencing for instance would be annoying. It's only script execution  
that needs to be paused. I'm also not sure if I'd really want recording to  
stop while looking at a page in a different tab. Again, if I'm in a  
conference call I'm almost always doing tasks on the side. E.g. looking up  
past discussions, scrolling through a document we're discussing, etc.


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

From satish at google.com  Wed May 19 01:22:54 2010
From: satish at google.com (Satish Sampath)
Date: Wed, 19 May 2010 09:22:54 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <op.vcx1a5o664w2qv@annevk-t60>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
	<4BF1A5B0.3020307@helsinki.fi>
	<AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>
	<4BF25B91.9070308@helsinki.fi>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
	<AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>
	<op.vcx1a5o664w2qv@annevk-t60>
Message-ID: <AANLkTimt9eQGkH1NhcHHXepKJugi31SkTVnc71B34I7b@mail.gmail.com>

>
> I don't really see how the problem is the same as with synchronous
> XMLHttpRequest. When you do a synchronous request nothing happens to the
> event loop so an alert() dialog could never happen. I think you want
> recording to continue though. Having a simple dialog stop video conferencing
> for instance would be annoying. It's only script execution that needs to be
> paused. I'm also not sure if I'd really want recording to stop while looking
> at a page in a different tab. Again, if I'm in a conference call I'm almost
> always doing tasks on the side. E.g. looking up past discussions, scrolling
> through a document we're discussing, etc.


Can you clarify how the speech input element (as described in the current
API sketch) is related to video conferencing or a conference call, since it
doesn't really stream audio to any place other than potentially a speech
recognition server and feeds the result back to the element?

--
Cheers
Satish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100519/6b06f6e5/attachment.htm>

From annevk at opera.com  Wed May 19 01:30:44 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 19 May 2010 10:30:44 +0200
Subject: [whatwg] Speech input element
In-Reply-To: <AANLkTimt9eQGkH1NhcHHXepKJugi31SkTVnc71B34I7b@mail.gmail.com>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<4BF14BFB.4090904@helsinki.fi>
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com>
	<4BF1A5B0.3020307@helsinki.fi>
	<AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com>
	<4BF25B91.9070308@helsinki.fi>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail.com>
	<AANLkTil8qrmfnyYIT6nB9CGPb_jmRc09OVM8TaoMnzD9@mail.gmail.com>
	<op.vcx1a5o664w2qv@annevk-t60>
	<AANLkTimt9eQGkH1NhcHHXepKJugi31SkTVnc71B34I7b@mail.gmail.com>
Message-ID: <op.vcx1xiqd64w2qv@annevk-t60>

On Wed, 19 May 2010 10:22:54 +0200, Satish Sampath <satish at google.com>  
wrote:
>> I don't really see how the problem is the same as with synchronous
>> XMLHttpRequest. When you do a synchronous request nothing happens to the
>> event loop so an alert() dialog could never happen. I think you want
>> recording to continue though. Having a simple dialog stop video  
>> conferencing
>> for instance would be annoying. It's only script execution that needs  
>> to be paused. I'm also not sure if I'd really want recording to stop  
>> while looking at a page in a different tab. Again, if I'm in a  
>> conference call I'm almost always doing tasks on the side. E.g. looking  
>> up past discussions, scrolling through a document we're discussing, etc.
>
> Can you clarify how the speech input element (as described in the current
> API sketch) is related to video conferencing or a conference call, since  
> it doesn't really stream audio to any place other than potentially a  
> speech
> recognition server and feeds the result back to the element?

Well, as indicated in the other thread I'm not sure whether this is the  
best way to do it. Usually we start with a lower-level API (i.e.  
microphone input) and build up from there. But maybe I'm wrong and speech  
input is a case that needs to be considered separately. It would still not  
be like synchronous XMLHttpRequest though.


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

From jsalsman at gmail.com  Wed May 19 01:36:26 2010
From: jsalsman at gmail.com (James Salsman)
Date: Wed, 19 May 2010 01:36:26 -0700
Subject: [whatwg] Speech input element
In-Reply-To: <op.vcxz2mrg64w2qv@annevk-t60>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com>
	<op.vcv259qm64w2qv@annevk-t60>
	<AANLkTimXfRGorcSaO9mhta1YzA2tU7jIAlkFR8jvlqI1@mail.gmail.com>
	<op.vcxz2mrg64w2qv@annevk-t60>
Message-ID: <AANLkTin0bYOPQWaf71qB8ojHXKPHxIHPYgnQKJx9CUDe@mail.gmail.com>

On Wed, May 19, 2010 at 12:50 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Tue, 18 May 2010 10:52:53 +0200, Bjorn Bringert <bringert at google.com> wrote:
>>...
>> Advantages of the speech input element:
>>
>> - Web app developers do not need to build and maintain a speech
>> recognition service.

But browser authors would, and it's not clear they will do so in a
cross-platform, compatible way.  Client devices with limited cache
memory sizes and battery power aren't very good at the Viterbi beam
search algorithm, which isn't helped much by small caches because it's
mostly random reads across wide memory spans.

>> - Implementations can have special UI treatment for speech input,
>> which may be different from that for general audio capture.
>
> I guess I don't really see why this cannot be added on top of the <device>
> element. Maybe it is indeed better though to separate the two. The reason
> I'm mostly asking is that one reason we went with <device> rather than
> <input> is that the result of the user operation is not something that will
> partake in form submission....

That's not a good reason.  Audio files are uploaded with <input
type=file> all the time, but it wasn't until Flash made it possible
that browser authors started considering the possibilities of
microphone upload, even though they were urged to address the issue a
decade ago:

> From: Tim Berners-Lee <timbl at w3.org>
> Date: Fri, 31 Mar 2000 16:37:02 -0500
>...
> This is a question of getting browser manufacturers to
> implement what is already in HTML....  HTML 4 does already
> include a way of requesting audio input.  For instance,
> you can write:
>
> <INPUT name="audiofile1" type="file" accept="audio/*">
>
> and be prompted for various means of audio input (a recorder,
> a mixing desk, a file icon drag and drop receptor, etc).
> Here "file" does not mean "from a disk" but "large body of
> data with a MIME type".
>
> As someone who used the NeXT machine's "lip service" many
> years ago I see no reason why browsers should not implement
> both audio and video and still capture in this way.   There
> are many occasions that voice input is valuable. We have speech
> recognition systems in the lab, for example, and of course this
> is very much needed....  So you don't need to convince me of
> the usefulness.
>
> However, browser writers have not implemented this!
>
> One needs to encourage this feature to be implemented, and
> implemented well.
>
> I hope this helps.
>
> Tim Berners-Lee

Further back in January, 2000, that same basic feature request had
been endorsed by more than 150 people, including:

    * Michael Swaine - in his article, "Sounds like..." -
webreview.com/pub/98/08/21/frames  - mswaine at swaine.com - well-known
magazine columnist for and long-time editor-in-chief of Dr. Dobb's
Journal
    * David Turner and Keith Ross of Institut Eurecom - in their
paper, "Asynchronous Audio Conferencing on the Web" -
www.eurecom.fr/~turner/papers/aconf/abstract.html -
{turner,ross}@eurecom.fr
    * Integrating Speech Technology in Language Learning SIG -
dbs.tay.ac.uk/instil - and InSTIL's ICARE committee, both chaired by
Lt. Col. Stephen LaRocca - gs0416 at exmail.usma.army.mil - a language
instructor at the U.S. Military Academy
    * Dr. Goh Kawai - goh at kawai.com - a researcher in the fields of
computer aided language instruction and speech recognition, and
InSTIL/ICARE founding member - www.kawai.com/goh
    * Ruth Ross - ruth at earthlab.com - IEEE Learning Technologies
Standards Committee - www.earthlab.com/RCR
    * Phil Siviter - Phil.Siviter at brighton.ac.uk - IEEE LTSC -
www.it.bton.ac.uk/staff/pfs/research.htm
    * Safia Barikzai - S.Barikzai at sbu.ac.uk - IEEE LTSC - www.sbu.ac.uk/barikzai
    * Gene Haldeman - gene at gene-haldeman.com - Computer Professionals
for Social Responsibility, Ethics Working Group
    * Steve Teicher - steve-teicher at att.net - University of Central
Florida; CPSR Education Working Group
    * Dr. Melissa Holland - mholland at arl.mil - team leader for the
U.S. Army Research Laboratory's Language Technology Group
    * Tull Jenkins - jenkinst at atsc.army.mil - U.S. Army Training
Support Centers

However, W3C decided not to move forward with the implementation
details at http://www.w3.org/TR/device-upload because they were said
to be "device dependent," which was completely meaningless, really.

Regards,
James Salsman

From jorlow at chromium.org  Wed May 19 02:11:58 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Wed, 19 May 2010 10:11:58 +0100
Subject: [whatwg] Speech input element
In-Reply-To: <op.vcx1xiqd64w2qv@annevk-t60>
References: <AANLkTilApc5W1olX_cGwSatRN6gHbCa2W_EzQVXVeHop@mail.gmail.com> 
	<AANLkTil8fGvOxqSqinHTmX0VR7-VyVKpBaX8-o9mJuyM@mail.gmail.com> 
	<4BF1A5B0.3020307@helsinki.fi>
	<AANLkTin_xBo8NEOZ5MnrMR65IzbLh0eI3M3KVnhyMRgP@mail.gmail.com> 
	<4BF25B91.9070308@helsinki.fi>
	<AANLkTimxhVZedBmf4d50vI6ZHS2RvpMQ3SspqQGE_ecx@mail.gmail