From whatwg at phroggy.com  Sat Nov  1 00:04:29 2008
From: whatwg at phroggy.com (Andy Lyttle)
Date: Sat, 1 Nov 2008 00:04:29 -0700
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <Pine.LNX.4.62.0811010253320.1041@hixie.dreamhostps.com>
References: <1804894DFB2E401FB4E722D71118DEBC@Sanktum01>
	<Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
	<6ea53250810311820v3126b276t9120e1d51dbdb9e0@mail.gmail.com>
	<Pine.LNX.4.62.0811010253320.1041@hixie.dreamhostps.com>
Message-ID: <B4A52B17-B683-4DAE-8A07-3570A5DC84F2@phroggy.com>

On Oct 31, 2008, at 7:57 PM, Ian Hickson wrote:
>>> That's what the "class" attribute is for.
>>
>> What's the difference then between <mark> and <span> then? I mean,  
>> does
>> the <mark> element provide anything that <span> with an appropriate
>> class wouldn't?
>
> A default style when there's no CSS support, support in accessibility
> tools, the ability for search engines to understand what's going on,
> easier round-tripping between editors, simpler rules in CSS and other
> selector-like environments, etc. The usual benefits of semantics.

Are we talking about assigning particular meanings to certain class  
names?  Or are we saying "this is for semantic purposes, but do  
whatever you want with it, because nobody will see it except UAs that  
are applying CSS rules and users who view the HTML source code"?  If  
the former, it's a terrible idea because developers have been working  
with the assumption that there are no reserved keywords so there are  
bound to be conflicts.  If the latter...  it doesn't really mean  
anything, does it?

By the way, I gave a ridiculous example earlier of why defining  
class="footnote" to have semantic meaning would be bad; I got really  
bored and fleshed out that example:  http://phroggy.com/musicalfeet/

-- 
Andy Lyttle
whatwg at phroggy.com






From pentasis at lavabit.com  Sat Nov  1 00:59:09 2008
From: pentasis at lavabit.com (Pentasis)
Date: Sat, 1 Nov 2008 09:59:09 +0200
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
References: <1804894DFB2E401FB4E722D71118DEBC@Sanktum01>
	<Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
Message-ID: <7FBE8F6412594407AEA330DB9A0D23DF@Sanktum01>


>
> The spec already describes how to do footnotes:
>
>   http://www.whatwg.org/specs/web-apps/current-work/#footnotes
>

Yes, but this is a theoretical explanation that does not provide a 
consistent, practical solution.

>
>> As the <mark> element has different usages defined on it already why not
>> include a "type" attribute (or similar) that defines what it is used
>> for. One of these types would then be "footnote", others could be
>> (relating to what is already in the spec) "term", "highlight" etc. (I am
>> sure others would be much better at thinking up names than I am).
>
> That's what the "class" attribute is for.
>

Like I said before, I think class (and id) should be reserved for styling 
and not be content/semantic related at all. It is strange how we all 
advocate separation of the two but allow these attributes to encompass 
descriptive values for both.

Bert 




From julian.reschke at gmx.de  Sat Nov  1 03:14:52 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 01 Nov 2008 11:14:52 +0100
Subject: [whatwg] Proposing URI Templates for WebForms 2.0
In-Reply-To: <310AF3FB-0D2F-4F96-A0E8-188DC88B28A8@mnot.net>
References: <00ff01c735b5$dde0abf0$0702a8c0@Guides.local>
	<eo7r1f$afj$1@sea.gmane.org>
	<Pine.LNX.4.62.0810281919200.1237@hixie.dreamhostps.com>
	<D180CE85-F9B2-458C-A139-FB1827DAEB13@mnot.net>
	<02dd01c93bc5$6e75cda0$6702a8c0@Guides.local>
	<15C6CE72-1963-4A41-93B8-A95F685326CB@mnot.net>
	<5D73ACAE-DE0F-4670-8AF3-8D834749F5CB@mnot.net>
	<032101c93bf5$b68bc790$6702a8c0@Guides.local>
	<342E43A5-7BDD-4796-B2E2-77D0378CF7E8@mnot.net>
	<033701c93c02$89672810$6702a8c0@Guides.local>
	<310AF3FB-0D2F-4F96-A0E8-188DC88B28A8@mnot.net>
Message-ID: <490C2C1C.3060409@gmx.de>

Mark Nottingham wrote:
> ...
> Try what I did with hinclude <http://www.mnot.net/javascript/hinclude/>; 
> write a javascript library to handle a declarative syntax, and have it 
> gracefully degrade once the browsers handle it natively. If the markup 
> is declarative, it doesn't matter if it's in HTML5 or not, you still can 
> cater to unintended uses.
> ...

Speaking of which: that one (hinclude) is totally useful; and it would 
also help with one of the cases Google's recent dictionary-based 
compression proposal is for.

I'd totally be in favor to have something like this in HTML5 (and no, 
others have asked for it as well).

BR, Julian


From ian at hixie.ch  Sat Nov  1 07:34:09 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 1 Nov 2008 14:34:09 +0000 (UTC)
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <56081EAFEA6A46EFA06E236BBE960D82@Sanktum01>
References: <1804894DFB2E401FB4E722D71118DEBC@Sanktum01>
	<Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
	<56081EAFEA6A46EFA06E236BBE960D82@Sanktum01>
Message-ID: <Pine.LNX.4.62.0811011428240.1041@hixie.dreamhostps.com>

On Sat, 1 Nov 2008, Andy Lyttle wrote:
> On Oct 31, 2008, at 7:57 PM, Ian Hickson wrote:
> > > > That's what the "class" attribute is for.
> > > 
> > > What's the difference then between <mark> and <span> then? I mean, 
> > > does the <mark> element provide anything that <span> with an 
> > > appropriate class wouldn't?
> > 
> > A default style when there's no CSS support, support in accessibility 
> > tools, the ability for search engines to understand what's going on, 
> > easier round-tripping between editors, simpler rules in CSS and other 
> > selector-like environments, etc. The usual benefits of semantics.
> 
> Are we talking about assigning particular meanings to certain class 
> names?

All class names have meaning. That's what the class attribute is for -- 
it's a way for authors to extend the language to cover semantics the 
language doesn't have, using terms they have defined for their page, site, 
or organisation.


> Or are we saying "this is for semantic purposes, but do whatever 
> you want with it, because nobody will see it except UAs that are 
> applying CSS rules and users who view the HTML source code"?

If by "this" you mean the class attribute, then neither; it's an extension 
mechanism, authors should use it for the purpose of annotating their 
semantics so that they can use those annotated semantics from other 
contexts (such as tools, scripts, style sheets, etc).


On Sat, 1 Nov 2008, Pentasis wrote:
> >
> > The spec already describes how to do footnotes:
> > 
> >   http://www.whatwg.org/specs/web-apps/current-work/#footnotes
> 
> Yes, but this is a theoretical explanation that does not provide a 
> consistent, practical solution.

I don't understand why these solutions aren't consistent or practical.


> > > As the <mark> element has different usages defined on it already why 
> > > not include a "type" attribute (or similar) that defines what it is 
> > > used for. One of these types would then be "footnote", others could 
> > > be (relating to what is already in the spec) "term", "highlight" 
> > > etc. (I am sure others would be much better at thinking up names 
> > > than I am).
> > 
> > That's what the "class" attribute is for.
> 
> Like I said before, I think class (and id) should be reserved for 
> styling and not be content/semantic related at all.

I'm afraid that's not what class and id are for, they are entirely 
intended as a way for authors to annotate their semantics in more detail.


> It is strange how we all advocate separation of the two but allow these 
> attributes to encompass descriptive values for both.

You should never use class (or id) for specifically stylistic reasons. You 
should use class to annotate the semantics, and then separately use the 
style sheets to hook onto your annotated semantics to get the style you 
want in more fine grained detail than the elements allow.

This is why values like class="big" or class="green" are bad, but values 
like class="footnote" or class="user-search-terms" are fine.

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


From ian at hixie.ch  Sat Nov  1 09:03:49 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 1 Nov 2008 16:03:49 +0000 (UTC)
Subject: [whatwg] WF2 terminology: tokens vs. productions
In-Reply-To: <F40FC77B-7F32-4BB1-A743-ECAE8E4B799F@iki.fi>
References: <F40FC77B-7F32-4BB1-A743-ECAE8E4B799F@iki.fi>
Message-ID: <Pine.LNX.4.62.0811011539360.1237@hixie.dreamhostps.com>

On Wed, 21 Nov 2007, Henri Sivonen wrote:
>
> Quoting the spec:
> > An e-mail address, following the format of the addr-spec  token defined in
> > RFC 2822 section 3.4.1 [RFC2822], but excluding the CFWS  subtoken
> > everywhere, and excluding the FWS subtoken everywhere except in the
> > quoted-string subtoken.
> 
> The text should probably talk about productions instead of tokens.

Fixed.

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


From pentasis at lavabit.com  Sat Nov  1 09:13:46 2008
From: pentasis at lavabit.com (Pentasis)
Date: Sat, 1 Nov 2008 18:13:46 +0200
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <Pine.LNX.4.62.0811011428240.1041@hixie.dreamhostps.com>
References: <1804894DFB2E401FB4E722D71118DEBC@Sanktum01>
	<Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
	<56081EAFEA6A46EFA06E236BBE960D82@Sanktum01>
	<Pine.LNX.4.62.0811011428240.1041@hixie.dreamhostps.com>
Message-ID: <779135F4FC5F4DD59EB5F7B415BCE379@Sanktum01>

>> Yes, but this is a theoretical explanation that does not provide a
>> consistent, practical solution.
>
> I don't understand why these solutions aren't consistent or practical.

First of all, the spec admits it itself:
"HTML does not have a dedicated mechanism for marking up footnotes. Here are 
the recommended alternatives."
Alternatives are not real mechanisms.

It gives us the option of using the title attribute (which has no mechanism 
of expansion and we cannot group them).
Then it gives us the a element solution, which is how it is already done in 
most cases but leaves much to be desired (there are plenty of articles about 
it on the web).
And last it tells us we can use the aside element. But in this example there 
is no *direct* relation to the actual word/phrase we put in the aside. It 
also gives us -again- no direct mechanism of expansion and no way of 
grouping footnotes/sidenotes.

Now, I am perfectly happy for this spec not to provide a footnote construct, 
but in that case I would strongly suggest removing these alternatives and 
simply say it should be resolved using scripting (which has much more 
flexibility) or not say anything at all about it.

>> Like I said before, I think class (and id) should be reserved for
>> styling and not be content/semantic related at all.
>
> I'm afraid that's not what class and id are for, they are entirely
> intended as a way for authors to annotate their semantics in more detail.
>
> You should never use class (or id) for specifically stylistic reasons. You
> should use class to annotate the semantics, and then separately use the
> style sheets to hook onto your annotated semantics to get the style you
> want in more fine grained detail than the elements allow.
>
> This is why values like class="big" or class="green" are bad, but values
> like class="footnote" or class="user-search-terms" are fine.

I will agree to the fact that this is the general consensus. And I have been 
doing it like that for a long time as well. But I will leave it at that, 
this is an entirely different discussion which has nothing to do with 
footnotes and I apologize for bringing it up.

Bert 




From jackalmage at gmail.com  Sat Nov  1 09:44:58 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sat, 1 Nov 2008 11:44:58 -0500
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <779135F4FC5F4DD59EB5F7B415BCE379@Sanktum01>
References: <1804894DFB2E401FB4E722D71118DEBC@Sanktum01>
	<Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
	<56081EAFEA6A46EFA06E236BBE960D82@Sanktum01>
	<Pine.LNX.4.62.0811011428240.1041@hixie.dreamhostps.com>
	<779135F4FC5F4DD59EB5F7B415BCE379@Sanktum01>
Message-ID: <dd0fbad0811010944j7e8c307cu8fd371d7b803bc47@mail.gmail.com>

On Sat, Nov 1, 2008 at 11:13 AM, Pentasis <pentasis at lavabit.com> wrote:

> Yes, but this is a theoretical explanation that does not provide a
>>> consistent, practical solution.
>>>
>>
>> I don't understand why these solutions aren't consistent or practical.
>>
>
> First of all, the spec admits it itself:
> "HTML does not have a dedicated mechanism for marking up footnotes. Here
> are the recommended alternatives."
> Alternatives are not real mechanisms.
>
> It gives us the option of using the title attribute (which has no mechanism
> of expansion and we cannot group them).
> Then it gives us the a element solution, which is how it is already done in
> most cases but leaves much to be desired (there are plenty of articles about
> it on the web).
> And last it tells us we can use the aside element. But in this example
> there is no *direct* relation to the actual word/phrase we put in the aside.
> It also gives us -again- no direct mechanism of expansion and no way of
> grouping footnotes/sidenotes.
>
> Now, I am perfectly happy for this spec not to provide a footnote
> construct, but in that case I would strongly suggest removing these
> alternatives and simply say it should be resolved using scripting (which has
> much more flexibility) or not say anything at all about it.
>

Grouping and such is a stylistic concern, though - as long as the document
expresses a footnote semantic, that's all it has to do.  For the rest, we
have a CSS Module that will cover that area, the Generated and Replaced
Content module [1].  By an astonishing coincidence, the editor of this
module is no less than Ian himself.

[1]: http://www.w3.org/TR/css3-content/

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081101/c3b07731/attachment.htm>

From pentasis at lavabit.com  Sat Nov  1 10:03:20 2008
From: pentasis at lavabit.com (Pentasis)
Date: Sat, 1 Nov 2008 19:03:20 +0200
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <dd0fbad0811010944j7e8c307cu8fd371d7b803bc47@mail.gmail.com>
References: <1804894DFB2E401FB4E722D71118DEBC@Sanktum01>
	<Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
	<56081EAFEA6A46EFA06E236BBE960D82@Sanktum01>
	<Pine.LNX.4.62.0811011428240.1041@hixie.dreamhostps.com>
	<779135F4FC5F4DD59EB5F7B415BCE379@Sanktum01>
	<dd0fbad0811010944j7e8c307cu8fd371d7b803bc47@mail.gmail.com>
Message-ID: <70981D35189342F08710E89B24CDF43A@Sanktum01>


  Grouping and such is a stylistic concern, though - as long as the document expresses a footnote semantic, that's all it has to do.  For the rest, we have a CSS Module that will cover that area, the Generated and Replaced Content module [1].  By an astonishing coincidence, the editor of this module is no less than Ian himself.


  [1]: http://www.w3.org/TR/css3-content/


  ~TJ


  In that case why don't they drop the abbr, dfn, cite, mark etc. elements? They can be styled through CSS as well and be semantically determined by using a class-name just as sugested for footnotes. 

  Bert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081101/3d710282/attachment.htm>

From pentasis at lavabit.com  Sat Nov  1 10:11:53 2008
From: pentasis at lavabit.com (Pentasis)
Date: Sat, 1 Nov 2008 19:11:53 +0200
Subject: [whatwg] Cascading Attribute Sheets
Message-ID: <EF905BC34B1849DE914CD1212B1C9AA3@Sanktum01>

In the "add type to mark element" discussion which I started, a side 
argument about ids and classes was brought up.
I conveyed my opinion that I think classes should only be used as style 
handles and not to convey extra semantic meaning.
The HTML4 spec states:

"The class attribute has several roles in HTML:

    * As a style sheet selector (when an author wishes to assign style 
information to a set of elements).
    * For general purpose processing by user agents."

The first role is clear, it is used for styles (not semantics) the second is 
a bit more muddy I think, but the important part there is: "processing BY 
user agents". User agents have no interest in semantics, so I fail to see 
here also why classes may be used to define semantic roles.
The fact that a class should be named "footnote" for example is only so you 
will not get in trouble (unlike when you use a name like "red" or "left"). 
But this only tells me (the author) that this element should be styled like 
a footnote and for the user agent that it should render it like a footnote. 
It should not tell me (or anything else) that it IS a footnote. This would 
lead inevitably to inflexibility.

Let me however put forth a -maybe silly- idea I have had for a long time. In 
seperating content from style it would seem logical to me that the next step 
would be to place most attributes (except id and a new role-attribute) also 
in an external file. Assignment of attributes and purpose can then also be 
done externally from the html-file leaving it only to contain pure content. 
(this would benefit SEO, machine readability, accessibility and 
maintainability).

The obvious benefits would be that one can maintain things externally like: 
links, images, accesskeys, list-numbering, hiding, etc. and if we would 
assign a common attribute to all elements called "edit" we could set that 
externally too (like "draft, deleted, approved, date, etc.).
but the biggest benefit (I think) is that we can set classnames externally. 
this way we do not have to touch the html-file to change styles, but simply 
change the properties in the external attribute sheet. The new role 
attribute would be completely semantic and classes are no longer indide the 
html so their naming can be more style-related. And changing a style would 
no longer mean changing the stylesheet, but changing the attributesheet. It 
would make CSS a little bit more modular (and flexible).

Well, let me have it ;-)

Bert 




From herenvardo at gmail.com  Sat Nov  1 12:27:52 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Sat, 1 Nov 2008 19:27:52 +0000
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <Pine.LNX.4.62.0811010253320.1041@hixie.dreamhostps.com>
References: <1804894DFB2E401FB4E722D71118DEBC@Sanktum01>
	<Pine.LNX.4.62.0810311928170.1041@hixie.dreamhostps.com>
	<6ea53250810311820v3126b276t9120e1d51dbdb9e0@mail.gmail.com>
	<Pine.LNX.4.62.0811010253320.1041@hixie.dreamhostps.com>
Message-ID: <6ea53250811011227j3ebaae89v6ce7e259fa81cc1d@mail.gmail.com>

First of all, I'd like to avoid any missunderstandings: I have nothing
against the <mark> element itself; although I'm afraid my previous
e-mails may lead to think otherwise. It could be a really good
addition to HTML but, IMHO, it isn't yet, and I'm trying to show why I
think so.

On Sat, Nov 1, 2008 at 2:57 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 1 Nov 2008, Eduard Pascual wrote:
>> [...]
>> What's the difference then between <mark> and <span> then? I mean, does
>> the <mark> element provide anything that <span> with an appropriate
>> class wouldn't?
>
> A default style when there's no CSS support, support in accessibility
> tools, the ability for search engines to understand what's going on,
> easier round-tripping between editors, simpler rules in CSS and other
> selector-like environments, etc. The usual benefits of semantics.

Let's take that point by point:

-> A default style when there's no CSS support: that's entirely
presentational; and although I may accept it as a side-bonus, I don't
feel presentational arguments are a good base for including/excluding
a new element.

-> Support in accessibility tools: that's plain daydreaming: what kind
of support can an AT provide without any hint on whether the <mark>'ed
text is a search term, or the line of a code snippet that caused a
crash, or the total price of the orders in a shopping cart, or
whatever other usage authors may come up with?

-> The ability for search engines to understand what's going on??
Comming from someone else, I'd think they are simply wrong, but
comming from Ian I really hope you were joking: besides a SE would be
as clueless on that aspect as an AT; this would extremelly easily
abused by "black hat" SEO, to the point of making the element
completely meaningless for SEs: just a "mark { display: none; }" rule
and a site becomes able to freely spam "highlighted" keywords across
the entire page. And, although many SEs are capable of checking CSS
sheets, it's almost trivial to achieve the same from JavaScript, and
even to obfuscate the script if any SE managed to figure the trick
out.

-> Simpler rules in CSS and other selector-like environments: I simply
can't believe that this came from an editor of the CSS3 Selectors
module. How much simples is "mark" than ".match", ".crash_line",
".total", and so on? The only difference is a single dot; plus the
fact that classes give much more flexibility that directly styling (or
selecting on any other similar environment) could ever allow. And
finally, it's worth to mention that, as soon as a page needs to use
<mark> for two or more different purposes, there is no other way to
differentiate them in selectors than classes (and no way at all for
ATs or SEs to differentiate then, BTW).

-> The usual benefits of semantics. Honestly, that's a really good
purpose; it's only that it's not achieved. If you look again at the
counter-arguments above, you should be able to notice that they are
nothing else than the usual drawbacks of lack of semantics. Because,
simply put, the semantics defined for <mark> are so vague that, in
practical terms, they are the same as no semantics at all. Pentasis's
initial proposal would be a simple and efficient solution to this
issue: with some sort of type/role/whatever attribute (based on a
well-defined list of allowable values), an AT could tell the user why
some text is marked, a SE could figure out what's really going on, and
a designer could rely on that attribute upon selection instead of
defining classes with an entirely presentational purpose.

Well, that's my opinion, just wanted to share it.


From t.broyer at gmail.com  Sat Nov  1 12:34:19 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Sat, 1 Nov 2008 20:34:19 +0100
Subject: [whatwg] Cascading Attribute Sheets
In-Reply-To: <EF905BC34B1849DE914CD1212B1C9AA3@Sanktum01>
References: <EF905BC34B1849DE914CD1212B1C9AA3@Sanktum01>
Message-ID: <a9699fd20811011234q664e57e5g2fbf53530107f3d2@mail.gmail.com>

On Sat, Nov 1, 2008 at 6:11 PM, Pentasis wrote:
> In the "add type to mark element" discussion which I started, a side
> argument about ids and classes was brought up.
> I conveyed my opinion that I think classes should only be used as style
> handles and not to convey extra semantic meaning.
> The HTML4 spec states:
>
> "The class attribute has several roles in HTML:
>
>   * As a style sheet selector (when an author wishes to assign style
> information to a set of elements).
>   * For general purpose processing by user agents."
>
> The first role is clear, it is used for styles (not semantics)

Ian answered to this. You'll similarly or identically style elements
with similar or identical meaning; in other words, you'll attach style
to semantics, so your class names are likely to markup your document
with additional semantics.

> the second is
> a bit more muddy I think, but the important part there is: "processing BY
> user agents". User agents have no interest in semantics, so I fail to see
> here also why classes may be used to define semantic roles.

Microformats.

> The fact that a class should be named "footnote" for example is only so you
> will not get in trouble (unlike when you use a name like "red" or "left").
> But this only tells me (the author) that this element should be styled like
> a footnote and for the user agent that it should render it like a footnote.
> It should not tell me (or anything else) that it IS a footnote. This would
> lead inevitably to inflexibility.

Why not enclose your footnotes in <aside> elements?

Moreover, a note is not necessarily presented as a "footnote" (i.e.
moved to the end of the "page"), it can be shown in the margin (as in
the WHATWG version of the HTML5 spec) or in popup panels when you
click on a word or "footnote reference" (similarly to definitions in
the old HTMLHelp on Windows).

-- 
Thomas Broyer


From ian at hixie.ch  Sat Nov  1 13:49:55 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 1 Nov 2008 20:49:55 +0000 (UTC)
Subject: [whatwg]  HTML5 and URI Templates
In-Reply-To: <8579EEF4-5FAF-4252-884C-9239AFE8AB11@IEEE.org>
References: <00ff01c735b5$dde0abf0$0702a8c0@Guides.local>
	<eo7r1f$afj$1@sea.gmane.org>
	<Pine.LNX.4.62.0810281919200.1237@hixie.dreamhostps.com>
	<D180CE85-F9B2-458C-A139-FB1827DAEB13@mnot.net>
	<8579EEF4-5FAF-4252-884C-9239AFE8AB11@IEEE.org>
Message-ID: <Pine.LNX.4.62.0811012000280.1237@hixie.dreamhostps.com>


(In the interests of avoiding cross-posting, I have only sent this e-mail 
to the whatwg list. The original e-mails were also crossposted to the IETF 
URI list and the rest-discuss list.)


This might be a good time to bring the FAQ to people's attention -- it 
covers what we ask people to go through when proposing new features:

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

I encourage people to follow this process.


On Sat, 15 Dec 2007, James M Snell wrote:
>
> The gist of the idea (which I believe may have been brought up before 
> but I'm not certain) is to allow the use of a URI Template in place of 
> the form element action attribute, and to use form elements to provide 
> the replacement values, e.g.
> 
> <form template="http://example.org{-prefix|/|foo}?bar={bar}"
>       method="POST">
>   Foo: <input name="foo" type="input" >
>   Bar: <input name="bar" type="input">
> </form>

Why isn't the current form submission mechanism, with a redirect on the 
server-side, not acceptable?


On Fri, 21 Dec 2007, James M Snell wrote:
>
> FYI... I've put together a quick prototype example [1] of a html form 
> using a URI Template [2].  The processing of the template is performed 
> in the onsubmit event of the form.
> 
> - James
> 
> [1] http://www.snellspace.com/wp/?p=832
> [2] http://www.snellspace.com/wp/?p=831

This is great -- why is it not enough?


I have to admit to being a little concerned over the complexity of the URI 
template language as currently proposed.


On Fri, 31 Oct 2008, Jerome Louvel wrote:
> 
> It would just be easier to take advantage of them directly from HTML. 
> Right now, a Web form can already build a URI by adding query parameters 
> to the action URI of a GET form, why not go a bit further?

Because it adds significant complexity to the browser platform, without 
really adding new functionality.


> The benefit would be having more control over the construction of the 
> URI rather than just the query parameters. I could have a form with two 
> simple fields "a" and "b" and specify 
> "http://test.org/customers/{a}/reports/{b}" as the action URI.

I don't understand why this is such a big deal. Such, the URIs are nicer, 
but, big deal. Just do a redirect if it matters that much.


On Sat, 1 Nov 2008, Mark Nottingham wrote:
> 
> Doing it in script precludes unintended reuse, e.g., for accessibility, 
> search engines, and so forth [...]

Why would scripts preclude accessibility? And are you really expecting 
search engines to fill in forms that would use templates? (Some search 
engines fill in forms, but it's usually for searches, where the content 
would most properly be in the query component.)


On Fri, 31 Oct 2008, Mike Schinkel wrote:
> 
> What classifies as a "compelling use-case" in your mind?

Something that can't be done without the feature. Something that allows 
authors to write applications that make users say "wow!", which they can't 
do today.


On Sat, 1 Nov 2008, Mark Nottingham wrote:
>
> The benefits you're talking about seem to be all related to having more 
> flexibility in specifying URIs from forms. This is good and I agree that 
> in a perfect world, more flexibility would have been designed in from 
> the start. However, to put them into the mix while the machine is 
> running is a bit more complex; there needs to be something more 
> compelling (there's that word again) to drive adoption.

Agreed.


On Sat, 1 Nov 2008, Mike Schinkel wrote:
> 
> Please PLEASE don't make us wait until 2032 or so for this! ;-)

You can do it now with redirects or scripts. It's not clear to me that 
this is a feature that is important enough to ever be in the browser.


On Sat, 1 Nov 2008, Mark Nottingham wrote:
> 
> Because you're not introducing your idea to a new proposal that will 
> succeed or fail on its own merits; you're trying to get it into one of 
> the most widely-used formats in the world. As such, the barrier to entry 
> is higher; it has to be, or every idea that seems to be good would get 
> in, and HTML5 would be even more incomprehensible than it is now.

Indeed,


> I'm not the person to ask that, but frankly if you want the 
> functionality, go ahead and write the software, publish the site, 
> release the browser plug-in; the standards will follow if the minds do.

That's how many parts of HTML5 have made it in.


On Sat, 1 Nov 2008, Mike Schinkel wrote:
> 
> Adding URI Templates to forms fills a large hole in the forms 
> architecture; This is very much a case of empowering serendipity as the 
> current form architecture current cannotly service the full range of 
> URLs that can be used.  I'm asking for (most of) that gap to be filled.

There are many many gaps, why is this an important one to fill?


On Sat, 1 Nov 2008, Mike Schinkel wrote:
>
> I can understand, appreciate and respect that.  FYI I lost patience with 
> the standard process a while back because it seemed that no matter my 
> input I was always told "no."  Since I only found frustration, I gave 
> up.
>
> I'm participating again because Ian included me on a follow email on 
> this issue and because I really do want to see URI Templates become part 
> of HTML5.  That said, I really have no idea how to go about getting 
> things accepted I think because I look for what could be and it seems 
> most standards people only want to see what already is?

I encourage you to work with the browser vendors directly, as discussed 
here:

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


> The irony is that if TBL had gotten this kind of resistance when he 
> tried to launch the web it never would have happened because he couldn't 
> demonstrate an existing use-case (Oh wait a minute, he DID get this kind 
> of resistance from the IETF, and it almost killed the web stillborne.  
> Thank god it didn't.)

TBL did exactly what we're suggesting you do -- he wrote his own spec, 
wrote his own client, and wrote his own server, and put it out there. He 
didn't wait for a Standards Process to give him a stamp of approval.


On Sat, 1 Nov 2008, Paul Prescod wrote:
>
> The Mechanize family of libraries would presumably be able to take 
> advantage of them as they do current forms. With mechanize you can ask a 
> headless client library to "load a page", "fill out some fields in a 
> form" and "submit" and it infers what HTTP requests to make based on the 
> form's structure. It cannot do this if the form is based upon 
> Javascript. So I'd say that's a generalized argument against depending 
> on Javascript for form capabilities, orthogonal to the question of how 
> rich forms' URI-building capabilities need to be.

(Why can't Mechanize support script?)


On Sat, 1 Nov 2008, Mike Schinkel wrote:
> 
> 1.) I'm (hypothetically) the owner of atllogos.com and I want on provide 
> an HTML for to let visitors select from a drop-down to be able to visit 
> the Twitter users listed on http://atllogos.com/startup.html (Note that 
> "template" is a new attribute that is used for templates when no 
> "action" is specified):
> 
> See these people on Twitter:
> <form method="get" template="http://twitter.com/{name}">
> <select id="name">
> <option>sanjay</option>
> <option>lance</option>
> <option>stephenfleming</option>
> <option>keithmcgreggor</option>
> <option>melaniebrandt</option>
> <option>jhaynie</option>
> <option>MikeSchinkel</option>
> <option>coty</option>
> <option>wei_yang</option>
> <option>mmealling</option>
> <option>pfreet</option> 
> </select>
> <input type="submit" value="Go!">
> </form>

Why not just provide links, or use a redirect?

What if the URI you have to compute is more complicated than just 
substitution, like some parts being dependent on others, or needing 
calculation, or whatnot?


[snip 2, which was the same idea]


> 3.) I am writing a blog post on Blogger.com about "Ride to Work Day" where I
> am advocating people in the USA ride their motorcycle to work and I want to
> include a form that let's them type in their ZIP code and check there
> weather:
> 
> <form method="get" template="http://www.weather.com/weather/local/{zip}/">
> <input type="text" name="zip"/>
> <input type="submit" value="Check Weather!">
> </form>

What if the user types something that isn't supported by weather.com, like 
the string "x"?

Also, why can't you just do:

  <form method="get" action="http://www.weather.com/search/enhanced">
   <input type="text" name="where"/>
   <input type="submit" value="Check Weather!">
  </form>

...? That works today.


> In the case of #1 and #2, spiders like Google can crawl those as well 
> but could not crawl them. That's especially important if someone decides 
> to architect a site using "clean" URLs and then use drop-downs in forms 
> to allow people to navigate to pages. If implemented in Javascript it 
> can't be reliably called but if URI templates were supported in forms it 
> could be.

I don't really follow what you're saying here. I see no practical 
difference between URI templates and normal forms in terms of Google 
crawling the results.


On Sat, 1 Nov 2008, Erik Wilde wrote:
> >
> > But the most of the web today won't be taking advantage of this for a 
> > long time.
> 
> that is certainly true. but i think there are cases where this already would
> be useful on today's web.

I don't think anyone is denying that it is useful in certain cases. The 
question is whether it will be used widely enough to make it worth it.

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


From ian at hixie.ch  Sat Nov  1 15:03:02 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 1 Nov 2008 22:03:02 +0000 (UTC)
Subject: [whatwg] [WF2] form.submit() should not throw if form is invalid
In-Reply-To: <dd4c8a40801100448j4089093p5b76270465b6e7a5@mail.gmail.com>
References: <dd4c8a40801100448j4089093p5b76270465b6e7a5@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811012201150.1237@hixie.dreamhostps.com>

On Thu, 10 Jan 2008, Hallvord R M Steen wrote:
>
> I think some changes are required to make WF2 more web-compatible. In 
> particular, we need a clean way JS can override WF2's validation. 
> Cancelling an invalid event just prevents the UA's built-in message - we 
> need something that makes submission happen anyway.
> 
> The best candidate is the submit() method - if we drop the requirement 
> that it throws an error if the form is invalid. As specified, WF2 breaks 
> *a lot* of pages which use custom JS libraries for validation, trigger 
> WF2 rules by coincidence and expect to be able to submit forms with 
> form.submit().

Done.

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


From pentasis at lavabit.com  Sun Nov  2 01:53:44 2008
From: pentasis at lavabit.com (Pentasis)
Date: Sun, 2 Nov 2008 11:53:44 +0200
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <mailman.69833.1225568061.26350.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.69833.1225568061.26350.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <298A0DAB36A84501AE57ED552C427C23@Sanktum01>

>>
>>   * As a style sheet selector (when an author wishes to assign style
>> information to a set of elements).
>>   * For general purpose processing by user agents."
>>
>> The first role is clear, it is used for styles (not semantics)
>
> Ian answered to this. You'll similarly or identically style elements
> with similar or identical meaning; in other words, you'll attach style
> to semantics, so your class names are likely to markup your document
> with additional semantics.

That is exactly why I think it is wrong. It gives me less flexibility. It 
means I must either style all footnotes (or whatever) the same, or introduce 
more classes/ids to style them differently and in that case I create a 
situation in which some classes are pure semantic and others are only there 
for style reasons and have a less than perfect semantic name 
("footnote-style-1" for example).

>
>> the second is
>> a bit more muddy I think, but the important part there is: "processing BY
>> user agents". User agents have no interest in semantics, so I fail to see
>> here also why classes may be used to define semantic roles.
>
> Microformats.

Don't get me wrong, microformats are a good idea, but they lack the 
construct in standards to be used efficiently. They should not use title or 
class attributes. They specify a role and pure semantics and have absolutely 
nothing to do with styling on their own.

>
>> The fact that a class should be named "footnote" for example is only so 
>> you
>> will not get in trouble (unlike when you use a name like "red" or 
>> "left").
>> But this only tells me (the author) that this element should be styled 
>> like
>> a footnote and for the user agent that it should render it like a 
>> footnote.
>> It should not tell me (or anything else) that it IS a footnote. This 
>> would
>> lead inevitably to inflexibility.
>
> Why not enclose your footnotes in <aside> elements?

Because it isn't an aside.

> Moreover, a note is not necessarily presented as a "footnote" (i.e.
> moved to the end of the "page"), it can be shown in the margin (as in
> the WHATWG version of the HTML5 spec) or in popup panels when you
> click on a word or "footnote reference" (similarly to definitions in
> the old HTMLHelp on Windows).

Very true, that is exactly what I have been saying. The current spec does 
not take this into account. As it stands now, I must assign a class-name to 
the footnote and then style (and perhaps script) based on that 
class-reference. But it fails to give me a proper element to do this. Like I 
said, I think the Mark element would be great, but then either it should get 
a "role" atribute or the examples given in the spec should give it a more 
flexible meaning.
Footnotes (and the likes) fall in the same catagory as definitions, so why 
not give it an element just like it? (or broaden the meaning of the 
dfn-element).

Bert




From philipj at opera.com  Sun Nov  2 02:16:06 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Sun, 02 Nov 2008 11:16:06 +0100
Subject: [whatwg] HTMLMediaElement: pixelratio, unsigned int, timeupdate
Message-ID: <1225620966.10140.21.camel@nog>

Some assorted questions related to
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html


http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-source-pixelratio
How should a pixelratio <= 0.0 be treated? I would suggest that the DOM
attribute actually return the negative value but that it is explicitly
ignored in step 5 of
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#pick-a-media-resource


What should be done if a reflected unsigned integer DOM attribute is set
to a negative number? INDEX_SIZE_ERR, ignored or something else? I'm
quite sure it's well defined, just not in
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#reflect


In the section about cue ranges (can't seem to find an #anchor nearby):
"If the time was reached through the usual monotonic increase of the
current playback position during normal playback, the user agent must
then queue a task to fire a simple event called timeupdate at the
element."

How often should the timeupdate event be fired? Without a requirement
for this, anything from every ms to never would seem to be acceptable. I
agree with Eric Carlson and Jonas Sickling that this event isn't
particularly useful and would rather see it removed from the spec.

-- 
Philip J?genstedt
Opera Software



From jackalmage at gmail.com  Sun Nov  2 07:57:41 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sun, 2 Nov 2008 09:57:41 -0600
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <298A0DAB36A84501AE57ED552C427C23@Sanktum01>
References: <mailman.69833.1225568061.26350.whatwg-whatwg.org@lists.whatwg.org>
	<298A0DAB36A84501AE57ED552C427C23@Sanktum01>
Message-ID: <dd0fbad0811020757l2440decena2791b78c4a89dfc@mail.gmail.com>

On Sun, Nov 2, 2008 at 3:53 AM, Pentasis <pentasis at lavabit.com> wrote:

>
>>>  * As a style sheet selector (when an author wishes to assign style
>>> information to a set of elements).
>>>  * For general purpose processing by user agents."
>>>
>>> The first role is clear, it is used for styles (not semantics)
>>>
>>
>> Ian answered to this. You'll similarly or identically style elements
>> with similar or identical meaning; in other words, you'll attach style
>> to semantics, so your class names are likely to markup your document
>> with additional semantics.
>>
>
> That is exactly why I think it is wrong. It gives me less flexibility. It
> means I must either style all footnotes (or whatever) the same, or introduce
> more classes/ids to style them differently and in that case I create a
> situation in which some classes are pure semantic and others are only there
> for style reasons and have a less than perfect semantic name
> ("footnote-style-1" for example).


No, you're misunderstanding.  *Why* are you styling some footnotes
differently?

Is it because they're in a different section, and you want them to match
with the section-wide style?  In that case, there's no need for extra
classes.  As long as each section is wrapped in a container with an
appropriate class or id, you can then use a contextual selector to target
footnotes in each section and style them differently.

Is it because they are fundamentally a different kind of footnote?  Then of
course you need more classes.  Just giving them a single "footnote" class is
obviously not expressing your semantics appropriately.  This doesn't require
any style-oriented classes, just some additional classes that more
specifically express the separate roles your footnotes are filling.

Is it because you've decided you want your footnotes to have different
styles for purely aesthetic reasons?  Then yes, in this case you either need
to tag every footnote with an #id and style them directly, or give out
purely aesthetic classes.  Either way will require a lot of work - up-front
with the id strategy, and continuing with the class strategy (since you'll
need to go back in and change every class as you change your mind on
aesthetics).

Don't get me wrong - there is obviously a correlation between semantics and
style in that the amount of semantics I put into a document is a reflection
of how much style control I want.  This is not because I invent semantics
just for styling, but rather because I am lazy and don't have the time or
patience to accurately describe all of the semantics of the document
(actually, this is likely an impossible task, as the semantics of a document
change when used in different ways).  Thus, I describe what is useful to me,
which generally means what will help me target my styles and scripts.


>
>>  the second is
>>> a bit more muddy I think, but the important part there is: "processing BY
>>> user agents". User agents have no interest in semantics, so I fail to see
>>> here also why classes may be used to define semantic roles.
>>>
>>
>> Microformats.
>>
>
> Don't get me wrong, microformats are a good idea, but they lack the
> construct in standards to be used efficiently. They should not use title or
> class attributes. They specify a role and pure semantics and have absolutely
> nothing to do with styling on their own.


You are correct.  They *are* pure semantics and have nothing to do with
style.  Your conclusion that they should thus not use title or class
attributes is begging the question, however - you're assuming that classes
are purely stylistic from the start.  Microformats were meant to be an
example against that - a case where @class is used completely semantically
in a way that UAs can understand, rather than the standard effect of a
semantic language that only the author understands.


>
>>  The fact that a class should be named "footnote" for example is only so
>>> you
>>> will not get in trouble (unlike when you use a name like "red" or
>>> "left").
>>> But this only tells me (the author) that this element should be styled
>>> like
>>> a footnote and for the user agent that it should render it like a
>>> footnote.
>>> It should not tell me (or anything else) that it IS a footnote. This
>>> would
>>> lead inevitably to inflexibility.
>>>
>>
>> Why not enclose your footnotes in <aside> elements?
>>
>
> Because it isn't an aside.


I wish I'd responded to your earlier message here.   "The fact that a class
should be named "footnote" for example is only so you
will not get in trouble (unlike when you use a name like "red" or "left")"
is entirely incorrect.  Who would you get in trouble from, the semantics
police?  The reason you use classes like "footnote" rather than "red" is
because with the former you can change the appearance of your footnotes and
the class still makes sense.  With the latter, if you change your styling
(to make it blue, say) you either have to go into the code and change the
class to blue, or you have to change the "red" style itself and render it
completely nonsensical.  All CSS is providing you at this point is a
shortcut for the <font> tag, which is completely wasting the potential of
the language.


>  Moreover, a note is not necessarily presented as a "footnote" (i.e.
>> moved to the end of the "page"), it can be shown in the margin (as in
>> the WHATWG version of the HTML5 spec) or in popup panels when you
>> click on a word or "footnote reference" (similarly to definitions in
>> the old HTMLHelp on Windows).
>>
>
> Very true, that is exactly what I have been saying. The current spec does
> not take this into account. As it stands now, I must assign a class-name to
> the footnote and then style (and perhaps script) based on that
> class-reference. But it fails to give me a proper element to do this. Like I
> said, I think the Mark element would be great, but then either it should get
> a "role" atribute or the examples given in the spec should give it a more
> flexible meaning.


Why does the spec need to provide you with a "proper element"?  You can just
assign a class!  In CSS or scripting terms there is absolutely no
difference.


> Footnotes (and the likes) fall in the same catagory as definitions, so why
> not give it an element just like it? (or broaden the meaning of the
> dfn-element).


Just a day or two ago Ian sent out a reminder of what the process is for
getting something new added to the spec.  "Why not?" is *not* part of the
process.  If it was, the spec would already have gone down in flames as a
bloated piece of "me too!"-riddled crap.  You need to provide *strong
reasons* to get something into the spec, reasons that actually make the
lives of a significant number of authors significantly easier.  If something
is a fairly niche area without much direct benefit and which can already be
done well by styling and/or scripting alone, then generally it's not worth
adding to the spec.  You can just do it yourself in the rare times that you
need it.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081102/2ffe26f4/attachment.htm>

From pentasis at lavabit.com  Sun Nov  2 08:44:40 2008
From: pentasis at lavabit.com (Pentasis)
Date: Sun, 2 Nov 2008 18:44:40 +0200
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <dd0fbad0811020757l2440decena2791b78c4a89dfc@mail.gmail.com>
References: <mailman.69833.1225568061.26350.whatwg-whatwg.org@lists.whatwg.org>
	<298A0DAB36A84501AE57ED552C427C23@Sanktum01>
	<dd0fbad0811020757l2440decena2791b78c4a89dfc@mail.gmail.com>
Message-ID: <F757F8CD65DF4EA19ABC60092D7B1250@Sanktum01>

The problem with your entire reply is that you take the last remarks and respond to them out of context, but just on a final note:


  No, you're misunderstanding.  *Why* are you styling some footnotes differently?  

  I never said I am styling footnotes differently. I merely poiiunted out that if we want to style something with the same class diferently we need to assigne extra classes to it.


        the second is
        a bit more muddy I think, but the important part there is: "processing BY
        user agents". User agents have no interest in semantics, so I fail to see
        here also why classes may be used to define semantic roles.


      Microformats.


    Don't get me wrong, microformats are a good idea, but they lack the construct in standards to be used efficiently. They should not use title or class attributes. They specify a role and pure semantics and have absolutely nothing to do with styling on their own.


  You are correct.  They *are* pure semantics and have nothing to do with style.  Your conclusion that they should thus not use title or class attributes is begging the question, however - you're assuming that classes are purely stylistic from the start.  Microformats were meant to be an example against that - a case where @class is used completely semantically in a way that UAs can understand, rather than the standard effect of a semantic language that only the author understands.

  Sure, classes can be used that way, but I quoted the HTML4 spec earlier and have not seen anyone contradict the fact that it does not provide that functionality to the class-attribute. Now, perhaps it does in the HTML5 spec, if so, I stand corrected.






        The fact that a class should be named "footnote" for example is only so you
        will not get in trouble (unlike when you use a name like "red" or "left").
        But this only tells me (the author) that this element should be styled like
        a footnote and for the user agent that it should render it like a footnote.
        It should not tell me (or anything else) that it IS a footnote. This would
        lead inevitably to inflexibility.


      Why not enclose your footnotes in <aside> elements?


    Because it isn't an aside.


  I wish I'd responded to your earlier message here.   "The fact that a class should be named "footnote" for example is only so you
  will not get in trouble (unlike when you use a name like "red" or "left")" is entirely incorrect.  Who would you get in trouble from, the semantics police?

  No, from exactly what you describe below. That was my point. The other point I make here is that no matter how semantically correct I name my class it is still a stylesheet hook.

    The reason you use classes like "footnote" rather than "red" is because with the former you can change the appearance of your footnotes and the class still makes sense.  With the latter, if you change your styling (to make it blue, say) you either have to go into the code and change the class to blue, or you have to change the "red" style itself and render it completely nonsensical.  All CSS is providing you at this point is a shortcut for the <font> tag, which is completely wasting the potential of the language.






    Very true, that is exactly what I have been saying. The current spec does not take this into account. As it stands now, I must assign a class-name to the footnote and then style (and perhaps script) based on that class-reference. But it fails to give me a proper element to do this. Like I said, I think the Mark element would be great, but then either it should get a "role" atribute or the examples given in the spec should give it a more flexible meaning.


  Why does the spec need to provide you with a "proper element"?  

  Because I was under the impression we want a semantic web?

    Footnotes (and the likes) fall in the same catagory as definitions, so why not give it an element just like it? (or broaden the meaning of the dfn-element).


  Just a day or two ago Ian sent out a reminder of what the process is for getting something new added to the spec.  "Why not?" is *not* part of the process.  If it was, the spec would already have gone down in flames as a bloated piece of "me too!"-riddled crap.  You need to provide *strong reasons* to get something into the spec, reasons that actually make the lives of a significant number of authors significantly easier.  If something is a fairly niche area without much direct benefit and which can already be done well by styling and/or scripting alone, then generally it's not worth adding to the spec.  You can just do it yourself in the rare times that you need it.


  I did not start out this discussion with a "why not" question. But sofar all the arguments I have been given do not add up logically. And if you say "why should it"? I can most definatly respond with "why not?"

  For me the discussion ends here since I don't think it is worth the trouble. All I can say is that I think discussions on this list are of a very closed, almost defensive nature. But perhaps that is my own fault.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081102/f6d60788/attachment.htm>

From herenvardo at gmail.com  Sun Nov  2 09:29:33 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Sun, 2 Nov 2008 17:29:33 +0000
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <F757F8CD65DF4EA19ABC60092D7B1250@Sanktum01>
References: <mailman.69833.1225568061.26350.whatwg-whatwg.org@lists.whatwg.org>
	<298A0DAB36A84501AE57ED552C427C23@Sanktum01>
	<dd0fbad0811020757l2440decena2791b78c4a89dfc@mail.gmail.com>
	<F757F8CD65DF4EA19ABC60092D7B1250@Sanktum01>
Message-ID: <6ea53250811020929u13593385u4b5ebdad674d8301@mail.gmail.com>

On Sun, Nov 2, 2008 at 4:44 PM, Pentasis <pentasis at lavabit.com> wrote:
> Sure, classes can be used that way, but I quoted the HTML4 spec earlier and
> have not seen anyone contradict the fact that it does not provide that
> functionality to the class-attribute. Now, perhaps it does in the HTML5
> spec, if so, I stand corrected.
I want to clarify something here, although it's as much personal
opinion as it's fact.
Classes *are intended* to be semantic. The original idea behind them
in HTML4 was already focused in that direction, although the wording
was quite vague. In addition, the HTML4 spec had deprecated all the
presentational stuff, and hooking CSS through classes was the best
alternative to all this deprecated stuff.
HTML5, while still quite vague, has a clearer wording on how classes
are intended to be used:
>From http://www.whatwg.org/specs/web-apps/current-work/#classes:
"Authors may use any value in the class attribute, but are encouraged
to use the values that describe the nature of the content, rather than
values that describe the desired presentation of the content."
With this, HTML5 is *not* changing the intention of classes, it is
just making it clearer. The actual issue is that HTML4 mentioned an
example of typical/expected usage (CSS hooking), and it has been taken
as the "norm" rather than as the "specific-case example" it was
suposed to be. So, what HTML5 is trying to change here is how classes
are actually used, bringing them back to their original intent.

Anyway, this whole class-usage discussion, despite interesting, is
just tangentially related to the original topic. If you have any issue
with that part of the spec, maybe you should start a separate
discussion for it. I should point out, anyway, that while I agree with
you about the need of some type/role attribute to better scope those
vaguely-semantic elements like <mark>; I mostly disagree with your
idea that classes should be used only for styling.

> I did not start out this discussion with a "why not" question. But sofar all
> the arguments I have been given do not add up logically. And if you say "why
> should it"? I can most definatly respond with "why not?"
Of course you didn't. If you had, I wouldn't have even bothered on replying.
Actually, I gave a list of arguments about why the <mark> element, as
currently defined, miserably fails to fulfill any of its purposes
(except the presentational one); and how your proposal would indeed
fulfill such purposes. Nobody has even bothered to reply to it.
Ok, I'll admit: I'm human, hence I'm not perfect, hence I might be
wrong: but nobody has made any effort to prove me wrong. My reply
made, IMO, quite good points about your proposal, so I got simply
ignored; and you made the little mistake of straying into a side topic
(classes usage), and people have picked on you for that, using that
mistake to bury the valid points of your original suggestion into
oblivion.

> For me the discussion ends here since I don't think it is worth the trouble.
Definitely, it isn't. I don't even know why am I still wasting my time
here: I had some hope that web author's feedback would be really taken
into consideration when I joined, but not anymore now that I've seen
through the facade of this list.

> All I can say is that I think discussions on this list are of a very closed,
> almost defensive nature. But perhaps that is my own fault.
Your only fault, just like me, was to believe this was a serious place
for discussion. But it isn't: it is just a tool: feedback "praising"
the spec will be kept well safe, while feedback suggesting anything
that was not the idea of browser vendors gets buried in
side-discussions or simply ignored. In the end, feedback is not being
used to improve the spec, but to hide the fact that it is nothing else
than the tyrannical imposition of browser vendors upon the entire Web.
So once they go through and publish HTML5 as a recommendation or
standard, they will use all this filtered, non-representative
feedback, to claim that it was defined by the entire Web community.
But the truth is that browser vendors will do whatever they please,
just like they did before the W3C existed, only that they are now also
trying to attach it the "standard" tag.
Maybe I'm completely wrong on this but, since I joined this list few
months ago, I have seen absolutelly nothing that could make me think I
am.


From pentasis at lavabit.com  Sun Nov  2 09:49:32 2008
From: pentasis at lavabit.com (Pentasis)
Date: Sun, 2 Nov 2008 19:49:32 +0200
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <6ea53250811020929u13593385u4b5ebdad674d8301@mail.gmail.com>
References: <mailman.69833.1225568061.26350.whatwg-whatwg.org@lists.whatwg.org>
	<298A0DAB36A84501AE57ED552C427C23@Sanktum01>
	<dd0fbad0811020757l2440decena2791b78c4a89dfc@mail.gmail.com>
	<F757F8CD65DF4EA19ABC60092D7B1250@Sanktum01>
	<6ea53250811020929u13593385u4b5ebdad674d8301@mail.gmail.com>
Message-ID: <C8DF718A4F3043069DE0C9FB87717A96@Sanktum01>


>> All I can say is that I think discussions on this list are of a very 
>> closed,
>> almost defensive nature. But perhaps that is my own fault.
> Your only fault, just like me, was to believe this was a serious place
> for discussion. But it isn't: it is just a tool: feedback "praising"
> the spec will be kept well safe, while feedback suggesting anything
> that was not the idea of browser vendors gets buried in
> side-discussions or simply ignored. In the end, feedback is not being
> used to improve the spec, but to hide the fact that it is nothing else
> than the tyrannical imposition of browser vendors upon the entire Web.
> So once they go through and publish HTML5 as a recommendation or
> standard, they will use all this filtered, non-representative
> feedback, to claim that it was defined by the entire Web community.
> But the truth is that browser vendors will do whatever they please,
> just like they did before the W3C existed, only that they are now also
> trying to attach it the "standard" tag.
> Maybe I'm completely wrong on this but, since I joined this list few
> months ago, I have seen absolutelly nothing that could make me think I
> am.

I had my doubts when I heard browser vendors were going to do the next 
standard. But I gave them the benefit of the doubt, I had high hopes as 
well. I read both the X/HTML5 and the XHTML2 spec over the past two months, 
and if I was given a choice (but that is personal ofcourse) I would choose 
XHTML2 without a second thought. Despite the fact that it (too) is very 
inaccessible. At least it is less bloated and less stringent. The X/HTML 
spec reads too much like a law and leave little or no room for the creative 
designer minds that eventually need to work with it.
I am slowely but seriously contemplating organising the designer world and 
creating our own standards. these browsers have been nothing but troubles 
since the first day of the internet. First a "war", then it was slow and bad 
implementation of standards, and now it is creating a new standard which is 
unusable in a practical sense for designers. (and it won't guarantee anyone 
that it will mean all browsers will be standards compliant, so what is the 
point?) As a designer all I want is a standard that enables me to design and 
to comply to usability, accessibility etc. without having to worry about UAs 
breaking or doing things differently just because someone thought: "wow, 
look we can do that...how gimmicky. Let us implement it".
Browser vendors should equally comply to standards and simply make browsers 
user friendly. Neither designers nor UA manufacturers have any business of 
writing specs!
Well, sorry for the rant, but this is just another sad example I think of 
free market and free speech being abused.




From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Nov  3 15:28:13 2008
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Tue, 04 Nov 2008 00:28:13 +0100
Subject: [whatwg] Add 'type' attribute to <mark>
In-Reply-To: <C8DF718A4F3043069DE0C9FB87717A96@Sanktum01>
References: <mailman.69833.1225568061.26350.whatwg-whatwg.org@lists.whatwg.org>
	<298A0DAB36A84501AE57ED552C427C23@Sanktum01>
	<dd0fbad0811020757l2440decena2791b78c4a89dfc@mail.gmail.com>
	<F757F8CD65DF4EA19ABC60092D7B1250@Sanktum01>
	<6ea53250811020929u13593385u4b5ebdad674d8301@mail.gmail.com>
	<C8DF718A4F3043069DE0C9FB87717A96@Sanktum01>
Message-ID: <1225754893.14302.19.camel@12345luise>

Am Sonntag, den 02.11.2008, 19:49 +0200 schrieb Pentasis:
> I had my doubts when I heard browser vendors were going to do the next 
> standard. But I gave them the benefit of the doubt, I had high hopes as 
> well. I read both the X/HTML5 and the XHTML2 spec over the past two months, 
> and if I was given a choice (but that is personal ofcourse) I would choose 
> XHTML2 without a second thought.
XHTML2 has some points going for it, for example the <h> element,
removal of legacy elements or the "any object can be a link" @href
attribute. However, it has it inconsistencies, too - I would be careful
with attributing that to the makers of the spec. Fact: (X)HTML5 at least
seems to have a more open process and that means: You can probably work
on it.

> The X/HTML spec reads too much like a law and leave little or no room for the creative 
> designer minds that eventually need to work with it.
Creative designer minds working on rendering engines and DOM
properties ? Sorry, but one "creative" vendor (MS) apparently is enough
to throw the web off balance ... and no reasonable sane person wants to
repeat that.

> I am slowely but seriously contemplating organising the designer world and 
> creating our own standards. these browsers have been nothing but troubles 
> since the first day of the internet.
Wait, what ?

> First a "war", then it was slow and bad 
> implementation of standards, and now it is creating a new standard which is 
> unusable in a practical sense for designers.(and it won't guarantee anyone 
> that it will mean all browsers will be standards compliant, so what is the 
> point?)
Yeah, what's the point of standards if one can just ignore them ? Maybe
heavily armed web mercenaries tort^H^H^H^H^H easing the vendors into
compliance would be a better way to go ?

> As a designer all I want is a standard that enables me to design and 
> to comply to usability, accessibility etc. without having to worry about UAs 
> breaking or doing things differently just because someone thought: "wow, 
> look we can do that...how gimmicky. Let us implement it".
Then go burn Redmond. Send cash to Opera. Or Mozilla. Wait, Google does
the last thing already. Seriously, bother someone else.

> Browser vendors should equally comply to standards and simply make browsers 
> user friendly. Neither designers nor UA manufacturers have any business of 
> writing specs!
Separation of powers, eh ? I'm gonna make my own web standard, with
hookers and blackjack ! In fact, forget the web standard ...

> Well, sorry for the rant, but this is just another sad example I think of 
> free market and free speech being abused.
Thing is, we have nearly infinite resources on the web. Go make your
standard. The only concept I know of that has "abusing free speech" is
using free speech to abolish it (e.g. [GODWIN DETECTED]).


Now GTFO my web,
-- 
Nils Dagsson Moskopp
<http://dieweltistgarnichtso.net>



From jonas at sicking.cc  Mon Nov  3 15:59:18 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 03 Nov 2008 15:59:18 -0800
Subject: [whatwg] Exposing UA information to workers
Message-ID: <490F9056.7080806@sicking.cc>

For future compat it would be good to expose to workers information on 
what browser is currently being used. This can be used to work around 
bugs and lack of features.

In a 'normal' window context the navigator object exposes a set of 
properties, such as userAgent, that can be used for this purpose. I 
suggest we add something similar to the worker context. The HTML5 spec 
defines the following:

interface Navigator {
   // client identification
   readonly attribute DOMString appName;
   readonly attribute DOMString appVersion;
   readonly attribute DOMString platform;
   readonly attribute DOMString userAgent;

   // ... other things not related to identifying the UA
};

I'm not sure how stable this part of the HTML5 spec is, (I know firefox 
exposes a whole host of more properties), but it seems like a good set 
to start with. We should probably keep the two in sync if the window 
context Navigator object changes in the future.


Orthoginally, it seems like at least the 'onLine' boolean on the 
Navigator interface would be useful too, and could be exposed at the 
same place.

Let me know what you think.

/ Jonas


From ian at hixie.ch  Mon Nov  3 18:12:16 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 4 Nov 2008 02:12:16 +0000 (UTC)
Subject: [whatwg] [WF2] backwards compatibility with values of custom
 required attributes
In-Reply-To: <dd4c8a40801041036v21025043t135f2581894807e3@mail.gmail.com>
References: <dd4c8a40801041036v21025043t135f2581894807e3@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811032246440.1237@hixie.dreamhostps.com>

On Fri, 4 Jan 2008, Hallvord R M Steen wrote:
>
> some code from airgreenland.com reminded me to bring up the discussion 
> of how to treat values of "required" attributes:
> 
> <input name="CONTROLGROUPCONTACT$ContactInputView$TextBoxAddressLine2"
> type="text" maxlength="52"
> id="CONTROLGROUPCONTACT_ContactInputView_TextBoxAddressLine2"
> class="w10" required="false" requiredError="Street address Field 2 is
> required.">
> 
> I've seen this before (and I'm sure many of you will recognise the 
> ASP.NET stuff). The problem is that <input required="false"> is treated 
> as <input required> by WF2 because the "false" value isn't recognised. I 
> think WF2 needs to do something sensible to ensure backwards 
> compatibility - ASP.NET form validation is going to cause us serious 
> problems otherwise.

I notice that Opera still supports required="" today. Did this turn out to 
be a surmountable problem?

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


From aa at google.com  Mon Nov  3 23:08:58 2008
From: aa at google.com (Aaron Boodman)
Date: Mon, 3 Nov 2008 23:08:58 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker interfaces
Message-ID: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>

Hello all,

A few months ago, I suggested that we combine the DedicatedWorker and
SharedWorker interfaces
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016228.html),
but we never reached consensus.

Since Mozilla and Apple are both working on implementing this now, I'd
like to revisit the issue before we end up with something non-ideal
baked into implementations.

My biggest issue with the proposal as currently drafted is that there
are so many different ways to send and receive messages. I think this
overcomplicates the proposal for both developers and implementors.

For dedicated workers, you can either send single messages using the
Worker object directly, like in Gears:

var worker = new Worker("foo.js");
worker.postMessage("ping");

Or, you can use the more powerful startConversation() API to easily
group related messages together:

var port = worker.startConversation();
port.postMessage("ping");

Note that the worker has to know ahead of time which API the callers
will use since the way that it replies is different depending on that.
If the caller used Worker.sendMessage(), the worker should reply like
this:

onmessage = function() {
  postMessage("pong");
}

... but if the caller used Worker.startConversation().sendMessage(),
then the worker should reply like this:

onmessage = function(e) {
  e.port.postMesage("pong");
}

SharedWorkers require a third, completely different API to send messages:

var w = new SharedWorker("foo.js", "foo");
w.port.postMessage("ping");
w.port.onmessage = function(e) {};

The interface to receive messages in a SharedWorker is also special:

onconnect = function(e) {
  e.port.onmessage = function(e) {
    e.port.postMessage("pong");
  }
}

This lack of generality bothers me on an aesthetic level, but I also
think it has the following real problems:

* Workers have to know what interface was used to send them messages.
If the page using a worker decide to start using a more powerful send
API, the worker must also be upgraded. You can already see examples of
this problem in the samples at the beginning of the draft. They are
marked with the comments "// support being used as a shared worker as
well as a dedicated worker".

* Having different interfaces for each use case means that each new
feature has to be added to each interface separately. We can already
see this problem in the fact that the SharedWorker interface lacks
startConversation() for no apparent reason.

* Having multiple interfaces probably increases the chance of
developers misunderstanding and using the wrong tool for the job. I
can easily see developers accidentally reimplementing
startConversation() on top of Worker.sendMessage().

* More API for developers to learn and implementors to build.


I think that these issues can all be addressed by simplifying and
combining the various APIs. This will make the simplest examples of
workers require slightly more code, but I think it is much simpler and
more elegant.

Here is how it would work:
* Get rid of the DedicatedWorker interface.
* Add startConversation() to SharedWorker, but rename it "connect()"
and make the onconnect event fire inside the worker each time it is
called.

Here's an example in code:

// dedicated workers (outside)
var worker = new Worker("foo.js");
var port = worker.connect();
port.onmessage = function() { }
port.postMessage("ping");

// dedicated workers (inside)
onconnect = function(e) {
  e.port.onmessage = function(e) {
    e.port.postMessage("pong");
  }
}

Shared workers are exactly the same except the constructor is
SharedWorker("foo.js", "foo");

Note that I do not think it is necessary to implement this all at
once. For one, the SharedWorker constructor could easily be punted for
future releases.

Thoughts?

- a


From aa at google.com  Mon Nov  3 23:14:52 2008
From: aa at google.com (Aaron Boodman)
Date: Mon, 3 Nov 2008 23:14:52 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
Message-ID: <278fd46c0811032314m7dca9960h3d9d7aa2b8fff41d@mail.gmail.com>

On Mon, Nov 3, 2008 at 11:08 PM, Aaron Boodman <aa at google.com> wrote:
>sendMessage()

I'm sorry, please excuse my mixing the names 'sendMessage' and
'postMessage'. The Gears API is named 'sendMessage' and I keep
accidentally using that.

The name in Web Workers should of course be 'postMessage' everywhere.

- a


From ap at webkit.org  Tue Nov  4 05:42:34 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Tue, 4 Nov 2008 16:42:34 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
Message-ID: <563D44EA-F2C1-4177-A16B-05F67767E862@webkit.org>


Nov 4, 2008, ? 10:08 AM, Aaron Boodman ???????(?):

> This lack of generality bothers me on an aesthetic level, but I also
> think it has the following real problems:

Agreed on all points.

> * Add startConversation() to SharedWorker, but rename it "connect()"

Makes sense - when we had other MessagePort methods mirrored to worker  
global scope, this name was natural, but it no longer is now.

> Here's an example in code:
>
> // dedicated workers (outside)
> var worker = new Worker("foo.js");
> var port = worker.connect();
> port.onmessage = function() { }
> port.postMessage("ping");
>
> // dedicated workers (inside)
> onconnect = function(e) {
>  e.port.onmessage = function(e) {
>    e.port.postMessage("pong");
>  }
> }

I think this can be written as (note the different name of  
MessageEvent attribute, and the use of "this" in onmessage):
onconnect = function(e) {
  e.messagePort.onmessage = function() {
    this.postMessage("pong");
  }
}

In general, one extra line of code doesn't look like a huge downside -  
this is not something that needs to be done again and again in client  
code.

> Shared workers are exactly the same except the constructor is
> SharedWorker("foo.js", "foo");


Is there any benefit in having a different name for this constructor?  
If dedicated and shared workers are going to have identical  
implementation (notably, if they have exactly the same lifetime), I  
don't see any benefit in making them look different.

- WBR, Alexey Proskuryakov




From simonp at opera.com  Tue Nov  4 08:49:51 2008
From: simonp at opera.com (Simon Pieters)
Date: Tue, 04 Nov 2008 17:49:51 +0100
Subject: [whatwg] PDF version comments
Message-ID: <op.uj3s1dqhidj3kv@zcorpandell.linkoping.osa>

I had a quick look at the PDF version of the spec...

The "check for updates" box should probably be hidden.

Why are the status boxes in the margin hidden? It seems to me that they  
would be useful also on paper.

The acks section shows question marks for ??? and ????.


Cheers,
-- 
Simon Pieters
Opera Software


From aa at google.com  Tue Nov  4 09:02:01 2008
From: aa at google.com (Aaron Boodman)
Date: Tue, 4 Nov 2008 09:02:01 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <563D44EA-F2C1-4177-A16B-05F67767E862@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<563D44EA-F2C1-4177-A16B-05F67767E862@webkit.org>
Message-ID: <278fd46c0811040902i2cecdf54p8231271ecf700e6f@mail.gmail.com>

2008/11/4 Alexey Proskuryakov <ap at webkit.org>:
> Nov 4, 2008, ? 10:08 AM, Aaron Boodman ???????(?):
>> Here's an example in code:
>>
>> // dedicated workers (outside)
>> var worker = new Worker("foo.js");
>> var port = worker.connect();
>> port.onmessage = function() { }
>> port.postMessage("ping");
>>
>> // dedicated workers (inside)
>> onconnect = function(e) {
>>  e.port.onmessage = function(e) {
>>   e.port.postMessage("pong");
>>  }
>> }
>
> I think this can be written as (note the different name of MessageEvent
> attribute, and the use of "this" in onmessage):
> onconnect = function(e) {
>  e.messagePort.onmessage = function() {
>   this.postMessage("pong");
>  }
> }

Right you are. Thanks for fixing.

>> Shared workers are exactly the same except the constructor is
>> SharedWorker("foo.js", "foo");
>
> Is there any benefit in having a different name for this constructor? If
> dedicated and shared workers are going to have identical implementation
> (notably, if they have exactly the same lifetime), I don't see any benefit
> in making them look different.

I don't have a strong opinion on this either way.

- a


From pentasis at lavabit.com  Tue Nov  4 09:25:54 2008
From: pentasis at lavabit.com (Pentasis)
Date: Tue, 4 Nov 2008 19:25:54 +0200
Subject: [whatwg] ---
In-Reply-To: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <5F72A897C4E14A23BBD26E332702CF17@Sanktum01>

>> The X/HTML spec reads too much like a law and leave little or no room for 
>> the creative
>> designer minds that eventually need to work with it.
> Creative designer minds working on rendering engines and DOM
> properties ? Sorry, but one "creative" vendor (MS) apparently is enough
> to throw the web off balance ... and no reasonable sane person wants to
> repeat that.

I think here you may well have said exactly what is wrong with this whole 
browser-vendors doing standards problem.

Who ever said that the standards are here for browsers?????????
Just because browsers need to implement the standards does NOT, I repeat NOT 
mean they are written for browser vendors.
Especially not the HTML standards. (I would sooner agree with you on this 
point regarding CSS than HTML).

HTML is a markup language that is meant to describe how content is to be 
"tagged" so it can be retrieved based on markup.
This has absolutely nothing, and I mean NOTHING to do with browsers, 
screenreaders, bots, or even humans as far as I am concerned. It is a sec 
standard describing the hooks that exist in the real world that have existed 
and evolved since mankind could write and later publish. Humans, UAs, bots, 
etc. only need to know about these hooks and either implement them or use 
them as described.

You mention the DOM for example. Good, the DOM is a way of describing how 
HTML can be implemented in a browser. If you as browser vendors want to 
describe that and agree upon it amongst yourselves...fine, I would welcome 
that. But I fail to see why this means you have any right to change HTML 
itself in the process.

If you want a standard that describes how browsers or UAs in general must 
deal with HTML than write THAT standard, but leave HTML out of it please.

Bert 




From joao.eiras at gmail.com  Tue Nov  4 09:36:10 2008
From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=)
Date: Tue, 4 Nov 2008 17:36:10 +0000
Subject: [whatwg] ---
In-Reply-To: <5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
Message-ID: <e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>

> Who ever said that the standards are here for browsers?????????

That's the whoe point of standards: to ensure interoperability between
the laters.


> HTML is a markup language that is meant to describe how content is to be
> "tagged" so it can be retrieved based on markup.
> This has absolutely nothing, and I mean NOTHING to do with browsers,
> screenreaders, bots, or even humans as far as I am concerned.

HTML still needs to be interpreted and rendered.


> You mention the DOM for example. Good, the DOM is a way of describing how
> HTML can be implemented in a browser. If you as browser vendors want to
> describe that and agree upon it amongst yourselves...fine, I would welcome
> that.

That's what the WHATWG and W3C are for: to agree a common set of rules
for web technologies.

Thanks for the laugh. Now, think twice before rewritting such non-sense.

Goodbye.


From pentasis at lavabit.com  Tue Nov  4 09:49:30 2008
From: pentasis at lavabit.com (Pentasis)
Date: Tue, 4 Nov 2008 19:49:30 +0200
Subject: [whatwg] ---
In-Reply-To: <e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
Message-ID: <BB71B7BDAB2248DD903605906ECF5B5A@Sanktum01>

>> Who ever said that the standards are here for browsers?????????
>
> That's the whoe point of standards: to ensure interoperability between
> the laters.
>
>
>> HTML is a markup language that is meant to describe how content is to be
>> "tagged" so it can be retrieved based on markup.
>> This has absolutely nothing, and I mean NOTHING to do with browsers,
>> screenreaders, bots, or even humans as far as I am concerned.
>
> HTML still needs to be interpreted and rendered.
>
>
>> You mention the DOM for example. Good, the DOM is a way of describing how
>> HTML can be implemented in a browser. If you as browser vendors want to
>> describe that and agree upon it amongst yourselves...fine, I would 
>> welcome
>> that.
>
> That's what the WHATWG and W3C are for: to agree a common set of rules
> for web technologies.
>
> Thanks for the laugh. Now, think twice before rewritting such non-sense.
>
> Goodbye.

No need to get personal.

Like I said, I fully understand that UAs must have a standard construct to 
be able to deal with markup. But that does by no means mean that they should 
have control over the markup itself.
this does not mean ofcourse that UA-vendors couldn't do it; anybody could do 
it for all I care, as long as they do it with the actual purpose of HTML in 
mind, and defining an HTML based on the premise "it must be able to render 
on our browsers" is clearly not it. You have got it the wrong way round, it 
is "our browser can render it" that would be correct.

Bert 




From pentasis at lavabit.com  Tue Nov  4 10:07:56 2008
From: pentasis at lavabit.com (Pentasis)
Date: Tue, 4 Nov 2008 20:07:56 +0200
Subject: [whatwg] ---
In-Reply-To: <e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
Message-ID: <38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>

Ok, let's try to get the "heat" off of this discussion. Let me try to 
explain it.

The HTML spec consists of several parts. Some of these parts are indeed 
browsers spcific, like the DOM, the rendering engine, etc.
But the other part is pure semantics. It is about marking up content.

I agree that the first part should be done by UA vendors, but I strongly 
oppose that the second part is done by them as well. That should be done by 
linguistics, typographs, and people who have to actually create the content.

The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on the 
browser part. I understand, after all that is your job and I am sure you are 
all very capable of that. But please, let the actual markup language itself 
be defined by others who are more capable of doing that.

Bert 




From rimantas at gmail.com  Tue Nov  4 10:27:23 2008
From: rimantas at gmail.com (Rimantas Liubertas)
Date: Tue, 4 Nov 2008 20:27:23 +0200
Subject: [whatwg] ---
In-Reply-To: <38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
Message-ID: <5ccfb3340811041027s1dbd0f48t351bf47f94565193@mail.gmail.com>

<...>
> The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on the
> browser part. I understand, after all that is your job and I am sure you are
> all very capable of that. But please, let the actual markup language itself
> be defined by others who are more capable of doing that.

Thanks for the laugh, indeed.

Regards,
Rimantas
--
http://rimantas.com/


From mjs at apple.com  Tue Nov  4 11:45:32 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 04 Nov 2008 11:45:32 -0800
Subject: [whatwg] ---
In-Reply-To: <38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
Message-ID: <0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>


On Nov 4, 2008, at 10:07 AM, Pentasis wrote:

> Ok, let's try to get the "heat" off of this discussion. Let me try  
> to explain it.
>
> The HTML spec consists of several parts. Some of these parts are  
> indeed browsers spcific, like the DOM, the rendering engine, etc.
> But the other part is pure semantics. It is about marking up content.
>
> I agree that the first part should be done by UA vendors, but I  
> strongly oppose that the second part is done by them as well. That  
> should be done by linguistics, typographs, and people who have to  
> actually create the content.
>
> The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies  
> on the browser part. I understand, after all that is your job and I  
> am sure you are all very capable of that. But please, let the actual  
> markup language itself be defined by others who are more capable of  
> doing that.

The HTML5 spec is open to feedback from linguists, typographers and  
content creators. I would agree we should particularly give  
consideration to people with those backgrounds with regards to issues  
of semantics. On the other hand, there is not total freedom here  
because some choices will result in conflict with Web compatibility or  
with practical implementation concerns.

Do you have any specific concerns about the current spec? That would  
be more useful than criticizing the design process in the abstract.

Regards,
Maciej


From ian at hixie.ch  Tue Nov  4 12:37:18 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 4 Nov 2008 20:37:18 +0000 (UTC)
Subject: [whatwg] ---
In-Reply-To: <0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
Message-ID: <Pine.LNX.4.62.0811042023470.1041@hixie.dreamhostps.com>

On Tue, 4 Nov 2008, Pentasis wrote:
> 
> Who ever said that the standards are here for browsers?

The HTML5 spec exists for a number of groups, primarily Web authors (and 
people writing tutorials for Web authors), Web browser implementors, tool 
implementors, and validator implementors. Roughly in that order.


> You mention the DOM for example. Good, the DOM is a way of describing 
> how HTML can be implemented in a browser. If you as browser vendors want 
> to describe that and agree upon it amongst yourselves...fine, I would 
> welcome that. But I fail to see why this means you have any right to 
> change HTML itself in the process.

We don't really have a "right" to write HTML anymore than anyone else, but 
in our version of HTML, we're making sure that the rules for browsers are 
defined along with the rules for Web authors. It's part of our effort. 
Making sure the DOM aspects of this are well-defined is a key part of this 
process, so we have phrased HTML5 such that it is actually defined in 
terms of the DOM.


> If you want a standard that describes how browsers or UAs in general 
> must deal with HTML than write THAT standard, but leave HTML out of it 
> please.

HTML5 is, amongst other things, that standard.


On Tue, 4 Nov 2008, Pentasis wrote:
> 
> Like I said, I fully understand that UAs must have a standard construct 
> to be able to deal with markup. But that does by no means mean that they 
> should have control over the markup itself.

Indeed, browser vendors are just one of many groups of people who are 
involved in this effort.


On Tue, 4 Nov 2008, Pentasis wrote:
> 
> The HTML spec consists of several parts. Some of these parts are indeed 
> browsers spcific, like the DOM, the rendering engine, etc. But the other 
> part is pure semantics. It is about marking up content.
> 
> I agree that the first part should be done by UA vendors, but I strongly 
> oppose that the second part is done by them as well. That should be done 
> by linguistics, typographs, and people who have to actually create the 
> content.

Input from everyone is welcome.


> The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on 
> the browser part. I understand, after all that is your job and I am sure 
> you are all very capable of that.

HTML5's emphasis appears to be on the browser part only because that part 
is more complex than other parts. (I can't speak for the other specs, 
though I wouldn't say that they are really browser-emphasised.)


> But please, let the actual markup language itself be defined by others 
> who are more capable of doing that.

We welcome input from everyone.


Incidentally, I'd like to remind everyone that conversations on this list 
have to remain civil and everyone should be treated with respect, 
regardless of their opinions. If people are rude, I will take action.

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


From jonas at sicking.cc  Tue Nov  4 14:11:59 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 04 Nov 2008 14:11:59 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
Message-ID: <4910C8AF.3000404@sicking.cc>

> Here's an example in code:
> 
> // dedicated workers (outside)
> var worker = new Worker("foo.js");
> var port = worker.connect();
> port.onmessage = function() { }
> port.postMessage("ping");
> 
> // dedicated workers (inside)
> onconnect = function(e) {
>   e.port.onmessage = function(e) {
>     e.port.postMessage("pong");
>   }
> }
> 
> Shared workers are exactly the same except the constructor is
> SharedWorker("foo.js", "foo");
> 
> Note that I do not think it is necessary to implement this all at
> once. For one, the SharedWorker constructor could easily be punted for
> future releases.
> 
> Thoughts?

My main concern is that I think this makes the most simple use case a 
bit too complicated. In the case when you have a dedicated worker that 
you want to offload some calculations too you need quite a bit of code 
to set up that communication.

With the current API you'd do the following:

main.js:
w = new Worker('worker.js');
w.postMessage(17);
w.onmessage = function(e) {
   answer = e.data;
}

worker.js:
function heavyCalulation(inValue) {
   ...
}
onmessage = function(e) {
   postMessage(heavyCalculation(e.data));
}


With the proposed API:

main.js:
w = new Worker('worker.js');
p = w.connect();
p.postMessage(17);
p.onmessage = function(e) {
   answer = e.data;
}

worker.js:
function heavyCalulation(inValue) {
   ...
}
onconnect = function(e) {
   e.port.onmessage = function(e2) {
     e.port.postMessage(heavyCalulation(e2.data));
   }
}


This complexity I feel is extra bad since I suspect the simple case is 
going to be the common case (I know we disagree there). I especially 
dislike the fact that you have to wait for two events, first a 'connect' 
event and then the actual message event. This seems overly complex for 
the simple case of simply wanting to use a single communication channel 
with a dedicated worker. And even though there isn't that much more code 
in my example above, it took significantly more effort to get it right 
given the nested two handlers that were needed.

So I think we should keep the simple case of a dedicated worker and a 
single communication channel as simple as possible. This means that I 
think we should keep postMessage/onmessage available on the dedicated 
worker directly, as well as the dedicated worker global scope.

As an added bonus this keeps things very similar to message passing 
between windows.


I'm fine with removing things like 'startConversation' and the implicit 
call to connect() on shared workers. 'startConversation' isn't really a 
new communication mechanism, but rather a convenience method on top of 
postMessage.

/ Jonas


From jonas at sicking.cc  Tue Nov  4 14:45:20 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 04 Nov 2008 14:45:20 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <4910C8AF.3000404@sicking.cc>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
Message-ID: <4910D080.4090509@sicking.cc>

Jonas Sicking wrote:
>> Here's an example in code:
>>
>> // dedicated workers (outside)
>> var worker = new Worker("foo.js");
>> var port = worker.connect();
>> port.onmessage = function() { }
>> port.postMessage("ping");
>>
>> // dedicated workers (inside)
>> onconnect = function(e) {
>>   e.port.onmessage = function(e) {
>>     e.port.postMessage("pong");
>>   }
>> }
>>
>> Shared workers are exactly the same except the constructor is
>> SharedWorker("foo.js", "foo");
>>
>> Note that I do not think it is necessary to implement this all at
>> once. For one, the SharedWorker constructor could easily be punted for
>> future releases.
>>
>> Thoughts?
> 
> My main concern is that I think this makes the most simple use case a 
> bit too complicated. In the case when you have a dedicated worker that 
> you want to offload some calculations too you need quite a bit of code 
> to set up that communication.
> 
> With the current API you'd do the following:
> 
> main.js:
> w = new Worker('worker.js');
> w.postMessage(17);
> w.onmessage = function(e) {
>   answer = e.data;
> }
> 
> worker.js:
> function heavyCalulation(inValue) {
>   ...
> }
> onmessage = function(e) {
>   postMessage(heavyCalculation(e.data));
> }
> 
> 
> With the proposed API:
> 
> main.js:
> w = new Worker('worker.js');
> p = w.connect();
> p.postMessage(17);
> p.onmessage = function(e) {
>   answer = e.data;
> }
> 
> worker.js:
> function heavyCalulation(inValue) {
>   ...
> }
> onconnect = function(e) {
>   e.port.onmessage = function(e2) {
>     e.port.postMessage(heavyCalulation(e2.data));
>   }
> }
> 
> 
> This complexity I feel is extra bad since I suspect the simple case is 
> going to be the common case (I know we disagree there). I especially 
> dislike the fact that you have to wait for two events, first a 'connect' 
> event and then the actual message event. This seems overly complex for 
> the simple case of simply wanting to use a single communication channel 
> with a dedicated worker. And even though there isn't that much more code 
> in my example above, it took significantly more effort to get it right 
> given the nested two handlers that were needed.
> 
> So I think we should keep the simple case of a dedicated worker and a 
> single communication channel as simple as possible. This means that I 
> think we should keep postMessage/onmessage available on the dedicated 
> worker directly, as well as the dedicated worker global scope.
> 
> As an added bonus this keeps things very similar to message passing 
> between windows.
> 
> 
> I'm fine with removing things like 'startConversation' and the implicit 
> call to connect() on shared workers. 'startConversation' isn't really a 
> new communication mechanism, but rather a convenience method on top of 
> postMessage.

So Hixie brought up a good point on IRC, there really is only one 
communication mechanism, which is postMessage/onmessage.

I'd note that if we drop startConversation (which it seems like no-one 
is opposing) then all proposals have two 'communication' mechanisms: 
postMessage and connect.

With Aarons proposal you have to both for a shared worker and a 
dedicated worker use both mechanisms; first call connect() and then call 
postMessage(). If keep postMessage on the dedicated worker the only 
difference is that for a dedicated worker you skip the connect() and go 
directly to postMessage.

/ Jonas


From martin at weborganics.co.uk  Tue Nov  4 16:42:30 2008
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Wed, 05 Nov 2008 00:42:30 +0000
Subject: [whatwg] ---
In-Reply-To: <5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
Message-ID: <4910EBF6.9020001@weborganics.co.uk>

Pentasis wrote:
> Who ever said that the standards are here for browsers?????????
Tim Berners-Lee  apparently when he introduced a bunch of technologies 
such as HTTP, HTML FTP, IP TCIP and others and called it the World Wide 
Web, closely followed by the Mosaic Web Browser[1] a direct descendant 
of Firefox ;-)

[http://en.wikipedia.org/wiki/Mosaic_(web_browser)]


-- 
Martin McEvoy

http://weborganics.co.uk/



From sam.kuper at uclmail.net  Tue Nov  4 17:30:25 2008
From: sam.kuper at uclmail.net (Sam Kuper)
Date: Wed, 5 Nov 2008 01:30:25 +0000
Subject: [whatwg] ---
In-Reply-To: <4910EBF6.9020001@weborganics.co.uk>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<4910EBF6.9020001@weborganics.co.uk>
Message-ID: <4126b3450811041730v25d5ee22g60c174d8d4126971@mail.gmail.com>

2008/11/5 Martin McEvoy <martin at weborganics.co.uk>:
>[...]
> closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox

Ancestor, surely?


From timeless at gmail.com  Tue Nov  4 23:05:42 2008
From: timeless at gmail.com (timeless)
Date: Wed, 5 Nov 2008 09:05:42 +0200
Subject: [whatwg] ---
In-Reply-To: <4910EBF6.9020001@weborganics.co.uk>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<4910EBF6.9020001@weborganics.co.uk>
Message-ID: <26b395e60811042305w34891c8eh299e24376d0a6034@mail.gmail.com>

On Wed, Nov 5, 2008 at 2:42 AM, Martin McEvoy <martin at weborganics.co.uk> wrote:
> Tim Berners-Lee  apparently when he introduced a bunch of technologies such
> as HTTP, HTML FTP, IP TCIP and others and called it the World Wide Web,
> closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox
> ;-)
>
> [http://en.wikipedia.org/wiki/Mosaic_(web_browser)]

Netscape got the engineering team which made mosaic, hence Mozilla
(mosaic killer). But the engine actually is more directly related to
Internet Explorer.

http://en.wikipedia.org/wiki/Internet_Explorer#History


From tommy at kvaleberg.com  Wed Nov  5 00:45:00 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Wed, 05 Nov 2008 09:45:00 +0100
Subject: [whatwg] "end body tag" parsing clarification
Message-ID: <49115D0C.8010906@kvaleberg.no>

I've been looking at the parsing chapter of the HTML5 specification, and 
I've found something which I don't think makes sense. The last two 
sentences in the 'An end tag whose tag name is "body"' section in the 
"in body" insertion mode says:

   Switch the insertion mode to "after body". Otherwise, ignore the token.

The "Otherwise" does not really make sense in this context, does it? 
Should that last sentence just be erased?

Regards,
Tommy Thorsen


From pentasis at lavabit.com  Wed Nov  5 00:46:19 2008
From: pentasis at lavabit.com (Pentasis)
Date: Wed, 5 Nov 2008 10:46:19 +0200
Subject: [whatwg] ---
In-Reply-To: <0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
Message-ID: <5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>

>
> The HTML5 spec is open to feedback from linguists, typographers and 
> content creators. I would agree we should particularly give  consideration 
> to people with those backgrounds with regards to issues  of semantics. On 
> the other hand, there is not total freedom here  because some choices will 
> result in conflict with Web compatibility or  with practical 
> implementation concerns.
>
> Do you have any specific concerns about the current spec? That would  be 
> more useful than criticizing the design process in the abstract.
>

I would be more than willing to do so, but only if these ideas are taken 
seriously and we can have a civil, open dicussion about it without going 
into defensive  mode or side-arguments.
First of all, I want to make it absolutely clear that these ideas are 
strictly dealing with context and semantics. I do not wish to interfere in 
the technical part of the spec. I do understand that sometimes there are 
ideas that may involve technical solutions. My first and foremost concern is 
about having a specification that deals with the naming of elements and 
their usage in such a way that this would give us a standard which will 
enable us to markup content consistantly and flexibally without ambiguity, 
and which is flexible enough to act on-the-fly (so we don't have to wait for 
the next version of the spec if something is missing).
also, please keep in mind I am not a native english speaker. I sometimes 
have difficulty explaining exactly what I mean. If something is unclear, 
just say so.
Finally, the ideas portrait below are just that. Ideas. I don't feel 
strongly about the actual ideas themself, but I do feel strongly about the 
mechanism they represent.


The best way of explaining what I mean is by talking about the inline text 
elements, but the concept is the same for all element (apart from maybe the 
metadata group).

What the spec currently does is:
1) *exactly* defining some elements
2) Giving examples for *some* constructions whcih are not defined exactly
3) not talk about other things.

Like I have said before, the problem is that nobody can think up all 
possible type of semantic/content/context in existance (let alone those who 
are thought up).
The only solution would be by creating a type of classification methode. 
Partly this is allready there (block, inline, text, structure, etc.). But 
this should be done one more level down.

For example:

abbr, dfn, cite are all the same "type" of "word". Why not remove them and 
replace them with something like <reference> (just an example!).
Then use the class attribute to define the actual role (class="abbreviation" 
etc.). In other words, implement the microformats on  a much wider base as 
part of the standard.
These classifications can then be requested and implemented outside of the 
spec in an open forum.A process which should be fast and more structurised 
than it is currently.
The same applies for em and strong. Not sure hwo these should eb classified, 
but I think they are used to change a word or group of word in context. So 
perhaps a <contxt> tag? sup and sub would also fall in this catagory 
(technically speaking sup and sub are style elements).
pre is also a style element. Why not simply use <p> and style it 
preformatted if needed depending on the role it has?

<var> is the best example I think. Why <var> but not <function> <operator> 
<operand> etc. etc. etc.? And if code gets this attention why not language? 
(<verb>, <noun> etc. etc.) If we do it like that it would never work.

So, the general idea is to classify all all elements as high up the 
classification-tree as possible, and then allow subclassing in the 
class-attribute. Main classes would be specified in the standard, and 
sub-classes are specified in an open list which can act upon need on a 
practical basis. (I understand the need for such a list to be maintained on 
a consistent level, something like that could be defined in the standard as 
well).

Apart from this classification system I think there are other points where 
the spec could be improved, but this classification system I think is the 
most important. I understand that it is based on microformats and is not 
new, I am not claiming some new revolutionary idea here, simply trying to 
point out the advantages of doing it like that.

I will leave other ideas for later (if you want)

Bert 




From martin at weborganics.co.uk  Wed Nov  5 01:13:06 2008
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Wed, 05 Nov 2008 09:13:06 +0000
Subject: [whatwg] ---
In-Reply-To: <4126b3450811041730v25d5ee22g60c174d8d4126971@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>	
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>	
	<4910EBF6.9020001@weborganics.co.uk>
	<4126b3450811041730v25d5ee22g60c174d8d4126971@mail.gmail.com>
Message-ID: <491163A2.3050201@weborganics.co.uk>

Sam Kuper wrote:
> 2008/11/5 Martin McEvoy <martin at weborganics.co.uk>:
>   
>> [...]
>> closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox
>>     
>
> Ancestor, surely?
>   

LOL yes


-- 
Martin McEvoy

http://weborganics.co.uk/



From martin at weborganics.co.uk  Wed Nov  5 01:24:56 2008
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Wed, 05 Nov 2008 09:24:56 +0000
Subject: [whatwg] ---
In-Reply-To: <26b395e60811042305w34891c8eh299e24376d0a6034@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>	
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>	
	<4910EBF6.9020001@weborganics.co.uk>
	<26b395e60811042305w34891c8eh299e24376d0a6034@mail.gmail.com>
Message-ID: <49116668.9060509@weborganics.co.uk>

timeless wrote:
> On Wed, Nov 5, 2008 at 2:42 AM, Martin McEvoy <martin at weborganics.co.uk> wrote:
>   
>> Tim Berners-Lee  apparently when he introduced a bunch of technologies such
>> as HTTP, HTML FTP, IP TCIP and others and called it the World Wide Web,
>> closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox
>> ;-)
>>
>> [http://en.wikipedia.org/wiki/Mosaic_(web_browser)]
>>     
>
> Netscape got the engineering team which made mosaic, hence Mozilla
> (mosaic killer). But the engine actually is more directly related to
> Internet Explorer.
>
> http://en.wikipedia.org/wiki/Internet_Explorer#History
>   
IE and FF are both related to Mosaic ;-)   see:

http://en.wikipedia.org/wiki/Spyglass,_Inc.#The_Browser_Wars


-- 
Martin McEvoy

http://weborganics.co.uk/



From pentasis at lavabit.com  Wed Nov  5 01:36:31 2008
From: pentasis at lavabit.com (Pentasis)
Date: Wed, 5 Nov 2008 11:36:31 +0200
Subject: [whatwg] ---
In-Reply-To: <Pine.LNX.4.62.0811042023470.1041@hixie.dreamhostps.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<Pine.LNX.4.62.0811042023470.1041@hixie.dreamhostps.com>
Message-ID: <4F1C308219174E1CA75F9EE95AD1438E@Sanktum01>

>
>> The emphasis of the HTML5 spec (but also the XHTML2 and HTML4) lies on
>> the browser part. I understand, after all that is your job and I am sure
>> you are all very capable of that.
>
> HTML5's emphasis appears to be on the browser part only because that part
> is more complex than other parts. (I can't speak for the other specs,
> though I wouldn't say that they are really browser-emphasised.)
>

Sematics, linguistics, typography etc. etc. are pretty damned complex too. 
Now, this does by no means mean that the semantic part of HTML should comply 
to that complexity. All I am saying is that because it is so complex we need 
people who can simplify it. And that is something that has nothing to do 
with browser technology. A quick example: In language you have "rhetorics". 
According to wikipedia there are two types of rhetorics in english (schemes 
and tropes). But there are languages that have more types, how to deal with 
that?
(if you are wondering what use rhetorics would have in HTML, think of words 
like "erm", "whoa", "tjirp" in combination with accessibility.)

Bert 




From hsivonen at iki.fi  Wed Nov  5 02:11:56 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 5 Nov 2008 12:11:56 +0200
Subject: [whatwg] ---
In-Reply-To: <5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>
Message-ID: <134DC4C5-AEB5-4288-AFEB-ABD86C950C4B@iki.fi>

On Nov 5, 2008, at 10:46, Pentasis wrote:

> <var> is the best example I think. Why <var> but not <function>  
> <operator> <operand> etc. etc. etc.? And if code gets this attention  
> why not language? (<verb>, <noun> etc. etc.) If we do it like that  
> it would never work.


<var>, <cite> and <dfn> (and, one might argue, <em>) are legacy  
elements flowing out of a desire to replace <i> with something  
"semantic".

Since the elements are part of the HTML legacy, there isn't a great  
rationale that would justify their inclusion today if they had never  
been in HTML and were proposed as new elements now.

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




From derernst at gmx.ch  Wed Nov  5 02:22:02 2008
From: derernst at gmx.ch (Markus Ernst)
Date: Wed, 05 Nov 2008 11:22:02 +0100
Subject: [whatwg] ---
In-Reply-To: <5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>
Message-ID: <491173CA.9070506@gmx.ch>

Pentasis schrieb:
>>
>> The HTML5 spec is open to feedback from linguists, typographers and 
>> content creators. I would agree we should particularly give  
>> consideration to people with those backgrounds with regards to issues  
>> of semantics. On the other hand, there is not total freedom here  
>> because some choices will result in conflict with Web compatibility 
>> or  with practical implementation concerns.
>>
>> Do you have any specific concerns about the current spec? That would  
>> be more useful than criticizing the design process in the abstract.
>>
> 
> I would be more than willing to do so, but only if these ideas are taken 
> seriously and we can have a civil, open dicussion about it without going 
> into defensive  mode or side-arguments.
> First of all, I want to make it absolutely clear that these ideas are 
> strictly dealing with context and semantics. I do not wish to interfere 
> in the technical part of the spec. I do understand that sometimes there 
> are ideas that may involve technical solutions. My first and foremost 
> concern is about having a specification that deals with the naming of 
> elements and their usage in such a way that this would give us a 
> standard which will enable us to markup content consistantly and 
> flexibally without ambiguity, and which is flexible enough to act 
> on-the-fly (so we don't have to wait for the next version of the spec if 
> something is missing).
> also, please keep in mind I am not a native english speaker. I sometimes 
> have difficulty explaining exactly what I mean. If something is unclear, 
> just say so.
> Finally, the ideas portrait below are just that. Ideas. I don't feel 
> strongly about the actual ideas themself, but I do feel strongly about 
> the mechanism they represent.

[ideas snipped]

If I understand you correctly, you suggest a very basic set of 
structural elements, which are to be flexibally qualified by the authors 
via the class attribute. The composition of that set should follow some 
kind of basic language logic.

If I understand HTML correctly, it provides a limited set of 
pre-qualified elements, some of them with a more structural emphasis, 
some of them with a more semantic (or or even presentational) one. The 
composition of that set does not follow a higher logic, but the everyday 
needs of the common web author (or what the writers of the spec assume 
this is).

(I hope this is understandable; I am not a native English speaker, either.)

So, supposed I got these both correctly, you do not really talk about 
HTML, but about an alternative approach of marking up text documents. I 
personnally find thinking about alternative approaches very interesting 
and useful for opening up one's mind.

I agree with you that there are many things in HTML that have a purely 
historic legitimation, such as the h1-h6 elements. <h level="n"> would 
be much more flexible. I personnally often get mad about the IMO totally 
unlogic set of form elements. I would highly appreciate such thigs to be 
cleaned up in a new HTML spec. But of course the task ot those who 
design HTML5 is not to re-invent the wheel, but to evolve the existing 
HTML in a highly backwards-compatible way.

I made the experience when I suggested a new set of form elements, that 
I did not get much response on those contributions. The same might 
happen to your suggestions, as they are on a more basic level, than the 
HTML5 works act on. I don't think you can blame the people working on 
HTML5 for this, as they are quite far in the process, and your 
suggestions do rather set new starting points, than contribute to the 
acutal state of the work.


From pentasis at lavabit.com  Wed Nov  5 02:32:06 2008
From: pentasis at lavabit.com (Pentasis)
Date: Wed, 5 Nov 2008 12:32:06 +0200
Subject: [whatwg] SPOOFED: Re:  ---
In-Reply-To: <491173CA.9070506@gmx.ch>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>
	<491173CA.9070506@gmx.ch>
Message-ID: <D349B3A754FD40C2ADA8677192466CED@Sanktum01>

> I made the experience when I suggested a new set of form elements, that I 
> did not get much response on those contributions. The same might happen to 
> your suggestions, as they are on a more basic level, than the HTML5 works 
> act on. I don't think you can blame the people working on HTML5 for this, 
> as they are quite far in the process, and your suggestions do rather set 
> new starting points, than contribute to the acutal state of the work.

This I understand, and I can even sympathise with it. However, I do hope 
that at least "they" will take this issue seriously and at least try to 
build in something that will enable "us" to work on that part of the spec 
independantly later on. I still think that the semantic part has very, very 
little to do with the technical side of the spec. so somewhere the two 
should be able to split up.
Just to give you a comparative example: what if wordprocessor manufacturers 
were to start writing a spec that enabled them to standardise their native 
document format. Would you agree to the premise that that would mean that 
they had to take control of dictionaries and grammer?
I don't want to imply that this is what happening here, but like you said, 
historically the two have been interlinked with each other in HTML, but IMO 
the time has come to AT LEAST THINK about the possiblity that they 
shouldn't.

Bert 




From derernst at gmx.ch  Wed Nov  5 03:15:56 2008
From: derernst at gmx.ch (Markus Ernst)
Date: Wed, 05 Nov 2008 12:15:56 +0100
Subject: [whatwg] SPOOFED: Re:  ---
In-Reply-To: <D349B3A754FD40C2ADA8677192466CED@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>	<491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01>
Message-ID: <4911806C.6070101@gmx.ch>

Pentasis schrieb:
> This I understand, and I can even sympathise with it. However, I do hope 
> that at least "they" will take this issue seriously and at least try to 
> build in something that will enable "us" to work on that part of the 
> spec independantly later on. I still think that the semantic part has 
> very, very little to do with the technical side of the spec. so 
> somewhere the two should be able to split up.

I am not sure whether I understand you correctly... Of course the 
practical use of a specification lies in its technical implementations, 
or do you disagree with that? You are free to specify your own markup 
language, but it will be useless if there is no kind of mechanism to 
interpret the documents marked up that way. So I don't understand how 
the technical side could be split away.


From pentasis at lavabit.com  Wed Nov  5 03:29:44 2008
From: pentasis at lavabit.com (Pentasis)
Date: Wed, 5 Nov 2008 13:29:44 +0200
Subject: [whatwg] SPOOFED: Re:  SPOOFED: Re:  ---
In-Reply-To: <4911806C.6070101@gmx.ch>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>	<491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01>
	<4911806C.6070101@gmx.ch>
Message-ID: <2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>


> Pentasis schrieb:
>> This I understand, and I can even sympathise with it. However, I do hope 
>> that at least "they" will take this issue seriously and at least try to 
>> build in something that will enable "us" to work on that part of the spec 
>> independantly later on. I still think that the semantic part has very, 
>> very little to do with the technical side of the spec. so somewhere the 
>> two should be able to split up.
>
> I am not sure whether I understand you correctly... Of course the 
> practical use of a specification lies in its technical implementations, or 
> do you disagree with that? You are free to specify your own markup 
> language, but it will be useless if there is no kind of mechanism to 
> interpret the documents marked up that way. So I don't understand how the 
> technical side could be split away.

Strictly speaking, does it matter for the DOM or parser or whatever, if a 
tag is named and used like: <abbr title="description">someword</abbr> or 
like this:
<reference class="abbreviation" ttle="some 
description">someword</reference>.
I don't see how that would make things technically different?
The same applies for the difference in (for example) <code>blabla</code> or 
<p class=code>blabla</p>.

Obviously there are constructs thinkable where the two would indeed at least 
rub shoulders like for example in nesting headers, but I am sure something 
like that is not a major issue and would only mean the two specs need to 
come to agreement with somethings like that.
Another example (just a thought, don't take it seriously) What if we 
eliminate headers alltogether and specify that the title attribute of a 
section is the header. Now, in that case I agree one should colaborate with 
the technical department. But in the grand scheme of things, those are minor 
points surely?

Bert 




From ap at webkit.org  Wed Nov  5 06:56:42 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Wed, 5 Nov 2008 17:56:42 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <4910C8AF.3000404@sicking.cc>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
Message-ID: <F663827F-B945-4254-B37E-48419938D9C4@webkit.org>


Nov 5, 2008, ? 1:11 AM, Jonas Sicking ???????(?):

> main.js:
> w = new Worker('worker.js');
> p = w.connect();
> p.postMessage(17);
> p.onmessage = function(e) {
>  answer = e.data;
> }


I prefer to think of it as:

window.onload = function() {
     var worker = new Worker('encrypt.js');
     var workerPort = worker.connect();
     workerPort.onmessage = processWorkerReply;
}

function spawnEncryptData(id, data) {
    workerPort.postMessage("encrypt " + id + " " + data);
}

Aside from one time setup (which usually needs to be performed in  
advance), the "simple case" looks no different, but there is no  
confusion about which port to use.

- WBR, Alexey Proskuryakov



From leons.petrazickis at gmail.com  Wed Nov  5 07:00:56 2008
From: leons.petrazickis at gmail.com (Leons Petrazickis)
Date: Wed, 5 Nov 2008 10:00:56 -0500
Subject: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
In-Reply-To: <2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01> <491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01> <4911806C.6070101@gmx.ch>
	<2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
Message-ID: <5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>

On Wed, Nov 5, 2008 at 6:29 AM, Pentasis <pentasis at lavabit.com> wrote:
>> I am not sure whether I understand you correctly... Of course the
>> practical use of a specification lies in its technical implementations, or
>> do you disagree with that? You are free to specify your own markup language,
>> but it will be useless if there is no kind of mechanism to interpret the
>> documents marked up that way. So I don't understand how the technical side
>> could be split away.
>
> Strictly speaking, does it matter for the DOM or parser or whatever, if a
> tag is named and used like: <abbr title="description">someword</abbr> or
> like this:
> <reference class="abbreviation" ttle="some
> description">someword</reference>.
> I don't see how that would make things technically different?
> The same applies for the difference in (for example) <code>blabla</code> or
> <p class=code>blabla</p>.

It matters in the sense that web browsers would have to implement both
approaches for backwards compatibility. Web site developers would then
be given a choice between a succinct approach that works in all
browsers and a verbose approach that only works in the newer ones.
Given such a choice, web site developers mostly prefer brevity and
compatibility, especially when working for a client.

Any change that tries to replace an existing feature with a more
complicated feature will likely not be adopted de facto, even if it is
enshrined in a de jure standard.

Standards that have tried to make changes like that -- XHTML2 comes to
mind -- have not been as successful as HTML4, as the loose dialect of
HTML4 in use on the web. HTML5 aims to be as successful as HTML4.
Adoption and usability are the twin goals -- not purity or
consistency.

This works everywhere and is brief:
<abbr title="description">someword</abbr>

This would only work in new browsers and is wordy:
<reference class="abbreviation" ttle="some description">someword</reference>.

It doesn't add any extra information. It's harder to use.
Conceptually, it may be more elegant, but conceptual elegance is not
an impetus for large scale adoptions. In my opinion, it is not a
worthwhile change to pursue, when there are so many actively broken
issues that can be fixed.

Regards,

Leons Petrazickis
http://lpetr.org/blog/


From ian at hixie.ch  Wed Nov  5 07:20:25 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 Nov 2008 15:20:25 +0000 (UTC)
Subject: [whatwg] [WF2] |min| and |max| number of selected |option|s
In-Reply-To: <865CD5B4-851A-4977-9859-A5F7CD9D1495@crissov.de>
References: <865CD5B4-851A-4977-9859-A5F7CD9D1495@crissov.de>
Message-ID: <Pine.LNX.4.62.0811051519020.1237@hixie.dreamhostps.com>

On Sat, 31 May 2008, Christoph P?per wrote:
> 
> When using
> 
>   <input type=checkbox>
> 
> or
> 
>   <select multiple>
> 
> one somtimes wants to limit the number of selected check boxes or 
> options. I have no idea how to model this with |input|, but |select| 
> could adopt the |min| and |max| attributes. They would not limit the 
> content of |value| but the number of selected |option|s, which is 
> similar to what is already specified for file upload controls. A common 
> and special case would be setting the same value on both attributes to 
> require a certain number of options to be selected.
> 
> I'd really like it if someone could come up with a way to make this work 
> with |input|, too.

Since this is a pretty specialised desire, and not one that we really want 
to encourage (it's somewhat sub-optimal UI), I think this is something we 
should leave up to scripts to enforce, using oninput="", 
setCustomValidity(), and so forth.

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

From ian at hixie.ch  Wed Nov  5 07:32:41 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 Nov 2008 15:32:41 +0000 (UTC)
Subject: [whatwg] Errormessages in forms
In-Reply-To: <4884D7DC.7030909@keryx.se>
References: <4884D7DC.7030909@keryx.se>
Message-ID: <Pine.LNX.4.62.0811051523410.1237@hixie.dreamhostps.com>

On Mon, 21 Jul 2008, Keryx Web wrote:
> 
> A simple use case: It is getting quite common to have the following:
> 
> <label for="myfield">Instructions
>   <strong class="error"> Must be a valid  value</strong>
> </label>
> <input id="myfield" etc />
>
> But presentationwise it should be displayed like this:
> 
> Instructions  [ (input) ] Must be a valid value

What's wrong with?:

   <label>
     Instructions
     <input name="idfield" ...>
     <strong class="error"> Must be a valid value </strong>
   </label>


> And by adding a new element the following two additional benefits could 
> be achieved:
> 
> 1. A default hook for errormessages from the UA. I.e. if a field has an 
> associated errormsg-element the UA knows exactly where to put its 
> messages.

Opera seems to use a pop-up UI, which seems fine, and less likely to 
cause problems.


> 2. Assistive technology can use this additional semantics and it is not 
> hard to imagine how that could lead to better user experiences.

It's not clear to me how.

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


From ian at hixie.ch  Wed Nov  5 07:44:05 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 Nov 2008 15:44:05 +0000 (UTC)
Subject: [whatwg] Form submission progress display by UA (incl. file
 upload)
In-Reply-To: <4798A7EA.6010702@peda.net>
References: <4798A7EA.6010702@peda.net>
Message-ID: <Pine.LNX.4.62.0811051534590.1237@hixie.dreamhostps.com>

On Thu, 24 Jan 2008, Mikko Rantalainen wrote:
>
> Consider a form with a file input. User selects a huge file and hits 
> submit. Most UAs do not display nothing but an animated throbber until 
> the full submit is done and the download progress bar only starts to do 
> anything after the full submit part is already done. An another example 
> could be a long blog article that is being sent over an GPRS mobile 
> connection (with common speeds around 9kbps).
> 
> I think that WF2 section 5.6 
> (http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes) 
> should be modified to say something along the lines
> 
> "User agents with interactive user interfaces should inform the user 
> about the progress of the data submission. For example, an UA with a 
> graphical user interface could display a visual progress bar which would 
> be updated once every second; the bar would be initially displayed as 
> empty and would fill over time as the encoded form data set is 
> transmitted. For transmissions that take more than a few seconds UA 
> might in addition display estimated time before done."
> 
> Rationale: Upload progress monitoring is becoming more important every 
> day as browsers are often used for content authoring, the digital 
> content gets bigger and common user connections are highly asymmetric 
> (e.g. 24mbps downstream, 1mbps upstream in case of ADSL2+). The delay 
> expected by the user for sending a 100MB file could be close to 
> downloading a 100MB which is not the reality. An user in a hurry would 
> hit stop button and retry again after waiting for some time without 
> knowing that upload is in progress.

I don't think we really should be saying anything about UI to this level 
of detail. We don't say that there should be a progress bar when the page 
loads, either. I recommend petitioning your UA implementor to add this.

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


From pentasis at lavabit.com  Wed Nov  5 08:01:02 2008
From: pentasis at lavabit.com (Pentasis)
Date: Wed, 5 Nov 2008 18:01:02 +0200
Subject: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
In-Reply-To: <5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>
	<491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01>
	<4911806C.6070101@gmx.ch>
	<2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
	<5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
Message-ID: <022ADA760ACA468EB5D0B6945FF7E9E5@Sanktum01>

>
> This would only work in new browsers and is wordy:
> <reference class="abbreviation" ttle="some 
> description">someword</reference>.
>
> It doesn't add any extra information. It's harder to use.
> Conceptually, it may be more elegant, but conceptual elegance is not
> an impetus for large scale adoptions. In my opinion, it is not a
> worthwhile change to pursue, when there are so many actively broken
> issues that can be fixed.
>
>

True, it doesn't provide any extra information, and perhaps it is harder to 
use, but that is not the point. The point is that this tag can be used to 
mark up any possible reference-type word (notes, sidenotes, footnotes, 
translations, meanings, definitiones, you name all of them and then some). 
So with just one tag, I catch all possible semantics within a classified 
wordgroup.
That (or something similar) is what creates room for natural growth and 
evolution of contextual semantics on a medium (Internet) that is still 
developing and very dynamic.

Bert 




From vetesnik at mrmil.cz  Wed Nov  5 08:10:58 2008
From: vetesnik at mrmil.cz (=?iso-8859-2?B?T2xk+GljaCBWZXRluW7taw==?=)
Date: Wed, 05 Nov 2008 17:10:58 +0100
Subject: [whatwg] Errormessages in forms
In-Reply-To: <Pine.LNX.4.62.0811051523410.1237@hixie.dreamhostps.com>
References: <4884D7DC.7030909@keryx.se>
	<Pine.LNX.4.62.0811051523410.1237@hixie.dreamhostps.com>
Message-ID: <op.uj5lwkoro84pey@pc08.ebrana.cz>

Dne Wed, 05 Nov 2008 16:32:41 +0100 Ian Hickson <ian at hixie.ch> napsal/-a:

> What's wrong with?:
>
>    <label>
>      Instructions
>      <input name="idfield" ...>
>      <strong class="error"> Must be a valid value </strong>
>    </label>

Hello, let me just react on this,
first of all I don't mind using this solution, I want to share an opinion  
though:

This solution doesn't work in IE6, you'd have to add the "for" attribute:

<label for="idfield">
   Instructions
   <input name="idfield" id="idfield">
   <strong class="error"> Must be a valid value </strong>
</label>

which is totally O.K. but just from a point of view, input is not a label,  
nor the error message is. I may need to wrap the text into another element  
for floating purposes though:

<label for="idfield">
   <span class="label">Instructions</span>
   <input name="idfield" id="idfield">
   <strong class="error"> Must be a valid value </strong>
</label>

and here you can see the redundant coding, I'm using another element to  
mark the true label.
It would be awesome if something like this would be possible:

<label for="idfield">Instructions</label>
<input name="idfield" id="idfield">
<error for="idfield">Must be a valid value</error>

And to further enhance this futuristic view:

<label for="idfield">Instructions</label>
<input name="idfield" id="idfield">
<hint for="idfield">Type in dd-mm-yyyy format</hint>
<error for="idfield">Must be a valid value</error> (if error is true)

What do you think about it? :)


From ian at hixie.ch  Wed Nov  5 09:20:46 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 Nov 2008 17:20:46 +0000 (UTC)
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
 interface
In-Reply-To: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com>

On Sun, 10 Feb 2008, Samuel Santos wrote:
> 
> This is a problem for the input element with type="file". If the 
> language selected in his profile is, e.g. portuguese, and the language 
> in the browser is english (the default), he will see all the application 
> in portuguese and the input file browse button text value will be in 
> english.

Why is this a problem given that all the rest of the UA strings -- menus, 
for example -- will also be in the default language? Isn't it up to the 
user to pick the right language in the UA?


> What I propose is to add a new attribute to the input element like this:
>            attribute DOMString       browseText;
> this allows us developers to change the input file browse button text to
> have it in the same language as the rest of the application and not with the
> language selected in the browser.

We really don't want to allow authors to fiddle with this control, because 
it is highly security-sensitive (similarly browsers don't allow styling of 
this control).

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


From aa at google.com  Wed Nov  5 12:06:58 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 5 Nov 2008 12:06:58 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
Message-ID: <278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>

Jonas, Hixie, and I talked about this yesterday on IRC (logs start
here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
into the next day).

Jonas is still against removing postMessage/onmessage from the Worker
interface in favor of connect() only. Also, several people feel like
connect/startConversation is just a convenience and not totally
necessary.

In light of both of these, I have a new proposal for how to
simplify/combine these two interfaces. Here are the deltas from the
current spec:

* Remove startConversation() from the Worker interface
* Remove the port property from the SharedWorker interface and give it
a postMessage and onmessage just like dedicated workers have.
* Leave the interfaces for the insides of the workers as they are now

There are other options for what to do with the inside interfaces. I
would prefer that they were more normalized, but I already know that
Jonas won't like that and I am fine with this proposal.

Thoughts?

- a


From phil127 at gmail.com  Wed Nov  5 12:47:36 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Wed, 5 Nov 2008 21:47:36 +0100
Subject: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
In-Reply-To: <5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01> <491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01> <4911806C.6070101@gmx.ch>
	<2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
	<5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
Message-ID: <f042876c0811051247q7735952fm16a79b4cbee415d1@mail.gmail.com>

On Wed, Nov 5, 2008 at 4:00 PM, Leons Petrazickis
<leons.petrazickis at gmail.com> wrote:
> It matters in the sense that web browsers would have to implement both
> approaches for backwards compatibility.
>

This depends what you mean when talking about "implementing" a tag.
Browsers already load all tags and attributes they encounter into the
page DOM today , regardless if they "know" them or not. This is also
the behavior that HTML5 demands, if I'm not mistaken. Interactive
elements and "special" elements like "script", "head", "table", etc do
need further special treatment, but so far browsers seem to do little
more with semantic elements than apply a default style to them. And
sice CSS selectors have already widespread support as well, this
behavior would be trivially repeatable for new tags by web authors
themselves. So there is not that much of an implementation burden at
the moment.

>Standards that have tried to make changes like that -- XHTML2 comes to
>mind -- have not been as successful as HTML4 [...]

We can't really make any statements about how successful XHTML2 would
be on the public web. It's not yet a recommendation (though this would
probably not change much) and no browser implemented it, so there was
never opportunity to find out.

>Adoption and usability are the twin goals -- not purity or
>consistency.

Of course I fully agree that purity must not the only goal itself. The
W3C definitely went overboard with this in their latest proposals.
However, sometimes it does look as if the WHATWG takes it to the
opposite extreme and treat purity and consistency as explicit
non-goals.
If consistency hampers usabillity, usabillity is of course to be
preferred. However, I think, often the two are interrelated instead of
opposing goals. After all, each inconsistency is a new rule that
implementors have to implement and authors have to learn. This makes
the language harder to understand and actually slows down adaption.
Look at XML for the opposite story. Many people have frowned at the
mass of XML-based languages, formats and specifications that popped
up. But then again, why DID so many people create XML formats so
quickly? Because the concept of "nested tags with attributes" is
really simple to understand. Of course HTML5 has to cope with really
horrible legacy content and many inconsistencies are just there. But
we should still try not to introduce more.
And yes, I do believe <reference class="abbreviation" ...> would be
easier, because then web authors wouldn't need to remember which
semantic content can be described by tags and which needs custom
classes.

But anyway, this discussion is moot, since many of those tags can't be
changed due to backwards compatibility. Maybe someone should clarify
though how agents are supposed to use those semantic tags, especially
semantic, user-defined classes. What actual benefit do I have if I use
class="heading" instead of class="style15"?


From ap at webkit.org  Wed Nov  5 13:23:50 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Thu, 6 Nov 2008 00:23:50 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
Message-ID: <ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>


Nov 5, 2008, ? 11:06 PM, Aaron Boodman ???????(?):

> Jonas, Hixie, and I talked about this yesterday on IRC (logs start
> here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
> into the next day).
<...>
> * Remove startConversation() from the Worker interface
> * Remove the port property from the SharedWorker interface and give it
> a postMessage and onmessage just like dedicated workers have.
> * Leave the interfaces for the insides of the workers as they are now


Something that seems missing from these discussions is how the API  
changes affect semantics of worker behavior, which makes it hard to  
compare proposals. For example, having some port singled out as an  
attribute of Worker (or as an implicit hidden attribute, used by  
methods defined on Worker itself) sorta implies that closing it should  
close other ports and dispose of the worker global scope soon.  
Similarly, having separate interfaces for Worker and SharedWorker  
implies that there is some fundamental difference in their behavior -  
a difference that eludes me so far.

It would seem that we could make better progress if we had a list of  
requirements that we want to have fulfilled (e.g., should it be  
possible to easily manage worker lifetime manually by closing a  
dedicated port? or should workers strive to remain available for as  
long as any client has an open port, which helps write reliable code?).

I really don't think that the desire to save one line in a 500-line  
program should affect the design too much. Convenience methods can be  
added later, but over-engineered parts cannot be removed later. And at  
this point, I believe that  we are mostly speculating about use cases  
(probably except for Google Gears folks, who are shipping a similar  
API, and get developer feedback already).

- WBR, Alexey Proskuryakov



From ian at hixie.ch  Wed Nov  5 14:59:32 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 5 Nov 2008 22:59:32 +0000 (UTC)
Subject: [whatwg] Combining the DedicatedWorker and
	SharedWorker	interfaces
In-Reply-To: <278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811052250240.1041@hixie.dreamhostps.com>

On Wed, 5 Nov 2008, Aaron Boodman wrote:
> 
> In light of both of these, I have a new proposal for how to 
> simplify/combine these two interfaces. Here are the deltas from the 
> current spec:
> 
> * Remove startConversation() from the Worker interface

And from MessagePort, presumably?


> * Remove the port property from the SharedWorker interface and give it
> a postMessage and onmessage just like dedicated workers have.

I really don't like this. With (Dedicated)Worker it makes sense because 
both sides bury the underlying message channel and ports and so things 
like closing the port, or whether the port is active, are hidden on both 
sides. But with SharedWorker, if we only bury it on one side, there is a 
lack of symmetry that IMHO is going to lead to all kinds of issues and 
confusion. I really don't like that. If people start sending one side's 
pipe down another channel, we can end up with a situation where a 
SharedWorker object really represents a port that has nothing to do with 
the worker anymore.

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


From jonas at sicking.cc  Wed Nov  5 15:18:32 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 05 Nov 2008 15:18:32 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>
Message-ID: <491229C8.8080205@sicking.cc>

Alexey Proskuryakov wrote:
> 
> Nov 5, 2008, ? 11:06 PM, Aaron Boodman ???????(?):
> 
>> Jonas, Hixie, and I talked about this yesterday on IRC (logs start
>> here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
>> into the next day).
> <...>
>> * Remove startConversation() from the Worker interface
>> * Remove the port property from the SharedWorker interface and give it
>> a postMessage and onmessage just like dedicated workers have.
>> * Leave the interfaces for the insides of the workers as they are now
> 
> 
> Something that seems missing from these discussions is how the API 
> changes affect semantics of worker behavior, which makes it hard to 
> compare proposals. For example, having some port singled out as an 
> attribute of Worker (or as an implicit hidden attribute, used by methods 
> defined on Worker itself) sorta implies that closing it should close 
> other ports and dispose of the worker global scope soon.

No, that is not how the spec currently works. Currently if you call 
close() on the port property of a shared worker that only closes *that* 
port. This does not affect other communication channels with the worker, 
including channels held by the same script. So in other words, if I do 
(in the current proposal):

w = new SharedWorker("foo.js", "name");
ch = new MessageChannel();
otherPort = ch.port1;
w.port.postMessage("here's the other port", ch.port2);
w.port.close();

I can still use otherPort to communicate with w. I'll just be 
communicating with whatever messagehandler the worker installed on the 
port that was delivered along with the "here's the other port" message.

> Similarly, 
> having separate interfaces for Worker and SharedWorker implies that 
> there is some fundamental difference in their behavior - a difference 
> that eludes me so far.

A shared worker is shared between all scripts on a single site[*] that 
instantiates a worker with the same name. I.e. where the second argument 
to the constructor is the same. (Don't remember what happens if the 
second argument is the same as an existing worker, but the first is not, 
check with the spec).

This means that two pages on the same site can share whatever resources 
the worker is using, such as a connection to a serverside database, or a 
local cache of calculated results.

> It would seem that we could make better progress if we had a list of 
> requirements that we want to have fulfilled (e.g., should it be possible 
> to easily manage worker lifetime manually by closing a dedicated port? 
> or should workers strive to remain available for as long as any client 
> has an open port, which helps write reliable code?).

We have discussed a lot of use cases in the past. I'm not sure if we've 
saved that anywhere though :(

/ Jonas


From jonas at sicking.cc  Wed Nov  5 15:19:48 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 05 Nov 2008 15:19:48 -0800
Subject: [whatwg] Combining the DedicatedWorker and
	SharedWorker	interfaces
In-Reply-To: <Pine.LNX.4.62.0811052250240.1041@hixie.dreamhostps.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
	<Pine.LNX.4.62.0811052250240.1041@hixie.dreamhostps.com>
Message-ID: <49122A14.2050503@sicking.cc>

Ian Hickson wrote:
>> * Remove the port property from the SharedWorker interface and give it
>> a postMessage and onmessage just like dedicated workers have.
> 
> I really don't like this. With (Dedicated)Worker it makes sense because 
> both sides bury the underlying message channel and ports and so things 
> like closing the port, or whether the port is active, are hidden on both 
> sides. But with SharedWorker, if we only bury it on one side, there is a 
> lack of symmetry that IMHO is going to lead to all kinds of issues and 
> confusion. I really don't like that. If people start sending one side's 
> pipe down another channel, we can end up with a situation where a 
> SharedWorker object really represents a port that has nothing to do with 
> the worker anymore.

It's not really that different from what you have today where a 
myWorker.port object can send messages to something that isn't a worker 
at all.

It also removes the issue where the .port property on a shared worker is 
readonly but dead.

/ Jonas


From samaxes at gmail.com  Wed Nov  5 16:15:27 2008
From: samaxes at gmail.com (Samuel Santos)
Date: Thu, 6 Nov 2008 00:15:27 +0000
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
	interface
In-Reply-To: <Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
Message-ID: <fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>

On Wed, Nov 5, 2008 at 10:46 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 5 Nov 2008, Samuel Santos wrote:
> >
> > I find it very hard to convince some clients that in order to have the
> > browse button in their language they must configure their browsers. The
> > vast majority of them don't even know where they can configure the
> > default browser language, and don't feel they should even have to do it.
> > It's also strange for them to have all the buttons in their language
> > except the browse buttons.
>
> I understand but why don't they also complain about, say, the title of the
> dialog box that comes up? Or the items on the context menus?
>
> Why do they use the wrong language browser in the first place?


In Portugal a lot computers come with the english OS version.This means that
the browser is in english and configured to have english as the default
language.

The problem with the input file button is that the client/user assumes that
the text that appears in it is the developer's responsibility, like with the
other button controls.
In the example you gave he knows that the dialog box is from the UA
(browser) and has nothing to do with the rest of the application.

I'm pretty sure that this happens a lot in non-english countries.


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



-- 
Samuel Santos
http://www.samaxes.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081106/5f1346b9/attachment.htm>

From herenvardo at gmail.com  Wed Nov  5 16:32:57 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Thu, 6 Nov 2008 00:32:57 +0000
Subject: [whatwg] ---
In-Reply-To: <491173CA.9070506@gmx.ch>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01> <491173CA.9070506@gmx.ch>
Message-ID: <6ea53250811051632h1f5de1a0u20c33d7845bbf635@mail.gmail.com>

First of all, I want to apologize. I'm quite afraid that the explosion
of frustration and disappointment on my last message to this list was
one of the triggers (if not the only or main one) igniting the
conflict here. I'm really sorry for that: my only intention when
joined this list was to contributing into making of HTML5 the best it
can be, for web users, content authors, browser and tool implementers,
and all other affected parties; and that message didn't help this
intention at all.

Before going on, I want to make clear that most of what I express in
my mails is an opinion or point of view. I, just like anyone else, may
be wrong at any time; and I'm more than willing to accept I am when
I'm shown some sustainable evidence or argument proving so. If any of
you thinks I'm wrong, on whatever I might say or have said, just let
me know, and I'll listen (or read) you.
Yet the source of my frustration didn't come from being proven wrong
our finding disagreement on some or many suggestions; but on the fact
that most of the threads I tried to participate in ended up being
ignored or stepping into unrelated side-topics. I'm quite willing to
make one more effort to assume good faith, and to take the assumption
that my messages went unnoticed, or that I failed to express myself so
miserably that nobody was able to get my point, or felt into oblivion
for any other unintentional reason; rather than thinking that I'm
being deliberatelly ignored. (I might add as well that a cold shower
really helps with that :P ).

Now, let me add that my opinions are not based on just impulsive
thoughts; but on over five years of professional experience as a
webmaster, web application developer, and SEO specialist; plus roughly
five more as a hobbyist "web tinkerer" (ie: setting up dynamic
websites just for the sake of it, with no other purpose than seeing
how far could I go before messing things up). I've been also into
programming since I was 8; so even if I don't write browsers and
authoring tools myself, I normally have a quite approximate idea of
how easy/hard something could be to implement. I perfectly know that
some people here will have more and deeper experience than me; yet I
still think that I have enough background to at least contribute
something useful.

My first opinion on the current discussion is that there is too much
going on. If just an off-topic side comment has been enough to lead
some entire discussions astray, I don't think it is possible at all to
have a rational and/or useful discussion about so many topics at once.
I'd like to (briefly) reply to some of the comments posted on this
discussion, and even add a few of my own; but if somebody feels
anything of what I say here is worth replying to, then it's probably
worth updating the subject to something relevant, splitting this
thread into more focused dicussions.

To Pentasis's comment "Who ever said that the standards are here for
browsers?" and all the replies to it:
There are several facts here to keep in mind. First of all, there is a
relevant collective among web authors (I can't say how big is it,
relative to the entire web authors collective), who simply don't trust
browser vendors. And there are quite good reasons for that:
Microsoft and Netscape literally *negotiated* HTML3.2, with horrible
consequences that we are still suffering over a decade after.
Microsoft has single-handedly boicoted the propper adoption of XHTML1
with IE's obnoxious treatment of the "application/xhtml+xml" MIMEtype
(and, whether you like it or not, there are some cases where draconian
error handling is a feature rather than a drawback, added to the
extensibility mechanisms XML offers). There has never been an HTML vs.
XHTML debate: IE took the choice away, forcing those who tried to use
XHTML to do a lot of extra effort, and it's quite obvious that the
affected authors didn't like that too much.
Microsoft has also stagnated the evolution of the Web, by deciding to
take over a decade before decently implementing CSS2. All those
authors who were eager to take the most of the new CSS when it was
published are quite pissed off by the fact that a single vendor denied
them all these new features, for no other reason than lazyness and the
commodity of having the market under a monopoly.
These are the most obvious and sound; and I hope people from other
sectors can get an idea from here about why there are so many
developers that are quite exceptic towards browser vendors choices and
claims.
Now, we have to add the second fact to the mix: the WHATWG group is
mostly made of representatives of browser makers (although Google has
recently stepped into the sector with its Chrome browser; I think Ian
shouldn't be looked at as another browser maker representative; but
still we should keep in mind that it's up to them to replace him with
another editor if they feel like it). Top it up with the extra fact
that the spec is copyrighted by three of these browser vendors. For
those of us who don't trust browser vendors this is, in the best case,
scary.
Hence, don't expect web authors (at least this subset of them) to
blindly trust the vendor-centric WHATWG (by vendor-centric I simply
mean that it's composed of browser vendors at its core) from the
beginning. By joining this list, providing our feedback, and sharing
our opinions and PoV, we are giving the group a chance to earn that
trust. How does the group use that chance is up to their members.
Of course, we are quite aware that browser vendors have the final say
on what do they implement; or at least they think so... But content
authors have the final say on what do we use to mark up our documents;
and currently we do have a choice: it is possible to perfectly render
XHTML2 pages on all currently used browsers (although IE up to 7 can
be a bit tricky, due to the lack of CSS2 support).
Someone (I won't name that person, because it was a private
conversation) told me that if HTML5 didn't meet the requirements of
browsers, at the end browsers would implement something else; the same
way XHTML2 didn't meet those requirements and browsers aren't going to
implement it (actually, by implementing XML, namespaces, and XSLT,
they are already implementing enough of XHTML2, but that's a separate
point). The same reasoning applies to content authors: if HTML5
doesn't meet authoring requirements, authors will end up authoring
with something else. Actually, to put a specific example, there is
only one issue that keeps me from using XHTML2 for my current website
project (and it's completely unrelated to browsers); and it would
currently be the best option: it serves my needs better than XHTML1.x
or HTML4.x; and HTML5 isn't mature enough yet to be even taken into
consideration for that site.
However, the main reason why I joined the lists is that I think HTML5
has the potential to beat (read: become much better) than XHTML2.


Enough of that; let's go to the next point:

On Wed, Nov 5, 2008 at 10:11 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Nov 5, 2008, at 10:46, Pentasis wrote:
>
>> <var> is the best example I think. Why <var> but not <function> <operator>
>> <operand> etc. etc. etc.? And if code gets this attention why not language?
>> (<verb>, <noun> etc. etc.) If we do it like that it would never work.
>
> <var>, <cite> and <dfn> (and, one might argue, <em>) are legacy elements
> flowing out of a desire to replace <i> with something "semantic".
>
> Since the elements are part of the HTML legacy, there isn't a great
> rationale that would justify their inclusion today if they had never been in
> HTML and were proposed as new elements now.
This makes me wonder: is the backwards compatibility topic being dealt
appropriately? For example, why keep <var> (and others), but drop
<big>? Why don't keep <font> as well? It is part of the HTML legacy,
after all, and a quite large part if you look at the markup of
currently existing documents (I'd bet that it's among the three most
used elements in the current web, sharing the podium with <p> and <a>,
but can't say for sure).
I think following HTML4's and XHTML1's approach and having
Transitional and Strict flavors wouldn't be a bad idea (I don't know
if the Frameset one would still be needed: <table> + <iframe>; or even
<iframe> + CSS's display: table-cell; seems quite cleaner, more
flexible, and doesn't require authors to use two separate content
models for similar stuff). Browsers wouldn't need to care at all when
using their "tag-soup" parsers; and it would be just a matter of
feeding one DTD/schema or the other when using an XML parser. It would
allow separating "obsolete" stuff that is only kept for backwards
compatibility from really structural stuff.
The impact of doing this (ordered from the worst to the best side effects):
Validator implementers would face quite a deal of extra work, since
they'd need to validate for different kinds of document (namely,
"Transitional soup", "Strict soup", "Transitional XML", and "Strict
XML").
Spec writers will have to properly define the flavours. On this early
stage, it could be enough to mark the appropriate stuff in the spec as
"transitional"; and then writting the DTD's or similar formalizations
once the content model becomes stable enough.
Authoring Tool implementers wouldn't face too much issues: if they
already make a distinction between HTML4's / XHTML1's flavors, reusing
most of the code should be quite doable. For those that don't separate
flavours, simply don't expect them to start now :P.
Browser implementers would be trivially affected: they'd just need to
incorporate both flavors of the DTD/Schema for XML parsing, and at
much add a bit of logics to ensure the appropriate one is fed to the
parser (but browsers are supposed to already be doing this when they
are dealing with XHTML1, so it shouldn't be an issue).
Authors who chose Strict doctypes would enjoy a succint, efficient,
and non-bloated language allowing them to conciselly and consistently
mark up their documents.
As soon as different kinds of UAs (including browsers, assistive
technologies, and search engines, among others) become aware (read:
are updated) of the new markup stuff, users will enjoy a wide variety
of benefits. Better bookmarking, smarter hints by assistive
technologies, and more representative snippets in SERPs are the first
ones that come to my mind.

Next point:
On Wed, Nov 5, 2008 at 10:22 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Pentasis schrieb:
>> [...]
>> First of all, I want to make it absolutely clear that these ideas are
>> strictly dealing with context and semantics. I do not wish to interfere in
>> the technical part of the spec. I do understand that sometimes there are
>> ideas that may involve technical solutions. My first and foremost concern is
>> about having a specification that deals with the naming of elements and
>> their usage in such a way that this would give us a standard which will
>> enable us to markup content consistantly and flexibally without ambiguity,
>> and which is flexible enough to act on-the-fly (so we don't have to wait for
>> the next version of the spec if something is missing).
[...]
> If I understand you correctly, you suggest a very basic set of structural
> elements, which are to be flexibally qualified by the authors via the class
> attribute. The composition of that set should follow some kind of basic
> language logic.
>
> If I understand HTML correctly, it provides a limited set of pre-qualified
> elements, some of them with a more structural emphasis, some of them with a
> more semantic (or or even presentational) one. The composition of that set
> does not follow a higher logic, but the everyday needs of the common web
> author (or what the writers of the spec assume this is).
>
> (I hope this is understandable; I am not a native English speaker, either.)
>
> So, supposed I got these both correctly, you do not really talk about HTML,
> but about an alternative approach of marking up text documents. I
> personnally find thinking about alternative approaches very interesting and
> useful for opening up one's mind.
Actually, I think that what Pentasis is talking about is nothing else
than HTML in its earliest and purest form, untainted by the side
effects of the browser wars and the mistakes of the past. Although we
can't undo past mistakes, we can learn from them; and put some effort
on fixing them.
Initially, HTML was entirely structural: no presentation, and no
semantics. Just paragraphs, headings, anchors, and few other things.
With HTML3.2, there was an atempt to make HTML presentational, and it
soundly failed. It was aknowledged as a mistake, and HTML4 (plus CSS)
put a good deal of work on fixing it: presentational stuff went out
(more preciselly, "deprecated"), and presentation was delegated to a
separate language (CSS). HTML only left @class for hooking to external
information, and @style for when embedding was more appropriate. Then,
to make sure noone was left out, a Strict flavor of the language was
published, keeping it "pure", and a Transitional one, keeping all the
deprecated stuff on it to ease transition, and to enable
document-level backwards compatibility. I hope we all agree this was a
good solution and that it worked; but if somebody doesn't, please let
me know. (It's true that shortly after came XHTML1, adding quite a bit
of confussion to the scene, but that's a separate topic).
So, if it worked, why not reuse that approach? Why do we need to go
through the same mistakes again? Ok, that's an easy one: we need
'cause we are human :P. Jokes aside; am I really the only one here
that sees this as exactly the same thing!?
Let me try to make it even clearer: after the 3.2 disaster, it was
found that: (1) presentational markup didn't enough to properly
control the presentation of webpages; and (2) presentational markup
clashed so often with structural markup that markup itself was not
reliable anymore to infer the structure of a document: either
structure was sacrified in favor of presentation, or presentation was
sacrified for structure.
Now, Pentasis initial posts were showing up a fact: sematic markup
doesn't do enough to properly describe the semantics of webpages. I
had already posted some comments and even a few examples showing how
semantics and structure can often clash, requiring one to be tweaked
to achieve the other. Doesn't sound familiar? Can't we simply apply an
equivalent solution to the one we used for an equivalent problem ten
years ago?
Before going on, here are some of the simplest examples I posted a
couple of months ago about this issue:
<nav> is the only facility in the spec right now to describe
"navigation" semantics; but it also implies a "section" structure:
hence there is no means to express "navigation" semantics for
something that isn't structurally a "section" (for example, headings
of the recent changes to a site in the site's main page, linked to the
relevant sections, are quite "navigation" stuff, but they are
definitely not sections).
Similarly, there is no way to mark something as "tangentially related"
without making it a "section" (with the <aside> element).
And, for example, what about something that's both "navigation" and
"tangentially related" (regardless of wether it is a section or not)?
For example, a list of "see also" stuff on a documentation page: you
would be forced to markup it as <<a "navigation" section inside an
"aside" section>> or as <<an "aside" section inside a "navigation"
section>>: none of both reflects the real structure of the page; but
they are the only ways to represent both semantics. I know these
examples are really simple, and the workarounds wouldn't really hurt
that much; but they should be enough to show how we are stepping into
the same issues with semantics that we did over a decade ago with
presentation. Do we really have to wait to be hurt by the issue before
solving it, when we can see it so clearly approaching? I don't know
you, but I know I am *not* masochist, so I don't really want to get
hurt.
Now, to something more specific, we'd need:
1) Some (external to HTML) way to describe semantics. (And no, I don't
think RDF, on its current form, is a solution for this; but maybe the
solution could be based on or inspired by RDF.) That should be to
semantics what CSS is to presentation. And we don't really need to
care about browsers quickly implementing it, or about legacy browsers
that don't implement it, because currently browsers don't care at all
about semantics (at least, not beyond displaying @title values and for
default rendering, and rendering can be dealt with through CSS
anyway).
2) A way to hook these external semantics to arbitrary elements of a
page: we already got @class for this :D
3) A way to add inline semantics when needed. I guess a "semantics"
attribute would be the most straight-forward approach. About the
format it uses, we should care about it once we have solved 1).
If we got that, then we could:
1) Get rid of all the "wannabe semantic" elements that didn't really
work well enough, sending them to the
deprecated/transitional/supported-for-backwards-compatibility-only
limbo.
2) Get rid of all the *new* "wannabe semantic" elements that wouldn't
be really serving any purpose (ie: un-bloat the content model)
3) Have the simplest and cleanest markup, the most accurate
presentation mechanisms, and the richest semantic descriptions of the
last 10 (or even more) years, all in one package.

> I agree with you that there are many things in HTML that have a purely
> historic legitimation, such as the h1-h6 elements. <h level="n"> would be
> much more flexible. I personnally often get mad about the IMO totally
> unlogic set of form elements. I would highly appreciate such thigs to be
> cleaned up in a new HTML spec. But of course the task ot those who design
> HTML5 is not to re-invent the wheel, but to evolve the existing HTML in a
> highly backwards-compatible way.
I have already mentioned what do I think about the
backwards-compatibility requirement, and the way it's being
approached.

Anyway, I think its also worth pointing out the issue with headings:
currently, the spec recommends using <h1> for all levels of headings,
but that would mess the hell up on current browsers. Hasn't anybody
noticed that?

> I made the experience when I suggested a new set of form elements, that I
> did not get much response on those contributions. The same might happen to
> your suggestions, as they are on a more basic level, than the HTML5 works
> act on. I don't think you can blame the people working on HTML5 for this, as
> they are quite far in the process, and your suggestions do rather set new
> starting points, than contribute to the acutal state of the work.
These are quite different cases: the main issue with form elements is
that their functionality is normally hardcoded in the browser.
Pentasis suggestions (and even my own) would only significantly affect
the spec itself and validators; and maybe future "smart browsing"
features that aren't yet implemented anyway.


Well, that's been a long enough message, and over 3 hours of typing
and reviewing stuff are now asking me for a cigarrete, so I'll post
again soon with the "additional comments" I was planning to add.
I want to remind you all that this message mostly reflects my point of
view; and if someone disagrees I'm more than willing to pay attention
to your arguments. Also, I think it'd be good to start branching stuff
from here rather than keeping the multi-discussion on this thread.

Regards,
Eduard Pascual


From herenvardo at gmail.com  Wed Nov  5 17:32:39 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Thu, 6 Nov 2008 01:32:39 +0000
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
	interface
In-Reply-To: <fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
Message-ID: <6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>

On Thu, Nov 6, 2008 at 12:15 AM, Samuel Santos <samaxes at gmail.com> wrote:
>
> On Wed, Nov 5, 2008 at 10:46 PM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> On Wed, 5 Nov 2008, Samuel Santos wrote:
>> >
>> > I find it very hard to convince some clients that in order to have the
>> > browse button in their language they must configure their browsers. The
>> > vast majority of them don't even know where they can configure the
>> > default browser language, and don't feel they should even have to do it.
>> > It's also strange for them to have all the buttons in their language
>> > except the browse buttons.
>>
>> I understand but why don't they also complain about, say, the title of the
>> dialog box that comes up? Or the items on the context menus?
>>
>> Why do they use the wrong language browser in the first place?
>
> In Portugal a lot computers come with the english OS version.
> This means that the browser is in english and configured to have english as
> the default language.
>
> The problem with the input file button is that the client/user assumes that
> the text that appears in it is the developer's responsibility, like with the
> other button controls.
> In the example you gave he knows that the dialog box is from the UA
> (browser) and has nothing to do with the rest of the application.
> I'm pretty sure that this happens a lot in non-english countries.

I agree with Samuel in that this is an issue. In Catalunya, most often
Spanish software is used (both OS and browsers), because a lot of the
software is not easily (or at all) available in Catalan (specially
Microsoft software, such as Windows and IE, which ammount for a quite
big fraction of web surfers). Seeing Spanish stuff in pages that are
supposed to be in Catalan is quite annoying (especially when keeping
in mind some historic factors).

I can understand that there may be some security concerns with this
control; but I don't think changing the "Browse" caption poses any
threat. But if there is so much paranoia on this, browsers could be
allowed (or even required) to ask for confirmation when picking a file
if the caption has been changed (something like "Are you sure you
would like to submit C:\example.txt to example.com?" should be enough,
and users would easily see such question as comming from the UA rather
than from the webpage).


From samaxes at gmail.com  Wed Nov  5 19:09:24 2008
From: samaxes at gmail.com (Samuel Santos)
Date: Thu, 6 Nov 2008 03:09:24 +0000
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
	interface
In-Reply-To: <6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
	<6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>
Message-ID: <fe7db4750811051909pe487a40y9975ede0c0d58684@mail.gmail.com>

Ian,
If changing the button text can be a security issue (e.g. induce the user to
an action that he's not aware of), we can come up with some solutions.

What about allowing the Author to change the control's locale?
By doing so, the UA can then render the button with the same locale as the
application without compromising the security.


On Thu, Nov 6, 2008 at 1:32 AM, Eduard Pascual <herenvardo at gmail.com> wrote:

> On Thu, Nov 6, 2008 at 12:15 AM, Samuel Santos <samaxes at gmail.com> wrote:
> >
> > On Wed, Nov 5, 2008 at 10:46 PM, Ian Hickson <ian at hixie.ch> wrote:
> >>
> >> On Wed, 5 Nov 2008, Samuel Santos wrote:
> >> >
> >> > I find it very hard to convince some clients that in order to have the
> >> > browse button in their language they must configure their browsers.
> The
> >> > vast majority of them don't even know where they can configure the
> >> > default browser language, and don't feel they should even have to do
> it.
> >> > It's also strange for them to have all the buttons in their language
> >> > except the browse buttons.
> >>
> >> I understand but why don't they also complain about, say, the title of
> the
> >> dialog box that comes up? Or the items on the context menus?
> >>
> >> Why do they use the wrong language browser in the first place?
> >
> > In Portugal a lot computers come with the english OS version.
> > This means that the browser is in english and configured to have english
> as
> > the default language.
> >
> > The problem with the input file button is that the client/user assumes
> that
> > the text that appears in it is the developer's responsibility, like with
> the
> > other button controls.
> > In the example you gave he knows that the dialog box is from the UA
> > (browser) and has nothing to do with the rest of the application.
> > I'm pretty sure that this happens a lot in non-english countries.
>
> I agree with Samuel in that this is an issue. In Catalunya, most often
> Spanish software is used (both OS and browsers), because a lot of the
> software is not easily (or at all) available in Catalan (specially
> Microsoft software, such as Windows and IE, which ammount for a quite
> big fraction of web surfers). Seeing Spanish stuff in pages that are
> supposed to be in Catalan is quite annoying (especially when keeping
> in mind some historic factors).
>
> I can understand that there may be some security concerns with this
> control; but I don't think changing the "Browse" caption poses any
> threat. But if there is so much paranoia on this, browsers could be
> allowed (or even required) to ask for confirmation when picking a file
> if the caption has been changed (something like "Are you sure you
> would like to submit C:\example.txt to example.com?" should be enough,
> and users would easily see such question as comming from the UA rather
> than from the webpage).
>



-- 
Samuel Santos
http://www.samaxes.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081106/aa8fcc5b/attachment.htm>

From herenvardo at gmail.com  Wed Nov  5 19:32:24 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Thu, 6 Nov 2008 03:32:24 +0000
Subject: [whatwg] Fwd: Review of the 3.16 section and the HTMLInputElement
	interface
In-Reply-To: <6ea53250811051931g5d5cfa96s56a65e38586ee4d3@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
	<6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>
	<fe7db4750811051909pe487a40y9975ede0c0d58684@mail.gmail.com>
	<6ea53250811051931g5d5cfa96s56a65e38586ee4d3@mail.gmail.com>
Message-ID: <6ea53250811051932i38c89b38v10d488a9f3553c8c@mail.gmail.com>

LOL forgot to add the whatwg list to the To: field ^^;


---------- Forwarded message ----------
From: Eduard Pascual <herenvardo at gmail.com>
Date: Thu, Nov 6, 2008 at 3:31 AM
Subject: Re: [whatwg] Review of the 3.16 section and the
HTMLInputElement interface
To: Samuel Santos <samaxes at gmail.com>


On Thu, Nov 6, 2008 at 3:09 AM, Samuel Santos <samaxes at gmail.com> wrote:
> What about allowing the Author to change the control's locale?
> By doing so, the UA can then render the button with the same locale as the
> application without compromising the security.
I was going to suggest this, but I don't think it's really doable:
browsers would need to include all the translations of that caption in
all their versions. In the specific case of IE, considering that
Microsoft tends to license only single-language versions of its
products (if you want it in two languages, you need to pay twice), I'm
afraid this would be an issue (despite the fact that IE is actually
distributed for free, it would still mess with their "packaging").
Still, I think that requiring user confirmation whenever something in
the control has been altered (like the button caption) should be
enough: as long as the user knows that s/he is sending that file to
that site; how much matters how the control actually looks or what the
button's caption reads?


From ap at webkit.org  Wed Nov  5 21:53:52 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Thu, 6 Nov 2008 08:53:52 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <491229C8.8080205@sicking.cc>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>
	<491229C8.8080205@sicking.cc>
Message-ID: <AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org>


Nov 6, 2008, ? 2:18 AM, Jonas Sicking ???????(?):

>> Similarly, having separate interfaces for Worker and SharedWorker  
>> implies that there is some fundamental difference in their behavior  
>> - a difference that eludes me so far.
>
> A shared worker is shared between all scripts on a single site[*]  
> that instantiates a worker with the same name. I.e. where the second  
> argument to the constructor is the same. (Don't remember what  
> happens if the second argument is the same as an existing worker,  
> but the first is not, check with the spec).


Sure, that part is clear - but it's only about the behavior of the  
object's constructor, not the object itself! It alone doesn't warrant  
having a separate interface.

As an example from another area, see mmap(2) function - you can pass  
MAP_ANON or MAP_FILE via its flags to achieve similar results. Note  
also that it has a number of other options. If we create a separate  
interface for every Worker isolation level needed (both inside and  
outside), we'll soon end up with PrivateWorker, SharedDataWorker and  
who knows what else.

- WBR, Alexey Proskuryakov



From tommy at kvaleberg.com  Thu Nov  6 01:28:59 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Thu, 06 Nov 2008 10:28:59 +0100
Subject: [whatwg] parsing nested forms
Message-ID: <4912B8DB.3010706@kvaleberg.no>

Hi again!

Before I get to the real issue, I think I should give you a little bit 
of background. I'm working for a company which makes a web browser. 
We've been having some problems with our algorithm for parsing illegal 
html, so we decided to scrap the whole module and implement the 
algorithm exactly as outlined in the html5 spec. So far this has been a 
great success. We're already way better than we used to be, but there 
are some situations where the html5 parsing algorithm does not quite 
give us the result we expected.

Yesterday I noticed that we were not displaying the site 
http://bankrate.com correctly. The problem we had on that page boils 
down to the following markup:

<div id="firstdiv">
    A
    <div id="seconddiv">
        <form id="firstform">
            <div id="thirddiv">
                <form id="secondform"></form>
            </div>
        </form>
    </div>
    B
</div>

I'll walk you through it; Everything is normal until we reach the start 
tag for the "secondform". It is ignored, since we're already in a form 
(the form element pointer points to "firstform".) Then we see the end 
tag which was meant for "secondform". We pop elements from the stack of 
open elements until we find a form element (which is "firstform") 
popping off "thirddiv" in the process. The next token we get is the end 
div tag which was meant for "thirddiv". Since "thirddiv" is already 
gone, we pop "seconddiv" instead, and now we're sort of off-balance. The 
result is that A and B does not end up as children of the same div.

If any of you would like to see the effect this can have on a real page, 
you can use the parse.py script in html5lib. On a command line, use the 
following commands:

[tommy at tommyslaptop html]$ wget -k -O bankrate.html http://bankrate.com
[tommy at tommyslaptop html]$ /path/to/html5lib/python/parse.py 
bankrate.html > bankrate_parsed.html
[tommy at tommyslaptop html]$ firefox bankrate_parsed.html

I've applied a fix to our code which makes us handle this particular 
case better. I haven't tested it very thoroughly, but the change is to 
implement the 'An end tag whose tag name is "form"' section in "in body" 
as if it said:

------
An end tag whose tag name is "form"

    Let /node/ be the form element pointer
    Set the form element pointer to null.

    If the stack of open elements does not have an element in scope with 
the same tag name as that of the token, then this is a parse error; 
ignore the token.

    Otherwise, run these steps:

       1. Generate implied end tags.
       2. If the current node is not an element with the same tag name 
as that of the token, then this is a parse error.
       3. Remove /node/ from the stack of open elements
------

This seems to give us pretty much the same behaviour as Opera for the 
simple example above. Can any of you see any potential problems with 
this approach? In any case, I do believe that the specification needs to 
be changed one way or another, so that it handles this case better.

I think I have a couple of other instances where we've had to deviate 
from the specification in order to tackle problems discovered by our 
testers, and if any of you are interested in this kind of feedback, I'll 
dig them out and post them on this list.

Best regards
Tommy Thorsen


From philipj at opera.com  Thu Nov  6 07:08:45 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 06 Nov 2008 16:08:45 +0100
Subject: [whatwg] HTMLMediaElement: static TimeRanges/ByteRanges,
	"potentially	playing" definition
Message-ID: <1225984125.6755.22.camel@localhost>

More random issues related to HTMLMediaElement

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-buffered

"The buffered attribute must return a static normalized TimeRanges object"

The phrasing for the other ranges attributes is similar, but what does
"static" mean in this context. I'm guessing that it means static in the
sense that the same object is returned each time. As a consequence you
can't keep a copy of an old ranges object to compare it with a new one
later. This is all very fine, I just want to verify that it's correct.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#potentially-playing

"A media element is said to be potentially playing when its paused
attribute is false, the readyState attribute is either HAVE_FUTURE_DATA
or HAVE_FUTURE_DATA, the element has not ended playback, playback has
not stopped due to errors, and the element has not paused for user
interaction."

There's a typo here with two HAVE_FUTURE_DATA. I'm not sure what the
intention was, but it seems to me that readyState shouldn't be involved
here. Consider:

new Audio("foo.wav").play();

"Media elements that are potentially playing while not in a Document
must not play any video, but should play any audio component. Media
elements must not stop playing just because all references to them have
been removed..."

Immediately after the above call has returned, the readyState of the
media element is HAVE_NOTHING unless the resource happened to be
cached. The definition of "potentially playing" must be such that this
object isn't immediately garbage collected. Suggested definition:

"A media element is said to be potentially playing when its paused
attribute is false, the element has not ended playback, playback has
not stopped due to errors."

In other words, remove the readyState and "paused for user interaction"
stuff (surely a media element could potentially keep playing after such
user interaction, otherwise there would be no need to ask).

(Also, I'm still wondering about the issues in my previous mail.)

-- 
Philip J?genstedt
Opera Software



From ian at hixie.ch  Thu Nov  6 09:21:28 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 6 Nov 2008 17:21:28 +0000 (UTC)
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
 interface
In-Reply-To: <fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com> 
	<Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com> 
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com> 
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811061720190.1041@hixie.dreamhostps.com>

On Thu, 6 Nov 2008, Samuel Santos wrote:
> >
> > Why do they use the wrong language browser in the first place?
> 
> In Portugal a lot computers come with the english OS version.This means 
> that the browser is in english and configured to have english as the 
> default language.
> 
> The problem with the input file button is that the client/user assumes 
> that the text that appears in it is the developer's responsibility, like 
> with the other button controls. In the example you gave he knows that 
> the dialog box is from the UA (browser) and has nothing to do with the 
> rest of the application.
> 
> I'm pretty sure that this happens a lot in non-english countries.

Well that is quite unfortunate. However, I think that to fix this problem 
it would be better to get the default installation language changed than 
to get the HTML specification changed.

As noted earlier, we can't really allow any author control over this 
widget anyway, as it is so security-sensitive.

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


From eric.carlson at apple.com  Thu Nov  6 09:46:45 2008
From: eric.carlson at apple.com (Eric Carlson)
Date: Thu, 06 Nov 2008 09:46:45 -0800
Subject: [whatwg] Video element and duration attribute
In-Reply-To: <c2e346f90810311318j4ff29785teb8d33af6de93a8b@mail.gmail.com>
References: <c2e346f90810311318j4ff29785teb8d33af6de93a8b@mail.gmail.com>
Message-ID: <F2EC97A7-2EF3-45D5-AAE3-9176249CDFB8@apple.com>

Chris -

On Oct 31, 2008, at 1:18 PM, Chris Double wrote:

> Some video formats don't make it easy to get the duration.
>
> For example, Ogg files can be concatenated to form a single playable
> file. To compute the duration you need to do multiple seeks to find
> the chains and total the durations of each chain. Even in the
> unchained case a seek is required to go to the end of the file and
> work backwards finding a packet with a timestamp. While this is not
> difficult to implement it can be expensive over HTTP, requiring
> multiple byte range requests.
>
> The most common player for Ogg files on the web is probably the
> Cortado Java applet, and it has an applet parameter to specify the
> duration. There have been requests in #theora from people wishing that
> <video> supported a duration attribute that could be set in the HTML.
>
> Would such an attribute be useful? It seems to be a commonly used in
> current Ogg web solutions. Are there any other video formats that
> could benefit from this?
>
   There are other audio and video formats that require a file's  
duration to be computed, eg. an MP3 file without an "MPEG audio  
frames" packet or a muxed MPEG stream, but I don't think including a  
"duration" attribute is necessary. Instead of seeking to the end of  
the file to calculate an exact duration as you describe, it is much  
cheaper to estimate the duration by processing a fixed portion of the  
file and extrapolating to the duration based on the file size.  
QuickTime does this and it works quite well.

   An estimate may not be correct, but the spec requires a user agent  
to post a "durationchange" event for exactly this case. If we have a  
"duration" attribute a user agent will still have to deal with pages  
that don't include it, or that include a value that is wildly  
inaccurate (copy/paste editing?), so I think it makes more sense for  
the user agent/media engine to just figure it out.

eric




From ian at hixie.ch  Thu Nov  6 09:50:31 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 6 Nov 2008 17:50:31 +0000 (UTC)
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
 interface
In-Reply-To: <6ea53250811051932i38c89b38v10d488a9f3553c8c@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
	<6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>
	<fe7db4750811051909pe487a40y9975ede0c0d58684@mail.gmail.com>
	<6ea53250811051931g5d5cfa96s56a65e38586ee4d3@mail.gmail.com>
	<6ea53250811051932i38c89b38v10d488a9f3553c8c@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811061722180.1041@hixie.dreamhostps.com>

On Thu, 6 Nov 2008, Eduard Pascual wrote:
> 
> I agree with Samuel in that this is an issue. In Catalunya, most often 
> Spanish software is used (both OS and browsers), because a lot of the 
> software is not easily (or at all) available in Catalan (specially 
> Microsoft software, such as Windows and IE, which ammount for a quite 
> big fraction of web surfers). Seeing Spanish stuff in pages that are 
> supposed to be in Catalan is quite annoying (especially when keeping in 
> mind some historic factors).
> 
> I can understand that there may be some security concerns with this 
> control; but I don't think changing the "Browse" caption poses any 
> threat. But if there is so much paranoia on this, browsers could be 
> allowed (or even required) to ask for confirmation when picking a file 
> if the caption has been changed (something like "Are you sure you would 
> like to submit C:\example.txt to example.com?" should be enough, and 
> users would easily see such question as coming from the UA rather than 
> from the webpage).

It has been shown that prompts are ignored by users, so that wouldn't 
really solve the problem.


On Thu, 6 Nov 2008, Samuel Santos wrote:
>
> If changing the button text can be a security issue (e.g. induce the 
> user to an action that he's not aware of), we can come up with some 
> solutions.
> 
> What about allowing the Author to change the control's locale? By doing 
> so, the UA can then render the button with the same locale as the 
> application without compromising the security.

It seems like browsers should do this already based on the lang="" 
attribute. I recommend asking browser vendors to implement this.


On Thu, 6 Nov 2008, Eduard Pascual wrote:
>
> I was going to suggest this, but I don't think it's really doable: 
> browsers would need to include all the translations of that caption in 
> all their versions. In the specific case of IE, considering that 
> Microsoft tends to license only single-language versions of its products 
> (if you want it in two languages, you need to pay twice), I'm afraid 
> this would be an issue (despite the fact that IE is actually distributed 
> for free, it would still mess with their "packaging").

It's true that this may not be something browsers want to implement.

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


From ian at hixie.ch  Thu Nov  6 10:06:33 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 6 Nov 2008 18:06:33 +0000 (UTC)
Subject: [whatwg] parsing nested forms
In-Reply-To: <4912B8DB.3010706@kvaleberg.no>
References: <4912B8DB.3010706@kvaleberg.no>
Message-ID: <Pine.LNX.4.62.0811061806090.1041@hixie.dreamhostps.com>

On Thu, 6 Nov 2008, Tommy Thorsen wrote:
> 
> I think I have a couple of other instances where we've had to deviate 
> from the specification in order to tackle problems discovered by our 
> testers, and if any of you are interested in this kind of feedback, I'll 
> dig them out and post them on this list.

Please do; all feedback is very welcome, especially implementation 
experience.

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


From samaxes at gmail.com  Thu Nov  6 10:17:27 2008
From: samaxes at gmail.com (Samuel Santos)
Date: Thu, 6 Nov 2008 18:17:27 +0000
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
	interface
In-Reply-To: <Pine.LNX.4.62.0811061722180.1041@hixie.dreamhostps.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<Pine.LNX.4.62.0811051717000.1237@hixie.dreamhostps.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
	<6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>
	<fe7db4750811051909pe487a40y9975ede0c0d58684@mail.gmail.com>
	<6ea53250811051931g5d5cfa96s56a65e38586ee4d3@mail.gmail.com>
	<6ea53250811051932i38c89b38v10d488a9f3553c8c@mail.gmail.com>
	<Pine.LNX.4.62.0811061722180.1041@hixie.dreamhostps.com>
Message-ID: <fe7db4750811061017i6a8de93ar831dff9febf4b707@mail.gmail.com>

On Thu, Nov 6, 2008 at 5:50 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 6 Nov 2008, Eduard Pascual wrote:
> >
> > I agree with Samuel in that this is an issue. In Catalunya, most often
> > Spanish software is used (both OS and browsers), because a lot of the
> > software is not easily (or at all) available in Catalan (specially
> > Microsoft software, such as Windows and IE, which ammount for a quite
> > big fraction of web surfers). Seeing Spanish stuff in pages that are
> > supposed to be in Catalan is quite annoying (especially when keeping in
> > mind some historic factors).
> >
> > I can understand that there may be some security concerns with this
> > control; but I don't think changing the "Browse" caption poses any
> > threat. But if there is so much paranoia on this, browsers could be
> > allowed (or even required) to ask for confirmation when picking a file
> > if the caption has been changed (something like "Are you sure you would
> > like to submit C:\example.txt to example.com?" should be enough, and
> > users would easily see such question as coming from the UA rather than
> > from the webpage).
>
> It has been shown that prompts are ignored by users, so that wouldn't
> really solve the problem.
>
>
> On Thu, 6 Nov 2008, Samuel Santos wrote:
> >
> > If changing the button text can be a security issue (e.g. induce the
> > user to an action that he's not aware of), we can come up with some
> > solutions.
> >
> > What about allowing the Author to change the control's locale? By doing
> > so, the UA can then render the button with the same locale as the
> > application without compromising the security.
>
> It seems like browsers should do this already based on the lang=""
> attribute. I recommend asking browser vendors to implement this.


@lang will definitively fix the problem if browsers are willing to implement
it.


>
>
>
> On Thu, 6 Nov 2008, Eduard Pascual wrote:
> >
> > I was going to suggest this, but I don't think it's really doable:
> > browsers would need to include all the translations of that caption in
> > all their versions. In the specific case of IE, considering that
> > Microsoft tends to license only single-language versions of its products
> > (if you want it in two languages, you need to pay twice), I'm afraid
> > this would be an issue (despite the fact that IE is actually distributed
> > for free, it would still mess with their "packaging").
>
> It's true that this may not be something browsers want to implement.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
Samuel Santos
http://www.samaxes.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081106/65c9774b/attachment.htm>

From ian at hixie.ch  Thu Nov  6 12:29:23 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 6 Nov 2008 20:29:23 +0000 (UTC)
Subject: [whatwg] Form control consistency
In-Reply-To: <47BC6D59.9020104@gmx.ch>
References: <47BC6D59.9020104@gmx.ch>
Message-ID: <Pine.LNX.4.62.0811062005160.1237@hixie.dreamhostps.com>

On Wed, 20 Feb 2008, Markus Ernst wrote:
> 
> I suggest to change the point-of-view for future HTML versions. A 
> consistent structure could look somehow like the following:

Unfortunately since we have to be compatible with the legacy content and 
browsers, we are quite constrained in terms of what we can change.

Changing things for the benefit of a more consistent language doesn't 
really gain us enough to warrant the implementation cost. For example:


> - for a multiline text field, either a "multiline" attribute or a new
> "textarea" type is introduced
> - the textarea element gets deprecated

We can't ever obsolete <textarea> -- so deprecating it is pointless. All 
this would do is just introduce more redundancy.


> - also, a rich text editor could be introduced, either by a "richtext"
> attribute or a new "richtext" type (of course this would introduce new
> questions, such as, how to configure its toolbars...)

We have this with contentEditable. We can't really do more than that, 
since there is so much disparity in what people actually want from a rich 
text editor.


> - checkbox, radio, submit, reset, button, and image types get deprecated

How does this actually improve anything? We can't ever get rid of them, so 
why deprecate them?


> - introduce type attribute to determine appearance:
> type="menu" (default): display as today's select element
> type="boxes": display as group of check or radio boxes

This seems like something for CSS3 UI or XBL2.


> - the current option syntax gets deprecated; the label will be added 
> with the label tag rather than be included in the option tag
> 
> Examples:
> - default selectbox, as we know it
>   <select name="foo">
>     <option id="foo1" value="bar1"><label for="foo1">Bar 1</label>
>     <option id="foo2" value="bar2"><label for="foo2">Bar 2</label>
>     <option id="foo3" value="bar3"><label for="foo3">Bar 3</label>
>   </select>

This wouldn't be compatible with the HTML parsing rules.


> - the "checkbox" element gets no value attribute; the submitted value is 
> "1" when checked, "0" when not checked (this is actually the main reason 
> for introducing a new element - changing input type="checkbox" in this 
> manner would cause severe backwards compatibility problems in many 
> applications; one more reason for the new element is the problem of 
> styling the input element, where i.e. borders or dimensions usually do 
> not apply to checkboxes but only to text fields)
> 
> Example:
>   <checkbox id="chk1" name="confirm">
>   <label for="chk1">I have read and understood the general conditions</label>

Why is the current behavior a problem?


> - button type="image" is introduced in order to totally replace all 
> button functionalities of the input element

What problem does this solve? This seems to just introduce more 
inconsistency.

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


From giles at xiph.org  Thu Nov  6 13:48:12 2008
From: giles at xiph.org (Ralph Giles)
Date: Thu, 6 Nov 2008 13:48:12 -0800
Subject: [whatwg] Video element and duration attribute
In-Reply-To: <F2EC97A7-2EF3-45D5-AAE3-9176249CDFB8@apple.com>
References: <c2e346f90810311318j4ff29785teb8d33af6de93a8b@mail.gmail.com>
	<F2EC97A7-2EF3-45D5-AAE3-9176249CDFB8@apple.com>
Message-ID: <5d88ef650811061348u56f4d302t8c1ee5a436e035fc@mail.gmail.com>

On Thu, Nov 6, 2008 at 9:46 AM, Eric Carlson <eric.carlson at apple.com> wrote:

>                  Instead of seeking to the end of the file to calculate an exact
> duration as you describe, it is much cheaper to estimate the duration by
> processing a fixed portion of the file and extrapolating to the duration
> based on the file size. QuickTime does this and it works quite well.

I expect this works much better for mp3 than it does for variable
bitrate streams. Nevertheless it's much better than nothing.

Your argument that the durationchange event makes flexible
determination reasonable is a good one. I'm fine with not including
the duration argument, for whatever that's worth.

 -r


From philipj at opera.com  Thu Nov  6 14:23:26 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 06 Nov 2008 23:23:26 +0100
Subject: [whatwg] HTMLMediaElement: static TimeRanges/ByteRanges
In-Reply-To: <fb6fbf560811061355l60cb80cawb1a9ddb4c7195b1a@mail.gmail.com>
References: <fb6fbf560811061355l60cb80cawb1a9ddb4c7195b1a@mail.gmail.com>
Message-ID: <1226010206.6755.35.camel@localhost>

On Thu, 2008-11-06 at 16:55 -0500, Jim Jewett wrote:
> Philip J?genstedt wrote:
> 
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-buffered
> 
> > "The buffered attribute must return a static normalized TimeRanges object"
> 
> > ... what does "static" mean in this context. I'm guessing that it means static in the
> > sense that the same object is returned each time.
> 
> I would have assumed exactly the opposite -- that "static" meant it
> wasn't live, and would not be updated as the buffering state and
> playing continued.

Actually, this does makes more sense. Otherwise ranges might be merged
as loading progresses with confusing results and exceptions. In any
event, since there were different interpretations it's probably best to
clarify this in the spec.

-- 
Philip J?genstedt
Opera Software



From ian at hixie.ch  Thu Nov  6 21:41:42 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 7 Nov 2008 05:41:42 +0000 (UTC)
Subject: [whatwg] 'input' event interpretation
In-Reply-To: <ea84759c0805020212w645bddfak5dd9b2cc64ddc67f@mail.gmail.com>
References: <ea84759c0805020212w645bddfak5dd9b2cc64ddc67f@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811070503400.1237@hixie.dreamhostps.com>

On Fri, 2 May 2008, Rimvydas wrote:
>
> The question is related to the 'input' event on Web Forms 2.0.
> 
> The WF2 specification says:
> "This [input] event must be fired on a control whenever the value of
> the control changes due to input from the user, and is otherwise
> identical to the change event."
> 
> However, there are a few problems with current interpretation of this sentence.
> 
> The first one - what is considered an "input from the user"? I just
> check on opera and firefox3 - they fire the event when I enter
> something, but if i select an entry from autocomplete list or browser
> fills some forms for me - it is not fired. When I select a value from
> a list I usually want the value in the field to change - it is like
> typing, just faster. I have filed a bug for ff. Maybe a specification
> could be more precise on what is an input from the user...

I've tried to be clearer. Let me know if this is still ambiguous.

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


From timeless at gmail.com  Thu Nov  6 22:07:29 2008
From: timeless at gmail.com (timeless)
Date: Fri, 7 Nov 2008 08:07:29 +0200
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
	interface
In-Reply-To: <fe7db4750811061017i6a8de93ar831dff9febf4b707@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
	<6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>
	<fe7db4750811051909pe487a40y9975ede0c0d58684@mail.gmail.com>
	<6ea53250811051931g5d5cfa96s56a65e38586ee4d3@mail.gmail.com>
	<6ea53250811051932i38c89b38v10d488a9f3553c8c@mail.gmail.com>
	<Pine.LNX.4.62.0811061722180.1041@hixie.dreamhostps.com>
	<fe7db4750811061017i6a8de93ar831dff9febf4b707@mail.gmail.com>
Message-ID: <26b395e60811062207g100fea5fqc91ad21d7f8d7066@mail.gmail.com>

On Thu, 6 Nov 2008, Samuel Santos wrote:
> What about allowing the Author to change the control's locale? By doing
> so, the UA can then render the button with the same locale as the
> application without compromising the security.

On Thu, Nov 6, 2008 at 5:50 PM, Ian Hickson <ian at hixie.ch> wrote:
> It seems like browsers should do this already based on the lang=""
> attribute. I recommend asking browser vendors to implement this.

On Thu, Nov 6, 2008 at 8:17 PM, Samuel Santos <samaxes at gmail.com> wrote:
> @lang will definitively fix the problem if browsers are willing to implement
> it.

[Ignoring the fact that Klingon isn't officially supported by Unicode]
as most people don't actually speak Klingon, being able to set the
button label to the Klingon translation will not help our users
(similarly for most other languages). And I will campaign against
this. In an internet cafe, it's somewhat reasonable to assume that the
browser could be configured to support a wide range of languages (in
the bay area this would include Korean among others), on average it's
likely that someone visiting an internet cafe could easily not know
all languages spoken by all likely patrons of the cafe, which means
there are probably a number of languages that a web application could
use which would be effectively equivalent from the user's perspective
to Klingon.

If you'd like a certain user agent to use an icon instead of a label,
file a bug report and perhaps it might be implemented.

I think you'll find that this change is even less welcome for average
web applications, however, I wouldn't be opposed.

currently people think of <input type=file> as:

<div><input type=text> <input type=button></div>

however in some browsers, it's more like:

<div><input type=image><caption for=image /> <input type=button></div>

in the browsers I'm thinking about, the image actually represents the
selected file and iirc button is more of a reset button (the caption
is the file's leaf name).


From chaals at opera.com  Fri Nov  7 01:00:20 2008
From: chaals at opera.com (Charles McCathieNevile)
Date: Fri, 07 Nov 2008 15:00:20 +0600
Subject: [whatwg] Context help in Web Forms
In-Reply-To: <Pine.LNX.4.62.0810220731500.1237@hixie.dreamhostps.com>
References: <op.srgo2bvkwxe0ny@widsith.local>
	<Pine.LNX.4.61.0506061003070.8388@dhalsim.dreamhost.com>
	<op.sr7mjtg0wxe0ny@widsith.local>
	<Pine.LNX.4.61.0506111444100.18378@dhalsim.dreamhost.com>
	<op.sr7qrrxiwxe0ny@widsith.local>
	<Pine.LNX.4.61.0506121039170.18378@dhalsim.dreamhost.com>
	<op.sr9aioyuwxe0ny@widsith.local>
	<Pine.LNX.4.62.0810220731500.1237@hixie.dreamhostps.com>
Message-ID: <op.uj8raukpwxe0ny@152.10.10.10.in-addr.arpa>

Adding HTML-WG so people know what's going on and can comment if necessary.

On Wed, 22 Oct 2008 14:42:48 +0700, Ian Hickson <ian at hixie.ch> wrote:

[in the context of a request for a way to identify context-specific help,  
e.g. some further information about a given form field that can  be made  
available without requiring the user to read it].

...
> I don't understand how inline text is inaccessible. Could you elaborate?
> An example would be useful.

Large quantities of text reduce the overall accessibility of a page in a
couple of ways.

The most common is actually making the page harder to read - and reading
difficulties are very common as a type of disability. The effect can be
very mild (it is a bit slower) or very severe (many people actually find
it incredibly difficult to read something if there is too much text there).
(For this reason, designers will often look for ways not to have the text
present in the page's default view...)

The other common problem it introduces is reducing the ability of users to
navigate efficiently. This applies especially to screen reader users who
are "scanning" text by skipping through it. One of the benefits HTML
provides over plain text is the various navgiable structures to improve
this situation - having a lot of inline text can negate some of that
improvement, especially if it is not marked in a way that makes it clear
that it is ancillary to the main content. (One of the problems with
visible metadata is that people assume that since it is visible it doesn't
really need more markup...)

>> Hixie had said...
>> > Great! Thanks. I think your idea of making rel="help" be relative to  
>> > the nearest parent <label> is a good one. We could also say it is >  
>> relative to the nearest parent <label>, <body>, <section>, <form>,
>> > <fieldset>, or other such grouping element. I'll look at this in
>> > more detail when defining the rel="" values.
> Chaals replied:
>> Cool. The idea is that the thing is really reliably discoverable -
>> otherwise authors will come up with something that makes sense but
>> breaks the implicit model that the spec is built on. I am actually not
>> sure that we mean the same thing when we say "nearest" but I will talk
>> to you off the list about that to clarify that in my mind :-)
>
> Ok.
>
> rel=help is now defined to apply to the link element's parent and its
> children.

Thanks, this seems sound to me.

cheers

Chaals

-- 
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 naktinis at gmail.com  Fri Nov  7 05:49:45 2008
From: naktinis at gmail.com (Rimvydas)
Date: Fri, 7 Nov 2008 14:49:45 +0100
Subject: [whatwg] 'input' event interpretation
In-Reply-To: <Pine.LNX.4.62.0811070503400.1237@hixie.dreamhostps.com>
References: <ea84759c0805020212w645bddfak5dd9b2cc64ddc67f@mail.gmail.com>
	<Pine.LNX.4.62.0811070503400.1237@hixie.dreamhostps.com>
Message-ID: <ea84759c0811070549h5d7b4615ob5fcb76a0fbd9bb8@mail.gmail.com>

Are you talking about section "4.2.  The  change  and  input  events" ?

It still concentrates mostly on entering text with keyboard. But what
another forms of input i've mentioned? They are still popular among
UAs but are not mentioned here. However I think, as I've mentioned,
they change the value of an input field due to input from the user
(mouse click).

2008/11/7 Ian Hickson <ian at hixie.ch>:
> On Fri, 2 May 2008, Rimvydas wrote:
>>
>> The question is related to the 'input' event on Web Forms 2.0.
>>
>> The WF2 specification says:
>> "This [input] event must be fired on a control whenever the value of
>> the control changes due to input from the user, and is otherwise
>> identical to the change event."
>>
>> However, there are a few problems with current interpretation of this sentence.
>>
>> The first one - what is considered an "input from the user"? I just
>> check on opera and firefox3 - they fire the event when I enter
>> something, but if i select an entry from autocomplete list or browser
>> fills some forms for me - it is not fired. When I select a value from
>> a list I usually want the value in the field to change - it is like
>> typing, just faster. I have filed a bug for ff. Maybe a specification
>> could be more precise on what is an input from the user...
>
> I've tried to be clearer. Let me know if this is still ambiguous.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
Rimvydas Naktinis


From ian at hixie.ch  Fri Nov  7 07:23:46 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 7 Nov 2008 15:23:46 +0000 (UTC)
Subject: [whatwg] 'input' event interpretation
In-Reply-To: <ea84759c0811070549h5d7b4615ob5fcb76a0fbd9bb8@mail.gmail.com>
References: <ea84759c0805020212w645bddfak5dd9b2cc64ddc67f@mail.gmail.com> 
	<Pine.LNX.4.62.0811070503400.1237@hixie.dreamhostps.com>
	<ea84759c0811070549h5d7b4615ob5fcb76a0fbd9bb8@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811071522190.1041@hixie.dreamhostps.com>

On Fri, 7 Nov 2008, Rimvydas wrote:
>
> Are you talking about section "4.2.  The change and input events" ?
> 
> It still concentrates mostly on entering text with keyboard. But what 
> another forms of input i've mentioned? They are still popular among UAs 
> but are not mentioned here. However I think, as I've mentioned, they 
> change the value of an input field due to input from the user (mouse 
> click).

My apologies, I meant in the HTML5 spec:

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

There are various places that discuss 'input' and 'change', but in 
particular:

   http://www.whatwg.org/specs/web-apps/current-work/#common-event-behaviors

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


From ian at hixie.ch  Sat Nov  8 09:45:02 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 8 Nov 2008 17:45:02 +0000 (UTC)
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
In-Reply-To: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
References: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
Message-ID: <Pine.LNX.4.62.0811081731570.1237@hixie.dreamhostps.com>

On Mon, 16 Jun 2008, Adele Peterson wrote:
>
> In HTML5, focus() and blur() are now defined on HTMLElement instead of 
> being restricted to specific form elements.
> 
> In Web Forms 2.0, the autofocus attribute is defined for "any form 
> control (except hidden and output controls)".  It seems like it would 
> make more sense to allow autofocus to be on any HTMLElement, and have it 
> follow the same focusable rules that focus() follows.

While I think this would make sense from a consistency point of view, I 
don't think we want to encourage people to autofocus elements that are not 
built-in controls. The .focus() method is there because otherwise there's 
no way to focus the elements, but autofocus is just a convenience.

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


From ian at hixie.ch  Sat Nov  8 09:46:48 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 8 Nov 2008 17:46:48 +0000 (UTC)
Subject: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
In-Reply-To: <13C69AFD-0B30-470B-AD88-D04204421433@apple.com>
References: <E32C6794-C605-4F41-BB64-1E3EDB3A039C@apple.com>
	<op.ucuwaneb64w2qv@annevk-t60.oslo.opera.com>
	<13C69AFD-0B30-470B-AD88-D04204421433@apple.com>
Message-ID: <Pine.LNX.4.62.0811081745340.1237@hixie.dreamhostps.com>

On Mon, 16 Jun 2008, Adele Peterson wrote:
>
> I saw the need for this in our Web Inspector, which has a lot of custom 
> controls (including some that use contenteditable elements).  Some of 
> these don't have a default focused appearance, but its nice that they 
> can follow the focus pseudo-class CSS selector.
> 
> I agree that the disabled attribute would fit in well with this.  
> Again, it would be nice for these custom controls to be able to use the 
> disabled pseudo-class CSS selector.

I really would rather see XBL2's <div> element be extended to be
focusable and disablable rather than have HTML support this. Does that 
make sense?

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


From herenvardo at gmail.com  Sat Nov  8 15:56:27 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Sat, 8 Nov 2008 23:56:27 +0000
Subject: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
In-Reply-To: <f042876c0811051247q7735952fm16a79b4cbee415d1@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01> <491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01> <4911806C.6070101@gmx.ch>
	<2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
	<5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
	<f042876c0811051247q7735952fm16a79b4cbee415d1@mail.gmail.com>
Message-ID: <6ea53250811081556h3b083214ka63f23a2a080a1f9@mail.gmail.com>

On Wed, Nov 5, 2008 at 8:47 PM, Philipp Serafin <phil127 at gmail.com> wrote:
> On Wed, Nov 5, 2008 at 4:00 PM, Leons Petrazickis
> <leons.petrazickis at gmail.com> wrote:
>> It matters in the sense that web browsers would have to implement both
>> approaches for backwards compatibility.
>>
>
> This depends what you mean when talking about "implementing" a tag.
> Browsers already load all tags and attributes they encounter into the
> page DOM today , regardless if they "know" them or not. This is also
> the behavior that HTML5 demands, if I'm not mistaken.
I have just put a sample file together, and checked it on what I have available:
On Dreamweaver (CS3) and FF3, it is rendered perfectly.
On IE7 and Microsoft's Visual Web Developer 2008 Express SP1, it
ungracefully degrades, as I expected: they ignore the entire
<reference> tag, so neither the default styles defined for the tag nor
the specific classes are displayed. I also included title attributes,
for fancy tooltip effects, and they show perfectly on FF; IE of course
doesn't show them because they are part of the ignored <reference>
tag.
And, of course, both authoring tools make a mention of <reference> not
being valid... but that was something that could be expected :P

I tried to test this on IE8beta2, but the instalation is failing ??'.
Would MS be so kind to do something that doesn't break? Thanks.
Sarcasms aside, if somebody wants to give this sample a try on other
browsers, I've put it online at
http://herenvardo.googlepages.com/test.html. Note that I have
deliberatelly abused of styling to make the result stand out (ie: to
easily see whether it works or not). Use your browser's "View source"
features to get an idea of what to expect.

>>Standards that have tried to make changes like that -- XHTML2 comes to
>>mind -- have not been as successful as HTML4 [...]
>
> We can't really make any statements about how successful XHTML2 would
> be on the public web. It's not yet a recommendation (though this would
> probably not change much) and no browser implemented it, so there was
> never opportunity to find out.
And even so it's being used sporadically :P
In addition, this case can't be compared with XHTML2: it'd give the
authors a choice, since <abbr> and similar elements would still be
supported, for backwards compatibility.

> But anyway, this discussion is moot, since many of those tags can't be
> changed due to backwards compatibility.
Actually, it isn't: <abbr> doesn't need to be kept more than <big> of
<font> do for the compatibility issue. The spec needs to define how to
handle all of those anyway; but it isn't really tied on what does it
define as "conformant" and "non-conformant".

Now, going back to Pentasis's actual concern: authoring content in a
way that makes sense. Just go ahead: it seems that browsers that deal
with "unknown" elements in an HTML5-conformant way will handle it
properly, as long as you provide some rendering info in your
style-sheets. You don't really need this spec to "define" that
element, as long as it works on browsers; and the spec will still
require browsers to process it in a reasonable way (ie: include in the
DOM, apply relevant styles, and hopefully even apply global attribs
like @class or @title). So, essentially, including an element like
<reference> or not is, from the browser's viewpoint, irrelevant: their
required behavior will be exactly the same either way. On the author's
side, it will only be relevant for authors that care about conformity
and need the element, in which case it will be good to have it
available. Of course, it requires a bit of extra work by the WG, to
describe it in the spec (what would it be, one paragraph?). Validators
may face some extra work, but I don't think anyone with a bit of
sanity left would hardcode each element in the validators, but instead
use some DTD-like description of the syntax and/or content model, so
it isn't really that much work. And finally, on the assistive
technologies' and search engines' side, this kind of elements would
allow to describe the contents of webpages far better, which would be
a clear benefit.

So, in summary, there are some benefits for including this kind of
elements; and there is any relevant backward (just a bit of extra,
trivial work for spec and validator writters). Some benefits, and no
*real* issues, the only plausible reason to not include this would be
a desire to hurt the web (which, BTW, some XHTML2 evangelists out
there think is the only goal of the WG). Can somebody put forward any
technical argument against this idea? If somebody does, I'd be glad to
discuss them seriously; but please think if what you're going to say
at least makes sense: don't come up with the "implementation issue"
(the inclusion of this kind of elements wouldn't require from
implementations anything that the spec doesn't already require) or the
"backwards compatibility thing" (the inclusion of new element never
affects how other elements should be treated); I've better things to
spend my time on than needlessly looping and replying to the same void
fallacies once and again.


From ian at hixie.ch  Sun Nov  9 08:13:07 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 9 Nov 2008 16:13:07 +0000 (UTC)
Subject: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
In-Reply-To: <6ea53250811081556h3b083214ka63f23a2a080a1f9@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01> <491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01> <4911806C.6070101@gmx.ch>
	<2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
	<5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
	<f042876c0811051247q7735952fm16a79b4cbee415d1@mail.gmail.com>
	<6ea53250811081556h3b083214ka63f23a2a080a1f9@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811091547280.1041@hixie.dreamhostps.com>

On Sat, 8 Nov 2008, Eduard Pascual wrote:
> 
> Can somebody put forward any technical argument against this idea?

For my benefit, could you succintly summarise the changes that this would 
involve to the spec? (Not the exact wording, but a basic overview of what 
you see being added or changed.) I'm not sure I really understand the 
proposal at the concrete level.

Also, it would be helpful to have a clear summary of the use cases.

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


From herenvardo at gmail.com  Sun Nov  9 10:30:46 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Sun, 9 Nov 2008 18:30:46 +0000
Subject: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
In-Reply-To: <Pine.LNX.4.62.0811091547280.1041@hixie.dreamhostps.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01> <491173CA.9070506@gmx.ch>
	<D349B3A754FD40C2ADA8677192466CED@Sanktum01> <4911806C.6070101@gmx.ch>
	<2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
	<5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
	<f042876c0811051247q7735952fm16a79b4cbee415d1@mail.gmail.com>
	<6ea53250811081556h3b083214ka63f23a2a080a1f9@mail.gmail.com>
	<Pine.LNX.4.62.0811091547280.1041@hixie.dreamhostps.com>
Message-ID: <6ea53250811091030u271b9820m5267f486426fd4d3@mail.gmail.com>

On Sun, Nov 9, 2008 at 4:13 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 8 Nov 2008, Eduard Pascual wrote:
>>
>> Can somebody put forward any technical argument against this idea?
>
> For my benefit, could you succintly summarise the changes that this would
> involve to the spec? I'm not sure I really understand the proposal at the
> concrete level.
Sure! I'd like to speak with Pentasis first (it was him who started
this thread with this suggestion), to make sure we have the similar
idea in mind (or to cover both viewpoints if needed), before putting
something more concrete together, so just give us a couple of days or
so to discuss these details; and we'll make our best to word it in a
succint and concrete way.

> Also, it would be helpful to have a clear summary of the use cases.
Definitely, it would. I'll try to put together the cases Pentasis and
I have in mind, and also do some research through the web to try find
out those cases that might have gone unnoticed.

So, expect a more formal (and concrete) reply within a few days.


From herenvardo at gmail.com  Sun Nov  9 18:10:41 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Mon, 10 Nov 2008 02:10:41 +0000
Subject: [whatwg] Format issue on the spec: unreadable (or hardly readable)
	text.
Message-ID: <6ea53250811091810j2956a965n796c4244a03d33ff@mail.gmail.com>

I can't say for sure if this is an issue from the spec document
itself, or just a rendering bug on my browser (FF 3.0.3), but here it
goes:
Within the section "4.3.1 The script element", on the algorythm
labeled "Running a script", step 6, the text for the first "condition"
shows overlapped, each line covering part of the text in the previous
line. I have put a screenshot on
http://herenvardo.googlepages.com/brokentext.png just for case anyone
wants to see it.
So, unless it is actually a FF bug, I hope someone fixes it.
Actually, I *can* read half-visible text like that, but even being
used to do that it still takes some extra effort from my eyes and
brain. And I wouldn't expect everyone reading the spec to be used to
look at scrambled text.


From paul.arzul at gmail.com  Sun Nov  9 22:53:31 2008
From: paul.arzul at gmail.com (Paul Arzul)
Date: Mon, 10 Nov 2008 08:53:31 +0200
Subject: [whatwg] Warnings for non-applicable properties
In-Reply-To: <575E98E041AC455F8E133EA9BEDFAB67@JukanPC>
References: <423830b0811090311i4fd12019j44c888a73ac68f27@mail.gmail.com>
	<4916CA07.2010008@googlemail.com>
	<575E98E041AC455F8E133EA9BEDFAB67@JukanPC>
Message-ID: <423830b0811092253l701ab43o8d3513e791149ae6@mail.gmail.com>

(whatwg, please see last bit.)


2008/11/9 Jukka K. Korpela <jkorpela at cs.tut.fi>:
> Benjamin Hawkes-Lewis wrote:
>
>> Paul Arzul wrote:
>>>
>>> CSS defines when properties are applicable (see the Applies column:
>>> <http://www.w3.org/TR/CSS21/propidx.html>)
>>>
>>> Should we generate warnings when properties are not applicable? For
>>> example: p
>>> {
>>>    border-collapse : collapse;
>>> }
>>>
>>> We could warn about the paragraph not being a table or inline-table
>>> element. (I get no warnings with Warnings set to All.)
>>
>> That would only be reliable if one could assume default CSS for HTML
>> and that p was an HTML element rather than an element in some random
>> XML dialect - but you can't assume either from the raw CSS.

i thought you could with css namespaces: http://www.w3.org/TR/css3-namespace/

please don't loose sight of the most common use case - an html file
with some css. are the css validator's web logs public? what do they
have to say? i'd love to know:

* how much css is validated off non-xhtml xml and how much is (x)html?
* how much traction css namespaces are getting


> Even in that case, the assumptions might fail because the document has
> intentionally been written or styled against your expectations.

i wasn't making assumptions. i was expecting the validator to check
against a running total (computed) value and not a static list which
is but a starting point for default values.


> But you _could_ issue warnings that are solely based on applicability
> statements made within CSS specs. For example, you could check whether the
> display property has the value table and if not, issue a non-applicability
> warning about border-collapse. Of course this means that you would need to
> include some assumed default browser style sheet, so that you know (or think
> you know) the default values for the display property of different elements,
> for example.

we could use the "Default style sheet for HTML 4":
http://www.w3.org/TR/CSS21/sample.html

some research against common browsers's user agent stylesheets should
be done to check for any serious discrepancies.


> Besides, you cannot really know the properties of an element by analyzing
> one style sheet only, even if you assume that the document is HTML. Any
> other style sheet (that will be used when rendering the document, along with
> the style sheet being analyzed) might assign display: table, making
> border-collapse applicable.

(i suggested a warning, not an error.) as always the cascade applies,
but it is still useful to know that a single css file is generating
warnings since someone else might decide to include it without
following your imports. we could also recommend validating from the
root/base html or css due to cascade implications.


>> The validator could include additional UI (e.g. checkboxes to indicate
>> that this CSS if for HTML and the valiator should assume the suggested
>> default CSS from CSS 2.1) that would mitigate those problems.
>
> I have no specific objections, but who is going to define what is and what
> is not applicable to different elements then?

is it unfortunate that the html4 stylesheet is only informative?
perhaps html5 could then consider giving us a normative default user
agent stylesheet - or at least a normative version with only display
properties.

- p


From vladimir at pobox.com  Mon Nov 10 00:05:30 2008
From: vladimir at pobox.com (Vladimir Vukicevic)
Date: Mon, 10 Nov 2008 00:05:30 -0800
Subject: [whatwg] Canvas performance issue: setting colors
In-Reply-To: <9AA03364-8B25-49F1-9E38-E8C7F2CE816F@apple.com>
References: <2A23FA39-E159-455B-99AE-FB09D582F820@w3future.com>
	<68fba5c50810031611x606a0188rbbabb8ddbee6c07@mail.gmail.com>
	<9AA03364-8B25-49F1-9E38-E8C7F2CE816F@apple.com>
Message-ID: <4917EB4A.1080408@pobox.com>

On 10/3/08 4:37 PM, Oliver Hunt wrote:
> <thinking out loud>
> Just had a thought (no idea how original) -- how about if fillStyle were
> able to accept a 3 or 4 number array? eg. fillStyle = [0, 0.3, 0.6, 1.0] ?
>
> That might work well if people are using arrays as vectors/colours
> </thinking out loud>

I actually have a patch sitting around that starts to do this -- I never 
got around to proposing it to the list.  Parsing CSS-style color names 
is certainly flexible, but given that 99.9% of uses are going to be rgb 
or rgba, I'd agree that [r, g, b] or [r, g, b, a] should be accepted as 
colors (in the range of 0.0 to 1.0) wherever colors are accepted in the 
canvas API..

    - Vlad


From tommy at kvaleberg.com  Mon Nov 10 02:51:34 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Mon, 10 Nov 2008 11:51:34 +0100
Subject: [whatwg] Handling <title> inside <body>
Message-ID: <49181236.7080105@kvaleberg.no>

I noticed that, according to the html5 algorithm, when the parser sees a 
<title> start tag when in the "in body" insertion mode, it's not 
supposed to relocate it to the head element. Opera matches this 
behaviour, but Firefox moves any title tag  it finds into the head element.

The description of the title element in the spec ("4.2.2 The title 
element") says:

    Contexts in which this element may be used:
        In a head element containing no other title elements.

I don't care very strongly about whether or not title elements are 
allowed anywhere, but I do think the output of the parsing algorithm 
should be valid html according to the rest of the spec. So, in my 
opinion, we need to change either the allowed context of the title 
element, or the parsing algorithm.

I think everything I've said about the <title> element also applies to 
the <base> element.


FWIW: In our implementation, I've changed the handling of "base" and 
"title" in "in body" to:

    Process the token using the rules for the "after head" insertion mode.

instead of processing them with the rules for "in head".


Best regards,
Tommy


From tommy at kvaleberg.com  Mon Nov 10 04:23:44 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Mon, 10 Nov 2008 13:23:44 +0100
Subject: [whatwg] li start tag algorithm clarification.
Message-ID: <491827D0.7020008@kvaleberg.no>

In the handler for 'A start tag whose tag name is "li"' in "in body", 
the algorithm says "jump to the last step" in a couple of places. Is 
"the last step" step 5, or is it the final unnumbered step which says, 
"Finally, insert an HTML element for the token"?

I suggest, to make this clearer, that we give the final step a number 
(the number 6 comes to mind) and change "jump to the last step" to "jump 
to step 5/6".

This also goes for the next section (the one called 'A start tag whose 
name is one of: "dd", "dt"').


regards,
Tommy


From simonp at opera.com  Mon Nov 10 04:59:30 2008
From: simonp at opera.com (Simon Pieters)
Date: Mon, 10 Nov 2008 13:59:30 +0100
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <49181236.7080105@kvaleberg.no>
References: <49181236.7080105@kvaleberg.no>
Message-ID: <op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>

On Mon, 10 Nov 2008 11:51:34 +0100, Tommy Thorsen <tommy at kvaleberg.com>  
wrote:

> I noticed that, according to the html5 algorithm, when the parser sees a  
> <title> start tag when in the "in body" insertion mode, it's not  
> supposed to relocate it to the head element. Opera matches this  
> behaviour, but Firefox moves any title tag  it finds into the head  
> element.

HTML5 used to match Firefox, but changed since, IIRC, Mozilla said they  
considered their behavior a bug and would change to match Opera.


> The description of the title element in the spec ("4.2.2 The title  
> element") says:
>
>     Contexts in which this element may be used:
>         In a head element containing no other title elements.
>
> I don't care very strongly about whether or not title elements are  
> allowed anywhere, but I do think the output of the parsing algorithm  
> should be valid html according to the rest of the spec.

Why?


> I think everything I've said about the <title> element also applies to  
> the <base> element.
>
>
> FWIW: In our implementation, I've changed the handling of "base" and  
> "title" in "in body" to:
>
>     Process the token using the rules for the "after head" insertion  
> mode.
>
> instead of processing them with the rules for "in head".

This doesn't result in "valid HTML" when there are multiple <title>s or  
<base>s or when the <base> doesn't have "either an href attribute, a  
target attribute, or both" or where the <base> element's href doesn't  
"contain a valid URL" or when the element doesn't "come before any other  
elements in the tree that have attributes defined as taking URLs", and so  
forth.

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-base-element

Not to mention cases where the notion of "valid HTML" depends on external  
resources or the author's intent (e.g. <img>).

-- 
Simon Pieters
Opera Software


From tommy at kvaleberg.com  Mon Nov 10 06:31:48 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Mon, 10 Nov 2008 15:31:48 +0100
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
References: <49181236.7080105@kvaleberg.no>
	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
Message-ID: <491845D4.1000908@kvaleberg.no>

Simon Pieters wrote:
>> The description of the title element in the spec ("4.2.2 The title 
>> element") says:
>>
>>     Contexts in which this element may be used:
>>         In a head element containing no other title elements.
>>
>> I don't care very strongly about whether or not title elements are 
>> allowed anywhere, but I do think the output of the parsing algorithm 
>> should be valid html according to the rest of the spec.
>
> Why?
>
Hmm. Good question. If not, then why do we do foster parenting at all?

 From an implementors point of view, it's good to have clearly defined 
boundaries between modules. An implementation would typically have one 
module that tokenises and parses html and one module that renders the 
resulting dom to the screen. If all the unexpected input is dealt with 
in the parsing module, then you can make some assumptions in the 
rendering module which can greatly simplify the implementation. Having 
to deal with an arbitrary amount of illegal input in either module is, 
IMHO, not the ideal design.

That being said, if Opera has the specified behaviour and Firefox is 
switching to it, then I'm no way near stubborn enough to keep arguing. 
As long as I'm reassured this is a concious decision and not an 
oversight on whatwg's part, I'll just go ahead and implement it after 
the spec.


From simonp at opera.com  Mon Nov 10 06:43:24 2008
From: simonp at opera.com (Simon Pieters)
Date: Mon, 10 Nov 2008 15:43:24 +0100
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <491845D4.1000908@kvaleberg.no>
References: <49181236.7080105@kvaleberg.no>
	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
	<491845D4.1000908@kvaleberg.no>
Message-ID: <op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>

On Mon, 10 Nov 2008 15:31:48 +0100, Tommy Thorsen <tommy at kvaleberg.com>  
wrote:

> Simon Pieters wrote:
>>> The description of the title element in the spec ("4.2.2 The title  
>>> element") says:
>>>
>>>     Contexts in which this element may be used:
>>>         In a head element containing no other title elements.
>>>
>>> I don't care very strongly about whether or not title elements are  
>>> allowed anywhere, but I do think the output of the parsing algorithm  
>>> should be valid html according to the rest of the spec.
>>
>> Why?
>>
> Hmm. Good question. If not, then why do we do foster parenting at all?

For Web compat. It's what browsers do. (IE and Opera don't foster parent  
but have magic <caption>-like elements around non-table content which  
makes it render pretty much the same.)


>  From an implementors point of view, it's good to have clearly defined  
> boundaries between modules. An implementation would typically have one  
> module that tokenises and parses html and one module that renders the  
> resulting dom to the screen. If all the unexpected input is dealt with  
> in the parsing module, then you can make some assumptions in the  
> rendering module which can greatly simplify the implementation. Having  
> to deal with an arbitrary amount of illegal input in either module is,  
> IMHO, not the ideal design.

When you support XHTML you'll have to deal with arbitrary trees anyway.  
And, actually, just with DOM and scripting you can end up with arbitrary  
trees.

-- 
Simon Pieters
Opera Software


From jackalmage at gmail.com  Mon Nov 10 07:00:43 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 10 Nov 2008 09:00:43 -0600
Subject: [whatwg] Format issue on the spec: unreadable (or hardly
	readable) text.
In-Reply-To: <6ea53250811091810j2956a965n796c4244a03d33ff@mail.gmail.com>
References: <6ea53250811091810j2956a965n796c4244a03d33ff@mail.gmail.com>
Message-ID: <dd0fbad0811100700i4ecee635ib161839f59fedb61@mail.gmail.com>

On Sun, Nov 9, 2008 at 8:10 PM, Eduard Pascual <herenvardo at gmail.com> wrote:

> I can't say for sure if this is an issue from the spec document
> itself, or just a rendering bug on my browser (FF 3.0.3), but here it
> goes:
> Within the section "4.3.1 The script element", on the algorythm
> labeled "Running a script", step 6, the text for the first "condition"
> shows overlapped, each line covering part of the text in the previous
> line. I have put a screenshot on
> http://herenvardo.googlepages.com/brokentext.png just for case anyone
> wants to see it.
> So, unless it is actually a FF bug, I hope someone fixes it.
> Actually, I *can* read half-visible text like that, but even being
> used to do that it still takes some extra effort from my eyes and
> brain. And I wouldn't expect everyone reading the spec to be used to
> look at scrambled text.
>

That's not an FF bug, it's a styling bug.  That line has class="XXX", which
gives it a bit of padding, a fat red border, and 1em of margin on top and
bottom.  However, inline elements ignore margins, so the border just
overlaps the surrounding line boxes instead.  Ian should change his styling
to make sure that any element which receives classes "XXX" or "big-issue"
are display: block.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081110/d6a22f33/attachment.htm>

From ian at hixie.ch  Mon Nov 10 07:39:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 10 Nov 2008 15:39:15 +0000 (UTC)
Subject: [whatwg] Format issue on the spec: unreadable (or hardly
 readable) text.
In-Reply-To: <6ea53250811091810j2956a965n796c4244a03d33ff@mail.gmail.com>
References: <6ea53250811091810j2956a965n796c4244a03d33ff@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811101538480.1041@hixie.dreamhostps.com>

On Mon, 10 Nov 2008, Eduard Pascual wrote:
>
> I can't say for sure if this is an issue from the spec document
> itself, or just a rendering bug on my browser (FF 3.0.3), but here it
> goes:
> Within the section "4.3.1 The script element", on the algorythm
> labeled "Running a script", step 6, the text for the first "condition"
> shows overlapped, each line covering part of the text in the previous
> line. I have put a screenshot on
> http://herenvardo.googlepages.com/brokentext.png just for case anyone
> wants to see it.
> So, unless it is actually a FF bug, I hope someone fixes it.
> Actually, I *can* read half-visible text like that, but even being
> used to do that it still takes some extra effort from my eyes and
> brain. And I wouldn't expect everyone reading the spec to be used to
> look at scrambled text.

It'll be fixed when I fix the issue given in the red box. In the meantime, 
apologies for the inconvenience.

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


From ian at hixie.ch  Mon Nov 10 07:59:54 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 10 Nov 2008 15:59:54 +0000 (UTC)
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
References: <49181236.7080105@kvaleberg.no>
	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
	<491845D4.1000908@kvaleberg.no>
	<op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>

On Mon, 10 Nov 2008, Tommy Thorsen wrote:
>
> I don't care very strongly about whether or not title elements are 
> allowed anywhere, but I do think the output of the parsing algorithm 
> should be valid html according to the rest of the spec. So, in my 
> opinion, we need to change either the allowed context of the title 
> element, or the parsing algorithm.

There are a bazillion ways in which the parser algorithm will result in 
non-conforming DOM trees given non-conforming input. There's not really 
any way we can change that given our constraints of being compatible with 
legacy markup.


> FWIW: In our implementation, I've changed the handling of "base" and 
> "title" in "in body" to:
> 
>    Process the token using the rules for the "after head" insertion 
>    mode.
> 
> instead of processing them with the rules for "in head".

Unless there are pages that depend on this (are there?), I'm very 
reluctant to change the spec in this way.


On Mon, 10 Nov 2008, Tommy Thorsen wrote:
> 
> From an implementors point of view, it's good to have clearly defined 
> boundaries between modules. An implementation would typically have one 
> module that tokenises and parses html and one module that renders the 
> resulting dom to the screen. If all the unexpected input is dealt with 
> in the parsing module, then you can make some assumptions in the 
> rendering module which can greatly simplify the implementation. Having 
> to deal with an arbitrary amount of illegal input in either module is, 
> IMHO, not the ideal design.

Unfortunately, we have little choice in the matter. Scripting and XML both 
allow you to unambiguously create highly non-conforming DOMs, e.g. with 
<title> elements as the root element and <html> elements as children of 
<input> elements. The renderer has to deal with all such DOMs.

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


From herenvardo at gmail.com  Mon Nov 10 08:38:52 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Mon, 10 Nov 2008 16:38:52 +0000
Subject: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
In-Reply-To: <2C32028C7AF94D0AA1C4998F3380297A@Sanktum01>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<2CFB8CC50DA845DD873E962FD28F80DF@Sanktum01>
	<5b04ec2d0811050700m2aa92046ke717ee739511c6b7@mail.gmail.com>
	<f042876c0811051247q7735952fm16a79b4cbee415d1@mail.gmail.com>
	<6ea53250811081556h3b083214ka63f23a2a080a1f9@mail.gmail.com>
	<Pine.LNX.4.62.0811091547280.1041@hixie.dreamhostps.com>
	<6ea53250811091020l8aac03p702e4a8f4e3d2bc2@mail.gmail.com>
	<C723E1A1BCD741A18A7E6B75CFCFB181@Sanktum01>
	<6ea53250811091755vd6c05a6p405aac60fd81843f@mail.gmail.com>
	<2C32028C7AF94D0AA1C4998F3380297A@Sanktum01>
Message-ID: <6ea53250811100838x69bd56b4m31c519a4b8da0c4c@mail.gmail.com>

On Mon, Nov 10, 2008 at 2:57 PM, Pentasis <pentasis at lavabit.com> wrote:
> Hi,
>
> I seem to have a few problems here, but nothing I cannot handle. For some
> reason I get my e-mails later than I should and they are working on the
> electricity grid here, so I have no power during the day (only at night).
> On the other hand that gave me some time today to think about ti and I
> already wrote some stuff down on paper. I will type it tonight. What
> file-type do you prefer, is word 95 ok?

I'd rather suggest plain text or, if you really need some formatting,
html. After all, it would be a quite reasonable assumption that most
people in the list can view HTML documents, but it wouldn't be too
safe to asume they can view word proprietary format; and even if they
can, it can sometimes take some extra work to do so (for example,
loading it into Google Docs or the like), and the final document would
be significantly bigger in .doc than in .html.
Just my opinion.


From jkorpela at cs.tut.fi  Mon Nov 10 10:01:00 2008
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Mon, 10 Nov 2008 20:01:00 +0200
Subject: [whatwg] Warnings for non-applicable properties
In-Reply-To: <423830b0811092253l701ab43o8d3513e791149ae6@mail.gmail.com>
References: <423830b0811090311i4fd12019j44c888a73ac68f27@mail.gmail.com>
	<4916CA07.2010008@googlemail.com>
	<575E98E041AC455F8E133EA9BEDFAB67@JukanPC>
	<423830b0811092253l701ab43o8d3513e791149ae6@mail.gmail.com>
Message-ID: <59AB96F28A6A480EB7678939E2AD9C8E@JukanPC>

Paul Arzul wrote:

> we could use the "Default style sheet for HTML 4":
> http://www.w3.org/TR/CSS21/sample.html

That style sheet is purported to be both descriptive and prescriptive (read 
the prelude carefully, and you'll see how messed-up it is). In reality, it 
is neither. No browser implements it (though most parts thereof are more or 
less consistent with real practices). Nobody who reads it with his brain 
turned on thinks it _should_ be implemented - it has obscurities and poor 
practices.

> some research against common browsers's user agent stylesheets should
> be done to check for any serious discrepancies.

I don't think so. What good would it do? It is useful for using CSS (I did 
some serious work on this for my book on CSS), but that's not a "validation" 
issue or even a "lint" issue. We should expect and accept that browsers 
differ.

> as always the cascade applies,

As always, most people either misunderstand or forget the cascade. The 
cascade is the most complex and most controversial part of CSS, but it's 
there.

> but it is still useful to know that a single css file is generating
> warnings

Is it? I mean when the warnings are based on the assumption that the style 
sheet is used in isolation. Useful analysis could be performed by a 
_browser_, which can determine all the style sheets it is applying. So such 
kind of checking is best performed by a real browser, not a checker program. 
It's something that should be implemented as an addition or a plug-in to 
Firefox, for example, rather than a standalone utility by W3C for example.

-> is it unfortunate that the html4 stylesheet is only informative?

No, but it is unfortunate that it does not say this clearly and it does not 
say what it tries to inform. It claims to be informative, and next it tells 
browser vendors to implement it. Sigh.

> perhaps html5 could then consider giving us a normative default user
> agent stylesheet - or at least a normative version with only display
> properties.

Various HTML specs have made notes about "typical rendering" and even 
suggested rendering, usually in an ill-advised manner. Such statements have 
always been taken a stronger than intended. Moreover, the suggested 
rendering is usually lousy. Who invented the idea of having equal spacing 
above and under a heading, empty lines between paragraphs, large indents for 
lists, and nonzero cellspacing? People who design markup languages need not 
be experts in typography, and they usually aren't even good at it. People 
who implement markup languages should include experts in typography, but we 
all know how it goes. Anyway, no specification should fix some sloppily 
written default rendering rules as "correct", thereby declaring good 
typography as anathema.

P.S. One of the most common problems with property settings that get ignored 
(by conforming browsers) is that some properties, such as width, are set for 
non-replaced inline elements even though they don't apply to them. Catching 
these could be useful, but how would you do that? It's not even clear what 
elements are non-replaced inline elements by default. Moreover, any <span> 
or <a> can become a block element just with the magic of display: block, and 
this is fairly common. And to know whether such a magic applies to a given 
element, you really need to process and _interpret_ all the style sheets 
that apply.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/ 



From mpt at myrealbox.com  Mon Nov 10 12:46:05 2008
From: mpt at myrealbox.com (Matthew Paul Thomas)
Date: Mon, 10 Nov 2008 20:46:05 +0000
Subject: [whatwg] ---
In-Reply-To: <6ea53250811051632h1f5de1a0u20c33d7845bbf635@mail.gmail.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01>
	<491173CA.9070506@gmx.ch>
	<6ea53250811051632h1f5de1a0u20c33d7845bbf635@mail.gmail.com>
Message-ID: <2c979fe1c9f365be6a27e29e1e57a5c8@myrealbox.com>

On Nov 6, 2008, at 12:32 AM, Eduard Pascual wrote:
> ...
> Initially, HTML was entirely structural: no presentation, and no
> semantics. Just paragraphs, headings, anchors, and few other things.
> ...

The earliest surviving HTML draft from 1992 includes the <PLAINTEXT>  
and <LISTING> elements, both entirely presentational.  
<http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/ 
Tags.html>

HTML+ in 1993 went further: "In many cases it is convenient to indicate  
directly how the text is to be rendered, e.g. as italic, bold,  
underline or strike-through".  
<http://www.w3.org/MarkUp/HTMLPlus/htmlplus_16.html> Those  
presentational elements continued into HTML 2.0.

HTML has always been a dance between structure and presentation. Too  
structural, and humans won't understand it; too presentational, and  
computers won't understand it.

-- 
Matthew Paul Thomas
http://mpt.net.nz/


---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---



From ian at hixie.ch  Mon Nov 10 12:47:28 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 10 Nov 2008 20:47:28 +0000 (UTC)
Subject: [whatwg] Select element suggestion
In-Reply-To: <421209.22740.qm@web32606.mail.mud.yahoo.com>
References: <421209.22740.qm@web32606.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.62.0811102045530.1237@hixie.dreamhostps.com>

On Tue, 15 Jul 2008, Csaba Gabor wrote:
> 
> It is frequently the case that SELECT elements of size 1 (drop downs) are quite long, requiring scrolling to reach most of the options.  For example:
> Year a person was born in
> States of the US
> Countries of the world
> Height (in inches or cm)
> 
> This necessitates a minimum of 4 actions for most of the options (click 
> to pull down the select, click on scroll bar, drag scroll bar, click 
> desired option) vs. 2 actions (the first and last) for those options 
> near the top.  Clearly the time difference is significant, especially 
> when the same select element must be selected on repeated visits.  
> Furthermore, the overwhelming liklihood is that only a few of the many 
> options will ever be of interest to any individual.
> 
> Therefore, it makes sense to float those values to the top of the select 
> element in a reasonable way.

This seems like something the user agent could do on its own without help 
from the page, or that the server could do on its own without help from 
the client. I'm not sure that the language needs to be adjusted to support 
this idea.

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


From ian at hixie.ch  Mon Nov 10 12:50:37 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 10 Nov 2008 20:50:37 +0000 (UTC)
Subject: [whatwg] Errormessages in forms
In-Reply-To: <op.uj5lwkoro84pey@pc08.ebrana.cz>
References: <4884D7DC.7030909@keryx.se>
	<Pine.LNX.4.62.0811051523410.1237@hixie.dreamhostps.com>
	<op.uj5lwkoro84pey@pc08.ebrana.cz>
Message-ID: <Pine.LNX.4.62.0811102049080.1237@hixie.dreamhostps.com>

On Wed, 5 Nov 2008, Old?ich Vete?n?k wrote:
> 
> It would be awesome if something like this would be possible:
> 
> <label for="idfield">Instructions</label>
> <input name="idfield" id="idfield">
> <error for="idfield">Must be a valid value</error>

You can use <output> for this purpose at this point.


> And to further enhance this futuristic view:
> 
> <label for="idfield">Instructions</label>
> <input name="idfield" id="idfield">
> <hint for="idfield">Type in dd-mm-yyyy format</hint>
> <error for="idfield">Must be a valid value</error> (if error is true)
> 
> What do you think about it? :)

This seems excessively complicated and I'm not convinced there is really a 
problem to solve here. Just using plain text seems enough.

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

From ian at hixie.ch  Mon Nov 10 12:52:55 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 10 Nov 2008 20:52:55 +0000 (UTC)
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811102051400.1237@hixie.dreamhostps.com>

On Tue, 29 Jul 2008, Garrett Smith wrote:
>
> I took a brief look at the WF 2.0 document yesterday and found some
> serious misconceptions and examples of "programming by coincidence."
> These reflect very poorly on html5.
> 
> The errors can be found on the link:
> http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
> 
> Doc Bugs:
> 1) Treating a a form element as an HTMLCollection.
> 2) The use of - with - to augment the scope chain is not necessary.
> 3) Calling the "elements" HTMLCollection an "array"
> 
> (1) The definition of HTMLFormElement does not have a specialized 
> [[Get]] for element names (nor should there be, as this is known to be 
> problematic). The example in the documetation depends on such behavior.

It actually does at this point.


> (2) - with - augments the scope chain with the object. This is 
> completely unnecessary here and will create problems if, for example, 
> there is an element named "watch". It is a bad practice and I see this 
> influence in the popular libraries.

This is a non-issue in the HTML5 spec, it seems.


> (3) There is no specification for a special [[Get]] for the "elements" 
> HTMLCollection as a shortcut to "namedItem", either (though this would 
> not seem to be a problem, and all implementations have supported this 
> behavior for quite a long time). I did notice that the elements 
> collection is mistakenly called an 'array'. This is a serious 
> documentation mistake of the worst kind: The spreading of 
> misinformation. It will continue influence the muddy knowledge that is 
> so common among most developers who tend want to call "push" et c 
> directly on that NodeList object (see the "dojo.NodeList" for details). 
> The elements Collection should be called an HTMLCollection and this 
> should be changed immediately.

Is this all resolved in HTML5?

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


From ian at hixie.ch  Mon Nov 10 12:56:47 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 10 Nov 2008 20:56:47 +0000 (UTC)
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808141815n7ad99649v59501f538d40a416@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com> 
	<c9e12660808041046m5f96b6f2qd929935714263b2b@mail.gmail.com> 
	<D5371802747748F0968F905E90058F3B@POCZTOWIEC> 
	<Pine.LNX.4.62.0808132101390.5136@hixie.dreamhostps.com>
	<c9e12660808141815n7ad99649v59501f538d40a416@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811102054140.1237@hixie.dreamhostps.com>

On Thu, 14 Aug 2008, Garrett Smith wrote:
>
> There is no note in the WF 2.0 specification, nor the HTML 4.01, nor the 
> HTML DOM specifications that an element should not be named "submit" or 
> "action" to avoid such consequences. Was this considered?

I don't think we want to limit these names, since this would be an 
unbounded set of names that made older documents non-conforming as the 
language evolved.


> What is the decision for advocating the coding practice of 
> form-as-collection?

It's convenient.


> What is the rationale for standardizing it?

Browsers support it.


> The implied expectation of the specification is that the values for 
> form.action and form.submit will be replaced by elements of the 
> corresponding name. It could be expected that an element named "length" 
> or "tagName" would create a "length" property on the form, except for 
> the fact that form.length is defined as readonly[1] in another 
> specification. What should happen in that case? Can a readonly property 
> be replaced? What is the suggested approach for submitting to an API 
> that requires a parameter named "submit" or "action"?

WebIDL will define these cases.

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


From ian at hixie.ch  Mon Nov 10 13:01:02 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 10 Nov 2008 21:01:02 +0000 (UTC)
Subject: [whatwg] input=datetime and unixtime?
In-Reply-To: <dd0fbad0807301515g1b327d43ve2269578f1754545@mail.gmail.com>
References: <dd0fbad0807301515g1b327d43ve2269578f1754545@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811102058200.1237@hixie.dreamhostps.com>

On Wed, 30 Jul 2008, Tab Atkins Jr. wrote:
>
> I did some searching through the archives, but didn't find anything at 
> all that talked about this.  Out of curiousity, was there a reason that 
> datetime doesn't store/send it's value as a unix timestamp?  True, the 
> standard unixtime unit is insufficient for representing a useful range 
> of dates, but systems are gradually moving toward representing unixtime 
> with a 64-bit integer.

The main reason for using the human-readable form is that we want the 
value="" attribute to be human-writable, and we want the value="" 
attribute value to be round-trippable in down-level clients.

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


From herenvardo at gmail.com  Mon Nov 10 14:34:46 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Mon, 10 Nov 2008 22:34:46 +0000
Subject: [whatwg] ---
In-Reply-To: <2c979fe1c9f365be6a27e29e1e57a5c8@myrealbox.com>
References: <mailman.78021.1225818125.26350.whatwg-whatwg.org@lists.whatwg.org>
	<5F72A897C4E14A23BBD26E332702CF17@Sanktum01>
	<e72b1b360811040936tc2d8003u2d62a1abd0cece65@mail.gmail.com>
	<38E1F08350454A6391AB0F6D39A64E0E@Sanktum01>
	<0D5B4DE4-C1F7-4C27-99CD-373783098690@apple.com>
	<5CC94CDA61C841EDBD9FC3F152C2F63C@Sanktum01> <491173CA.9070506@gmx.ch>
	<6ea53250811051632h1f5de1a0u20c33d7845bbf635@mail.gmail.com>
	<2c979fe1c9f365be6a27e29e1e57a5c8@myrealbox.com>
Message-ID: <6ea53250811101434p6d525015i8dd0e6ac250265bc@mail.gmail.com>

On Mon, Nov 10, 2008 at 8:46 PM, Matthew Paul Thomas <mpt at myrealbox.com> wrote:
> The earliest surviving HTML draft from 1992 includes the <PLAINTEXT> and
> <LISTING> elements, both entirely presentational.
> <http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html>
<PLAINTEXT> was aimed to mark the end of hypertext in a document,
hence the contents beyond it were to be treated as plain text instead,
ignoring anything that could look like markup. That's quite
structural, IMO. The fact that the draft described an obvious
preferable rendering (intended to make the plain text stand out as
plain text) doesn't make it "entirely presentational": if that were
the case, almost all elements described there would be presentational.
The case of <LISTING> is more of the same: it was intended to denote
listings (such as code, terminal output, or directory listings), hence
the name, and the draft proposed using monospaced rendering for this
element because it generally makes these kinds of listings much easier
to read.
On both cases, the elements are quite structural, and the rendering
described in the draft is simply an obvious consequence of the kind of
structure denoted by them.

> HTML+ in 1993 went further: "In many cases it is convenient to indicate
> directly how the text is to be rendered, e.g. as italic, bold, underline or
> strike-through". <http://www.w3.org/MarkUp/HTMLPlus/htmlplus_16.html> Those
> presentational elements continued into HTML 2.0.
I wouldn't take too seriously specs that never went beyond the "draft"
stage, but if you insist, it'd be interesting to point out that in the
introduction of the HTML+ proposal those elements were described as
mere "hints".
About those elements "continuing" into HTML 2.0, it's worth saying
that only three of them (<i>, <b>, and <tt>) were actually included in
that version, and for all of them the spec allowed for "alternative
representation"
(http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.7.2).

> HTML has always been a dance between structure and presentation. Too
> structural, and humans won't understand it; too presentational, and
> computers won't understand it.
It hasn't been such a dance: there were a few presentational elements
at the beginning, because there was a need to describe the
presentation for such cases; then when the presentational needs became
more exigent there was an attempt (known as 3.2) to make the language
presentational, which soundly failed; and thanks to this failure the
W3C realized that HTML couldn't be the solution to these
presentational needs, hence they created CSS and added some hooking
and embeeding mechanisms in HTML4. All the presentational stuff that
is still in HTML after 3.2 is only retained for compatibility with
older documents. If there was a dance, it was a quite short one.
Actually, it's easier for most humans to understand a document with a
clear structure than a non-sense of eye-bleeding presentational
tag-soup. Of course, presentation can help humans understanding a
document, but it works best when it's used to highlight and emphasize
the structure of the document. I'm afraid you are understimating
humans.
And, besides that, computers actually "understand" completely
presentational markup: they understand that something is italic,
something is underlined, and some chunk of text is red and
right-aligned. Of course, they won't be able to figure out why is
something italic, or underlined, or red; but that's not because a
limitation of the machines, it's simply because the document doesn't
really convey that information.

Besides all of this, may I ask you what was the point of your message?
I mean, I hope I understood the contents, but I fail to see the intent
of it: you just quoted a small comment and tried to prove wrong a
point that, even if it is indeed wrong, was not the main point of that
comment; mostly because it was taken as the basis for a comparison.
Actually, after reviewing in more dept these "pre-histroric" specs, I
now see the paralelism between presentation and semantics even more
obvious.

Greetings,
Eduard Pascual


From robert at ocallahan.org  Mon Nov 10 18:50:37 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 11 Nov 2008 15:50:37 +1300
Subject: [whatwg] Same-origin checking for media elements
Message-ID: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>

Should <video> and <audio> elements be able to load and play resources from
other origins?

Perhaps Ian thinks not:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
There's a to-and-fro discussion here:
http://lists.xiph.org/pipermail/theora/2008-November/001931.html
Jonas got involved here:
http://lists.xiph.org/pipermail/theora/2008-November/001958.html

There are three obvious options:
1) Allow unrestricted cross-origin <video>/<audio>
2) Allow cross-origin <video>/<audio> but carefully restrict the API to
limit the information a page can get about media loaded from a different
origin
3) Disallow cross-origin <video>/<audio> unless the media server explicitly
allows it via the Access Control spec (e.g. by sending the
"Access-Control-Allow-Origin: *" header).

The reason to allow cross-origin playback is obvious: it's most convenient
for authors. At this point in time few, if any, major file hosting sites
support Access Controls in any way.

Reasons to disallow cross-origin playback are a little less obvious. The
main issue is the need to avoid leaking information from, say,
intranet.example.com when an example.com user visits evil.com. The threat is
that an evil.com page tries to guess a URL in intranet.example.com, load it
via <video>/<audio>, and get information about the file via the APIs on
those elements. For example, currently Firefox reports progress events
containing the size of the file; but we don't want to allow people to probe
for the file sizes of intranet files. Ideally we would conceal whether the
cross-origin resource even exists. We may want to evolve <video>/<audio> to
include features like reporting of cues and caption data to the enclosing
page --- data that seem extremely unwise to expose cross-origin.

One thing to keep in mind is the possibility of someone using cross-origin
<iframe src="http://example.com/video.ogg">. (This works in Firefox today.)
This prevents access to the <video> element API and basically reduces the
information leakage and attack surface to that of iframes. We might want to
place restrictions on such iframe usage, to give server operators control
over their bandwidth. That's a secondary question if options 2 or 3 are
preferred.

Another thing to keep in mind is that plugins such as Quicktime allow
cross-origin loads without restrictions. We don't want to put <video> at an
authoring disadvantage. On the other hand, being just as secure as plugins
may not be satisfactory, and we want a richer in-page scripting API than
plugins tend to offer.

We've had some discussion inside Mozilla (with no consensus reached), and
some discussion with the Theora folks, but really it's a cross-browser issue
that we need to interoperate on, so I think WHATWG is a more appropriate
place to discuss it. And it's something that should be settled soon since
Safari shipped a while ago and we'll ship soon.

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/20081111/89472f85/attachment.htm>

From mjs at apple.com  Mon Nov 10 19:49:35 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Mon, 10 Nov 2008 19:49:35 -0800
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
Message-ID: <D48E66E8-FEF4-40A1-9898-F2707124C40A@apple.com>


On Nov 10, 2008, at 6:50 PM, Robert O'Callahan wrote:

> Should <video> and <audio> elements be able to load and play  
> resources from other origins?
>
> Perhaps Ian thinks not:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
> There's a to-and-fro discussion here:
> http://lists.xiph.org/pipermail/theora/2008-November/001931.html
> Jonas got involved here:
> http://lists.xiph.org/pipermail/theora/2008-November/001958.html
>
> There are three obvious options:
> 1) Allow unrestricted cross-origin <video>/<audio>
> 2) Allow cross-origin <video>/<audio> but carefully restrict the API  
> to limit the information a page can get about media loaded from a  
> different origin
> 3) Disallow cross-origin <video>/<audio> unless the media server  
> explicitly allows it via the Access Control spec (e.g. by sending  
> the "Access-Control-Allow-Origin: *" header).

I'd prefer 1 or 2 (assuming the restrictions assumed by 2 are  
reasonable).

> The reason to allow cross-origin playback is obvious: it's most  
> convenient for authors. At this point in time few, if any, major  
> file hosting sites support Access Controls in any way.
>
> Reasons to disallow cross-origin playback are a little less obvious.  
> The main issue is the need to avoid leaking information from, say,  
> intranet.example.com when an example.com user visits evil.com. The  
> threat is that an evil.com page tries to guess a URL in  
> intranet.example.com, load it via <video>/<audio>, and get  
> information about the file via the APIs on those elements. For  
> example, currently Firefox reports progress events containing the  
> size of the file; but we don't want to allow people to probe for the  
> file sizes of intranet files. Ideally we would conceal whether the  
> cross-origin resource even exists. We may want to evolve <video>/ 
> <audio> to include features like reporting of cues and caption data  
> to the enclosing page --- data that seem extremely unwise to expose  
> cross-origin.
>
> One thing to keep in mind is the possibility of someone using cross- 
> origin <iframe src="http://example.com/video.ogg">. (This works in  
> Firefox today.) This prevents access to the <video> element API and  
> basically reduces the information leakage and attack surface to that  
> of iframes. We might want to place restrictions on such iframe  
> usage, to give server operators control over their bandwidth. That's  
> a secondary question if options 2 or 3 are preferred.
>
> Another thing to keep in mind is that plugins such as Quicktime  
> allow cross-origin loads without restrictions. We don't want to put  
> <video> at an authoring disadvantage. On the other hand, being just  
> as secure as plugins may not be satisfactory, and we want a richer  
> in-page scripting API than plugins tend to offer.

QuickTime offers a fairly rich API; in fact many things now in the  
<video>/<audio> API were partly inspired by the API of the QuickTime  
plugin, when Apple proposed them. And the newest QuickTime plugin is  
being updated to be even closer to the HTML5 media element API.

> We've had some discussion inside Mozilla (with no consensus  
> reached), and some discussion with the Theora folks, but really it's  
> a cross-browser issue that we need to interoperate on, so I think  
> WHATWG is a more appropriate place to discuss it. And it's something  
> that should be settled soon since Safari shipped a while ago and  
> we'll ship soon.

I agree, the behavior should be interoperable.

Regards,
Maciej

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

From giles at xiph.org  Mon Nov 10 23:43:18 2008
From: giles at xiph.org (Ralph Giles)
Date: Mon, 10 Nov 2008 23:43:18 -0800
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <D48E66E8-FEF4-40A1-9898-F2707124C40A@apple.com>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<D48E66E8-FEF4-40A1-9898-F2707124C40A@apple.com>
Message-ID: <0779B6D2-8253-4E72-8882-3338BCCC2A3A@xiph.org>

On 10-Nov-08, at 7:49 PM, Maciej Stachowiak wrote:

>> 1) Allow unrestricted cross-origin <video>/<audio>
>> 2) Allow cross-origin <video>/<audio> but carefully restrict the  
>> API to limit the information a page can get about media loaded  
>> from a different origin
>> 3) Disallow cross-origin <video>/<audio> unless the media server  
>> explicitly allows it via the Access Control spec (e.g. by sending  
>> the "Access-Control-Allow-Origin: *" header).
>
> I'd prefer 1 or 2 (assuming the restrictions assumed by 2 are  
> reasonable).

One point that came out of the theora-level thread is that (2) would  
be less surprising if there's some kind of error mechanism flagging  
the restriction. For example, taint-tracking infrastructure could  
throw an exception when the javascript vm attempts to move cross-site  
data outside the layout and render engines.

This would offer some help to authors when a locally tested design  
mysteriously stops working when deployed.

FWIW,
  -r



From tommy at kvaleberg.com  Tue Nov 11 01:06:13 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Tue, 11 Nov 2008 10:06:13 +0100
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
References: <49181236.7080105@kvaleberg.no>	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>	<491845D4.1000908@kvaleberg.no>	<op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
Message-ID: <49194B05.5010801@kvaleberg.no>

Ian Hickson wrote:
> On Mon, 10 Nov 2008, Tommy Thorsen wrote:
>   
>> FWIW: In our implementation, I've changed the handling of "base" and 
>> "title" in "in body" to:
>>
>>    Process the token using the rules for the "after head" insertion 
>>    mode.
>>
>> instead of processing them with the rules for "in head".
>>     
>
> Unless there are pages that depend on this (are there?), I'm very 
> reluctant to change the spec in this way.
>   

No, I haven't seen any pages that depend on this. I'll revert this 
change in our implementation one day soon, and try to match Opera's 
behaviour instead.

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

From tommy at kvaleberg.com  Tue Nov 11 02:58:02 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Tue, 11 Nov 2008 11:58:02 +0100
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
References: <49181236.7080105@kvaleberg.no>	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>	<491845D4.1000908@kvaleberg.no>	<op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
Message-ID: <4919653A.1040209@kvaleberg.com>

Ian Hickson wrote:
> On Mon, 10 Nov 2008, Tommy Thorsen wrote:
>> From an implementors point of view, it's good to have clearly defined 
>> boundaries between modules. An implementation would typically have one 
>> module that tokenises and parses html and one module that renders the 
>> resulting dom to the screen. If all the unexpected input is dealt with 
>> in the parsing module, then you can make some assumptions in the 
>> rendering module which can greatly simplify the implementation. Having 
>> to deal with an arbitrary amount of illegal input in either module is, 
>> IMHO, not the ideal design.
>>     
>
> Unfortunately, we have little choice in the matter. Scripting and XML both 
> allow you to unambiguously create highly non-conforming DOMs, e.g. with 
> <title> elements as the root element and <html> elements as children of 
> <input> elements. The renderer has to deal with all such DOMs.
>
>   

I just came across another related problem. Consider the following markup:

<!doctype html><select><title>TITLE</title></select>

My version of Firefox moves the title to head, Opera ignores the title 
completely, and the html 5 parsing algorithm produces the following 
peculiar markup:

<!DOCTYPE html>
<html>
    <head></head>
    <body>
        <select>TITLE</select>
    </body>
</html>

Should this title be allowed or ignored? Right now we ignore the start 
and end tags, but insert the CDATA into the select element. I'm tempted 
to ignore CDATA unless the current node is an option element in the "in 
select" insertion mode.


Since we were discussing scripts creating unexpected DOMs, I had to try 
the following:

<!doctype html>
<script>
    function button_onclick() {
        document.getElementById('myselect').innerHTML = 
'<title>TITLE</title>';
        alert('title inserted');
    }
</script>
<select id="myselect"></select>
<input type="button" value="Make Title" onclick="button_onclick();" />

On Firefox, the title is inserted into the select element, but does not 
actually work. Opera seems to prevent the title element from being 
inserted into the select element altogether.

-Tommy


From tommy at kvaleberg.com  Tue Nov 11 03:27:04 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Tue, 11 Nov 2008 12:27:04 +0100
Subject: [whatwg] script tag handling in "after head"
Message-ID: <49196C08.8020307@kvaleberg.com>

This one is kinda complex, but I'll try to explain the problem. The 
algorithm for handling script start tags in the "after head" insertion 
mode requires us to push the head element pointer onto the stack of open 
elements, then process the token using the rules for the "in head" 
insertion mode. Finally we are required to:

    Pop the current node (which will be the node pointed to by the head 
element pointer)

The assertion that the current node is still the head element pointer 
does not seem correct, as we push a script element onto the stack of 
open elements in the "A start tag whose tag name is 'script'" section of 
the "in head" insertion mode.

Alternatively, the script tag handling in "in head" could be interpreted 
to not require us to push the script element onto the stack of open 
elements, but then the following assertion in "An end tag whose tag name 
is 'script'" in "in CDATA/RCDATA" will not hold true:

    Let script be the current node  (which will be a script element).

In our implementation, I've chosen to implement the "A start tag token 
whose tag name is one of: 'base', 'link', 'meta', 'noframes', 'script', 
'style', 'title'" as if it said:

    Parse error.
    Let /node/ be the head element pointer
    Push the node pointed to by the head element pointer onto the stack 
of open elements.
    Process the token using the rules for the "in head" insertion mode.
    Remove /node/ from the stack of open elements

I haven't come across any problems with this approach so far...


regards,
Tommy


From vetesnik at mrmil.cz  Tue Nov 11 03:38:08 2008
From: vetesnik at mrmil.cz (=?iso-8859-2?B?T2xk+GljaCBWZXRluW7taw==?=)
Date: Tue, 11 Nov 2008 12:38:08 +0100
Subject: [whatwg] Errormessages in forms
In-Reply-To: <Pine.LNX.4.62.0811102049080.1237@hixie.dreamhostps.com>
References: <4884D7DC.7030909@keryx.se>
	<Pine.LNX.4.62.0811051523410.1237@hixie.dreamhostps.com>
	<op.uj5lwkoro84pey@pc08.ebrana.cz>
	<Pine.LNX.4.62.0811102049080.1237@hixie.dreamhostps.com>
Message-ID: <op.ukgc9yk8o84pey@pc08.ebrana.cz>

Dne Mon, 10 Nov 2008 21:50:37 +0100 Ian Hickson <ian at hixie.ch> napsal/-a:

>> <label for="idfield">Instructions</label>
>> <input name="idfield" id="idfield">
>> <hint for="idfield">Type in dd-mm-yyyy format</hint>
>> <error for="idfield">Must be a valid value</error> (if error is true)
>
> This seems excessively complicated and I'm not convinced there is really  
> a problem to solve here. Just using plain text seems enough.

Indeed it seems enough. Although this kind of solution could improve  
Screen Readers' abilities to effectively interpret forms.

It could be finally clear how to code it right for both web developers and  
Screen Reader developers how (& what) to implement (I'm guessing here, I  
don't know how difficult it would be to implement such behavior).  
Nowadays, all kinds of hints & errors are outside the label element thus  
sreen readers don't read them out. That's bad. This could improve the  
forms & feedback accessibility in general.

I'm not saying this is the best solution, if you have another, please  
share. I'm proposing those changes because current situation is horrible  
and nobody really knows how to code it right.

An example: I'm sort of disgussed when I see how Zend Framework implements  
default form element wrapper-tags: dt's for labels, dd's for inputs and ul  
li's for errors. I think form elements (labels, inputs...) are not meant  
to be used in a definition list (because they aren't), errors (mostly  
one-line) are not meant to be in a list. Such abuse of html! Yes of course  
everyone does it differently, but I think people tend to do those kind of  
"evil" things when they don't have enough semantic tags to use. Just like  
<figure> solves those captionized pulled images - and replacing floated  
tables, divs or paragraphs - this could solve the  
how-the-heck-do-I-make-a-correctly-coded-and-accessible-form situation.

If I'm mistaken again, or this issue has been already discussed, I apology  
for wasting your time. :)
Take care,
Ollie


From hsivonen at iki.fi  Tue Nov 11 04:02:42 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 11 Nov 2008 14:02:42 +0200
Subject: [whatwg] script tag handling in "after head"
In-Reply-To: <49196C08.8020307@kvaleberg.com>
References: <49196C08.8020307@kvaleberg.com>
Message-ID: <2187F5A8-C33E-47DE-A01F-5266D539E46C@iki.fi>

On Nov 11, 2008, at 13:27, Tommy Thorsen wrote:

> The assertion that the current node is still the head element  
> pointer does not seem correct, as we push a script element onto the  
> stack of open elements in the "A start tag whose tag name is  
> 'script'" section of the "in head" insertion mode.


This is http://www.w3.org/Bugs/Public/show_bug.cgi?id=6038

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




From tommy at kvaleberg.com  Tue Nov 11 06:21:31 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Tue, 11 Nov 2008 15:21:31 +0100
Subject: [whatwg] script tag handling in "after head"
In-Reply-To: <2187F5A8-C33E-47DE-A01F-5266D539E46C@iki.fi>
References: <49196C08.8020307@kvaleberg.com>
	<2187F5A8-C33E-47DE-A01F-5266D539E46C@iki.fi>
Message-ID: <491994EB.7090901@kvaleberg.com>

Henri Sivonen wrote:
> On Nov 11, 2008, at 13:27, Tommy Thorsen wrote:
>
>> The assertion that the current node is still the head element pointer 
>> does not seem correct, as we push a script element onto the stack of 
>> open elements in the "A start tag whose tag name is 'script'" section 
>> of the "in head" insertion mode.
>
>
> This is http://www.w3.org/Bugs/Public/show_bug.cgi?id=6038
>

Ah, thank you. I hadn't really looked at that bugzilla before. I added 
my solution as a third possible fix.

I think the first solution in the description of that bug sounds nice, 
but I'm not too fond of the second solution. (The one which involves 
sometimes popping one extra time.) Just my two cents' worth.



From samaxes at gmail.com  Tue Nov 11 06:31:55 2008
From: samaxes at gmail.com (Samuel Santos)
Date: Tue, 11 Nov 2008 14:31:55 +0000
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
	interface
In-Reply-To: <fe7db4750811061017i6a8de93ar831dff9febf4b707@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com>
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com>
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com>
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com>
	<6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com>
	<fe7db4750811051909pe487a40y9975ede0c0d58684@mail.gmail.com>
	<6ea53250811051931g5d5cfa96s56a65e38586ee4d3@mail.gmail.com>
	<6ea53250811051932i38c89b38v10d488a9f3553c8c@mail.gmail.com>
	<Pine.LNX.4.62.0811061722180.1041@hixie.dreamhostps.com>
	<fe7db4750811061017i6a8de93ar831dff9febf4b707@mail.gmail.com>
Message-ID: <fe7db4750811110631p361641b9n2ec16f0b4dd009ea@mail.gmail.com>

On Thu, Nov 6, 2008 at 6:17 PM, Samuel Santos <samaxes at gmail.com> wrote:

> On Thu, Nov 6, 2008 at 5:50 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Thu, 6 Nov 2008, Eduard Pascual wrote:
>> >
>> > I agree with Samuel in that this is an issue. In Catalunya, most often
>> > Spanish software is used (both OS and browsers), because a lot of the
>> > software is not easily (or at all) available in Catalan (specially
>> > Microsoft software, such as Windows and IE, which ammount for a quite
>> > big fraction of web surfers). Seeing Spanish stuff in pages that are
>> > supposed to be in Catalan is quite annoying (especially when keeping in
>> > mind some historic factors).
>> >
>> > I can understand that there may be some security concerns with this
>> > control; but I don't think changing the "Browse" caption poses any
>> > threat. But if there is so much paranoia on this, browsers could be
>> > allowed (or even required) to ask for confirmation when picking a file
>> > if the caption has been changed (something like "Are you sure you would
>> > like to submit C:\example.txt to example.com?" should be enough, and
>> > users would easily see such question as coming from the UA rather than
>> > from the webpage).
>>
>> It has been shown that prompts are ignored by users, so that wouldn't
>> really solve the problem.
>>
>>
>> On Thu, 6 Nov 2008, Samuel Santos wrote:
>> >
>> > If changing the button text can be a security issue (e.g. induce the
>> > user to an action that he's not aware of), we can come up with some
>> > solutions.
>> >
>> > What about allowing the Author to change the control's locale? By doing
>> > so, the UA can then render the button with the same locale as the
>> > application without compromising the security.
>>
>> It seems like browsers should do this already based on the lang=""
>> attribute. I recommend asking browser vendors to implement this.
>
>
> @lang will definitively fix the problem if browsers are willing to
> implement it.
>

Ian, can I ask you to please check this with browser vendors?


>
>
>>
>>
>>
>> On Thu, 6 Nov 2008, Eduard Pascual wrote:
>> >
>> > I was going to suggest this, but I don't think it's really doable:
>> > browsers would need to include all the translations of that caption in
>> > all their versions. In the specific case of IE, considering that
>> > Microsoft tends to license only single-language versions of its products
>> > (if you want it in two languages, you need to pay twice), I'm afraid
>> > this would be an issue (despite the fact that IE is actually distributed
>> > for free, it would still mess with their "packaging").
>>
>> It's true that this may not be something browsers want to implement.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>
>
>
> --
> Samuel Santos
> http://www.samaxes.com/
>



-- 
Samuel Santos
http://www.samaxes.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081111/de61ad1b/attachment.htm>

From ap at webkit.org  Tue Nov 11 12:44:42 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Tue, 11 Nov 2008 23:44:42 +0300
Subject: [whatwg] MessagePort close event and discarding a Document
Message-ID: <C53FC96A.61797%ap@webkit.org>


Currently, HTML5 specifies that when a Document is discarded, "close" event
should be asynchronously dispatched to MessagePorts that are entangled with
ports belonging (in some specific sense) to this document.

There is a race with garbage collection inherent to this requirement. Below
I describe the issue in detail, and propose a solution.

Suppose we have two browsing contexts, frameA and frameB, and two
MessagePorts, portA and portB, owned by these contexts respectively. The
ports are entangled with each other, and their queues are started.

Further, portA is not reachable from live code, but has a "close" event
listener (set via either onclose or addEventListener). Port portB is also
unreachable, so garbage collection can destroy both ports.

Now, we close frameB. This results in its document being discarded, so a
"close" event is dispatched on portA (portA becomes GC protected when the
task to dispatch it is posted). However, no event is dispatched if portA and
portB are collected before the document is destroyed. The problem is that
observable behavior depends on GC order, which it shouldn't.

In practice, it is normally the same GC pass that destroys the Document and
both unreachable ports, so a straightforward implementation is likely to
crash due to using semi-deleted objects.

I propose to remove the requirement to dispatch "close" event on the
surviving port (#3 in paragraph 7.5.3.1). This is the only fix I can see, as
making GC dispatch "close" to fix it from other side would suffer from
basically the same logical problem.

- WBR, Alexey Proskuryakov.




From herenvardo at gmail.com  Tue Nov 11 15:33:33 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Tue, 11 Nov 2008 23:33:33 +0000
Subject: [whatwg] Sections, headers, and styling
Message-ID: <6ea53250811111533s524ad4bbme10080deebb74bfb@mail.gmail.com>

It is a quite common practice on current web pages to style the h1..h6
elements to have them blend properly with the overall style of a site.
For HTML4/XHTML1 documents this is quite trivial; but with HTML5 the
"number part" of the heading element doesn't reliably define the
actual heading level anymore (specially when dealing with server-side
includes and / or user-provided content). I have tried to figure out
some CSS selectors to handle this task with HTML 5 documents and they
go completely crazy before getting anywhere near to being accurate:
there is an insane ammount of element-nesting combinations to keep
track of. Is there any sane way to deal with this basic need?

Greetings,
Eduard Pascual


From jackalmage at gmail.com  Tue Nov 11 15:41:48 2008
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 11 Nov 2008 17:41:48 -0600
Subject: [whatwg] Sections, headers, and styling
In-Reply-To: <6ea53250811111533s524ad4bbme10080deebb74bfb@mail.gmail.com>
References: <6ea53250811111533s524ad4bbme10080deebb74bfb@mail.gmail.com>
Message-ID: <dd0fbad0811111541sa1f31b2m252c9ed477e8a7c6@mail.gmail.com>

On Tue, Nov 11, 2008 at 5:33 PM, Eduard Pascual <herenvardo at gmail.com>wrote:

> It is a quite common practice on current web pages to style the h1..h6
> elements to have them blend properly with the overall style of a site.
> For HTML4/XHTML1 documents this is quite trivial; but with HTML5 the
> "number part" of the heading element doesn't reliably define the
> actual heading level anymore (specially when dealing with server-side
> includes and / or user-provided content). I have tried to figure out
> some CSS selectors to handle this task with HTML 5 documents and they
> go completely crazy before getting anywhere near to being accurate:
> there is an insane ammount of element-nesting combinations to keep
> track of. Is there any sane way to deal with this basic need?
>

Generally you want to decide if you're going to use the numbered range, or
just <h1>.

If the former, just work it like you always would.  If the latter, you have
to do something like "h1 ~ section h1" to match what would otherwise be an
h2.  This will also match deeper headings, of course, so you want to put in
the h3-equivalent selector as well, and possibly further.

However, this is an interesting problem in general, that is perhaps best
served by CSS itself.  Perhaps something like a :heading(n) pseudoclass,
which'll match headings of the given level.  What qualifies as a heading,
and how they nest and change levels, would be up to the markup language
(html5 in this case).  Vanilla html4 would just naively report <h1> as
matching :heading(1), <h2> as matching :heading(2), etc.  Html5 would match
according to the heading-depth algorithm, and take into account both the
<hn> number and the depth within <section>s.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081111/66bca01a/attachment.htm>

From jonas at sicking.cc  Tue Nov 11 15:59:26 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 11 Nov 2008 15:59:26 -0800
Subject: [whatwg] event.message in workers examples
Message-ID: <491A1C5E.1060007@mozilla.com>

The workers examples use 'event.message' in a bunch of places, however 
the property is called 'event.data'. Same mistake in the "View this 
example online" pages.

/ Jonas


From ian at hixie.ch  Tue Nov 11 16:14:41 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 00:14:41 +0000 (UTC)
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
 interface
In-Reply-To: <fe7db4750811110631p361641b9n2ec16f0b4dd009ea@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.com> 
	<fe7db4750811051048q61695eb5qaf35ac9d34ed161b@mail.gmail.com> 
	<Pine.LNX.4.62.0811052245330.1041@hixie.dreamhostps.com> 
	<fe7db4750811051615w736a95adr93697610f58a57dd@mail.gmail.com> 
	<6ea53250811051732i43ab88a3v150eed0c222d666f@mail.gmail.com> 
	<fe7db4750811051909pe487a40y9975ede0c0d58684@mail.gmail.com> 
	<6ea53250811051931g5d5cfa96s56a65e38586ee4d3@mail.gmail.com> 
	<6ea53250811051932i38c89b38v10d488a9f3553c8c@mail.gmail.com> 
	<Pine.LNX.4.62.0811061722180.1041@hixie.dreamhostps.com> 
	<fe7db4750811061017i6a8de93ar831dff9febf4b707@mail.gmail.com>
	<fe7db4750811110631p361641b9n2ec16f0b4dd009ea@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811120014110.1041@hixie.dreamhostps.com>

On Tue, 11 Nov 2008, Samuel Santos wrote:
> >> On Thu, 6 Nov 2008, Samuel Santos wrote:
> >> >
> >> > If changing the button text can be a security issue (e.g. induce 
> >> > the user to an action that he's not aware of), we can come up with 
> >> > some solutions.
> >> >
> >> > What about allowing the Author to change the control's locale? By 
> >> > doing so, the UA can then render the button with the same locale as 
> >> > the application without compromising the security.
> >>
> >> It seems like browsers should do this already based on the lang="" 
> >> attribute. I recommend asking browser vendors to implement this.
> >
> > @lang will definitively fix the problem if browsers are willing to 
> > implement it.
> 
> Ian, can I ask you to please check this with browser vendors?

I don't think the problem is worth fixing, so I'm probably not the best 
person to convince them. :-)

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


From ian at hixie.ch  Tue Nov 11 16:37:56 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 00:37:56 +0000 (UTC)
Subject: [whatwg] PDF version comments
In-Reply-To: <op.uj3s1dqhidj3kv@zcorpandell.linkoping.osa>
References: <op.uj3s1dqhidj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0811120036090.1041@hixie.dreamhostps.com>

On Tue, 4 Nov 2008, Simon Pieters wrote:
>
> I had a quick look at the PDF version of the spec...
> 
> The "check for updates" box should probably be hidden.

I've added:

   @media print { #configUI { display: none; } }

...which should take effect at the next PDF update.


> Why are the status boxes in the margin hidden? It seems to me that they 
> would be useful also on paper.

They're not hidden, they just don't exist. The boxes are generated by 
script, which Prince doesn't run.


> The acks section shows question marks for ??? and ????.

I presume this is a font problem; if someone can provide better fonts, I'm 
happy to try to hook them in.

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

From ian at hixie.ch  Tue Nov 11 17:11:19 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 01:11:19 +0000 (UTC)
Subject: [whatwg] About <input type="hidden">
In-Reply-To: <BAY116-DAV3D3855B7B091F2C076C35A4290@phx.gbl>,
	<018a01c9348d$8c233340$0a01a8c0@mikedeskxp>
References: <BAY116-DAV3D3855B7B091F2C076C35A4290@phx.gbl>,
	<018a01c9348d$8c233340$0a01a8c0@mikedeskxp>
Message-ID: <Pine.LNX.4.62.0811120102440.1237@hixie.dreamhostps.com>


(I've not replied to all the e-mails on this thread because they are 
mostly redundant with this one. Please let me know if you made a point 
regarding <input type=hidden> that you think needs changes to the spec 
that I missed.)

On Fri, 17 Oct 2008, Mike Wilson wrote:
> Anne van Kesteren wrote:
> >
> > For the table and lists cases, is there a good use case for 
> > complicating their content model
> 
> This being a good or important use case is hard to say - I guess it is 
> one of these real-world annoyances that both webdevs and browsers have 
> learnt to cope with. As part of the HTML5 initiative is based on 
> real-world browser behaviour I was thinking this may be a candidate for 
> some spec adjustment in some form (maybe just defining graceful 
> migration).
> 
> > or could you just as well put the input either before or after the 
> > table or list?
> 
> For hand-coding I certainly could, I see no real reason to do what I 
> suggest here when you are in control of the complete markup.
> 
> But it gets harder for the scenario I was mentioning in my initial mail: 
> [some incarnations of] server-side templating. Many templating systems 
> work with the whole page at once to specify what markup to generate for 
> specific data, but for more decoupled systems you may want to specify a 
> HTML snippet per object type or similar - and then apply recursive view 
> rendering on an object graph.

I agree, but it seems that having the hidden inputs be inside the next
<li> of a list, or the next <td>, or whatever is appropriate, isn't much 
to ask for.


> Andy Lyttle wrote:
> > This is something I wanted to do recently.  I was building HTML in a 
> > Perl script, adding table rows in a loop, and I wanted some rows to 
> > contain text field with user-editable value, while for other rows I 
> > wanted the value to be displayed but not editable
> 
> Yes, this is sort of similar to my scenario above, and you were able to 
> workaround it being in control of the whole markup in one place (and not 
> completely decoupled as I describe above). I think this is one of those 
> things that webdevs keep hitting every now and then, and it is caused by 
> a kind of inter- mingling of document structure and POSTable state in 
> HTML/DOM.

For Perl, it's definitely possible (and relatively easy) to just store the 
hidden inputs until the next suitable place (e.g. the next cell).


> Assuming you are in control of the whole page's markup at once then I 
> agree. But when you are not and, it may be far from trivial. (I 
> mentioned an example of this in the link I included earlier.)

I don't really follow why it's so hard in that case, but maybe you should 
use a better templating language. :-)


> Ian wrote:
> > > - keeping the whole thing invalid but still define in HTML5 how 
> > >   the migration of ill-placed <input>:s should work
> > 
> > That is theoretically already defined.
> 
> Interesting. Is it the foster-parenting of tables you are referring to, 
> or is there anything more specific for <input>:s?

Yes, foster parenting, and also the form element pointer, etc.

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


From ian at hixie.ch  Tue Nov 11 17:15:45 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 01:15:45 +0000 (UTC)
Subject: [whatwg] [WebForms2] custom form validation notifications
In-Reply-To: <6ea53250810231502t3b516187qf08edbed55cc736e@mail.gmail.com>
References: <op.tgvjyxmvxl3at9@dragast.mshome.net> 
	<1959130b0610032005r58684830s23b0780c5a24f387@mail.gmail.com> 
	<dd924299b3f7427da183b7cf9951d52f@myrealbox.com>
	<6617CB7F-D53C-47BE-B928-31FF7093860F@iki.fi>
	<Pine.LNX.4.62.0810231412500.1237@hixie.dreamhostps.com>
	<6ea53250810231502t3b516187qf08edbed55cc736e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811120111270.1237@hixie.dreamhostps.com>

On Thu, 23 Oct 2008, Eduard Pascual wrote:
>
> On Thu, Oct 23, 2008 at 4:40 PM, Ian Hickson <ian at hixie.ch> wrote:
> > You can call setCustomValidity() to set a specific string.
> Joao explicitly asked for a way to achieve this **without scripting
> enabled**. I think it's quite obvious why setCustomValidity() doesn't
> solve that need.

Granted, but it's not clear how one could do custom validity checking 
without script, and for the other cases there are declarative solutions 
(min="" and max="" are self-documenting, for instance; and title="" can be 
used for pattern=""'s documentation.)


> Would having some sort of "custom-error-message" attribute hurt that 
> much? (Of course, the name is just an example, and I wouldn't really 
> suggest it). It would simply ignored by current UAs, and not really hard 
> to implement (actually, it'd be trivial compared to implementing 
> reg.exp. parsing).

It's not clear to me what problem this would solve.


> >> If the UA has scripting disabled, trying to prevent the default 
> >> action for an invalid event won't work. Too overcome this problem, 
> >> there could be a new attribute which could be called 
> >> 'notifyoninvalid="true|false"' with a default value of true, for each 
> >> control, or for the entire form. If the value is false, then the UA 
> >> wouldn't notify the user in case of invalidity. This could then be 
> >> delegated to some CSS using :invalid;
> >
> > If scripting is disabled, why would you not want the user notified? 
> > That would be pretty bad UI. :-)
>
> That'd be really useful if validation can be delegated to server-side 
> scripting when no client-side scripting is available.

You can do that today, just don't use the new constraint attributes.


> Anyway, I don't think such an attribute is needed: a page can be 
> authored with a "catch-all" validation rule for the field, and then the 
> Javascript could update that rule upon the page's loading: if scripts 
> are dissabled, the rule wouldn't be updated and would stay as the 
> catch-all.

I don't really follow.


> OTOH, I think Joao's idea was more like to relying on visual hints (ie: 
> marking the field as red) on cases where an error message popup would be 
> redundant and annoying. I think that could be more elegantly handled 
> with an empty attribute value for an hipothetical "custom-error-message" 
> attribute (which is not the same as an absent attribute).

I really don't follow this. Maybe some concrete examples showing the 
problem with the current spec solutions would help.

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


From ian at hixie.ch  Tue Nov 11 17:25:48 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 01:25:48 +0000 (UTC)
Subject: [whatwg] WebForms2 validity
In-Reply-To: <4907C732.8000807@westnet.com.au>
References: <45CBA66A.1040002@westnet.com.au>
	<Pine.LNX.4.62.0810282007510.1237@hixie.dreamhostps.com>
	<4907C732.8000807@westnet.com.au>
Message-ID: <Pine.LNX.4.62.0811120117360.1237@hixie.dreamhostps.com>


It's proposed below to remove checkValidity() -- if people have an opinion 
on this, please do speak up.

On Tue, 28 Oct 2008, Eduard Pascual wrote:
> On Tue, Oct 28, 2008 at 8:09 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 9 Feb 2007, Sean Hogan wrote:
> >>
> >> Many textual input form-controls would begin in one or another 
> >> invalid state (valueMissing, patternMismatch) however authors would 
> >> typically want CSS validity styles to apply only after 
> >> checkValidity() - either a manual one or the automatic one performed 
> >> by form-submission.
> >
> > Why?
> 
> I agree with Sean's idea: at least on the initial state, controls 
> showing up with "invalid" styling can be quite confusing to many users. 
> It may depend a lot on the context, and even more on the user: although 
> the initial "" for a required text field would be invalid, and even 
> would make sense to visually convey that fact, many users may wonder 
> "What did I wrong if I didn't do anything yet?".

The only way that text field would be invalid is if it had required="" 
set; and in that case, one could disable the styling using :required to 
change the styling in some appropriate way.


> The best solution I can think of this would be an additional 
> pseudo-class, such as ":default", ":initial-value", ":non-modified", or 
> anything like that (I'm really bad at naming stuff, so please take those 
> only as *examples*, because that's what they are), which could be used 
> together depending on the needs of each site or application, like this:
>
> :valid {
> // code for "green" higlighting
> }
> :invalid {
> // code for "red" highlighting
> }
> :default {
> // overriding code to remove highlighting (or to apply "white" highlighting)
> }
> :default:invalid {
> // code for "yellow" highlighting
> }
> That's just an example. The idea is that an application may need to
> convey (through styling the validity pseudo-classes) the meanings "you
> have put something wrong here" and "you have to provide something
> here" as different concepts.

That would be interesting. It is, however, out of our scope. :-) If you 
want to follow up on this, I recommend bringing it up with the CSS working 
group at www-style at w3.org.


On Tue, 28 Oct 2008, Philipp Serafin wrote:
> 
> This seems to overlap with the "@placeholder" proposal. Maybe both 
> proposals could be merged somehow?
> 
> Ideas:
> a) Don't include :default but instead define :invalid so that it won't
> be set as long as the placeholder is visible;
> b) get rid of the placeholder attribute and use :default instead;

I don't really like the idea of making features interrelated in this way. 
It makes things really complicated to spec, implement, test, and use.


On Tue, 28 Oct 2008, Nils Dagsson Moskopp wrote:
>
> make an easy rule into a complicated one to cater to an unknown use
> case. yeah. way to go.
> </sarcasm>

Please don't be sarcastic on this list. :-)


> fact: invalid content is invalid. i'd use javascript to change the 
> element class from "never given focus" to "had focus" using onclick in 
> your case.

I agree that this seems like a better solution.


On Wed, 29 Oct 2008, Sean Hogan wrote:
>
> Ok. But what's the use of checkValidity() on form-control-elements?
> Isn't it just:
>  function() {
>    if (!this.validity.valid) this.dispatchEvent("invalid");
>    return this.validity.valid;
>  }

It's more like

   if (this.willValidate && !this.validity.valid)
     // dispatch invalid and return true
   else
     // return false

...but yes.

We could remove it, true. It's not that useful.

Do people want to keep it?


> > > Many textual input form-controls would begin in one or another 
> > > invalid state (valueMissing, patternMismatch) however authors would 
> > > typically want CSS validity styles to apply only after 
> > > checkValidity() - either a manual one or the automatic one performed 
> > > by form-submission.
> > 
> > Why?
>
> I would probably now agree that the default should be immediate 
> application of :valid / :invalid styling which can worked-around with 
> script. The opposing view (what I would have said a year ago) is...
> 
> I think that's the way it usually is now. More specifically:
> 1. It could be confusing to have :invalid styling on form-controls when the
> page first loads.
> 2. It could be distracting for the styling of a form-control to switch between
> :valid and :invalid while the user is typing into it.
> 3. It could be distracting for the :valid and :invalid styles to apply before
> the user tries to submit or explicitly requests the data to be checked.
> 
> #2 can be worked around using :focus. I can't see how #1 and #3 can be worked
> around without script.
> A :validated pseudo-class that applied after checkValidity() is called or
> form-submission has been attempted would give some extra flexibility in the
> noscript scenario.

Most controls will be valid unless they are required, as far as I can 
tell, so I'm not sure it's that big a deal.

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


From ian at hixie.ch  Tue Nov 11 18:02:35 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 02:02:35 +0000 (UTC)
Subject: [whatwg] Show upload progress
In-Reply-To: <20060505215033.46740.qmail@web50410.mail.yahoo.com>
References: <20060505215033.46740.qmail@web50410.mail.yahoo.com>
Message-ID: <Pine.LNX.4.62.0811120201070.1237@hixie.dreamhostps.com>

On Fri, 5 May 2006, Joaquin Cuenca Abela wrote:
> 
> A lot of people are implementing progress bars that show in real time 
> the upload status of files being uploaded.
> 
> Right now it's a pain to implement that kind of functionality, as the 
> browser has to poll regularly the server with a secondary connection to 
> get the total size of the request, and the number of bytes already 
> received.
> 
> Given that the browser already knows that information, I think it would 
> be great if it could expose it on some DOM object. What do you think?

I think we may at some future point add an upload progress events object 
to <form> elements, similar to what XHR is getting for upload. However, in 
the meantime, I think it would be better to ask browser vendors to make 
significant strides in improving the upload progress UI of form 
submission. There's really no reason browsers couldn't do this better than 
Web application authors could.

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


From tstarling at wikimedia.org  Tue Nov 11 19:22:03 2008
From: tstarling at wikimedia.org (Tim Starling)
Date: Wed, 12 Nov 2008 14:22:03 +1100
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
Message-ID: <491A4BDB.1070903@wikimedia.org>

Robert O'Callahan wrote:
> Should <video> and <audio> elements be able to load and play resources
> from other origins?
>
> Perhaps Ian thinks not:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
> There's a to-and-fro discussion here:
> http://lists.xiph.org/pipermail/theora/2008-November/001931.html
> Jonas got involved here:
> http://lists.xiph.org/pipermail/theora/2008-November/001958.html
>
> There are three obvious options:
> 1) Allow unrestricted cross-origin <video>/<audio>
> 2) Allow cross-origin <video>/<audio> but carefully restrict the API
> to limit the information a page can get about media loaded from a
> different origin
> 3) Disallow cross-origin <video>/<audio> unless the media server
> explicitly allows it via the Access Control spec (e.g. by sending the
> "Access-Control-Allow-Origin: *" header).
>

(3) is particularly nasty due to the incentive it creates for insecure
configuration. We've seen this already with Flash policy files. Many
administrators uploaded a crossdomain.xml with <allow-access-from
domain="*"/>, not realising what sort of vulnerability they were opening
up. It would be a shame to borrow security ideas from possibly the least
secure client on the web, and to mandate those insecure ideas in browser
standards.

JavaScript already has measures along the lines of (2), in the context
of frames. The information a script can obtain about a frame from a
different origin is carefully restricted. I think that a similar
solution would be best. It has the advantage of consistency and proven
security.

--
Tim Starling
Wikimedia Foundation


From robert at ocallahan.org  Tue Nov 11 20:02:02 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 12 Nov 2008 17:02:02 +1300
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <491A4BDB.1070903@wikimedia.org>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<491A4BDB.1070903@wikimedia.org>
Message-ID: <11e306600811112002t7d536743r10a07391e9264f4a@mail.gmail.com>

On Wed, Nov 12, 2008 at 4:22 PM, Tim Starling <tstarling at wikimedia.org>wrote:

> JavaScript already has measures along the lines of (2), in the context
> of frames. The information a script can obtain about a frame from a
> different origin is carefully restricted. I think that a similar
> solution would be best. It has the advantage of consistency and proven
> security.
>

I would say it has a history of proven *insecurity*. Look at clickjacking
for example.

Anyway, having discussed this with Hixie and Maciej and others a bit on
#whatwg, things seem to be leaning towards option 2.

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/20081112/32e9ef54/attachment.htm>

From dhtmlkitchen at gmail.com  Tue Nov 11 20:35:11 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 11 Nov 2008 20:35:11 -0800
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
References: <49181236.7080105@kvaleberg.no>
	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
	<491845D4.1000908@kvaleberg.no>
	<op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
Message-ID: <c9e12660811112035w2c2af22bwc78c06fb88e155c8@mail.gmail.com>

On Mon, Nov 10, 2008 at 7:59 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 10 Nov 2008, Tommy Thorsen wrote:


>
> On Mon, 10 Nov 2008, Tommy Thorsen wrote:
>>
>> From an implementors point of view, it's good to have clearly defined
>> boundaries between modules. An implementation would typically have one
>> module that tokenises and parses html and one module that renders the
>> resulting dom to the screen. If all the unexpected input is dealt with
>> in the parsing module, then you can make some assumptions in the
>> rendering module which can greatly simplify the implementation. Having
>> to deal with an arbitrary amount of illegal input in either module is,
>> IMHO, not the ideal design.
>
> Unfortunately, we have little choice in the matter. Scripting and XML both
> allow you to unambiguously create highly non-conforming DOMs, e.g. with
> <title> elements as the root element and <html> elements as children of
> <input> elements. The renderer has to deal with all such DOMs.
>

What does XML has to do with any of this?

A script that adds an HTML element to a INPUT element should cause an
hierarchy exception to be raised.

You have a choice:

1)  leave DOM 1 alone; let the implementation throw an hierarchy exception.
2)  make a standardized behavior for this case.

| Since user agents may vary in how they handle error conditions,
authors and users
| must not rely on specific error recovery behavior.

http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-invalid-docs

Garrett

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


From silviapfeiffer1 at gmail.com  Tue Nov 11 21:26:19 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 12 Nov 2008 16:26:19 +1100
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <11e306600811112002t7d536743r10a07391e9264f4a@mail.gmail.com>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<491A4BDB.1070903@wikimedia.org>
	<11e306600811112002t7d536743r10a07391e9264f4a@mail.gmail.com>
Message-ID: <2c0e02830811112126r4b3fe7fej8f6d287697d211fa@mail.gmail.com>

On Wed, Nov 12, 2008 at 3:02 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Wed, Nov 12, 2008 at 4:22 PM, Tim Starling <tstarling at wikimedia.org>
> wrote:
>>
>> JavaScript already has measures along the lines of (2), in the context
>> of frames. The information a script can obtain about a frame from a
>> different origin is carefully restricted. I think that a similar
>> solution would be best. It has the advantage of consistency and proven
>> security.
>
>
> I would say it has a history of proven *insecurity*. Look at clickjacking
> for example.
>
> Anyway, having discussed this with Hixie and Maciej and others a bit on
> #whatwg, things seem to be leaning towards option 2.

While my gut feeling tells me that this is the right solution - would
you mind sharing some of the reasoning as discussed on irc?

Thanks,
Silvia.


From bijumaillist at gmail.com  Tue Nov 11 21:36:06 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Wed, 12 Nov 2008 01:36:06 -0400
Subject: [whatwg] Issue when Video currentTime used for seeking.
Message-ID: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>

I see a problem while using video_element.currentTime instead of
video_element.start

ie, recent firefox nightly build removed video_element.start
before that we could do following to make a movie with new URL start
from 10th second frame

video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
video_element.start=10;
video_element.play();


Now to achieve same effect I tried

video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
video_element.currentTime=10;
video_element.play();

This gives a problem.
ie, I can not set .currentTime immediately after .src changed
it throughs error (may be it is waiting to load metadata)

So can we have a method .seek() or .skip() or something.

Syntax:-

.seek(secondsToSeek, isAbosolute, toKeyFrame)

Parameters:-

secondsToSeek - optional, positive/negative floating point value to
indicate seconds from current frame. Default 5 sec or a user set
value.

isAbosolute - optional, boolean, default false. if true indicate
"secondsToSeek" is from the start instead of from current frame.

toKeyFrame - optional, boolean, default false. if true indicates goto
the nearest keyframe of the value provided in secondsToSeek.
this is to improve performance while avoiding  bug
https://bugzilla.mozilla.org/show_bug.cgi?id=463358

Returns:-
.seek() will return the time to which it is seek-ed to.

so if seeking is true
.currentTime - will give current position till where the video is
already seek-ed
.seek(0) - will give currently being seek-ed position.


With out this extra method it will lot more Javascript code to archive the same.

Cheers
Biju


From chris.double at double.co.nz  Tue Nov 11 23:16:42 2008
From: chris.double at double.co.nz (Chris Double)
Date: Wed, 12 Nov 2008 20:16:42 +1300
Subject: [whatwg] Issue when Video currentTime used for seeking.
In-Reply-To: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
References: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
Message-ID: <c2e346f90811112316r2fc25382l6dd29b15b1c1a67b@mail.gmail.com>

On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
> video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
> video_element.currentTime=10;
> video_element.play();

You can use:

v.src = "foo.ogg";
v.addEventListener("loadedmetadata", function() { v.currentTime=10;
v.play(); }, false);

Chris.
-- 
http://www.bluishcoder.co.nz


From ian at hixie.ch  Tue Nov 11 23:21:02 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 07:21:02 +0000 (UTC)
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <c9e12660811112035w2c2af22bwc78c06fb88e155c8@mail.gmail.com>
References: <49181236.7080105@kvaleberg.no>
	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
	<491845D4.1000908@kvaleberg.no>
	<op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
	<c9e12660811112035w2c2af22bwc78c06fb88e155c8@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811120719590.1041@hixie.dreamhostps.com>

On Tue, 11 Nov 2008, Garrett Smith wrote:
> >
> > Unfortunately, we have little choice in the matter. Scripting and XML 
> > both allow you to unambiguously create highly non-conforming DOMs, 
> > e.g. with <title> elements as the root element and <html> elements as 
> > children of <input> elements. The renderer has to deal with all such 
> > DOMs.
> 
> What does XML has to do with any of this?

XML can denote arbitrarily nested DOMs.


> A script that adds an HTML element to a INPUT element should cause an 
> hierarchy exception to be raised.

No, it shouldn't.


> | Since user agents may vary in how they handle error conditions,
> | authors and users must not rely on specific error recovery behavior.
> 
> http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-invalid-docs

This was one of the biggest mistakes in HTML4, and HTML5 does not make 
that mistake again.

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


From chris.double at double.co.nz  Tue Nov 11 23:24:30 2008
From: chris.double at double.co.nz (Chris Double)
Date: Wed, 12 Nov 2008 20:24:30 +1300
Subject: [whatwg] Issue when Video currentTime used for seeking.
In-Reply-To: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
References: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
Message-ID: <c2e346f90811112324y2a87b806mce7639c1b52a908e@mail.gmail.com>

On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
> toKeyFrame - optional, boolean, default false. if true indicates goto
> the nearest keyframe of the value provided in secondsToSeek.
> this is to improve performance while avoiding  bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=463358

Good question. Should seeks go to the previous keyframe to the
requested time,  the next keyframe after the time, the closest
keyframe, or the exact frame requested?

Regarding that bug, I think it should be going to the last keyframe
then decoding up to the point of the requested frame so it can display
non-garbage data. But is there a requirement to be able to identify
keyframes from JavaScript? I suspect not but don't know.

> .seek() will return the time to which it is seek-ed to.

What time is that exactly? Is that the time of  the actual frame the
seek ended on? Seek can take some time if it requires multiple http
byte range requests to find the right location, and to search for the
keyframe. You wouldn't want this to be a blocking call but it would
need to be if you want to return the time.

Chris.
-- 
http://www.bluishcoder.co.nz


From hsivonen at iki.fi  Tue Nov 11 23:45:46 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 12 Nov 2008 09:45:46 +0200
Subject: [whatwg] PDF version comments
In-Reply-To: <Pine.LNX.4.62.0811120036090.1041@hixie.dreamhostps.com>
References: <op.uj3s1dqhidj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0811120036090.1041@hixie.dreamhostps.com>
Message-ID: <6DF5FFC4-B5FB-4104-BFD5-30CB45655C62@iki.fi>

On Nov 12, 2008, at 02:37, Ian Hickson wrote:

>> The acks section shows question marks for ??? and ????.
>
> I presume this is a font problem; if someone can provide better  
> fonts, I'm
> happy to try to hook them in.


Droid Sans Fallback Regular is a free font that has glyphs for the  
above characters.

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




From robert at ocallahan.org  Wed Nov 12 01:03:13 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 12 Nov 2008 22:03:13 +1300
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <2c0e02830811112126r4b3fe7fej8f6d287697d211fa@mail.gmail.com>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<491A4BDB.1070903@wikimedia.org>
	<11e306600811112002t7d536743r10a07391e9264f4a@mail.gmail.com>
	<2c0e02830811112126r4b3fe7fej8f6d287697d211fa@mail.gmail.com>
Message-ID: <11e306600811120103m77bc7276m3c2553245f6ab4fc@mail.gmail.com>

On Wed, Nov 12, 2008 at 6:26 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> While my gut feeling tells me that this is the right solution - would
> you mind sharing some of the reasoning as discussed on irc?
>

No new reasoning. Just a judgement call based on already known facts. IRC
logs:
http://krijnhoetmer.nl/irc-logs/whatwg/20081111
http://krijnhoetmer.nl/irc-logs/whatwg/20081112

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/20081112/bc73ffa7/attachment.htm>

From tommy at kvaleberg.com  Wed Nov 12 01:49:03 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Wed, 12 Nov 2008 10:49:03 +0100
Subject: [whatwg] Scoping elements and nested paragraphs
Message-ID: <491AA68F.7070807@kvaleberg.com>

Consider the following markup:
    <p><object><p>X</p></p>

The html5 parsing algorithm produces the following tree:
    
<html><head></head><body><p><object><p>X</p><p></p></object></p></body></html>

whereas Firefox and Opera both produce:
    <html><head></head><body><p><object><p>X</p></object></p></body></html>

and IE produces:
    <html><head></head><body><p><object></object></p></body></html>

The main problem with the html5 output, in my opinion, is the extra 
<p></p> inside the <object>. This happens because <object> is a scoping 
element and the final </p> is not able to find the first <p>.

I've fixed this in our implementation by implementing the first 
paragraph in 'An end tag whose name is "p"' in "in body" as if it said:

---
If the stack of open elements does not have an element in scope  with 
the same tag name as that of the token, then this is a parse error

If the stack of open elements does not contain an element with the same 
tag name as that of the token, then act as if a start tag with the tag 
name p had been seen, then reprocess the current token.
---


Best regards,
Tommy


From jonas at sicking.cc  Wed Nov 12 01:47:49 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 12 Nov 2008 01:47:49 -0800
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <491A4BDB.1070903@wikimedia.org>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<491A4BDB.1070903@wikimedia.org>
Message-ID: <491AA645.9020907@sicking.cc>

Tim Starling wrote:
> Robert O'Callahan wrote:
>> Should <video> and <audio> elements be able to load and play resources
>> from other origins?
>>
>> Perhaps Ian thinks not:
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
>> There's a to-and-fro discussion here:
>> http://lists.xiph.org/pipermail/theora/2008-November/001931.html
>> Jonas got involved here:
>> http://lists.xiph.org/pipermail/theora/2008-November/001958.html
>>
>> There are three obvious options:
>> 1) Allow unrestricted cross-origin <video>/<audio>
>> 2) Allow cross-origin <video>/<audio> but carefully restrict the API
>> to limit the information a page can get about media loaded from a
>> different origin
>> 3) Disallow cross-origin <video>/<audio> unless the media server
>> explicitly allows it via the Access Control spec (e.g. by sending the
>> "Access-Control-Allow-Origin: *" header).
>>
> 
> (3) is particularly nasty due to the incentive it creates for insecure
> configuration. We've seen this already with Flash policy files. Many
> administrators uploaded a crossdomain.xml with <allow-access-from
> domain="*"/>, not realising what sort of vulnerability they were opening
> up. It would be a shame to borrow security ideas from possibly the least
> secure client on the web, and to mandate those insecure ideas in browser
> standards.

Please read my posting to the xiph list linked above (specifically 
towards the end when talking about access-control). Access-Control is 
very different from flashs crossdomain.xml in that you can opt in to 
sharing just public data. This means that for every server on the 
internet, it is completely safe to add the header 
"Access-Control-Allow-Origin: *" without risking leaking private data 
that couldn't be fetched using wget already.

/ Jonas




From ian at hixie.ch  Wed Nov 12 02:14:36 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 10:14:36 +0000 (UTC)
Subject: [whatwg] Res: HTML5 - Server-Sent Events Implementation for
	Mozilla
In-Reply-To: <23305.68338.qm@web53505.mail.re2.yahoo.com>
References: <23305.68338.qm@web53505.mail.re2.yahoo.com>
Message-ID: <Pine.LNX.4.62.0811120849480.1237@hixie.dreamhostps.com>

On Wed, 22 Oct 2008, Wellington wrote:
>
> I've looked at the spec that you have updated, and I think it isn't 
> clear enough in the text below if either the error should be ignored 
> (and so don't stop processing the resource, retrying after the 
> reconnection time) or if the resource should be ignored completely.
>
> "Any other HTTP response code not listed here or network error (e.g. DNS 
> errors) must be ignored."
> 
> Considering your email below I think it means the last one. Please, 
> clarify it better in order to prevent misunderstandings.

I don't really know how to clarify this. I've used the same wording for:

# HTTP 200 OK responses that have a Content-Type other than 
# text/event-stream (or some other supported type), and HTTP responses 
# whose Access-Control headers indicate that the resource are not to be 
# used, must be ignored.

...as for:

# Any other HTTP response code not listed here or network error (e.g. DNS 
# errors) must be ignored.

In both cases, the user agent is simply to do nothing special, no 
automatic reconnection, no black listing, no nothing.

Can you suggest how to clarify this so that it makes sense to you?

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


From jonas at sicking.cc  Wed Nov 12 02:19:44 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 12 Nov 2008 02:19:44 -0800
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <D48E66E8-FEF4-40A1-9898-F2707124C40A@apple.com>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<D48E66E8-FEF4-40A1-9898-F2707124C40A@apple.com>
Message-ID: <491AADC0.9060701@sicking.cc>

Maciej Stachowiak wrote:
> 
> On Nov 10, 2008, at 6:50 PM, Robert O'Callahan wrote:
> 
>> Should <video> and <audio> elements be able to load and play resources 
>> from other origins?
>>
>> Perhaps Ian thinks not:
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104
>> There's a to-and-fro discussion here:
>> http://lists.xiph.org/pipermail/theora/2008-November/001931.html
>> Jonas got involved here:
>> http://lists.xiph.org/pipermail/theora/2008-November/001958.html
>>
>> There are three obvious options:
>> 1) Allow unrestricted cross-origin <video>/<audio>
>> 2) Allow cross-origin <video>/<audio> but carefully restrict the API 
>> to limit the information a page can get about media loaded from a 
>> different origin
>> 3) Disallow cross-origin <video>/<audio> unless the media server 
>> explicitly allows it via the Access Control spec (e.g. by sending the 
>> "Access-Control-Allow-Origin: *" header).
> 
> I'd prefer 1 or 2 (assuming the restrictions assumed by 2 are reasonable).

We're already exposing more on <video> than we are for <img>. 
ProgressEvents expose the file size, and there is API to get the 
duration of the playtime.

An additional, though rather minor problem, is that implementations will 
have to delay the loadstart event until it has confirmed that the 
targeted file is in fact a real video file, and has confirmed that with 
relatively high level of confidence. Otherwise the size of random HTML 
files can be measured using the <video> element.

And that's on top of the things that <img> unfortunately already exposes 
such as the image existence and it's on-screen size.

Things are largely mitigated if we don't send cookies (nor other auth 
credentials) when doing cross-site <video> requests. Then the only 
information that can be leaked is information protected by firewalls.

However I am still concerned with putting wording in the HTML spec 
basically saying

# If you are putting a video file, or something that looks a lot like
# it, behind a firewall, the firewall is not going to provide any actual
# security for some of the meta-data about that video. Any website on
# the internet is going to be able to see that videos existance, its
# filesize, its dimensions in pixels and its playtime duration in
# seconds. The only security the firewall is going to provide for
# that data is obscurity, i.e. it is unlikely that any other person
# outside will know the url to that video to fetch that meta data.

Yes, we should say the same thing for images (minus some of the meta 
data), but I can't say that I'm thrilled about that since I suspect few 
people realize that.


/ Jonas


From robert at ocallahan.org  Wed Nov 12 02:58:54 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 12 Nov 2008 23:58:54 +1300
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <491AADC0.9060701@sicking.cc>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<D48E66E8-FEF4-40A1-9898-F2707124C40A@apple.com>
	<491AADC0.9060701@sicking.cc>
Message-ID: <11e306600811120258l29d3d1aaud22c4b404b854653@mail.gmail.com>

On Wed, Nov 12, 2008 at 11:19 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> An additional, though rather minor problem, is that implementations will
> have to delay the loadstart event until it has confirmed that the targeted
> file is in fact a real video file, and has confirmed that with relatively
> high level of confidence. Otherwise the size of random HTML files can be
> measured using the <video> element.


We can fire "loadstart" normally and return 0 in the "loaded" attribute and
"unknown" in the "total" attribute (however that should be encoded). (We
have to be able to return "unknown" since there can be situations, e.g. live
streams, where we'll never know the total size.)

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/20081112/ffe15478/attachment.htm>

From philipj at opera.com  Wed Nov 12 03:16:14 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Wed, 12 Nov 2008 12:16:14 +0100
Subject: [whatwg] Same-origin checking for media elements
In-Reply-To: <11e306600811120258l29d3d1aaud22c4b404b854653@mail.gmail.com>
References: <11e306600811101850r2faede65m1d97df8480df3a48@mail.gmail.com>
	<D48E66E8-FEF4-40A1-9898-F2707124C40A@apple.com>
	<491AADC0.9060701@sicking.cc>
	<11e306600811120258l29d3d1aaud22c4b404b854653@mail.gmail.com>
Message-ID: <1226488574.6873.4.camel@localhost>

I don't quite see why one should betray the size of media data and not
other data. Surely the existance and size of media files on an intranet
could be sensitive information too, so a more general solution is needed
in my opinion. Am I misunderstanding what is being suggested?

Philip

On Wed, 2008-11-12 at 23:58 +1300, Robert O'Callahan wrote:
> On Wed, Nov 12, 2008 at 11:19 PM, Jonas Sicking <jonas at sicking.cc>
> wrote:
>         An additional, though rather minor problem, is that
>         implementations will have to delay the loadstart event until
>         it has confirmed that the targeted file is in fact a real
>         video file, and has confirmed that with relatively high level
>         of confidence. Otherwise the size of random HTML files can be
>         measured using the <video> element.
> 
> We can fire "loadstart" normally and return 0 in the "loaded"
> attribute and "unknown" in the "total" attribute (however that should
> be encoded). (We have to be able to return "unknown" since there can
> be situations, e.g. live streams, where we'll never know the total
> size.) 

-- 
Philip J?genstedt
Opera Software



From ap at webkit.org  Wed Nov 12 03:08:59 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Wed, 12 Nov 2008 14:08:59 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
Message-ID: <45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>


Nov 4, 2008, ? 10:08 AM, Aaron Boodman ???????(?):

> * Add startConversation() to SharedWorker, but rename it "connect()"
> and make the onconnect event fire inside the worker each time it is
> called.


What event do you suggest to dispatch in the worker when connect() is  
called? From the above, it formally follows that a MessageEvent with  
name "message" is dispatched, so a handler could also be installed as

addEventListener("message", onConnect, true);

This doesn't look very intuitive or straightforward, considering that  
message event handlers are also installed by ports to listen to  
messages.

- WBR, Alexey Proskuryakov



From eric.carlson at apple.com  Wed Nov 12 08:02:26 2008
From: eric.carlson at apple.com (Eric Carlson)
Date: Wed, 12 Nov 2008 08:02:26 -0800
Subject: [whatwg] Issue when Video currentTime used for seeking.
In-Reply-To: <c2e346f90811112324y2a87b806mce7639c1b52a908e@mail.gmail.com>
References: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
	<c2e346f90811112324y2a87b806mce7639c1b52a908e@mail.gmail.com>
Message-ID: <B5892135-B371-4FF9-B880-FF35C2097F42@apple.com>


On Nov 11, 2008, at 11:24 PM, Chris Double wrote:

> On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com>  
> wrote:
>> toKeyFrame - optional, boolean, default false. if true indicates goto
>> the nearest keyframe of the value provided in secondsToSeek.
>> this is to improve performance while avoiding  bug
>> https://bugzilla.mozilla.org/show_bug.cgi?id=463358
>
> Good question. Should seeks go to the previous keyframe to the
> requested time,  the next keyframe after the time, the closest
> keyframe, or the exact frame requested?
>
   Seeks should end up as close to the requested time as possible, the  
behavior wrt keyframes should be an implementation detail. I say "as  
close as possible" because it is not always possible to know the file  
location of an exact time unless all of the media data up to that time  
has already been downloaded.

> Regarding that bug, I think it should be going to the last keyframe
> then decoding up to the point of the requested frame so it can display
> non-garbage data. But is there a requirement to be able to identify
> keyframes from JavaScript? I suspect not but don't know.
>
   I agree that it doesn't make sense to try to identify keyframes  
from JavaScript. I can't imagine that it will be commonly used, and  
with (at least some) streaming formats a media engine has no  
information about keyframe location or availability.

eric



From dhtmlkitchen at gmail.com  Wed Nov 12 08:51:34 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 12 Nov 2008 08:51:34 -0800
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <Pine.LNX.4.62.0811120719590.1041@hixie.dreamhostps.com>
References: <49181236.7080105@kvaleberg.no>
	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
	<491845D4.1000908@kvaleberg.no>
	<op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com>
	<c9e12660811112035w2c2af22bwc78c06fb88e155c8@mail.gmail.com>
	<Pine.LNX.4.62.0811120719590.1041@hixie.dreamhostps.com>
Message-ID: <c9e12660811120851o4eaff773v892840d56769be6d@mail.gmail.com>

On Tue, Nov 11, 2008 at 11:21 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 11 Nov 2008, Garrett Smith wrote:
>> >
>> > Unfortunately, we have little choice in the matter. Scripting and XML
>> > both allow you to unambiguously create highly non-conforming DOMs,
>> > e.g. with <title> elements as the root element and <html> elements as
>> > children of <input> elements. The renderer has to deal with all such
>> > DOMs.
>>
>> What does XML has to do with any of this?
>
> XML can denote arbitrarily nested DOMs.
>
>
>> A script that adds an HTML element to a INPUT element should cause an
>> hierarchy exception to be raised.
>
> No, it shouldn't.
>

DOM 1 seems to disagree with that.

>
>> | Since user agents may vary in how they handle error conditions,
>> | authors and users must not rely on specific error recovery behavior.
>>
>> http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-invalid-docs
>
> This was one of the biggest mistakes in HTML4, and HTML5 does not make
> that mistake again.
>

Why?

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


From darin at apple.com  Wed Nov 12 10:08:55 2008
From: darin at apple.com (Darin Adler)
Date: Wed, 12 Nov 2008 10:08:55 -0800
Subject: [whatwg] Scoping elements and nested paragraphs
In-Reply-To: <491AA68F.7070807@kvaleberg.com>
References: <491AA68F.7070807@kvaleberg.com>
Message-ID: <C3F9F478-8E1A-4D5F-9CB6-918CD4DB8DE7@apple.com>

On Nov 12, 2008, at 1:49 AM, Tommy Thorsen wrote:

> Consider the following markup:
>   <p><object><p>X</p></p>
>
> The html5 parsing algorithm produces the following tree:
>   <html><head></head><body><p><object><p>X</p><p></p></object></p></ 
> body></html>
>
> whereas Firefox and Opera both produce:
>   <html><head></head><body><p><object><p>X</p></object></p></body></ 
> html>
>
> and IE produces:
>   <html><head></head><body><p><object></object></p></body></html>

For what it's worth, WebKit produces a DOM matching the HTML 5 parsing  
algorithm result above.

     -- Darin



From aa at google.com  Wed Nov 12 10:26:29 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 12 Nov 2008 10:26:29 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
Message-ID: <278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>

2008/11/12 Alexey Proskuryakov <ap at webkit.org>:
>
> Nov 4, 2008, ? 10:08 AM, Aaron Boodman ???????(?):
>
>> * Add startConversation() to SharedWorker, but rename it "connect()"
>> and make the onconnect event fire inside the worker each time it is
>> called.
>
> What event do you suggest to dispatch in the worker when connect() is
> called?

I meant "connect". The same "connect" event (I'm not sure of the
constructor off the top of my head) that Hixie originally had being
fired when new clients create new instances of a shared worker.

> From the above, it formally follows that a MessageEvent with name
> "message" is dispatched

How does that follow?

- a


From dimich at chromium.org  Wed Nov 12 11:33:43 2008
From: dimich at chromium.org (Dmitry Titov)
Date: Wed, 12 Nov 2008 11:33:43 -0800
Subject: [whatwg] Questions on Workers spec
Message-ID: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>

Hi,
I have couple of questions about Workers:

1. The sample code looks as
if  setTimeout/clearTimeout/setInterval/clearInterval should be available to
Workers (as methods of WorkerUtils?) but they are not explicitly specified
on any interface. Should they be there?

2. It seems workers should be able to create workers (including creating
'themselves' in case of SharedWorker). It is especially useful for a
 SharedWorker to create dedicated workers - since one of the popular
scenarios for it is likely  a "state container" that communicates with UI
pages while using dedicated workers to do other operations. Will spec
include this?


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

From ian at hixie.ch  Wed Nov 12 11:44:31 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 19:44:31 +0000 (UTC)
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <c9e12660811120851o4eaff773v892840d56769be6d@mail.gmail.com>
References: <49181236.7080105@kvaleberg.no>
	<op.ukemdgwuidj3kv@zcorpandell.linkoping.osa>
	<491845D4.1000908@kvaleberg.no>
	<op.ukeq6m18idj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0811101556430.1041@hixie.dreamhostps.com> 
	<c9e12660811112035w2c2af22bwc78c06fb88e155c8@mail.gmail.com> 
	<Pine.LNX.4.62.0811120719590.1041@hixie.dreamhostps.com>
	<c9e12660811120851o4eaff773v892840d56769be6d@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811121936010.1041@hixie.dreamhostps.com>

On Wed, 12 Nov 2008, Garrett Smith wrote:
> >>
> >> A script that adds an HTML element to a INPUT element should cause an 
> >> hierarchy exception to be raised.
> >
> > No, it shouldn't.
> 
> DOM 1 seems to disagree with that.

You are misreading DOM1 (the type of a node means text node vs element 
node, not one type of element node vs another), but in any case, DOM1 is 
obsolete now, and browsers uniformly implement a DOM that allows arbitrary 
elements to be nested arbitrarily, and this is what Web DOM Core will 
require too.


> >> | Since user agents may vary in how they handle error conditions,
> >> | authors and users must not rely on specific error recovery behavior.
> >>
> >> http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-invalid-docs
> >
> > This was one of the biggest mistakes in HTML4, and HTML5 does not make
> > that mistake again.
> 
> Why?

Not defining error handling is how we ended up with tag soup. It results 
in high barriers to entry for competition in the browser space and leads 
to subtle differences between browsers that causes developer pain and can 
be used (intentionally or not) as a vendor-lockin technique. I recommend 
reading some of the blogs and position papers from early 2004 around when 
the WHATWG was formed. Suffice it to say that from the WHATWG's 
perspective, it is taken as a basic axiom that error handling must be 
defined in detail.

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


From ap at webkit.org  Wed Nov 12 14:29:45 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Thu, 13 Nov 2008 01:29:45 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
	<278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
Message-ID: <79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>


Nov 12, 2008, ? 9:26 PM, Aaron Boodman ???????(?):

>>> * Add startConversation() to SharedWorker, but rename it "connect()"
>>> and make the onconnect event fire inside the worker each time it is
>>> called.
>>
>> What event do you suggest to dispatch in the worker when connect() is
>> called?
>
> I meant "connect". The same "connect" event (I'm not sure of the
> constructor off the top of my head) that Hixie originally had being
> fired when new clients create new instances of a shared worker.

Ok. That's "a MessageEvent interface, with the name connect". In our  
current implementation, all MessageEvents have the name "message", but  
I now see that this doesn't follow from anything HTML5 says about  
MessageEvents.

I'm fine with dispatching a MessageEvent named "connect" here.

>> From the above, it formally follows that a MessageEvent with name
>> "message" is dispatched
>
> How does that follow?


Well, that's what MessagePort.startConversation() sends, and the  
proposal only said that connect() is a renamed startConversation()  
from Worker (also, "The postMessage() and startConversation() methods  
on Worker objects must act as if, when invoked, they immediately  
invoked the method of the same name on the port, with the same  
arguments").

- WBR, Alexey Proskuryakov



From aa at google.com  Wed Nov 12 14:34:58 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 12 Nov 2008 14:34:58 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
	<278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
	<79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>
Message-ID: <278fd46c0811121434o3450e7edkbb487864b088bb28@mail.gmail.com>

2008/11/12 Alexey Proskuryakov <ap at webkit.org>:
> Well, that's what MessagePort.startConversation() sends, and the proposal
> only said that connect() is a renamed startConversation() from Worker (also,
> "The postMessage() and startConversation() methods on Worker objects must
> act as if, when invoked, they immediately invoked the method of the same
> name on the port, with the same arguments").

It doesn't make sense to me that startConversation() would dispatch a
MessageEvent object with name "message". If that's what the spec
currently says, I think it should be changed.

- a


From ap at webkit.org  Wed Nov 12 14:40:35 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Thu, 13 Nov 2008 01:40:35 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811121434o3450e7edkbb487864b088bb28@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
	<278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
	<79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>
	<278fd46c0811121434o3450e7edkbb487864b088bb28@mail.gmail.com>
Message-ID: <B337C8A0-0898-4300-A60D-0B9D44C7C891@webkit.org>


Nov 13, 2008, ? 1:34 AM, Aaron Boodman ???????(?):

> It doesn't make sense to me that startConversation() would dispatch a
> MessageEvent object with name "message". If that's what the spec
> currently says, I think it should be changed.


"The startConversation(message) method is a convenience method that  
simplifies create a new MessageChannel and invokingpostMessage() with  
one of the new ports." - it doesn't do anything postMessage() couldn't  
do. Receivers are supposed to differentiate events by evt.data.

- WBR, Alexey Proskuryakov



From aa at google.com  Wed Nov 12 14:46:02 2008
From: aa at google.com (Aaron Boodman)
Date: Wed, 12 Nov 2008 14:46:02 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <B337C8A0-0898-4300-A60D-0B9D44C7C891@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
	<278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
	<79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>
	<278fd46c0811121434o3450e7edkbb487864b088bb28@mail.gmail.com>
	<B337C8A0-0898-4300-A60D-0B9D44C7C891@webkit.org>
Message-ID: <278fd46c0811121446q2062960obe3ce696f460c422@mail.gmail.com>

2008/11/12 Alexey Proskuryakov <ap at webkit.org>:
> "The startConversation(message) method is a convenience method that
> simplifies create a new MessageChannel and invokingpostMessage() with one of
> the new ports." - it doesn't do anything postMessage() couldn't do.
> Receivers are supposed to differentiate events by evt.data.

I see. Well that kinda makes sense, as long as the method is not
called 'connect'. It would be really silly if there were a 'connect()'
method and an 'onconnect' event, but they were unrelated :).

I feel that it probably is not productive to continue discussing
details when there is disagreement on the large-scale shape of the API
between myself, Jonas, and Hixie. My opinion on this detail, for
example, probably varies depending on whether there is a
startConversation() method on shared workers, dedicated workers,
neither, or both.

- a


From ap at webkit.org  Wed Nov 12 15:01:06 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Thu, 13 Nov 2008 02:01:06 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811121446q2062960obe3ce696f460c422@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
	<278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
	<79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>
	<278fd46c0811121434o3450e7edkbb487864b088bb28@mail.gmail.com>
	<B337C8A0-0898-4300-A60D-0B9D44C7C891@webkit.org>
	<278fd46c0811121446q2062960obe3ce696f460c422@mail.gmail.com>
Message-ID: <0804F030-92DC-4646-AA8C-C4C1BDD018D9@webkit.org>


Nov 13, 2008, ? 1:46 AM, Aaron Boodman ???????(?):

> I feel that it probably is not productive to continue discussing
> details when there is disagreement on the large-scale shape of the API
> between myself, Jonas, and Hixie.


This is a weird situation indeed, as Firefox seems to be about to ship  
this feature with an API that other implementors do not like, and I  
certainly think that we need to come to an agreement soon.

FWIW, for now I'm implementing your proposal that combines Worker and  
SharedWorker APIs, see e.g. <https://bugs.webkit.org/show_bug.cgi?id=22203 
 > (I also think that SharedWorker doesn't deserve to have an  
interface of its own, but I'm not implementing shared workers yet  
anyway). I like that it doesn't tie Worker and MessagePort lifetimes  
too closely, which means that it has a higher chance of being paradox- 
free.

This is why I'm concerned about the details of this particular proposal.

- WBR, Alexey Proskuryakov



From ian at hixie.ch  Wed Nov 12 15:35:41 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 12 Nov 2008 23:35:41 +0000 (UTC)
Subject: [whatwg] Workers
In-Reply-To: <fa2eab050808271629v322b835ahf1b571bef7dee485@mail.gmail.com>
References: <48AE0582.2000902@sicking.cc>
	<Pine.LNX.4.62.0808270725000.14795@hixie.dreamhostps.com>
	<fa2eab050808271629v322b835ahf1b571bef7dee485@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811122316500.1237@hixie.dreamhostps.com>


(cc'ed whatwg -- sorry if that wasn't what you intended)

On Wed, 27 Aug 2008, Michael Nordman wrote:
> 
> I see... in that case, consider renaming the owner invoked 
> worker.close() method to use a different verb than self.close()... 
> worker.stop() or worker.terminate() or worker.kill() or worker.abandon() 
> or worker.discard()

I've renamed it worker.terminate().


> > > Is it possible for a worker (shared or dedicated) to reload itself?
> >
> > Not currently.
> 
> For dedicated workers, this can effectively be accomplished already by 
> one of the two means of close()ing a worker and then starting a new one 
> and then handing out ports as needed.
> 
> But for shared workers, this is a more interesting question. Provided 
> clients of the shared worker (those that have a reference to it) can be 
> relied on to restart it upon onclose(), reload() would effectively 
> happen. Are there any windows of time where a shared worker executes w/o 
> a client having a reference it?

Yes. Any worker can survive, e.g. if it has timers running, until its 
parent window (or any window that it ever spoke to) closes the document 
it is associated with.

I don't really see the use case for self-reloading. Do scripts self-reload 
in general?


> > > How do workers and appCaches interact?
> >
> > workers are associated with browsing contexts, so they go through the 
> > normal app cache networking changes. This probably interacts badly 
> > with shared workers used from different app caches. We should probably 
> > study this more.
> >
> > Aaron, Maciej, others, do you have opinions on how these should 
> > interact?
> 
> Seems reasonable to spec that dedicated workers are very related to 
> their owner, execute in a child browsing context, and consequently 
> inherit the same appCache.
> 
> Seems reasonable to spec that shared workers are associated with a 
> browsing context that is very distinct from their clients. Akin to an 
> "auxiliary top-level browsing context".

The above seems reasonable...


> Beyond that it gets less clear.
> 
> Do sharedWorker.js documents need a <html manifest='url'> equivalent?

They don't have one today. I don't really want to add one...


> Should a shraredWorker loaded from appCacheA be distinct from a named 
> shared worker loaded from appCacheB or from the network?

That seems like a reasonable possibility too...


I haven't fixed this yet.

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


From ian at hixie.ch  Wed Nov 12 16:37:54 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 13 Nov 2008 00:37:54 +0000 (UTC)
Subject: [whatwg] Combining the DedicatedWorker and
	SharedWorker	interfaces
In-Reply-To: <278fd46c0811121446q2062960obe3ce696f460c422@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
	<278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
	<79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>
	<278fd46c0811121434o3450e7edkbb487864b088bb28@mail.gmail.com>
	<B337C8A0-0898-4300-A60D-0B9D44C7C891@webkit.org>
	<278fd46c0811121446q2062960obe3ce696f460c422@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811130034480.1041@hixie.dreamhostps.com>

On Wed, 12 Nov 2008, Aaron Boodman wrote:
> 
> I feel that it probably is not productive to continue discussing details 
> when there is disagreement on the large-scale shape of the API between 
> myself, Jonas, and Hixie. My opinion on this detail, for example, 
> probably varies depending on whether there is a startConversation() 
> method on shared workers, dedicated workers, neither, or both.

I'm going through the feedback right now, for what it's worth.

In general I think the startConversation() issue is a red herring. The 
method was added just as a convenience and isn't really needed. I can 
remove it if it would make the discussions simpler.

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


From herenvardo at gmail.com  Wed Nov 12 17:28:21 2008
From: herenvardo at gmail.com (Eduard Pascual)
Date: Thu, 13 Nov 2008 01:28:21 +0000
Subject: [whatwg] [WebForms2] custom form validation notifications
In-Reply-To: <Pine.LNX.4.62.0811120111270.1237@hixie.dreamhostps.com>
References: <op.tgvjyxmvxl3at9@dragast.mshome.net>
	<1959130b0610032005r58684830s23b0780c5a24f387@mail.gmail.com>
	<dd924299b3f7427da183b7cf9951d52f@myrealbox.com>
	<6617CB7F-D53C-47BE-B928-31FF7093860F@iki.fi>
	<Pine.LNX.4.62.0810231412500.1237@hixie.dreamhostps.com>
	<6ea53250810231502t3b516187qf08edbed55cc736e@mail.gmail.com>
	<Pine.LNX.4.62.0811120111270.1237@hixie.dreamhostps.com>
Message-ID: <6ea53250811121728n1920ce18l79cfa440f3dfb81e@mail.gmail.com>

On Wed, Nov 12, 2008 at 1:15 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 23 Oct 2008, Eduard Pascual wrote:
>> [...]
>
> I don't really follow.
Neither do I, and I wrote that :S

Re-reading the conversation, I'm not really sure if I really
understood Joao's issue and proposal correctly; and without him
providing any clarification this doesn't turn any better... And, in
addition, I couldn't have worded my ideas worse than I did. It seems
that I got a "404 Brain not found" while writting that message.

Summarizing, my suggestion (a possible solution for what I thought to
be the main use-case for this) was to *not* include the
validation-related arguments in the markup (or use "catch-all"
placeholders), but instead add them from a script upon the page's
onload event. This way, when scripts are available, the javascript
will do whatever it needs, customize everything, and so on; but when
scripts are disabled or not supported, the client won't do anything,
and all the validation will be delegated to the server (that's what is
called *graceful* degradation, in contrast with "grace-less" stuff
like "<noscript>You have no scripting: your browser sux, get a new
one</noscript>" :P )

>> OTOH, I think Joao's idea was more like to relying on visual hints (ie:
>> marking the field as red) on cases where an error message popup would be
>> redundant and annoying. I think that could be more elegantly handled
>> with an empty attribute value for an hipothetical "custom-error-message"
>> attribute (which is not the same as an absent attribute).
>
> I really don't follow this. Maybe some concrete examples showing the
> problem with the current spec solutions would help.

The main point is that when a page already handless error-reporting
via CSS (for example, marking valid fields in green and invalid ones
in red), further notifications by the UA are redundant and sometimes
(if they take the form pop-up messages) annoying to the user. The need
would be to disable such messages even when scripts are not available.
I don't really know if there is a way to do that with the current
spec.
Anyway, as long as browsers don't use pop-ups for this kind of
notification, this shouldn't be an issue. Most browsers already
provide pop-up blocking functionality, so I hope they won't add
pop-ups of their own needlessly. In addition, a user that sees a field
becomming red (or marked as "invalid" in some other way) isn't likely
to hit the "submit" button before fixing it, so I don't think this is
too much of an issue anyway. Maybe Joao had something else in mind, or
some specific use-case, but unless he can provide more details, I
think this discussion will lead nowhere.

Greetings,
Eduard Pascual


From ap at webkit.org  Wed Nov 12 22:02:32 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Thu, 13 Nov 2008 09:02:32 +0300
Subject: [whatwg] Combining the DedicatedWorker and
	SharedWorker	interfaces
In-Reply-To: <Pine.LNX.4.62.0811130034480.1041@hixie.dreamhostps.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<45AA3532-54FC-4B85-9A68-7220CB1E02AA@webkit.org>
	<278fd46c0811121026i22f6dc5bga4dd3a0b019a72cb@mail.gmail.com>
	<79DFBC7C-FE23-4165-83BD-0388810729CD@webkit.org>
	<278fd46c0811121434o3450e7edkbb487864b088bb28@mail.gmail.com>
	<B337C8A0-0898-4300-A60D-0B9D44C7C891@webkit.org>
	<278fd46c0811121446q2062960obe3ce696f460c422@mail.gmail.com>
	<Pine.LNX.4.62.0811130034480.1041@hixie.dreamhostps.com>
Message-ID: <7B775C65-3050-4BA1-A059-E135E1A3832E@webkit.org>


Nov 13, 2008, ? 3:37 AM, Ian Hickson ???????(?):

> In general I think the startConversation() issue is a red herring. The
> method was added just as a convenience and isn't really needed. I can
> remove it if it would make the discussions simpler.


As far as I'm concerned, there is no issue any more - Aaron's  
explanation about the name of event dispatched by connect() is  
perfectly fine with me, and I don't think there are any issues with  
MessagePort.startConversation().

- WBR, Alexey Proskuryakov



From levin at google.com  Thu Nov 13 00:12:35 2008
From: levin at google.com (David Levin)
Date: Thu, 13 Nov 2008 00:12:35 -0800
Subject: [whatwg] Workers
In-Reply-To: <Pine.LNX.4.62.0811122316500.1237@hixie.dreamhostps.com>
References: <48AE0582.2000902@sicking.cc>
	<Pine.LNX.4.62.0808270725000.14795@hixie.dreamhostps.com>
	<fa2eab050808271629v322b835ahf1b571bef7dee485@mail.gmail.com>
	<Pine.LNX.4.62.0811122316500.1237@hixie.dreamhostps.com>
Message-ID: <b902e34a0811130012h2a8438d1vadfa5d451fb29642@mail.gmail.com>

On Wed, Nov 12, 2008 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> (cc'ed whatwg -- sorry if that wasn't what you intended)
>
> On Wed, 27 Aug 2008, Michael Nordman wrote:
>
> > > > Is it possible for a worker (shared or dedicated) to reload itself?
> > >
> > > Not currently.
> >
> > For dedicated workers, this can effectively be accomplished already by
> > one of the two means of close()ing a worker and then starting a new one
> > and then handing out ports as needed.
> >
> > But for shared workers, this is a more interesting question. Provided
> > clients of the shared worker (those that have a reference to it) can be
> > relied on to restart it upon onclose(), reload() would effectively
> > happen. Are there any windows of time where a shared worker executes w/o
> > a client having a reference it?
>
> Yes. Any worker can survive, e.g. if it has timers running, until its
> parent window (or any window that it ever spoke to) closes the document
> it is associated with.
>
> I don't really see the use case for self-reloading. Do scripts self-reload
> in general?
>

For people who want to update script in SharedWorker, could they do it by
making the SharedWorker merely a shell?

The SharedWorker would create a Worker to do everything.  If a reload is
needed, then the SharedWorker closes the Worker and starts it again (just
like the dedicated worker method described above).

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081113/7f4d608f/attachment.htm>

From ian at hixie.ch  Thu Nov 13 00:26:38 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 13 Nov 2008 08:26:38 +0000 (UTC)
Subject: [whatwg] Workers
In-Reply-To: <b902e34a0811130012h2a8438d1vadfa5d451fb29642@mail.gmail.com>
References: <48AE0582.2000902@sicking.cc>
	<Pine.LNX.4.62.0808270725000.14795@hixie.dreamhostps.com>
	<fa2eab050808271629v322b835ahf1b571bef7dee485@mail.gmail.com> 
	<Pine.LNX.4.62.0811122316500.1237@hixie.dreamhostps.com>
	<b902e34a0811130012h2a8438d1vadfa5d451fb29642@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811130826190.1041@hixie.dreamhostps.com>

On Thu, 13 Nov 2008, David Levin wrote:
> >
> > I don't really see the use case for self-reloading. Do scripts 
> > self-reload in general?
> 
> For people who want to update script in SharedWorker, could they do it 
> by making the SharedWorker merely a shell?
> 
> The SharedWorker would create a Worker to do everything.  If a reload is 
> needed, then the SharedWorker closes the Worker and starts it again 
> (just like the dedicated worker method described above).

Yes, that would work.

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


From levin at google.com  Thu Nov 13 00:29:57 2008
From: levin at google.com (David Levin)
Date: Thu, 13 Nov 2008 00:29:57 -0800
Subject: [whatwg] Questions on Workers spec
In-Reply-To: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>
References: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>
Message-ID: <b902e34a0811130029j4813799cj6f1e459c4c33b2ba@mail.gmail.com>

It looks like all of this is there in a just published update of the spec.


On Wed, Nov 12, 2008 at 11:33 AM, Dmitry Titov <dimich at chromium.org> wrote:

> Hi,
> I have couple of questions about Workers:
>
> 1. The sample code looks as
> if  setTimeout/clearTimeout/setInterval/clearInterval should be available to
> Workers (as methods of WorkerUtils?) but they are not explicitly specified
> on any interface. Should they be there?
>
> 2. It seems workers should be able to create workers (including creating
> 'themselves' in case of SharedWorker). It is especially useful for a
>  SharedWorker to create dedicated workers - since one of the popular
> scenarios for it is likely  a "state container" that communicates with UI
> pages while using dedicated workers to do other operations. Will spec
> include this?
>
>
> Thanks
> Dmitry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081113/2ab4b594/attachment.htm>

From jonas at sicking.cc  Thu Nov 13 02:12:19 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 13 Nov 2008 02:12:19 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>
	<491229C8.8080205@sicking.cc>
	<AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org>
Message-ID: <63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>

Alexey Proskuryakov wrote:
>
> Nov 6, 2008, ? 2:18 AM, Jonas Sicking ???????(?):
>
>>> Similarly, having separate interfaces for Worker and SharedWorker
>>> implies that there is some fundamental difference in their behavior -
>>> a difference that eludes me so far.
>>
>> A shared worker is shared between all scripts on a single site[*] that
>> instantiates a worker with the same name. I.e. where the second
>> argument to the constructor is the same. (Don't remember what happens
>> if the second argument is the same as an existing worker, but the
>> first is not, check with the spec).
>
> Sure, that part is clear - but it's only about the behavior of the
> object's constructor, not the object itself! It alone doesn't warrant
> having a separate interface.
>
> As an example from another area, see mmap(2) function - you can pass
> MAP_ANON or MAP_FILE via its flags to achieve similar results. Note also
> that it has a number of other options. If we create a separate interface
> for every Worker isolation level needed (both inside and outside), we'll
> soon end up with PrivateWorker, SharedDataWorker and who knows what else.

So at this point the main problem with making any changes is that we
are very close to shipping Firefox 3.1. I.e. it is extremely hard to
make changes. It is very unfortunate that we have ended up in this
situation again. We were in a very similar to the window.postMessage
API where we had to scramble last minute to make changes, the result
that time was that security issues in the API slipped by since those
changes happened after we had done our security review of the spec.

A few months ago representatives from google, apple, and mozilla met
to try to agree to an API. We came up with a few guidelines, such as
that it was ok to have a separate API for shared and dedicated workers
as well as others that I don't specifically remember. At the end of
the meeting we had a rough sketch of an API. A few days after that
Hixie published a proposal. At mozilla we were largely fine with the
proposal modulo some details that we commented on fairly quickly and
then proceeded to implement.

Now, months later, both google and apple is asking for some pretty
significant changes, including reverting things like separate APIs for
shared and dedicated workers. It is very close to release for us and
we are already in a very frozen state, so making changes at this point
is somewhere between risky and impossible.

If we really want to make changes to the spec, we better make them
really fast, ideally within a day or two. And depending on the
complexity of the changes we might still be able to do them. The other
alternative is of course removing workers from FF 3.1 and waiting
until next release (judging by past releases, somewhere between a year
or two from now). Finally, we can simply stick with the current API,
none of the complains about the current syntax seems to have been very
catastrophic, such as "doesn't satisfy use cases", "hard to
understand", "easy to have hard-to-discover bugs", etc. They mostly
seem to be syntactic and the case of the matter is as always that
there is no perfect syntax as the problem is over constrained.

I see lots of ideas floating around but many of them are severly
lacking in detail so it's hard to comment on. Things like 'rename
startConversation to connect' is very ambiguous as has shown by recent
discussions. So what follows is an effort to try to focus in on some
discussed changes more concretely:

The main two things that people seem to dislike in the current are
1. The many communication mechanisms.
2. Different APIs for shared and dedicated workers.

I've said before that I don't really think 1 is true. There is
currently one communication mechanism (postMessage/onmessage) and one
connection mechanism (onconnect). There is also one convenience
function on top of the communication mechanism (startConversaion), but
is a stretch to call it a separate communication mechanism. The
communication mechanism (postMessage/onmessage) does come in two
flavors though as you for shared workers and dedicated workers call
the functions on different objects.

2 I think is as much of a feature as a bug. Dedicated workers are by
nature simpler since there is a one-to-one relationship between
browsing context and worker rather than a many-to-one. So by having
different APIs we can allow the dedicated worker API to be simpler.
That said, I do agree that it is unfortunate that the mechanisms are
different.


So, here are some concrete proposals for a few changes we can make,
and comments i've heard/made about them. The changes refer to the
*current draft*, so please check the behavior defined there.

* Remove startConversation
Details:
Simply remove the startConversaion function on all interfaces where it
is defined. Since it doesn't define any new events no other changes
are needed.

Comments:
There seemed to be opinions before on that it should definitely be
removed, however it sounds like that is less the case now. I don't
really care about this one. startConversation is just a convenience
function on top of postMessage anyway. If there still is any
disagreement about its neccessity or the fact that it adds to that we
have too many communication mechanisms i'd prefer we remove it for now
and then discuss it once we've agreed on the rest of the API, or we
can let it be for this version of the spec. Others have commented that
startConversation is a red herring in these discussions, I agree.
 (This would be no problem for us since we don't implement
startConversation yet).

* Make the external API for shared workers that of the current dedicated worker
Details:
Move the postMessage/onmessage functions from the SharedWorker.port
object to the SharedWorker object. The SharedWorker would act as a
MessagePort that is entangled with the port that is provided to the
SharedWorkerGlobalScope through already specified 'connect' event that
is fired when a SharedWorker is created.

Comments:
The result of this would be that on the outside shared workers and
dedicated workers have exactly the same API to the outside world,
except that dedicated workers have a terminate() function (formerly
known as close(), changed in the latest version of the spec).
I think this is a good idea all around and we should make this change.
(This would be no problem for us since we don't implement shared
workers yet).
Hixie expressed some dislike about the fact that we'd end up with
MessagePort entangled with something that isn't a MessagePort. This
can result in uglyness if the MessagePort is passed out outside the
SharedWorker, and then passed on anywhere. A page could create a setup
where calling postMessage on a SharedWorker object actually resulted
in onmessage being called inside another window rather than inside a
worker global scope.
I don't really think this is a big deal though, you have a very
similar situation today where calling postMessage on a
SharedWorker.port object can do exactly the same thing.

* Make dedicated workers receive a 'connect' event when they are created
Details:
Make the internal communication API for a dedicated worker exactly
that of what a shared worker is currently specced as. This means
 - Once a dedicated worker is instantiated automatically fire a
'connect' event which contains a MessagePort object (accessible
through event.port).
 - Make the Worker object entangled with this MessagePort.
 - Remove the postMessage/onmessage functions from DedicatedWorkerGlobalScope

Comments:
I don't feel super strongly about this. From a purely dedicated worker
perspective this doesn't really add any value but rather just
complexity. Everyone using dedicated workers will have to set up a
dummy function that just listens for a 'connect' event and sets a
global port variable. The upside is that combined with the above
change it makes the API for dedicated and shared workers exactly the
same.
We are currently looking in to if this is doable without adding too
much risk to FF3.1. The big concern here is more objects means more
chances of leak bugs since we can't reuse the same leak prevention
mechanisms as we do on the main thread since that one isn't
threadsafe. Anyhow, it's an implementation detail, but it is a big
part of why making even small at this stage is non-trivial.

* Add a connect() method to Worker and/or SharedWorker
There has been lots of talk about this, but I'm still confused as to
what the exact proposals are due to lack of details. But here is my
interpretation
Details:
 - Make instantiating a SharedWorker *not* fire a 'connect' event automatically.
 - Remove the .port property from SharedWorker
 - Remove the postMessage/onmessage functions from Worker and
DedicatedWorkerGlobalScope
 - Add a onconnect property on WorkerGlobalScope
 - Add a connect() method on AbstractWorker. The function fires a
'connect' even on the WorkerGlobalScope, the event has a .port
property which is a MessagePort. This MessagePort is entangled with
another MessagePort which is the value from the connect() function.

Comments:
Compared to just doing the other above proposals I think this adds
needless complexion for value that I don't quite see. If you want to
have several 'conversations', I.e. several separate MessagePorts, with
a dedicated worker you can use postMessage and |new MessageChannel|
(or the startConversation shorthand) to accomplish that. If you want
several conversations with a dedicated worker you can do the same
thing, or even call |new SharedWorker| multiple times.


Ok, I hope I've covered all angles. Again, if we really need to make
changes that require changes to FF3.1 we need to make them fast and
keep them scoped if we are going to have any chance of making it.

/ Jonas

From bijumaillist at gmail.com  Thu Nov 13 03:48:48 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Thu, 13 Nov 2008 07:48:48 -0400
Subject: [whatwg] Issue when Video currentTime used for seeking.
In-Reply-To: <c2e346f90811112316r2fc25382l6dd29b15b1c1a67b@mail.gmail.com>
References: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
	<c2e346f90811112316r2fc25382l6dd29b15b1c1a67b@mail.gmail.com>
Message-ID: <4a27dd80811130348j6bce9764h701ad1b75215081d@mail.gmail.com>

On Wed, Nov 12, 2008 at 3:16 AM, Chris Double <chris.double at double.co.nz> wrote:
> On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
>> video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
>> video_element.currentTime=10;
>> video_element.play();
>
> You can use:
>
> v.src = "foo.ogg";
> v.addEventListener("loadedmetadata", function() { v.currentTime=10;
> v.play(); }, false);

Yes we can use JS to have a work around. But there will be other problems.
Example, the above code make all the subsequent assignment of url to
v.src make movie start from 10th second. So again we need to add code
to remove the event listener. That make things complicated for Web
Developers,  (see, all Web developers I know are JSP/Java, ASP/.Net or
Graphics Designers they all only cut and paste JavaScript code).


From bijumaillist at gmail.com  Thu Nov 13 03:49:02 2008
From: bijumaillist at gmail.com (Biju Gm@il)
Date: Thu, 13 Nov 2008 07:49:02 -0400
Subject: [whatwg] Issue when Video currentTime used for seeking.
In-Reply-To: <c2e346f90811112324y2a87b806mce7639c1b52a908e@mail.gmail.com>
References: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
	<c2e346f90811112324y2a87b806mce7639c1b52a908e@mail.gmail.com>
Message-ID: <4a27dd80811130349u665c2ed0xe7d6aac752feeb8c@mail.gmail.com>

On Wed, Nov 12, 2008 at 3:24 AM, Chris Double <chris.double at double.co.nz> wrote:
> On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
>> toKeyFrame - optional, boolean, default false. if true indicates goto
>> the nearest keyframe of the value provided in secondsToSeek.
>> this is to improve performance while avoiding  bug
>> https://bugzilla.mozilla.org/show_bug.cgi?id=463358
>
> Good question. Should seeks go to the previous keyframe to the
> requested time,  the next keyframe after the time, the closest
> keyframe, or the exact frame requested?

The idea for toKeyFrame argument came from some flash video controls
ie, when we silde the duration slider, these flash controls flips
through frames quickly.
At that time it dont really matter exactly which frame, it can be
before or after
which ever is EASY to find.

> Regarding that bug, I think it should be going to the last keyframe
> then decoding up to the point of the requested frame so it can display
> non-garbage data.

I agree...

>> .seek() will return the time to which it is seek-ed to.
>
> What time is that exactly? Is that the time of  the actual frame the

There are 2 situations after execution of .seek()
1. the video not doing seeking or completed seeking
eg:-
a) .seek(0)   (a seek with 0 time) when the video is not already seeking)
b) .seek(+n) when video is already at end of file
these two cases it will return value same as .currentTime

2. the video is still seeking or not completed seeking
.seek(n) should return the "cumulative" time to which it is being seek-ed.

one issue I see here is, if the video duration is only 10 seconds and
seek was called for 100 seconds, what should seek()
I feel for consistency we should return 100, ie with or with out
metadata we will be able to provide same value.


From jeremydo at google.com  Thu Nov 13 10:52:43 2008
From: jeremydo at google.com (Jeremy Doig)
Date: Thu, 13 Nov 2008 10:52:43 -0800
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
Message-ID: <35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>

did this thread go anywhere ?i'm concerned about the "maybe" case - looks
way too much like:
http://en.wikipedia.org/wiki/DShow#Codec_hell

also - when you probe for mime type, do you mean the entire "type" parameter
(including the codecs string) ? for example, there are too many cases where
just passing "video/mp4" would be insufficient. (fragmented index support ?
base/main/high profile ? paff ? cabac ?)

<source src="video.mp4" type="video/mp4; codecs=&quot;avc1.42E01E,
mp4a.40.2&quot;">


On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote:
>
>
>> On Tue, 14 Oct 2008, Robert O'Callahan wrote:
>>
>>> On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak <mjs at apple.com>
>>> wrote:
>>>
>>>  While the underlying media frameworks can't necessarily answer, "if I
>>>> give you a file with this MIME type, can you play it?", they can at
>>>> least give a yes/no/maybe answer, which can still be quite helpful,
>>>> since the UA will know it does not need to check some media streams at
>>>> all.
>>>>
>>>
>>> I agree. If the API lets us answer "maybe", there is not much need or
>>> temptation to lie, and we can still return information that could be
>>> useful to scripts.
>>>
>>
>> I have added window.navigator.canPlayType(mimeType). It returns 1, 0, or
>> -1 to represent positive, neutral, and negative responses.
>>
>
> This API would be tempting to treat as a boolean but would of course do
> completely the wrong thing. I think it would be better to either ensure that
> the positive and neutral responses are both values that JS would treat as
> true (for instance make the values true, "maybe" and false), or else make
> all of the return values something self-descriptive and symbolic (for
> instance the strings "yes", "maybe" and "no"). I think 1, 0, -1 are neither
> clear nor likely to be in any way beneficial for perforamnce.
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081113/8079096c/attachment.htm>

From eric.carlson at apple.com  Thu Nov 13 11:19:07 2008
From: eric.carlson at apple.com (Eric Carlson)
Date: Thu, 13 Nov 2008 11:19:07 -0800
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
	<35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
Message-ID: <58FD84AD-22BE-48FF-9350-4694EF726431@apple.com>


On Nov 13, 2008, at 10:52 AM, Jeremy Doig wrote:

> did this thread go anywhere ?
>

   See http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-navigator-canplaytype 
.



> i'm concerned about the "maybe" case - looks way too much like:
> http://en.wikipedia.org/wiki/DShow#Codec_hell
>
> also - when you probe for mime type, do you mean the entire "type"  
> parameter (including the codecs string) ? for example, there are too  
> many cases where just passing "video/mp4" would be insufficient.  
> (fragmented index support ? base/main/high profile ? paff ? cabac ?)
> <source src="video.mp4" type="video/mp4; codecs=&quot;avc1.42E01E,  
> mp4a.40.2&quot;">
>
   My interpretation is that it does, and the vagueness of many MIME  
types is the reason for the "maybe" case.

eric



> On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote:
>
>
> On Tue, 14 Oct 2008, Robert O'Callahan wrote:
> On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> While the underlying media frameworks can't necessarily answer, "if I
> give you a file with this MIME type, can you play it?", they can at
> least give a yes/no/maybe answer, which can still be quite helpful,
> since the UA will know it does not need to check some media streams at
> all.
>
> I agree. If the API lets us answer "maybe", there is not much need or
> temptation to lie, and we can still return information that could be
> useful to scripts.
>
> I have added window.navigator.canPlayType(mimeType). It returns 1,  
> 0, or
> -1 to represent positive, neutral, and negative responses.
>
> This API would be tempting to treat as a boolean but would of course  
> do completely the wrong thing. I think it would be better to either  
> ensure that the positive and neutral responses are both values that  
> JS would treat as true (for instance make the values true, "maybe"  
> and false), or else make all of the return values something self- 
> descriptive and symbolic (for instance the strings "yes", "maybe"  
> and "no"). I think 1, 0, -1 are neither clear nor likely to be in  
> any way beneficial for perforamnce.
>
> Regards,
> Maciej
>
>

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

From philipj at opera.com  Thu Nov 13 11:23:53 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 13 Nov 2008 20:23:53 +0100
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
	<35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
Message-ID: <1226604233.6632.23.camel@localhost>

I'm also a bit concerned about how to interpret the yes, no and maybe
return values. The truthful answer is going to be "maybe" for all but
the obviously unsupport (application/x-ms-dos-executable) and the more
trivial formats (audio/wav).

When asking about application/ogg, this could mean 2 things:

1. "can I demux Ogg"
2. "can I demux Ogg and decode an unknown codec"

If to answer yes the browser must be certain that it can play back all
content which could have the requested mime type then the answer must
always be "maybe" for container formats, e.g. "video/avi",
"video/x-msvideo", "application/ogg", "video/mp4", "video/mpeg" and so
on. Only if the codecs parameter is used is it ever possible to anwer
"yes"

It's hardly ever possible to answer "no" either, unless the underlying
media framework explicitly doesn't support a  When faced with something
unrecognized the safest thing is to say "maybe".

To sum up, the answer is always "maybe". This is nice for implementors
who don't need to write a lot of code, but it's not useful.

To fix this, I would suggest the following:

If the mime type is just a container format then the browser may answer
"yes" if it knows that it supports at least some content in that format
(again, it's difficult without 

On Thu, 2008-11-13 at 10:52 -0800, Jeremy Doig wrote:
> did this thread go anywhere ?
> i'm concerned about the "maybe" case - looks way too much like:
> http://en.wikipedia.org/wiki/DShow#Codec_hell
> 
> 
> also - when you probe for mime type, do you mean the entire "type"
> parameter (including the codecs string) ? for example, there are too
> many cases where just passing "video/mp4" would be insufficient.
> (fragmented index support ? base/main/high profile ? paff ? cabac ?)
> <source src="video.mp4" type="video/mp4; codecs=&quot;avc1.42E01E, mp4a.40.2&quot;">
> 
> On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak <mjs at apple.com>
> wrote:
>         
>         On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote:
>         
>                 
>                 On Tue, 14 Oct 2008, Robert O'Callahan wrote:
>                         On Tue, Oct 14, 2008 at 12:13 PM, Maciej
>                         Stachowiak <mjs at apple.com> wrote:
>                         
>                                 While the underlying media frameworks
>                                 can't necessarily answer, "if I
>                                 give you a file with this MIME type,
>                                 can you play it?", they can at
>                                 least give a yes/no/maybe answer,
>                                 which can still be quite helpful,
>                                 since the UA will know it does not
>                                 need to check some media streams at
>                                 all.
>                         
>                         I agree. If the API lets us answer "maybe",
>                         there is not much need or
>                         temptation to lie, and we can still return
>                         information that could be
>                         useful to scripts.
>                 
>                 I have added window.navigator.canPlayType(mimeType).
>                 It returns 1, 0, or
>                 -1 to represent positive, neutral, and negative
>                 responses.
>         
>         
>         This API would be tempting to treat as a boolean but would of
>         course do completely the wrong thing. I think it would be
>         better to either ensure that the positive and neutral
>         responses are both values that JS would treat as true (for
>         instance make the values true, "maybe" and false), or else
>         make all of the return values something self-descriptive and
>         symbolic (for instance the strings "yes", "maybe" and "no"). I
>         think 1, 0, -1 are neither clear nor likely to be in any way
>         beneficial for perforamnce.
>         
>         Regards,
>         Maciej
>         
> 
> 
-- 
Philip J?genstedt
Opera Software



From philipj at opera.com  Thu Nov 13 11:38:12 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Thu, 13 Nov 2008 20:38:12 +0100
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
	<35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
Message-ID: <1226605092.6632.36.camel@localhost>

(sorry, my mail was work in progress when I accidentally hit send)

I'm also a bit concerned about how to interpret the yes, no and maybe
return values. The truthful answer is going to be "maybe" for all but
the obviously unsupporter (application/x-ms-dos-executable) and the more
trivial formats (audio/wav).

When asking about application/ogg, this could mean 2 things:

1. "can I demux Ogg streams?"
2. "can I demux Ogg streams and decode unknown codecs?"

The answer to question 1 is reasonably simple to answer in most cases,
even if the underlying media frame doesn't support querying for mime
types a mapping between mime type and supported decoders isn't impossible.

The answer to question 2, on the other hand, is always "no" or "maybe".

Unless the codecs parameter is to be made mandatory I think that spec
should explicitly make it such that the question asked is 1. In either
case we will end up there because 2 is not a meaningful question and
user agents will make untruthful answers in attempts to stay compatible
with unknown and future content (which might be supported by installing
new codecs in the media framework without upgrading the browser).

Now, if the codec parameter is used then the user agent may answer yes
and no in a way that actually makes some sense.

I also think that this should be explicitly related to the type
attribute of the source element. One should be able to use canPlayType
to predict with 100% accuracy which source the user agent will use when
it encounters.

<video>
<source type="application/ogg"/>
<source type="application/ogg codecs=dirac,flac"/>
</video>

If this isn't specified then one can expect lots of web app authors
being forced to write scripts to work around the different behaviour of
canPlayType and the "pick a source" algorithm in different browsers.

Philip

On Thu, 2008-11-13 at 10:52 -0800, Jeremy Doig wrote:
> did this thread go anywhere ?
> i'm concerned about the "maybe" case - looks way too much like:
> http://en.wikipedia.org/wiki/DShow#Codec_hell
> 
> 
> also - when you probe for mime type, do you mean the entire "type"
> parameter (including the codecs string) ? for example, there are too
> many cases where just passing "video/mp4" would be insufficient.
> (fragmented index support ? base/main/high profile ? paff ? cabac ?)
> <source src="video.mp4" type="video/mp4; codecs=&quot;avc1.42E01E, mp4a.40.2&quot;">
> 
> On Wed, Oct 15, 2008 at 11:14 PM, Maciej Stachowiak <mjs at apple.com>
> wrote:
>         
>         On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote:
>         
>                 
>                 On Tue, 14 Oct 2008, Robert O'Callahan wrote:
>                         On Tue, Oct 14, 2008 at 12:13 PM, Maciej
>                         Stachowiak <mjs at apple.com> wrote:
>                         
>                                 While the underlying media frameworks
>                                 can't necessarily answer, "if I
>                                 give you a file with this MIME type,
>                                 can you play it?", they can at
>                                 least give a yes/no/maybe answer,
>                                 which can still be quite helpful,
>                                 since the UA will know it does not
>                                 need to check some media streams at
>                                 all.
>                         
>                         I agree. If the API lets us answer "maybe",
>                         there is not much need or
>                         temptation to lie, and we can still return
>                         information that could be
>                         useful to scripts.
>                 
>                 I have added window.navigator.canPlayType(mimeType).
>                 It returns 1, 0, or
>                 -1 to represent positive, neutral, and negative
>                 responses.
>         
>         
>         This API would be tempting to treat as a boolean but would of
>         course do completely the wrong thing. I think it would be
>         better to either ensure that the positive and neutral
>         responses are both values that JS would treat as true (for
>         instance make the values true, "maybe" and false), or else
>         make all of the return values something self-descriptive and
>         symbolic (for instance the strings "yes", "maybe" and "no"). I
>         think 1, 0, -1 are neither clear nor likely to be in any way
>         beneficial for perforamnce.
>         
>         Regards,
>         Maciej
>         
> 
> 
-- 
Philip J?genstedt
Opera Software



From robert at ocallahan.org  Thu Nov 13 12:53:24 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 14 Nov 2008 09:53:24 +1300
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <58FD84AD-22BE-48FF-9350-4694EF726431@apple.com>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
	<35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
	<58FD84AD-22BE-48FF-9350-4694EF726431@apple.com>
Message-ID: <11e306600811131253k3694697crbca0d87bbf3e77f5@mail.gmail.com>

On Fri, Nov 14, 2008 at 8:19 AM, Eric Carlson <eric.carlson at apple.com>wrote:

>
>   See
> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-navigator-canplaytype
> .
>

There was widespread dissatisfaction with the form of the API. I think it
would be a lot better if there were two methods returning booleans, say,
"canPlayType" and "cannotPlayType".

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/20081114/a77cce6c/attachment.htm>

From aa at google.com  Thu Nov 13 12:53:24 2008
From: aa at google.com (Aaron Boodman)
Date: Thu, 13 Nov 2008 12:53:24 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>
	<491229C8.8080205@sicking.cc>
	<AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org>
	<63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>
Message-ID: <278fd46c0811131253p3357f223uf54ff2e655a9cf1d@mail.gmail.com>

2008/11/13 Jonas Sicking <jonas at sicking.cc>:
> So at this point the main problem with making any changes is that we
> are very close to shipping Firefox 3.1. I.e. it is extremely hard to
> make changes. It is very unfortunate that we have ended up in this
> situation again. We were in a very similar to the window.postMessage
> API where we had to scramble last minute to make changes, the result
> that time was that security issues in the API slipped by since those
> changes happened after we had done our security review of the spec.
>
> A few months ago representatives from google, apple, and mozilla met
> to try to agree to an API. We came up with a few guidelines, such as
> that it was ok to have a separate API for shared and dedicated workers
> as well as others that I don't specifically remember. At the end of
> the meeting we had a rough sketch of an API. A few days after that
> Hixie published a proposal. At mozilla we were largely fine with the
> proposal modulo some details that we commented on fairly quickly and
> then proceeded to implement.
>
> Now, months later, both google and apple is asking for some pretty
> significant changes, including reverting things like separate APIs for
> shared and dedicated workers. It is very close to release for us and
> we are already in a very frozen state, so making changes at this point
> is somewhere between risky and impossible.

HIxie's draft after that meeting was August 20
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015853.html),
and my reply on this issue was Sep 12
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016228.html).
Not stellar turnaround, but not months either. In any case, I can
definitely appreciate the timing is poor for Mozilla and apologize for
that.

> If we really want to make changes to the spec, we better make them
> really fast, ideally within a day or two. And depending on the
> complexity of the changes we might still be able to do them. The other
> alternative is of course removing workers from FF 3.1 and waiting
> until next release (judging by past releases, somewhere between a year
> or two from now). Finally, we can simply stick with the current API,
> none of the complains about the current syntax seems to have been very
> catastrophic, such as "doesn't satisfy use cases", "hard to
> understand", "easy to have hard-to-discover bugs", etc. They mostly
> seem to be syntactic and the case of the matter is as always that
> there is no perfect syntax as the problem is over constrained.

This is true, the worst I can think of happening as a result of the
API Mozilla is planning no shipping would be "frustrating for
developers" or "frustrating for implementors" as more feature are
added that don't fit well.

> I see lots of ideas floating around but many of them are severly
> lacking in detail so it's hard to comment on. Things like 'rename
> startConversation to connect' is very ambiguous as has shown by recent
> discussions. So what follows is an effort to try to focus in on some
> discussed changes more concretely:

Thanks for restating the various proposals so well...

> The main two things that people seem to dislike in the current are
> 1. The many communication mechanisms.
> 2. Different APIs for shared and dedicated workers.
>
> I've said before that I don't really think 1 is true. There is
> currently one communication mechanism (postMessage/onmessage) and one
> connection mechanism (onconnect). There is also one convenience
> function on top of the communication mechanism (startConversaion), but
> is a stretch to call it a separate communication mechanism. The
> communication mechanism (postMessage/onmessage) does come in two
> flavors though as you for shared workers and dedicated workers call
> the functions on different objects.

Ok, maybe 'mechanism' was not the right word, but there are still
three separate ways to use the external API to workers (not counting
passing a port as an argument). I think this is undesirable.

Here are my preference on changes, in descending order:

> * Add a connect() method to Worker and/or SharedWorker
> There has been lots of talk about this, but I'm still confused as to
> what the exact proposals are due to lack of details. But here is my
> interpretation
> Details:
>  - Make instantiating a SharedWorker *not* fire a 'connect' event automatically.
>  - Remove the .port property from SharedWorker
>  - Remove the postMessage/onmessage functions from Worker and
> DedicatedWorkerGlobalScope
>  - Add a onconnect property on WorkerGlobalScope
>  - Add a connect() method on AbstractWorker. The function fires a
> 'connect' even on the WorkerGlobalScope, the event has a .port
> property which is a MessagePort. This MessagePort is entangled with
> another MessagePort which is the value from the connect() function.
>
> Comments:
> Compared to just doing the other above proposals I think this adds
> needless complexion for value that I don't quite see. If you want to
> have several 'conversations', I.e. several separate MessagePorts, with
> a dedicated worker you can use postMessage and |new MessageChannel|
> (or the startConversation shorthand) to accomplish that. If you want
> several conversations with a dedicated worker you can do the same
> thing, or even call |new SharedWorker| multiple times.

I think this is the best API because it offers the most functionality
with the smallest area. I also like that the API for dedicated and
shared workers is identical because it means that one you learn to use
dedicated workers, you already know how to use shared workers.

> * Remove startConversation
> Details:
> Simply remove the startConversaion function on all interfaces where it
> is defined. Since it doesn't define any new events no other changes
> are needed.
>
> Comments:
> There seemed to be opinions before on that it should definitely be
> removed, however it sounds like that is less the case now. I don't
> really care about this one. startConversation is just a convenience
> function on top of postMessage anyway. If there still is any
> disagreement about its neccessity or the fact that it adds to that we
> have too many communication mechanisms i'd prefer we remove it for now
> and then discuss it once we've agreed on the rest of the API, or we
> can let it be for this version of the spec. Others have commented that
> startConversation is a red herring in these discussions, I agree.
>  (This would be no problem for us since we don't implement
> startConversation yet).

If we don't make the above change, I think that we should remove
startConversation(). It doesn't offer enough different functionality
over passing a |new MessageChannel().port2| to be worth the extra API
IMO.

> * Make the external API for shared workers that of the current dedicated worker
> Details:
> Move the postMessage/onmessage functions from the SharedWorker.port
> object to the SharedWorker object. The SharedWorker would act as a
> MessagePort that is entangled with the port that is provided to the
> SharedWorkerGlobalScope through already specified 'connect' event that
> is fired when a SharedWorker is created.
>
> Comments:
> The result of this would be that on the outside shared workers and
> dedicated workers have exactly the same API to the outside world,
> except that dedicated workers have a terminate() function (formerly
> known as close(), changed in the latest version of the spec).
> I think this is a good idea all around and we should make this change.
> (This would be no problem for us since we don't implement shared
> workers yet).
> Hixie expressed some dislike about the fact that we'd end up with
> MessagePort entangled with something that isn't a MessagePort. This
> can result in uglyness if the MessagePort is passed out outside the
> SharedWorker, and then passed on anywhere. A page could create a setup
> where calling postMessage on a SharedWorker object actually resulted
> in onmessage being called inside another window rather than inside a
> worker global scope.
> I don't really think this is a big deal though, you have a very
> similar situation today where calling postMessage on a
> SharedWorker.port object can do exactly the same thing.

I don't have a strong opinion on this.

> * Make dedicated workers receive a 'connect' event when they are created
> Details:
> Make the internal communication API for a dedicated worker exactly
> that of what a shared worker is currently specced as. This means
>  - Once a dedicated worker is instantiated automatically fire a
> 'connect' event which contains a MessagePort object (accessible
> through event.port).
>  - Make the Worker object entangled with this MessagePort.
>  - Remove the postMessage/onmessage functions from DedicatedWorkerGlobalScope
>
> Comments:
> I don't feel super strongly about this. From a purely dedicated worker
> perspective this doesn't really add any value but rather just
> complexity. Everyone using dedicated workers will have to set up a
> dummy function that just listens for a 'connect' event and sets a
> global port variable. The upside is that combined with the above
> change it makes the API for dedicated and shared workers exactly the
> same.
> We are currently looking in to if this is doable without adding too
> much risk to FF3.1. The big concern here is more objects means more
> chances of leak bugs since we can't reuse the same leak prevention
> mechanisms as we do on the main thread since that one isn't
> threadsafe. Anyhow, it's an implementation detail, but it is a big
> part of why making even small at this stage is non-trivial.

I don't have a strong opinion on this.

- a


From robert at ocallahan.org  Thu Nov 13 13:14:47 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 14 Nov 2008 10:14:47 +1300
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <1226605092.6632.36.camel@localhost>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
	<35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
	<1226605092.6632.36.camel@localhost>
Message-ID: <11e306600811131314l5e83464u2db593a5a854d914@mail.gmail.com>

On Fri, Nov 14, 2008 at 8:38 AM, Philip J?genstedt <philipj at opera.com>wrote:

> I'm also a bit concerned about how to interpret the yes, no and maybe
> return values. The truthful answer is going to be "maybe" for all but
> the obviously unsupporter (application/x-ms-dos-executable) and the more
> trivial formats (audio/wav).
>

Even WAV is extensible.

When asking about application/ogg, this could mean 2 things:
>
> 1. "can I demux Ogg streams?"
> 2. "can I demux Ogg streams and decode unknown codecs?"


It means "can I play this stream, given that the only thing I know about it
is that it's an Ogg stream"? Which I guess is what you meant by option 2.

The browser can only answer "no" or "maybe" in this case. That seems fine to
me. It lets the author know whether the browser can demux Ogg streams, while
staying consistent with the behaviour when codec information is given in the
MIME type.

Unless the codecs parameter is to be made mandatory I think that spec
> should explicitly make it such that the question asked is 1. In either
> case we will end up there because 2 is not a meaningful question and
> user agents will make untruthful answers in attempts to stay compatible
> with unknown and future content (which might be supported by installing
> new codecs in the media framework without upgrading the browser).


I don't understand what the incentives are for browsers to lie. If we start
off telling the truth, then authors will have to write scripts that either
accept "maybe" or, better still, provide the codec information, or their
scripts won't work. I don't see how that would change over time.

Now, if the codec parameter is used then the user agent may answer yes
> and no in a way that actually makes some sense.


Yes. Authors should be strongly encouraged to give the codec parameters.

I also think that this should be explicitly related to the type
> attribute of the source element. One should be able to use canPlayType
> to predict with 100% accuracy which source the user agent will use when
> it encounters.
>
> <video>
> <source type="application/ogg"/>
> <source type="application/ogg codecs=dirac,flac"/>
> </video>
>
> If this isn't specified then one can expect lots of web app authors
> being forced to write scripts to work around the different behaviour of
> canPlayType and the "pick a source" algorithm in different browsers.


I agree.

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/20081114/a0526e2e/attachment.htm>

From silviapfeiffer1 at gmail.com  Thu Nov 13 14:15:15 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 14 Nov 2008 09:15:15 +1100
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <1226605092.6632.36.camel@localhost>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
	<35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
	<1226605092.6632.36.camel@localhost>
Message-ID: <2c0e02830811131415g4cd3c219vcd6482a18adac216@mail.gmail.com>

On Fri, Nov 14, 2008 at 6:38 AM, Philip J?genstedt <philipj at opera.com> wrote:
> Now, if the codec parameter is used then the user agent may answer yes
> and no in a way that actually makes some sense.
>
> I also think that this should be explicitly related to the type
> attribute of the source element. One should be able to use canPlayType
> to predict with 100% accuracy which source the user agent will use when
> it encounters.
>
> <video>
> <source type="application/ogg"/>
> <source type="application/ogg codecs=dirac,flac"/>
> </video>
>

On a little bit of a side not, may I point out that there is an
updated RFC for Ogg media types at http://www.ietf.org/rfc/rfc5334.txt
and it explicitly includes the codecs parameter with standard values
for the current ones supported by Ogg.

It also recommends using "video/ogg" for video files, so that would
change your example to:

<video>
<source type="video/ogg"/>
<source type="video/ogg; codecs=dirac,flac"/>
</video>

I know it's a minor issue, but I'd like us at HTML5 to get it right
and to recommend the correct mime types to web developers.

Cheers,
Silvia.


From jonas at sicking.cc  Thu Nov 13 14:20:58 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 13 Nov 2008 14:20:58 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <278fd46c0811131253p3357f223uf54ff2e655a9cf1d@mail.gmail.com>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>	
	<4910C8AF.3000404@sicking.cc>	
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>	
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>	
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>	
	<491229C8.8080205@sicking.cc>	
	<AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org>	
	<63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>
	<278fd46c0811131253p3357f223uf54ff2e655a9cf1d@mail.gmail.com>
Message-ID: <491CA84A.6020005@sicking.cc>

> Here are my preference on changes, in descending order:
> 
>> * Add a connect() method to Worker and/or SharedWorker
>> There has been lots of talk about this, but I'm still confused as to
>> what the exact proposals are due to lack of details. But here is my
>> interpretation
>> Details:
>>  - Make instantiating a SharedWorker *not* fire a 'connect' event automatically.
>>  - Remove the .port property from SharedWorker
>>  - Remove the postMessage/onmessage functions from Worker and
>> DedicatedWorkerGlobalScope
>>  - Add a onconnect property on WorkerGlobalScope
>>  - Add a connect() method on AbstractWorker. The function fires a
>> 'connect' even on the WorkerGlobalScope, the event has a .port
>> property which is a MessagePort. This MessagePort is entangled with
>> another MessagePort which is the value from the connect() function.
>>
>> Comments:
>> Compared to just doing the other above proposals I think this adds
>> needless complexion for value that I don't quite see. If you want to
>> have several 'conversations', I.e. several separate MessagePorts, with
>> a dedicated worker you can use postMessage and |new MessageChannel|
>> (or the startConversation shorthand) to accomplish that. If you want
>> several conversations with a dedicated worker you can do the same
>> thing, or even call |new SharedWorker| multiple times.
> 
> I think this is the best API because it offers the most functionality
> with the smallest area. I also like that the API for dedicated and
> shared workers is identical because it means that one you learn to use
> dedicated workers, you already know how to use shared workers.

Comparing to doing the other set of changes the differences in API are 
as follows:

  - Add a 'connect()' method on AbstractWorker which must be called every
    time after instantiating a worker.
  - The postMessage/onmessage functions are moved from the worker object
    to the port object.

To me this seems like strictly a bigger API. As far as functionality 
goes the differences are as follows:

  - You have to deal with two separate objects, the port and the worker.
  - You can create multiple communication channels with a worker by
    calling connect() multiple times.

Only the second thing here seems like a win. And only for dedicated 
workers since for shared workers you can simply call |new SharedWorker| 
multiple times if you want multiple communication channels.

So it seems to me like the pros and cons fall out as:
  Pros:
    - Easier to create multiple connection channels to dedicated workers
  Cons:
    - Bigger API (an extra connect() function)
    - More code required (an extra call to connect() required)
    - More objects (port and worker)


To me the cons outweigh the pros here. Is there a goal with connect() 
that I'm missing?


>> * Remove startConversation
>> Details:
>> Simply remove the startConversaion function on all interfaces where it
>> is defined. Since it doesn't define any new events no other changes
>> are needed.
>>
>> Comments:
>> There seemed to be opinions before on that it should definitely be
>> removed, however it sounds like that is less the case now. I don't
>> really care about this one. startConversation is just a convenience
>> function on top of postMessage anyway. If there still is any
>> disagreement about its neccessity or the fact that it adds to that we
>> have too many communication mechanisms i'd prefer we remove it for now
>> and then discuss it once we've agreed on the rest of the API, or we
>> can let it be for this version of the spec. Others have commented that
>> startConversation is a red herring in these discussions, I agree.
>>  (This would be no problem for us since we don't implement
>> startConversation yet).
> 
> If we don't make the above change, I think that we should remove
> startConversation(). It doesn't offer enough different functionality
> over passing a |new MessageChannel().port2| to be worth the extra API
> IMO.

No, this is *exactly* the same functionality as passing |new 
MessageChannel().port2| through postMessage.

Why does *not* making the "above change" (I assume adding connect()?) 
mean that we should remove startConversaion? I would have thought that 
the opposite would be true. Keeping startConversation makes much sense 
if we don't have connect() as both functions set up a 'conversation'.


>> * Make the external API for shared workers that of the current dedicated worker
...
> I don't have a strong opinion on this.
> 
>> * Make dedicated workers receive a 'connect' event when they are created
...
> I don't have a strong opinion on this.

Hmm.. I thought that the reason we are having this whole discussion was 
because there was dislike around the fact that dedicated and shared 
workers have different APIs. This also resulted in more communication 
APIs as the communication APIs were different. The above two changes 
fixes exactly that so I'm surprised you have no strong opinion on it.


At this point I have to ask what the problem you are trying to solve is? 
What is wrong with the current spec as is? I.e. rather than talking 
about various proposals, maybe we need to align the goals first as we 
might be talking past each other.

/ Jonas


From ap at webkit.org  Thu Nov 13 15:05:14 2008
From: ap at webkit.org (Alexey Proskuryakov)
Date: Fri, 14 Nov 2008 02:05:14 +0300
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <491CA84A.6020005@sicking.cc>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>	
	<4910C8AF.3000404@sicking.cc>	
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>	
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>	
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>	
	<491229C8.8080205@sicking.cc>	
	<AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org>	
	<63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>
	<278fd46c0811131253p3357f223uf54ff2e655a9cf1d@mail.gmail.com>
	<491CA84A.6020005@sicking.cc>
Message-ID: <3ABCAB85-91D0-42C6-BBDF-84656A026A12@webkit.org>


Nov 14, 2008, ? 1:20 AM, Jonas Sicking ???????(?):

>> If we don't make the above change, I think that we should remove
>> startConversation(). It doesn't offer enough different functionality
>> over passing a |new MessageChannel().port2| to be worth the extra API
>> IMO.
>
> No, this is *exactly* the same functionality as passing |new  
> MessageChannel().port2| through postMessage.

For the sake of completeness, a connect/startConversation method on a  
worker really should automatically open the receiving port - this is  
what examples posted so far implied, and it would cause a lot of  
aggravation if it didn't. I know I'm often forgetting to open the port  
when writing my tests, and it's not a very easy mistake to spot.

So, even though the current spec doesn't say this, there should be  
some difference in behavior.

> At this point I have to ask what the problem you are trying to solve  
> is? What is wrong with the current spec as is?


Not speaking for Aaron, of course, but...

Besides API usability that we've already discussed back and forth  
without reaching an agreement, I'm very much concerned about the  
current spec being implementable in its current form. It has a lot of  
notions and algorithms that are not correctly defined. For a randomly  
picked example:

-----------------------------
Each WorkerGlobalScope worker global scope has a list of the worker's  
ports, which consists of all the MessagePort objects that are  
entangled with another port and that have one (but only one) port  
owned by worker global scope. This list includes all the MessagePort  
objects that are in events pending in the queue of events, as well as  
the implicit MessagePort in the case of dedicated workers.
-----------------------------

In an async processing model, there is simply no way for the receiver  
to have a list of all objects that were posted to it - it's exactly  
the reason for the existence of the queue that events are delivered  
asynchronously and cannot be peeked before being delivered. For  
example, in a multi-process implementation, these events may still be  
across process boundary.

Also (from HTML5):
-----------------------------
Each MessagePort object can be entangled with another (a symmetric  
relationship).
-----------------------------

It is not possible to have a symmetric relationship in an asynchronous  
messaging model - we need a multi-step entagling/unentangling  
protocol, so the relationship is necessarily asymmetric. One can't  
freeze another process (or really, even another thread) to change  
something in it synchronously.

Some instances of implied synchronous thinking can be corrected rather  
easily, but not all of them. So, I do not really see how anyone can  
claim implementing the spec, or even a subset of it at this point.

- WBR, Alexey Proskuryakov



From ian at hixie.ch  Thu Nov 13 15:30:47 2008
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 13 Nov 2008 23:30:47 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>
References: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0811122339590.1237@hixie.dreamhostps.com>


I haven't written a summary of changes because this is a rather involved 
issue and I'd like everyone who has an opinion to actually read this.

I missed a few e-mails sent in the last few hours in this reply, as I 
started this yesterday. I'll read and respond to those in a bit.

On Thu, 28 Aug 2008, Jonas Sicking wrote:
> 
> The spec currently says:
> 
> Once the WorkerGlobalScope's closing flag is set to true, the queue must 
> discard anything else that would be added to it. Effectively, once the 
> closing flag is true, timers stop firing, notifications for all pending 
> asynchronous operations are dropped, etc.
> 
> Does this mean that anything already on the queue will remain there? Or 
> will it be dropped? It sounds like it will remain, but it's somewhat 
> unclear.

I've added a parenthetical clarifying this.


> In general I think the three shutdown mechanisms that exist are somewhat 
> messy:
>
> * Kill a worker
> * Terminate a worker
> * WorkerGlobalScope.close()
> 
> It seems excessive with 3 possible shutdown sequences, but more 
> importantly the differences between them seems unnecessarily big. Mostly 
> for users, but to a small extent also for implementors. Currently the 
> situation is as follows:
> 
> 
>                           | Abort   | Processes | Fires    | Fires
>                           | current | more      | close on | close on
>                           | script  | events    | scope    | tangled
>                           |         |           |          | ports
> ---------------------------------------------------------------------
> WorkerGlobalScope.close() | No      | Maybe[2]  | Yes      | Yes
> Kill a worker             | Maybe[1]| Maybe[1]  | Maybe[1] | No
> Terminate a worker        | Yes     | No        | Yes      | No
> ---------------------------------------------------------------------
> 
> [1] Implementation dependent. Presumably depends on how much patience 
> that the implementation thinks its users has.
>
> [2] Depends on if the event has been placed in the queue yet or not, 
> somewhat racy.

There are other ways to kill the worker:

  The worker is orphaned    | Maybe[1]| Yes       | Yes      | No
  The browser dies          | Yes     | No        | No       | No

Also, your "No" in the top-left cell is really a Maybe[1], since if the 
script doesn't stop then it'll trigger the Kill algorithm.


> This seems excessively messy. The number of differences in the columns 
> and the number of maybes seems bad. I propose the following:
> 
> * Remove the "Kill a worker" algorithm and use "Terminate a worker" 
> everywhere it is used.

I strongly disagree with that. The whole point of having a distinction is 
that we don't want scripts just being killed willy-nilly when the user 
navigates away from the page. Scripts in the page itself aren't 
terminated, why would we want such drastic behaviour in the threads?


> * Make WorkerGlobalScope.close() not process any more events. I.e. make 
> setting the 'closing flag' to true always clear out all events except a 
> single close event.

Again, this seems bad as it would mean that if you navigated away from a 
page that happened to use a worker, you could get data loss.


> * Always fire close on tangled ports. In many cases this will be a no-op 
> since we're doing it in workers that are being closed. However if the 
> port is in another window or a shared worker this might not be the case.

I thought we weren't doing this because it exposed the details of garbage 
collection?


On Fri, 12 Sep 2008, Aaron Boodman wrote:
>
> * We have discussed having onerror expose runtime script errors that 
> happened inside the worker. I don't think this makes sense for shared 
> workers, so I propose that it be spec'd to only expose load errors. 
> Script errors can still be exposed via a global onerror property inside 
> the worker, and they can still be reported to the error console. I don't 
> think having script errors that happened inside a worker be exposed 
> outside it is that useful (load errors are useful, though).

Right now only load errors are reported.

I'll wait til the API is more stable before exposing script errors and the 
like at all (whether on a global onerror or whatever). It is noted as an 
XXX issues in the spec source.


On Thu, 28 Aug 2008, Jonas Sicking wrote:
>
> Why is importScripts imposing a same origin restriction? This won't 
> increase security in any way since cross-origin scripts can always be 
> loaded from the main thread. I think cross-site loading is fairly common 
> exactly for the case that importScripts, which is loading libraries.

I don't recall the precise reason, but I seem to recall concern over 
specific attack vectors are what caused us to restrict this.


> Also, the spec doesn't seem clear on what to do if compiling a script 
> fails. I think some sort of exception should be thrown, probably the 
> same one that is thrown if eval() is given a non-compiling script.

Done.


On Tue, 30 Sep 2008, Alexey Proskuryakov wrote:
> 
> I've been trying to understand the difference between SharedWorker and 
> DedicatedWorker interfaces. Besides the ability to pick an existing 
> worker by name, are there any other semantic differences? I may be 
> missing something, but it looks like a single Worker interface with an 
> optional name parameter to constructor would work just as well.

That's what we used to have. It was changed because having shared and 
dedicated workers be too similar was considered bad API design. To be 
honest I somewhat agree with the position that says they should be 
distinct. I don't understand the benefit of making them the same.


On Thu, 9 Oct 2008 kevin.hakanson at thomsonreuters.com wrote:
>
> 1.1.3 Worker used for backgroud I/O
> backgroud (should be background)
>  
> 1.1.4 Shared workers
> idependently (should be independently)
>  
> 2. Infrastructure
> multple (should be multiple)

Thanks, fixed.


On Thu, 30 Oct 2008, Jonas Sicking wrote:
>
> Only the globalscope is specified to implement EventTarget, the actual 
> Worker should too.

Fixed.


On Mon, 3 Nov 2008, Jonas Sicking wrote:
>
> For future compat it would be good to expose to workers information on 
> what browser is currently being used. This can be used to work around 
> bugs and lack of features.
>
> In a 'normal' window context the navigator object exposes a set of 
> properties, such as userAgent, that can be used for this purpose. I 
> suggest we add something similar to the worker context. The HTML5 spec 
> defines the following:
> 
> interface Navigator {
>   // client identification
>   readonly attribute DOMString appName;
>   readonly attribute DOMString appVersion;
>   readonly attribute DOMString platform;
>   readonly attribute DOMString userAgent;
> 
>   // ... other things not related to identifying the UA
> };
> 
> I'm not sure how stable this part of the HTML5 spec is, (I know firefox 
> exposes a whole host of more properties), but it seems like a good set 
> to start with. We should probably keep the two in sync if the window 
> context Navigator object changes in the future.
> 
> Orthoginally, it seems like at least the 'onLine' boolean on the 
> Navigator interface would be useful too, and could be exposed at the 
> same place.

Done.


On Wed, 12 Nov 2008, Dmitry Titov wrote:
> 
> 1. The sample code looks as
> if  setTimeout/clearTimeout/setInterval/clearInterval should be available to
> Workers (as methods of WorkerUtils?) but they are not explicitly specified
> on any interface. Should they be there?

Added.


> 2. It seems workers should be able to create workers (including creating
> 'themselves' in case of SharedWorker). It is especially useful for a
>  SharedWorker to create dedicated workers - since one of the popular
> scenarios for it is likely  a "state container" that communicates with UI
> pages while using dedicated workers to do other operations. Will spec
> include this?

Added.


On Fri, 12 Sep 2008, Aaron Boodman wrote:
>
> * Similarly, I'd like to rename startConversation() to connect(). I 
> think this aligns nicely with the onconnect event (connect() should also 
> trigger a 'connect' event inside the worker).

On Tue, 4 Nov 2008, Jonas Sicking wrote:
> 
> I'm fine with removing things like 'startConversation' and the implicit 
> call to connect() on shared workers. 'startConversation' isn't really a 
> new communication mechanism, but rather a convenience method on top of 
> postMessage.

I removed startConversation() from the specs altogether, since it was 
causing too much confusion. It was only a convenience method (it was 
exactly equivalent to creating a new MessageChannel followed by calling 
postMessage with one of the new ports), so this doesn't change anything 
about the actual API.

I've snipped reference to startConversation from the following feedback, 
as noted below, to avoid confusion over this.


On Fri, 12 Sep 2008, Aaron Boodman wrote:
> 
> * I think it was an interesting idea to have separate interfaces for
> Dedicated and Shared workers, but in the end I don't think there's
> enough difference between the two cases to justify it. I'd rather have
> the total API surface be smaller, and generalize concepts as much as
> possible. So...
>   - We should remove all the postMessage/onmessage stuff from
>     DedicatedWorker, and just use the port convenience property.
>   - We should move onconnect() up into WorkerGlobalScope

On Tue, 30 Sep 2008, Aaron Boodman wrote:
>
> That is what we are debating here. Logically, there is a concept of a 
> "shared worker", which can be referenced from multiple pages in the same 
> origin. There is a debate about how much the interface between shared 
> workers and dedicated workers should be different.
>
> I'm of the opinion that there should be as little difference as 
> possible, to lower the amount of API to learn. Therefore in my preferred 
> proposal, the only difference between SharedWorker and DedicatedWorker 
> is that the latter has a close() method. It doesn't make sense to allow 
> one user of a SharedWorker to close something others are depending on.
>
> Jonas is in favor of making a particular use case of DedicatedWorker as 
> simple to use as possible. This requires extra API on DedicatedWorker 
> that doesn't make sense for SharedWorker.

On Tue, 30 Sep 2008, Alexey Proskuryakov wrote:
> 
> I'm not sure it's so good in the case of dedicated workers either, as 
> they can be used from other contexts via additional message ports. The 
> close() method could just close the default port.
> 
> Both shared and dedicated workers have to maintain a strong reference to 
> a context that created them, just to have a context to execute event 
> listeners in. So, they are basically the same as far as implementation 
> is concerned AFAICT.

On Tue, 30 Sep 2008, Aaron Boodman wrote:
> 
> Sure, but in order for that to have happened, whoever created the worker 
> in the first place must have done it on purpose. The original worker 
> instance is anonymous. If the creator of that worker decides to share 
> it, that's fine, but it's more like cooperative sharing.
> 
> close() was added so that you could forcibly kill a worker. For example, 
> if you are searching a large set with many workers, you may want to kill 
> them once one finds a match.
> 
> The same could be achieved by just setting all the ports to null and 
> waiting for GC, but:
> 
> a) GC might not be for awhile, which is wasteful
> b) It is hard to track where all the ports went
> 
> So I think it is useful to have a conceptual difference between workers 
> that are 'dedicated' and those that are 'shared'.

On Tue, 30 Sep 2008, Alexey Proskuryakov wrote:
> 
> Hmm... So this is more about how you use the interface, not what the 
> object behind it is. If one chooses to never call close() on a shared 
> worker (or, say, sets myWorker.close to null right after invoking 
> constructor), it becomes indistinguishable from a dedicated worker.
> 
> Hiding close() possibly sounds more like something a high-level 
> framework may want to do to enforce a certain design pattern than a core 
> feature.

On Tue, 30 Sep 2008, Aaron Boodman wrote:
> 
> I could see that too. When all the parties accessing a shared worker are 
> from the same origin (as they are today) it is less of an issue. You can 
> probably assume that they know not to close() the worker.

On Thu, 6 Nov 2008, Alexey Proskuryakov wrote:
> Nov 6, 2008, ? 2:18 AM, Jonas Sicking ???????(?):
> > 
> > A shared worker is shared between all scripts on a single site[*] that 
> > instantiates a worker with the same name. I.e. where the second 
> > argument to the constructor is the same. (Don't remember what happens 
> > if the second argument is the same as an existing worker, but the 
> > first is not, check with the spec).
> 
> Sure, that part is clear - but it's only about the behavior of the 
> object's constructor, not the object itself! It alone doesn't warrant 
> having a separate interface.
> 
> As an example from another area, see mmap(2) function - you can pass 
> MAP_ANON or MAP_FILE via its flags to achieve similar results. Note also 
> that it has a number of other options. If we create a separate interface 
> for every Worker isolation level needed (both inside and outside), we'll 
> soon end up with PrivateWorker, SharedDataWorker and who knows what 
> else.

We have different objects for shared and dedicated workers for a multitude 
of reasons:

 1. Shared workers have a name.
 2. Dedicated workers have a method to terminate() them.
 3. The two have different communication needs (see below for detail).
 4. It allows us to have clearly named constructors, which makes for
    more self-documenting code.
 5. It's less confusing to authors if the two concepts are distinct, 
    since they have such different use cases and use patterns.

The reasons for mixing them back together (as they used to be in the 
original proposal) seem very unclear to me.


On Fri, 12 Sep 2008, Aaron Boodman wrote:
> 
> * I think onclose makes sense on Port instead of on Worker. The other 
> side of a Port can close out from under you, even if it is a window.

MessagePorts do have an onclose; it's separate from the onclose of the 
Worker objects.


On Fri, 12 Sep 2008, Aaron Boodman wrote:
> 
> * Ojan brought this up earlier, but I don't think there should be 
> anything added to the global scope of workers except a single 'self' 
> object, which implements all the APIs that are available there.

I did this once, and was immediately told to undo it, so I'm reluctant to 
make this change again.


On Fri, 12 Sep 2008, Aaron Boodman wrote:
>
> * I think it would be a nice convenience to have an onmessage event 
> inside workers that receives all messages sent to any port in the 
> worker.

On Tue, 30 Sep 2008, Alexey Proskuryakov wrote:
>
> Creating/accessing a shared worker could also create a default port that 
> for use with Worker::postMessage, while all messages from such would be 
> forwarded to WorkerGlobalScope::onmessage perhaps? Closing such a port 
> wouldn't kill the worker thread, of course.

What's the use case for a global watching point like this? This seems very 
odd.


On Mon, 3 Nov 2008, Aaron Boodman wrote:
> 
> My biggest issue with the proposal as currently drafted is that there 
> are so many different ways to send and receive messages. I think this 
> overcomplicates the proposal for both developers and implementors.
> 
> For dedicated workers, you can either send single messages using the 
> Worker object directly, like in Gears:
> 
> var worker = new Worker("foo.js");
> worker.postMessage("ping");
> 
> [... snipped startConversation, which is equivalent to sending 
> MessagePorts manually ...]
> 
> Note that the worker has to know ahead of time which API the callers 
> will use since the way that it replies is different depending on that. 
> If the caller used Worker.postMessage(), the worker should reply like 
> this:
> 
> onmessage = function() {
>   postMessage("pong");
> }
> 
> ... but if the caller [posted a port to talk over], then the worker 
> should reply like this:
> 
> onmessage = function(e) {
>   e.port.postMesage("pong");
> }
> 
> * Workers have to know what interface was used to send them messages. If 
> the page using a worker decide to start using a more powerful send API, 
> the worker must also be upgraded. You can already see examples of this 
> problem in the samples at the beginning of the draft. They are marked 
> with the comments "// support being used as a shared worker as well as a 
> dedicated worker".

This is just like if the client sent "PING" instead of "ping". It's not a 
different mechanism, it's just a different way of using the mechanism. 
Sure, you have to set up a convention for messages for your worker. I 
don't see this as a problem.


On Fri, 12 Sep 2008, Aaron Boodman wrote:
>
> Thinking about this some more, having the "port" convenience properties 
> gets confusing when there are multiple clients sending messages, and 
> doesn't make a whole lot of sense with shared workers.
> 
> I think we should just get rid of these. It only adds one line of code
> to the simple case.

On Mon, 15 Sep 2008, Chris Prince wrote:
>
> I like this a lot.  +1 to making connect() always explicit.  Implicit 
> creation of ports led to many rough edges.

On Mon, 15 Sep 2008, Chris Prince wrote:
> 
> I think your proposal nearly works for window.postMessage() too.  If you 
> move 'onconnect' and 'connect()' into a MessageReceiver interface 
> [better name TBD], and make Worker and Window both inherit from 
> MessageReceiver, do you end up with a unified messaging model?

On Wed, 24 Sep 2008, Aaron Boodman wrote:
> 
> In the current design, there are three separate mechanisms to connect to 
> and communicate with a worker:
> 
> a) DedicatedWorker::postMessage() + DedicatedWorkerGlobalScope::onmessage
> 
> [... snipped startConversation ...]
> 
> c) new SharedWorker() + SharedWorkerGlobalScope::onconnect
> 
> I would like to combine all of these into one common mechanism:
> 
> - Create a worker using either new Worker() or new SharedWorker()
> - Call connect() to get a channel
> - Inside the worker, listen for onconnect, then receive messages using
> the port's onmessage event

On Tue, 30 Sep 2008, Aaron Boodman wrote:
>
> SharedWorkers are by definition meant to be used from multiple pages, so 
> a developer will usually not use the default port since it would only 
> work for the first client and not any other. If the developer only 
> intended for their to be one client, he would just use DedicatedWorker.

On Mon, 3 Nov 2008, Aaron Boodman wrote:
> 
> SharedWorkers require a third, completely different API to send messages:
> 
> var w = new SharedWorker("foo.js", "foo");
> w.port.postMessage("ping");
> w.port.onmessage = function(e) {};
> 
> The interface to receive messages in a SharedWorker is also special:
> 
> onconnect = function(e) {
>   e.port.onmessage = function(e) {
>     e.port.postMessage("pong");
>   }
> }
> 
> This lack of generality bothers me on an aesthetic level, but I also 
> think it has the following real problems:
> 
> * Having different interfaces for each use case means that each new 
> feature has to be added to each interface separately. [snip 
> misunderstanding over startConversation]
> 
> * Having multiple interfaces probably increases the chance of developers 
> misunderstanding and using the wrong tool for the job. [snip example 
> involving startConversation]
> 
> * More API for developers to learn and implementors to build.
> 
> I think that these issues can all be addressed by simplifying and 
> combining the various APIs. This will make the simplest examples of 
> workers require slightly more code, but I think it is much simpler and 
> more elegant.
> 
> Here is how it would work:
>
> * Get rid of the DedicatedWorker interface.
>
> * Add [a method called] "connect()" and make the onconnect event fire 
> inside the worker each time it is called.
> 
> Here's an example in code:
> 
> // dedicated workers (outside)
> var worker = new Worker("foo.js");
> var port = worker.connect();
> port.onmessage = function() { }
> port.postMessage("ping");
> 
> // dedicated workers (inside)
> onconnect = function(e) {
>   e.port.onmessage = function(e) {
>     e.port.postMessage("pong");
>   }
> }
> 
> Shared workers are exactly the same except the constructor is
> SharedWorker("foo.js", "foo");
> 
> Note that I do not think it is necessary to implement this all at
> once. For one, the SharedWorker constructor could easily be punted for
> future releases.

On Tue, 4 Nov 2008, Jonas Sicking wrote:
> 
> My main concern is that I think this makes the most simple use case a 
> bit too complicated. In the case when you have a dedicated worker that 
> you want to offload some calculations too you need quite a bit of code 
> to set up that communication.
> 
> With the current API you'd do the following:
> 
> main.js:
> w = new Worker('worker.js');
> w.postMessage(17);
> w.onmessage = function(e) {
>   answer = e.data;
> }
> 
> worker.js:
> function heavyCalulation(inValue) {
>   ...
> }
> onmessage = function(e) {
>   postMessage(heavyCalculation(e.data));
> }
> 
> 
> With the proposed API:
> 
> main.js:
> w = new Worker('worker.js');
> p = w.connect();
> p.postMessage(17);
> p.onmessage = function(e) {
>   answer = e.data;
> }
> 
> worker.js:
> function heavyCalulation(inValue) {
>   ...
> }
> onconnect = function(e) {
>   e.port.onmessage = function(e2) {
>     e.port.postMessage(heavyCalulation(e2.data));
>   }
> }
> 
> This complexity I feel is extra bad since I suspect the simple case is 
> going to be the common case (I know we disagree there). I especially 
> dislike the fact that you have to wait for two events, first a 'connect' 
> event and then the actual message event. This seems overly complex for 
> the simple case of simply wanting to use a single communication channel 
> with a dedicated worker. And even though there isn't that much more code 
> in my example above, it took significantly more effort to get it right 
> given the nested two handlers that were needed.
> 
> So I think we should keep the simple case of a dedicated worker and a 
> single communication channel as simple as possible. This means that I 
> think we should keep postMessage/onmessage available on the dedicated 
> worker directly, as well as the dedicated worker global scope.
> 
> As an added bonus this keeps things very similar to message passing 
> between windows.

On Tue, 4 Nov 2008, Jonas Sicking wrote:
> 
> So Hixie brought up a good point on IRC, there really is only one 
> communication mechanism, which is postMessage/onmessage.
> 
> I'd note that [...] all proposals have two 'communication' mechanisms: 
> postMessage and connect.
> 
> With Aarons proposal you have to both for a shared worker and a 
> dedicated worker use both mechanisms; first call connect() and then call 
> postMessage(). If keep postMessage on the dedicated worker the only 
> difference is that for a dedicated worker you skip the connect() and go 
> directly to postMessage.

On Thu, 6 Nov 2008, Alexey Proskuryakov wrote:
> 
> Something that seems missing from these discussions is how the API 
> changes affect semantics of worker behavior, which makes it hard to 
> compare proposals. For example, having some port singled out as an 
> attribute of Worker (or as an implicit hidden attribute, used by methods 
> defined on Worker itself) sorta implies that closing it should close 
> other ports and dispose of the worker global scope soon. Similarly, 
> having separate interfaces for Worker and SharedWorker implies that 
> there is some fundamental difference in their behavior - a difference 
> that eludes me so far.
> 
> It would seem that we could make better progress if we had a list of 
> requirements that we want to have fulfilled (e.g., should it be possible 
> to easily manage worker lifetime manually by closing a dedicated port? 
> or should workers strive to remain available for as long as any client 
> has an open port, which helps write reliable code?).
> 
> I really don't think that the desire to save one line in a 500-line 
> program should affect the design too much. Convenience methods can be 
> added later, but over-engineered parts cannot be removed later. And at 
> this point, I believe that we are mostly speculating about use cases 
> (probably except for Google Gears folks, who are shipping a similar API, 
> and get developer feedback already).

On Wed, 5 Nov 2008, Jonas Sicking wrote:
> Ian Hickson wrote:
> > > * Remove the port property from the SharedWorker interface and give 
> > > it a postMessage and onmessage just like dedicated workers have.
> > 
> > I really don't like this. With (Dedicated)Worker it makes sense 
> > because both sides bury the underlying message channel and ports and 
> > so things like closing the port, or whether the port is active, are 
> > hidden on both sides. But with SharedWorker, if we only bury it on one 
> > side, there is a lack of symmetry that IMHO is going to lead to all 
> > kinds of issues and confusion. I really don't like that. If people 
> > start sending one side's pipe down another channel, we can end up with 
> > a situation where a SharedWorker object really represents a port that 
> > has nothing to do with the worker anymore.
> 
> It's not really that different from what you have today where a 
> myWorker.port object can send messages to something that isn't a worker 
> at all.
> 
> It also removes the issue where the .port property on a shared worker is 
> readonly but dead.

I believe that the idea that the API for shared and dedicated workers 
should be the same is misguided. The spec used to make the two cases 
identical. The result was confusion, and the dedicated case was much more 
complex than necessary.

Shared workers and dedicated workers are fundamentally different and have 
different needs, and we should expose these needs in ways optimised for 
the two cases.

The basic need is that dedicated workers be able to have a two-way 
communication channel with their creators, and shared workers be able to 
have a two-way communication with each user of the worker.

Assuming we use MessagePorts on each end for communication, then we have 
to get the ports to each end somehow.

On the outside, we can expose a port on the worker object:

   var worker = new Worker(url);
   worker.port...

   var worker = new SharedWorker(url, name);
   worker.port...

...and on the inside we can have either the port provided through an 
event:

   // case A
   var port;
   onconnect = function(e) {
     port = e.port;
   };

...or accessible in general:

   self.port // case B

The latter (B) doesn't work for shared workers, since there are multiple 
ports in that case, so for shared workers we have to use the former (A).

For dedicated workers though that's way more complexity than we want to 
require of authors -- why do they have to listen for a port when there 
will always be exactly one? So it makes sense to use 

Now, we've at this point made the two different already, so as to simplify 
the dedicated worker, so we could (and the spec does) make the dedicated 
worker even simpler while we're at it.

One way to do that is to bury the ports into the Worker and global scope 
objects. If we do one side, though, we have to do the other, because it 
would be really weird to have a message channel that half-acts like a 
two-port channel and half doesn't. For example, if we bury it, we 
shouldn't expose .close(), since it's better for the worker to be closed 
using the actual .close() or .terminate() API, but if we only "bury" one 
side, then one end could close the pipe and not the other, and we'd have 
to make sure we expose .onclose on the buried end, and so forth.

So, we end up with what the spec has now.

I think what we have now is better than making dedicated and shared 
workers superficially the same (as the spec used to be, and as the people 
involved in this thread argued was bad) is more confusing for authors.

At this point, if the only arguments for changing the API are "it's 
confusing for authors", then I'd rather not change the API. We got to 
where we are today by carefully considering what would be better for 
authors. We could continue going back-and-forth and reverting earlier 
decisions until the cows come home, but I see no benefit to doing so.


On Fri, 12 Sep 2008, Aaron Boodman wrote:
> 
> * I still don't buy the utility of passing around MessagePorts, so I 
> suggest we table that for v2. It can always be added back later.

Since they so drastically affect the API design, I think putting them off 
is a mistake. We might end up constraining ourselves in unobvious ways.


If there are specific points that I have not explicitly replied to that 
materially affect the arguments and my responses, please let me know. I 
tried to take all the input above into account, but it was non-trivial, 
since much of it was contradictory, with even individual people putting 
forwards opposite arguments.

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

From singer at apple.com  Thu Nov 13 15:29:12 2008
From: singer at apple.com (Dave Singer)
Date: Thu, 13 Nov 2008 15:29:12 -0800
Subject: [whatwg] Scripted querying of <video> capabilities
In-Reply-To: <2c0e02830811131415g4cd3c219vcd6482a18adac216@mail.gmail.com>
References: <48BD8072.8020403@googlemail.com>
	<11e306600809021127g7a74d0b4gec09f8f2b4b59baf@mail.gmail.com>
	<Pine.LNX.4.62.0810132255440.1237@hixie.dreamhostps.com>
	<11e306600810131647p78d50571n21f36df8c5bd4a70@mail.gmail.com>
	<99E4A086-4E5F-4305-9D04-92B9A71BBF09@apple.com>
	<Pine.LNX.4.62.0810150057390.1237@hixie.dreamhostps.com>
	<DD19DDBD-DF36-4CD2-9F9D-5A327399FB9F@apple.com>
	<35c92870811131052o5f45d6c5hdf0304ed8fd40489@mail.gmail.com>
	<1226605092.6632.36.camel@localhost>
	<2c0e02830811131415g4cd3c219vcd6482a18adac216@mail.gmail.com>
Message-ID: <p06240802c54266c4d353@[17.202.35.52]>

Pitching in here, I think it's OK if we want to go to a two-state 
answer -- but those answers are No and Maybe, not No and Yes.  There 
are, after all, vanishingly small numbers of mime types where I can 
be 'completely' (within reason) confident of a 'yes' answer.  On the 
other hand, given a mime type I simply don't recognize, or a codec I 
know I don't have, I can be confident of a No.

Documenting it as providing a No/Maybe indication, and that how 
positive the 'Maybe' is depends to a large extent on how precise the 
supplied mime type is, would be fine by me, I think.
-- 
David Singer
Multimedia Standards, Apple Inc.


From ian at hixie.ch  Thu Nov 13 16:59:49 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 14 Nov 2008 00:59:49 +0000 (UTC)
Subject: [whatwg] Combining the DedicatedWorker and
	SharedWorker	interfaces
In-Reply-To: <3ABCAB85-91D0-42C6-BBDF-84656A026A12@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com> 
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com> 
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>
	<491229C8.8080205@sicking.cc>
	<AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org> 
	<63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>
	<278fd46c0811131253p3357f223uf54ff2e655a9cf1d@mail.gmail.com>
	<491CA84A.6020005@sicking.cc>
	<3ABCAB85-91D0-42C6-BBDF-84656A026A12@webkit.org>
Message-ID: <Pine.LNX.4.62.0811140025530.1237@hixie.dreamhostps.com>


On Thu, 13 Nov 2008, Alexey Proskuryakov wrote:
> 
> I like that it doesn't tie Worker and MessagePort lifetimes too closely, 
> which means that it has a higher chance of being paradox-free.

Could you elaborate on this? I'm not sure I understand. What paradoxes 
might exist?


On Thu, 13 Nov 2008, Jonas Sicking wrote:
>
> The main two things that people seem to dislike in the current are
> 1. The many communication mechanisms.
> 2. Different APIs for shared and dedicated workers.
> 
> I've said before that I don't really think 1 is true. There is currently 
> one communication mechanism (postMessage/onmessage) and one connection 
> mechanism (onconnect). The communication mechanism (postMessage/ 
> onmessage) does come in two flavors though as you for shared workers and 
> dedicated workers call the functions on different objects.

I agree that there is only one real communication mechanism, and I don't 
understand the problem with that.

The onconnect mechanism is unfortunate, but I don't see any other good way 
to get the ports into the shared worker case. Certainly we don't want to 
force the dedicated worker users to have to use it, IMHO.


> 2 I think is as much of a feature as a bug. Dedicated workers are by 
> nature simpler since there is a one-to-one relationship between browsing 
> context and worker rather than a many-to-one. So by having different 
> APIs we can allow the dedicated worker API to be simpler. That said, I 
> do agree that it is unfortunate that the mechanisms are different.

Agreed, somewhat.


> So, here are some concrete proposals for a few changes we can make, and 
> comments i've heard/made about them. The changes refer to the *current 
> draft*, so please check the behavior defined there.
> 
> * Remove startConversation
> Details:
> Simply remove the startConversaion function on all interfaces where it
> is defined. Since it doesn't define any new events no other changes
> are needed.

Done, for now. We might bring it back later, but it seemed simpler to 
remove it since it was causing confusion.


> * Make the external API for shared workers that of the current dedicated worker
> Details:
> Move the postMessage/onmessage functions from the SharedWorker.port
> object to the SharedWorker object. The SharedWorker would act as a
> MessagePort that is entangled with the port that is provided to the
> SharedWorkerGlobalScope through already specified 'connect' event that
> is fired when a SharedWorker is created.
> 
> Comments:
> The result of this would be that on the outside shared workers and
> dedicated workers have exactly the same API to the outside world,
> except that dedicated workers have a terminate() function (formerly
> known as close(), changed in the latest version of the spec).

Right.


> [...] Hixie expressed some dislike about the fact that we'd end up with 
> MessagePort entangled with something that isn't a MessagePort. This can 
> result in uglyness if the MessagePort is passed out outside the 
> SharedWorker, and then passed on anywhere. A page could create a setup 
> where calling postMessage on a SharedWorker object actually resulted in 
> onmessage being called inside another window rather than inside a worker 
> global scope.

Right. There's also the problem with whether to expose .close(), start(), 
etc, on the SharedWorker object -- i.e. whether to flatten the whole 
MessagePort API in, or whether to only expose some parts -- in the latter 
case, we'd have a weird asymetry where e.g. the worker could call 
.close(), but the SharedWorker wouldn't get the close event, etc.

I really don't like this.


> I don't really think this is a big deal though, you have a very
> similar situation today where calling postMessage on a
> SharedWorker.port object can do exactly the same thing.

We could change .port to .getPort(), or .connect(), and have it return a 
new port. That would remove the artificial link between the SharedWorker 
object and the MessagePort. Would that work for people?


> * Make dedicated workers receive a 'connect' event when they are created
> Details:
> Make the internal communication API for a dedicated worker exactly
> that of what a shared worker is currently specced as. This means
>  - Once a dedicated worker is instantiated automatically fire a
>    'connect' event which contains a MessagePort object (accessible
>    through event.port).
>  - Make the Worker object entangled with this MessagePort.
>  - Remove the postMessage/onmessage functions from DedicatedWorkerGlobalScope
> 
> Comments:
> I don't feel super strongly about this. From a purely dedicated worker 
> perspective this doesn't really add any value but rather just 
> complexity. Everyone using dedicated workers will have to set up a dummy 
> function that just listens for a 'connect' event and sets a global port 
> variable. The upside is that combined with the above change it makes the 
> API for dedicated and shared workers exactly the same.

This is what we used to have. People didn't like it, so much so that we 
ended up calling a small meeting with the people who'd spoken up on it, 
and the spec changed away from this model.

The current model makes dedicated workers much simpler to author with. 
With the connect case, you end up with multiple nested lambdas, which is 
really ugly.

I thus really don't want to go back there.


> * Add a connect() method to Worker and/or SharedWorker
> There has been lots of talk about this, but I'm still confused as to
> what the exact proposals are due to lack of details. But here is my
> interpretation
> Details:
>  - Make instantiating a SharedWorker *not* fire a 'connect' event 
>    automatically.
>  - Remove the .port property from SharedWorker
>  - Remove the postMessage/onmessage functions from Worker and
>    DedicatedWorkerGlobalScope
>  - Add a onconnect property on WorkerGlobalScope
>  - Add a connect() method on AbstractWorker. The function fires a
>    'connect' even on the WorkerGlobalScope, the event has a .port
>    property which is a MessagePort. This MessagePort is entangled with
>    another MessagePort which is the value from the connect() function.
> 
> Comments:
> Compared to just doing the other above proposals I think this adds 
> needless complexion for value that I don't quite see. If you want to 
> have several 'conversations', I.e. several separate MessagePorts, with a 
> dedicated worker you can use postMessage and |new MessageChannel| (or 
> the startConversation shorthand) to accomplish that. If you want several 
> conversations with a dedicated worker you can do the same thing, or even 
> call |new SharedWorker| multiple times.

I wouldn't mind doing this just for the shared case, to further separate 
the port from the SharedWorker object, but I don't see any good reason to 
do this for the dedicated worker case.



On Thu, 13 Nov 2008, Aaron Boodman wrote:
> 
> This is true, the worst I can think of happening as a result of the API 
> Mozilla is planning no shipping would be "frustrating for developers" or 
> "frustrating for implementors" as more feature are added that don't fit 
> well.

I'm not convinced that the current API will result in that problem, and I 
think that the proposed APIs are no better, frankly.


> Here are my preference on changes, in descending order:
> 
> > * Add a connect() method to Worker and/or SharedWorker
> > There has been lots of talk about this, but I'm still confused as to
> > what the exact proposals are due to lack of details. But here is my
> > interpretation
> > Details:
> >  - Make instantiating a SharedWorker *not* fire a 'connect' event automatically.
> >  - Remove the .port property from SharedWorker
> >  - Remove the postMessage/onmessage functions from Worker and
> > DedicatedWorkerGlobalScope
> >  - Add a onconnect property on WorkerGlobalScope
> >  - Add a connect() method on AbstractWorker. The function fires a
> > 'connect' even on the WorkerGlobalScope, the event has a .port
> > property which is a MessagePort. This MessagePort is entangled with
> > another MessagePort which is the value from the connect() function.
> >
> > Comments:
> > Compared to just doing the other above proposals I think this adds
> > needless complexion for value that I don't quite see. If you want to
> > have several 'conversations', I.e. several separate MessagePorts, with
> > a dedicated worker you can use postMessage and |new MessageChannel|
> > (or the startConversation shorthand) to accomplish that. If you want
> > several conversations with a dedicated worker you can do the same
> > thing, or even call |new SharedWorker| multiple times.
> 
> I think this is the best API because it offers the most functionality 
> with the smallest area.

I don't mind doing this for SharedWorkers if people want, but I don't see 
a reason to do this for dedicated workers.

Would that work? Or is having them be the same the goal for you?


> I also like that the API for dedicated and shared workers is identical 
> because it means that one you learn to use dedicated workers, you 
> already know how to use shared workers.

I think the fact that it makes you think that is an argument _against_ 
doing this. There is a huge difference between what you'd need to do for a 
dedicated worker (one onconnect event, in this model) and what you'd need 
to do for shared workers (many connections). Misleading people into 
thinking you can take a dedicated worker and have it just work in the 
shared case is IMHO bad language design.


> If we don't make the above change, I think that we should remove
> startConversation().

Gone.


On Thu, 13 Nov 2008, Jonas Sicking wrote:
> 
> Comparing to doing the other set of changes the differences in API are 
> as follows:
> 
>  - Add a 'connect()' method on AbstractWorker which must be called every
>    time after instantiating a worker.
>  - The postMessage/onmessage functions are moved from the worker object
>    to the port object.
> 
> To me this seems like strictly a bigger API. As far as functionality goes the
> differences are as follows:
> 
>  - You have to deal with two separate objects, the port and the worker.
>  - You can create multiple communication channels with a worker by
>    calling connect() multiple times.
> 
> Only the second thing here seems like a win.

I'm not convinced it's that much of a win, either.


> And only for dedicated workers since for shared workers you can simply 
> call |new SharedWorker| multiple times if you want multiple 
> communication channels.
> 
> So it seems to me like the pros and cons fall out as:
>  Pros:
>    - Easier to create multiple connection channels to dedicated workers
>  Cons:
>    - Bigger API (an extra connect() function)
>    - More code required (an extra call to connect() required)
>    - More objects (port and worker)
> 
> To me the cons outweigh the pros here. Is there a goal with connect() 
> that I'm missing?

I agree.


> At this point I have to ask what the problem you are trying to solve is? 
> What is wrong with the current spec as is? I.e. rather than talking 
> about various proposals, maybe we need to align the goals first as we 
> might be talking past each other.

I agree that this would be useful (and necessary) to understand.


On Fri, 14 Nov 2008, Alexey Proskuryakov wrote:
> 
> For the sake of completeness, a connect/startConversation method on a 
> worker really should automatically open the receiving port - this is 
> what examples posted so far implied, and it would cause a lot of 
> aggravation if it didn't. I know I'm often forgetting to open the port 
> when writing my tests, and it's not a very easy mistake to spot.

What do you mean by "open the port"? Do you mean calling start()? If so, 
that should happen automatically when you set onmessage the first time, 
per spec.


> Besides API usability that we've already discussed back and forth 
> without reaching an agreement, I'm very much concerned about the current 
> spec being implementable in its current form. It has a lot of notions 
> and algorithms that are not correctly defined. For a randomly picked 
> example:
> 
> -----------------------------
> Each WorkerGlobalScope worker global scope has a list of the worker's 
> ports, which consists of all the MessagePort objects that are entangled 
> with another port and that have one (but only one) port owned by worker 
> global scope. This list includes all the MessagePort objects that are in 
> events pending in the queue of events, as well as the implicit 
> MessagePort in the case of dedicated workers. 
> -----------------------------
> 
> In an async processing model, there is simply no way for the receiver to 
> have a list of all objects that were posted to it - it's exactly the 
> reason for the existence of the queue that events are delivered 
> asynchronously and cannot be peeked before being delivered. For example, 
> in a multi-process implementation, these events may still be across 
> process boundary.

It actually doesn't really matter if there is something that has been 
posted but not yet received, because that is indistinguishable (as far as 
I can tell) from the case of the worker having shut down a split second 
before that object was posted.


> Also (from HTML5):
> -----------------------------
> Each MessagePort object can be entangled with another (a symmetric
> relationship).
> -----------------------------
> 
> It is not possible to have a symmetric relationship in an asynchronous 
> messaging model - we need a multi-step entagling/unentangling protocol, 
> so the relationship is necessarily asymmetric. One can't freeze another 
> process (or really, even another thread) to change something in it 
> synchronously.

The above is not a requirement, it's just a description of the concept. I 
don't think anything actually depends on it being symmetric; all the parts 
that actually entangle ports have (or, are intended to have, maybe I 
missed some) pretty well-defined synchronisation points. For example, any 
method that entangles two ports blocks until both threads are synchronised 
and entangled.

(The spec is somewhat implicit about this, but the intent is that workers 
really be implemented either as two system threads, one doing 
communication and one running the JS, or by one system thread that runs 
the JS in an interruptible fashion. In particular, doing something that 
synchronises with a worker isn't expected to have to wait for that worker 
to finish running its current JS.)


> Some instances of implied synchronous thinking can be corrected rather 
> easily, but not all of them. So, I do not really see how anyone can 
> claim implementing the spec, or even a subset of it at this point.

Do you have any specific examples of what can't be implemented?

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


From shannon at arc.net.au  Thu Nov 13 17:16:31 2008
From: shannon at arc.net.au (Shannon)
Date: Fri, 14 Nov 2008 12:16:31 +1100
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0811122339590.1237@hixie.dreamhostps.com>
References: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>
	<Pine.LNX.4.62.0811122339590.1237@hixie.dreamhostps.com>
Message-ID: <491CD16F.30706@arc.net.au>

I don't see any value in the "user-agent specified amount of time" delay 
in stopping scripts. How can you write cleanup code when you have no 
consistency in how long it gets to run (or if it runs at all)? If you 
can't rely on a cleanup then it becomes necessary to have some kind of 
repair/validation sequence run on the data next time it is accessed to 
check if it's valid. If you can do that then you didn't really need a 
cleanup anyway. As far as I can tell the "user-agent specified amount of 
time" is going to be a major source of hard-to-spot, hard-to-test bugs 
(since full testing probably involves closing and killing browsing 
contexts in different ways followed by a login sequence and several page 
navigations to get back to the page). I can see authors maybe performing 
these tests in IE but not across a range of browsers and computer 
specifications.

The spec really needs to make a decision here. Either consistently 
provide no cleanup window or make it a requirement to provide a fixed 
number of seconds, which is still unreliable but at least within a 
smaller margin. Failure to do so will impact heavily on users of less 
popular browsers.


The specification for message ports is still limited to strings. If no 
effort is going to be made to allow numbers, arrays, structs and binary 
data then I'd suggest Workers be given functions to 
serialise/deserialise these objects. Since the whole point of workers is 
presumably the processing of large datasets then a reliable and 
low-overhead means of passing these sets between workers and main 
threads (without resorting to SQL, XMLHttpRequest or other indirection) 
is an essential function.


WorkerUtils does not implement document.cookie. I imagine this would be 
very useful in conjunction with cleanup code to flag if a cleanup 
operation failed to complete. Storage and Database interfaces are too 
heavy for the purpose of simple data like this.


Shannon


From ian at hixie.ch  Thu Nov 13 17:42:09 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 14 Nov 2008 01:42:09 +0000 (UTC)
Subject: [whatwg] Workers feedback
In-Reply-To: <491CD16F.30706@arc.net.au>
References: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>
	<Pine.LNX.4.62.0811122339590.1237@hixie.dreamhostps.com>
	<491CD16F.30706@arc.net.au>
Message-ID: <Pine.LNX.4.62.0811140136410.1041@hixie.dreamhostps.com>

On Fri, 14 Nov 2008, Shannon wrote:
>
> I don't see any value in the "user-agent specified amount of time" delay 
> in stopping scripts. How can you write cleanup code when you have no 
> consistency in how long it gets to run (or if it runs at all)?

The "user-agent specified amount of time" delay is implemented by every 
major browser for every script they run today.

How can people write clean code when they have no consistency in how long 
their scripts will run (or if they will run at all)?

Why is this any different?


> If you can't rely on a cleanup then it becomes necessary to have some 
> kind of repair/validation sequence run on the data next time it is 
> accessed to check if it's valid.

You need to do that anyway to handle powerouts and crashes.


> The spec really needs to make a decision here. Either consistently 
> provide no cleanup window or make it a requirement to provide a fixed 
> number of seconds, which is still unreliable but at least within a 
> smaller margin. Failure to do so will impact heavily on users of less 
> popular browsers.

I don't see how this is any different than the current script abort 
timeout feature in browsers.


> The specification for message ports is still limited to strings. If no 
> effort is going to be made to allow numbers, arrays, structs and binary 
> data then I'd suggest Workers be given functions to 
> serialise/deserialise these objects.

We're going to add "JSON-serialisable data" support in due course. I'd 
rather get the rest of the API nailed down first though.


> WorkerUtils does not implement document.cookie. I imagine this would be 
> very useful in conjunction with cleanup code to flag if a cleanup 
> operation failed to complete. Storage and Database interfaces are too 
> heavy for the purpose of simple data like this.

It's not clear which document the cookie would be for. localStorage is 
as light-weight than cookies (lighter-weight, arguably), though, so that 
should be enough, no?

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


From silviapfeiffer1 at gmail.com  Thu Nov 13 18:45:10 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 14 Nov 2008 13:45:10 +1100
Subject: [whatwg] Issue when Video currentTime used for seeking.
In-Reply-To: <4a27dd80811130348j6bce9764h701ad1b75215081d@mail.gmail.com>
References: <4a27dd80811112136l1fb56407s47cbeb2e3e71d095@mail.gmail.com>
	<c2e346f90811112316r2fc25382l6dd29b15b1c1a67b@mail.gmail.com>
	<4a27dd80811130348j6bce9764h701ad1b75215081d@mail.gmail.com>
Message-ID: <2c0e02830811131845g5e9d3f37ldb3d697c13d2774e@mail.gmail.com>

On Thu, Nov 13, 2008 at 10:48 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
> On Wed, Nov 12, 2008 at 3:16 AM, Chris Double <chris.double at double.co.nz> wrote:
>> On Wed, Nov 12, 2008 at 6:36 PM, Biju Gm at il <bijumaillist at gmail.com> wrote:
>>> video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";
>>> video_element.currentTime=10;
>>> video_element.play();
>>
>> You can use:
>>
>> v.src = "foo.ogg";
>> v.addEventListener("loadedmetadata", function() { v.currentTime=10;
>> v.play(); }, false);
>
> Yes we can use JS to have a work around. But there will be other problems.
> Example, the above code make all the subsequent assignment of url to
> v.src make movie start from 10th second. So again we need to add code
> to remove the event listener. That make things complicated for Web
> Developers,  (see, all Web developers I know are JSP/Java, ASP/.Net or
> Graphics Designers they all only cut and paste JavaScript code).
>

I still feel rather dubious about the currentTime attribute of the
video element.

When it is used to tell a server about starting at an offset rather
than a the beginning, I'd prefer we rather use media fragment URIs
(once they are standardised by the W3C media fragment working group).
It will then be obvious that the user is actually asking for a subpart
of the resource to be displayed only. This is controlled by the author
of the Web page.

When it is used to change the current play pointer during watching of
a video, i.e. is controlled by the user of the Web page, it should
really be done through an event and javascript. Maybe the onclick
event can be defined for the video element here and it could call a
seek javascript function?

I feel very dubious about mixing these two use cases into the same attribute.

Best Regards,
Silvia.


From ian at hixie.ch  Thu Nov 13 18:56:08 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 14 Nov 2008 02:56:08 +0000 (UTC)
Subject: [whatwg] video tag : loop for ever
In-Reply-To: <015401c9366c$b9d7df30$2d879d90$@ca>
References: <4a27dd80809270819o5fa677ddg353d3fdd094bfb96@mail.gmail.com>
	<CB2A585A-0CA8-4A22-A529-F55CE6FD9100@jorgenhorstink.nl>
	<op.uh519llfwxe0ny@widsith.local>
	<Pine.LNX.4.62.0810150034250.1237@hixie.dreamhostps.com>
	<A1D83E2D-011E-4AB0-95EB-810EE41BE054@apple.com>
	<26b395e60810240644p7432acacsecc730aa65ac77ab@mail.gmail.com>
	<76CCA921-34F8-473E-A04A-AC7D606B51F1@apple.com>
	<015401c9366c$b9d7df30$2d879d90$@ca>
Message-ID: <Pine.LNX.4.62.0811140153570.1237@hixie.dreamhostps.com>


There were 81 e-mails on the topic of looping audio and video.

I haven't included them here because they were mostly redundant. However, 
I read them all, and it seems that the use cases and feedback boiled down 
to these points:

 1. Feedback: Simplify the API where possible; in particular start/end/ 
    loopStart/loopEnd and so on.

 2. Use case: looping complete tracks of background audio or video without 
    glitches.

 3. Use case: playing a track starting at a particular location without 
    using script that waits for the media to load.

 4. Use case: playing different media segments with only one HTTP request.

To address point 1 I've removed all those attributes and related APIs.

To address point 2 I've added a single attribute "loop", which, when
set, causes the UA to loop back to time=0 when the clip ends.

To address point 3 I would like us to consider using recently begun
work relating to fragment identifiers for media content. I have edited
the spec so that it defers to the fragment identifier or any metadata
in the resource, but I expect we will have to further tweak this.

To address point 4 I would like to rely on a more generic solution
that also addresses this for CSS, images, etc. This could be jar:, or
it could me a MIME multipart solution, or offline caching, or data:
URLs, or something else. However, I think this transcends the media
API and therefore I haven't added anything specifically in this API to
deal with it.

If I have missed a key point, please do let me know. It's quite
possible that I missed something when reading this thread as it was
quite long and had a lot of repetition.

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


From ian at hixie.ch  Thu Nov 13 19:51:02 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 14 Nov 2008 03:51:02 +0000 (UTC)
Subject: [whatwg] Video : Slow motion, fast forward effects
In-Reply-To: <60FF1541F08B423EAF633C66C22BCFDE@pirate>
References: <4a27dd80808062158v11fba017sebc118ce3d278f77@mail.gmail.com>
	<c2e346f90808070110r43ae8581n8fbb48373311284@mail.gmail.com>
	<p06240815c4c0f833337f@10.0.1.8> <489B48CF.8080309@sicking.cc>
	<84ce626f0808071223m63984236v33050e3106c011f8@mail.gmail.com>
	<7C5020DF-2417-4CF7-BBC1-84D104E76269@mac.com>
	<6F28EE0F3FE648EAB4498288F2ED1128@pirate>
	<Pine.LNX.4.62.0810132109130.1237@hixie.dreamhostps.com>
	<84ce626f0810141224i198bcb43g1827d419d56f2aea@mail.gmail.com>
	<61796572B39048BCAA45D5305349BA47@pirate>
	<84ce626f0810141256h30fbf5cfif6ca025bbd530acd@mail.gmail.com>
	<E0FF92186A5A498EA85E244C6023E14C@pirate>
	<Pine.LNX.4.62.0810150844530.1237@hixie.dreamhostps.com>
	<60FF1541F08B423EAF633C66C22BCFDE@pirate>
Message-ID: <Pine.LNX.4.62.0811140334000.1237@hixie.dreamhostps.com>

On Wed, 15 Oct 2008, Charles Iliya Krempeaux wrote:
> On Wed, Oct 15, 2008 at 2:08 AM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > Regarding whether to play audio while rewinding:
> > 
> > Leaving this be something that is optional doesn't make sense to me. 
> > If we want interoperability, we need to either have all the browsers 
> > play sound while moving backwards through a sound or video file, or 
> > not play sound. Leaving things optional means that one author will 
> > test with one browser and expect one behavior, and then when the user 
> > uses that page on another browser, he will get unexpected behavior.
> > 
> > For example, if Alice uses Browser A, and finds that when rewinding 
> > the sound isn't played, and thus does a hack that fakes the sound 
> > playback by having a separate hidden <video> > element while 
> > rewinding, in which she seeks, plays forward for a bit, seeks, plays, 
> > etc, then when Bob loads that page in Browser B, which does play audio 
> > when rewinding, he'll get a horrible double audio effect.
> > 
> > Or similarly, if Alice, in an attempt to get a cool effect, plays a 
> > bunch of videos backwards, and when the user selects one, plays it 
> > forward, then Bob will find that all the audio from all the videos 
> > plays simultaneously instead of all being muted except the video that 
> > Alice is expecting to play.
> > 
> > So. We have to either require that backwards-playing audio be muted, 
> > or require that it play. I don't mind which. I've required that it be 
> > muted because implementors said playing would be hard.
> 
> Could we make it configurable though?...
> 
> So... the web developer could check if playing sound for this is available.
> 
> And if it is available, they can turn it on (if they wanted to).  And if 
> it is not available, they can "handle" it in some way.

We could, but this is something I'd leave for a future version, since 
browser vendors have already said that they don't want to support it 
today.


On Wed, 15 Oct 2008, Peter Kasting wrote:
>
> * These use cases are really a stretch, compared to the much more 
> plausible use case of simply allowing a user to scrub a video forwards 
> or backwards.

These aren't use cases, they're just examples of why we have to define 
this one way or the other.


> * All this still seems well-enough-solved if audio can be 
> programmatically muted.  The worst possible case is that the author, as 
> you say, does not test in one browser, and causes another browser to 
> have overlapped audio. Then users complain and the author is responsible 
> and fixes their JS to mute the audio (hopefully simple), or they are 
> lazy and don't.  Neither one seems like catastrophe.  As you say in your 
> mail, authors act irrationally, and not all will fix their pages.  But 
> so what?

If we don't define it, and some browsers do it and some don't, then 
eventually all browsers will be forced to do the same thing (probably mute 
when rewinding). Not defining things is an unstable equilibrium. In the 
meantime, we'll have wasted a bunch of engineering resources.


> By comparison, mandating that browsers play audio puts a great burden on 
> browsers and codec authors (since the feasibility of reversed audio 
> depends on the format, the OS, etc.), and mandating that they don't 
> completely rules out whole classes of use cases.  This cure is much 
> worse than the disease.

We can always add a new feature later that enables scrubbing audio when 
rewinding.

If we don't define it, we're forcing it just as much, it's just that the 
forcing will happen mostly out of our control, and might end up being much 
more of a mess than if we pick one first. That's how a lot of HTML's most 
crazy quirks came about.


> > We can get this by requiring that the user agent play _some_ audio, 
> > even if severely degraded, at all speeds including negative speeds. 
> > I'm happy to require that if people are ok with it.
> 
> I don't see how this is any better than the "no spec" case you wanted to 
> avoid.  Use your previous argument again: an author tests in one 
> browser, which plays reversed audio in a fashion he deems acceptable.  
> The released app, played in another browser, sounds hideous.  Users 
> complain.

But here, it's the less good browser that gets the bad effect, so the 
browser vendors end up forced towards the better behavior, not the worse 
behavior, as would happen otherwise.


> I don't see how an explicit attribute buys you anything more or less 
> than explicit muting until the day when every browser respects that 
> attribute in all cases -- and if our reason for not mandating reversed 
> playback is that it's technically infeasible in some circumstances 
> (which I think has merit), that's unlikely to ever happen.

We can design the feature to indicate whether or not rewinding is going to 
give audio or not.


On Wed, 15 Oct 2008, Kristof Zelechovski wrote:
>
> Requiring some audio to play is a good idea but it should be more 
> precise. If the implementors are required to play some audio, they can 
> do away by playing silence, or play white noise at level 0.

The spec defines that it has to be the media's audio.


> Authors should mute the audio if they don't actually want it.  Setting 
> "muted" to false is hardly the right way to do it.

This is somewhat orthogonal to the issue.


On Wed, 15 Oct 2008, Jeremy Doig wrote:
>
> personally, i think this edge case is complete nonsense. I totally 
> support making it optional. I can't think of a single site today that 
> has anything like this - or wants it. web video is about linear 
> consumption, not edit-type scenarios with frame level control.  We 
> absolutely need the ability to scrub/seek - but that's already in the 
> spec.it's easy for quicktime to talk about supporting it - because they 
> already have it implemented. but that doesn't mean anyone on the web 
> actually needs it.

The questions is not whether we should support it or not. It's an issue of 
making sure we have interoperability.


On Thu, 16 Oct 2008, WeBMartians wrote:
>
> Yeah, it's sort of like the date time situation: either you have to 
> support everything (or, well, at least, be consistent) or have some kind 
> of API to report what you do/don't support.
> 
> I hate big APIs and therefore vote for consistency (if consistency is 
> "the hobgoblin of small minds," I'm a flatworm).

I don't really follow what you mean.

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


From jonas at sicking.cc  Thu Nov 13 20:37:13 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 13 Nov 2008 20:37:13 -0800
Subject: [whatwg] Combining the DedicatedWorker and SharedWorker
	interfaces
In-Reply-To: <3ABCAB85-91D0-42C6-BBDF-84656A026A12@webkit.org>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com>	
	<4910C8AF.3000404@sicking.cc>	
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>	
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com>	
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>	
	<491229C8.8080205@sicking.cc>	
	<AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org>	
	<63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>
	<278fd46c0811131253p3357f223uf54ff2e655a9cf1d@mail.gmail.com>
	<491CA84A.6020005@sicking.cc>
	<3ABCAB85-91D0-42C6-BBDF-84656A026A12@webkit.org>
Message-ID: <491D0079.2060505@sicking.cc>

Alexey Proskuryakov wrote:
> 
> Nov 14, 2008, ? 1:20 AM, Jonas Sicking ???????(?):
> 
>>> If we don't make the above change, I think that we should remove
>>> startConversation(). It doesn't offer enough different functionality
>>> over passing a |new MessageChannel().port2| to be worth the extra API
>>> IMO.
>>
>> No, this is *exactly* the same functionality as passing |new 
>> MessageChannel().port2| through postMessage.
> 
> For the sake of completeness, a connect/startConversation method on a 
> worker really should automatically open the receiving port - this is 
> what examples posted so far implied, and it would cause a lot of 
> aggravation if it didn't. I know I'm often forgetting to open the port 
> when writing my tests, and it's not a very easy mistake to spot.

a port is automatically "opened" ('started' per spec) when you set the 
onmessage property or when you call .start() on it. This is required if 
we want to allow ports to be passed around several steps (i.e. to an 
worker inside an iframe inside an iframe) without having race conditions.

Note that this is unrelated to the workers spec as MessagePorts are 
defined in HTML5

>> At this point I have to ask what the problem you are trying to solve 
>> is? What is wrong with the current spec as is?
> 
> 
> Not speaking for Aaron, of course, but...
> 
> Besides API usability that we've already discussed back and forth 
> without reaching an agreement,

What are the API usability issues you have with the current API? It's 
the goals here that I think we need to agree on before we can have 
useful discussions around the proposals.

> I'm very much concerned about the current 
> spec being implementable in its current form. It has a lot of notions 
> and algorithms that are not correctly defined. For a randomly picked 
> example:
> 
> -----------------------------
> Each WorkerGlobalScope worker global scope has a list of the worker's 
> ports, which consists of all the MessagePort objects that are entangled 
> with another port and that have one (but only one) port owned by worker 
> global scope. This list includes all the MessagePort objects that are in 
> events pending in the queue of events, as well as the implicit 
> MessagePort in the case of dedicated workers.
> -----------------------------
> 
> In an async processing model, there is simply no way for the receiver to 
> have a list of all objects that were posted to it - it's exactly the 
> reason for the existence of the queue that events are delivered 
> asynchronously and cannot be peeked before being delivered. For example, 
> in a multi-process implementation, these events may still be across 
> process boundary.

Note that this list of ports is not exposed to any API. Honestly I'm not 
really sure why the spec says that you need a list at all, other than 
maybe to talk about GC (which i've many times mentioned I think the spec 
should not need to "define").

> Also (from HTML5):
> -----------------------------
> Each MessagePort object can be entangled with another (a symmetric 
> relationship).
> -----------------------------
> 
> It is not possible to have a symmetric relationship in an asynchronous 
> messaging model - we need a multi-step entagling/unentangling protocol, 
> so the relationship is necessarily asymmetric. One can't freeze another 
> process (or really, even another thread) to change something in it 
> synchronously.

Actually, the entanglement can be dealt with asyncronously, although 
it's a bit complicated and unperformant. This can be trivially changed 
though without making any changes to the API. I'll start a separate 
thread on that since this is not part of the workers spec.

> Some instances of implied synchronous thinking can be corrected rather 
> easily, but not all of them. So, I do not really see how anyone can 
> claim implementing the spec, or even a subset of it at this point.

Feel free to try our implementation of a subset of the spec ;)

It's available here and runs example 1.1.1 and 1.1.3 just fine.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

We're using separate threads for workers, not separate processes, but 
nothing we are doing couldn't be done across processes rather than 
across threads.

/ Jonas


From ian at hixie.ch  Thu Nov 13 20:39:54 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 14 Nov 2008 04:39:54 +0000 (UTC)
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <4831FB7C14654D82B37CFB56FDE4D58B@POCZTOWIEC>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<Pine.LNX.4.62.0810150919060.1237@hixie.dreamhostps.com>
	<4831FB7C14654D82B37CFB56FDE4D58B@POCZTOWIEC>
Message-ID: <Pine.LNX.4.62.0811140407090.1237@hixie.dreamhostps.com>

On Wed, 15 Oct 2008, Sander van Zoest wrote:
> > >
> > > <source pixelratio="10:11"> <!-- 525 composite NTSC -->
> > > <source pixelratio="59:54"> <!-- 625 composite PAL -->
> > > <source pixelratio="1018:1062"> <!-- 1920x1035 HDTV SMPTE RP 187-1995 -->
> >
> > Currently pixelratio is a floating point number, as in:
> >
> >   <source pixelratio="0.909090909"> <!-- 525 composite NTSC -->
> >   <source pixelratio="1.09259259"> <!-- 625 composite PAL -->
> >   <source pixelratio="0.958568738"> <!-- 1920x1035 HDTV SMPTE RP 187-1995 -->
> >
> > Is that not enough?
> 
> I hate to say it, but if it was enough, I wouldn't be commenting here. 
> It simply isn't accurate enough to store it as a float. Every respected 
> container stores the ratio as X x Y. See the PASP atom for example.

On Wed, 15 Oct 2008, Anne van Kesteren wrote:
> 
> How is not accurate? In terms of precision it shouldn't really matter...

I agree with Anne here. I've left the spec as is.

Note that the whole point here is to discourage people from using the 
attribute. Also, it is intended only for use by people who are trying to 
fix a broken video; they might not know the right value, so it doesn't 
really matter so much whether the value that is used is precise or not, 
just so long as it improves the video relative to what it would be if the 
value in the video data file itself was assumed.


On Wed, 15 Oct 2008, Sander van Zoest wrote:
> 
> We are talking video here. Precision is at its core. If you consider the 
> majority of the broken video out on the net today a good example of what 
> you want more of then, I see no reason to accurately define PAR. [...] 
> you can not accurately convert video on the fly if you do not have the 
> exact ratio. All this stems from the conversion from analog to digital 
> and in the analog world we did a lot of funky tricks to make things work 
> better on hardware of those days, but as our computers and electronics 
> in general get faster and faster, putting in inaccuracies can cause for 
> some seriously ill side effects, now and especially in the future.

The whole point here is that the video is wrong, and the author is trying 
to apply a last-minute hack to improve it a bit. If performance is an 
issue, then encode the video correctly and don't use the attribute at all.


On Wed, 15 Oct 2008, Jonas Sicking wrote:
> 
> I think if we make the syntax really simple like:
> 
> 1. Find the first ':'
> 2. Parse the value before as an integer
> 3. Parse the value after as an integer
> 
> then adding a new syntax is pretty cheap. Of course having separate 
> attributes is even cheaper. But if the "10:11" syntax is really common 
> then I think it might help authoring to use it.

The whole point is to discourage authors from using it, so actually we 
sort of _want_ it to not help authoring. :-)


On Wed, 15 Oct 2008, Eduard Pascual wrote:
> 
> The issue is that, for most (probably all cases), the limitations of 
> representation of floating numbers are a guarantee that the value will 
> be wrong. It is not the same 0.909090909 that 0.909090909090909090... 
> and that wouldn't still be the same that 10:11.

Assume that we have a video that is 10000 video pixels square. That's a 
100 megapixel video.

If we pretend that aspect ratio of the pixels is 11:11, then the video 
will, at 1:1 zoom, take 10000 horizontal pixels (and 10000 vertical 
pixels).

If we assume that the pixel ratio is 10:11 = 0.9090909090909090909090909, 
and we keep the vertical number of pixels at 10000, then it will be 
(rounding to 0dp) 9091 pixels wide. If we assume that the pixel ratio is 
just 10:11 = 0.90909 then it will STILL be (rounding to 0dp) 9091 pixels 
wide. In practice, videos are much smaller and displayed on much smaller 
displays. So, with all due respect, why is it not enough?


> Although the difference may seem negligible, simple image scaling 
> algorythms tend to yield horribel results for slight scaling (you can 
> try to render a PDF document at 101% zoom to see what I'm speaking 
> about; especially one with images). The alternative, bilinear or 
> trilinear scaling, could be too much of a strain for video: there is a 
> higly noticeable difference between running such algorythm once and 
> running it 25 or 30 times each second. If we add to the mix that pages 
> might be including several videos; that most probably there is also 
> audio playing along with the video, the computation cost of decoding, 
> and the fact that not every user on the web (probably, not even the 
> majority of them) uses a high end computer; then scaling needs to be 
> quick and simple enough to achieve decent rendering without mass-frying 
> CPUs.

Scaling a video to 9090 pixels wide or 9091 pixels wide isn't going to 
show the artifacts you are talking about.


> I still don't understand why the spec has to define each and every 
> parser algorythm (IMO, it should only define the syntax, and then the 
> implementation should define its own algorythm that parses that syntax 
> as defined)

We have to define the parsers because the syntax alone doesn't define the 
error handling behavior.


> but if that's the issue then a microsyntax can be perfectly avoided by 
> splitting the argument into two separate ones, such as pixelratiox and 
> pixelratioy.

We want to make this as cheap as possible, and adding more attributes 
doesn't make it cheaper.

For example, having two attributes introduces costs such as:

On Wed, 15 Oct 2008, Sander van Zoest wrote:
> 
> The only issue I have with splitting it into separate ones, is that we 
> need to ensure that both exist or none exist, having just X or just Y is 
> clearly confusing and should not be allowed.

On Wed, 15 Oct 2008, Kristof Zelechovski wrote:
>
> We could also say that specifying only one coordinate has no effect.  I 
> think the requirement that both attributes have to be present or absent 
> cannot be specified in a document type definition (if someone would like 
> to have one nevertheless).

On Wed, 15 Oct 2008, Peter Kasting wrote:
> 
> The entire problem is that it is not simple.  It is less simple to spec, 
> less simple to declare, less simple to parse, and less simple to test, 
> and there is zero real-world gain in it.  It is not a "hack" to note 
> that the floating-point precision available here is far higher than what 
> any display could ever manage and therefore any rounding errors occur at 
> levels many orders of magnitude to small to have any effect at all.


Going back to the original topic:

On Wed, 15 Oct 2008, Ralph Giles wrote:
> 
> It is enough. Sander and Eduard have provided excellent arguments why 
> the pixel aspect ratio, and especially the frame rate, should be 
> represented as rationals in video formats. But as an override for 
> already broken video streams compliance to best practice does not 
> justify another data type in html5.
> 
> To put Anne's comment another way, one needs a gigapixel display device 
> before the difference between 1.0925 (rounded to only 5 figures) and 
> 59/54 affects the behaviour of the scaling algorithm at all. There 
> aren't so many aspect ratios is common use--you're welcome to choose the 
> one nearest to the floating point value given if you think it's 
> important.

Agreed.


On Wed, 15 Oct 2008, Sander van Zoest wrote:
> 
> [...] having non-square pixels is not broken. If we go this route, we 
> might as well get rid of the distinction all together.

I think you may misunderstand what the attribute is for. It's only 
intended as an override for broken video files that don't have the correct 
pixel aspect ratio in the first place.


On Wed, 15 Oct 2008, Sander van Zoest wrote:
> 
> Following that logic, why add the attribute at all? If it is going to be 
> wrong, and require guessing to the nearest fraction by the user agent. 
> It is rarely going to be used. Why not just force people to transcode 
> the content to make it work correctly? Have them put it in a Ogg 
> container while they are at it?

This is intended to be a quick fix attribute for cases where the video is 
under someone else's control, e.g. if a blog wants to embed a YouTube 
video file that has the wrong ratio.


On Wed, 15 Oct 2008, Eric Carlson wrote:
>
> I agree that incorrectly encoded videos are annoying, but I don't think 
> we should have this attribute at all because I don't think it passes the 
> "will it be commonly used" smell test.
> 
> I am also afraid that it will difficult to use correctly, since you 
> frequently have to use clean aperture in conjunction with pixel aspect 
> ratio to get the correct display size.

For the videos we're talking about, just getting near the right ratio is 
probably all we can ask for -- we're not talking about professional video 
data here. We're talking misencoded YouTube videos where an embedder wants 
to fix the most egregious error before showing his friends the cat jumping 
off the side of the pool or something.

I agree that this is just a hack attribute, and I agree that it isn't 
going to be widely used. But I think it will be used enough to justify its 
existence. There are a surprisingly large number of misencoded videos on 
the Web, and plenty of people who care.


On Wed, 15 Oct 2008, Sander van Zoest wrote:
> 
> Certainly not. I forgot about the required crop. I am now even more 
> convinced it doesn't belong in the spec. Let the container handle this 
> detail.

Ideally it would; this is just intended for the case where it failed.

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


From jonas at sicking.cc  Thu Nov 13 20:43:54 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 13 Nov 2008 20:43:54 -0800
Subject: [whatwg] Workers feedback
In-Reply-To: <Pine.LNX.4.62.0811140136410.1041@hixie.dreamhostps.com>
References: <28040fc60811121133q3b52d4cdtde10501bd9daaa7d@mail.gmail.com>	<Pine.LNX.4.62.0811122339590.1237@hixie.dreamhostps.com>	<491CD16F.30706@arc.net.au>
	<Pine.LNX.4.62.0811140136410.1041@hixie.dreamhostps.com>
Message-ID: <491D020A.9030208@sicking.cc>

Ian Hickson wrote:
> On Fri, 14 Nov 2008, Shannon wrote:
>> I don't see any value in the "user-agent specified amount of time" delay 
>> in stopping scripts. How can you write cleanup code when you have no 
>> consistency in how long it gets to run (or if it runs at all)?
> 
> The "user-agent specified amount of time" delay is implemented by every 
> major browser for every script they run today.
> 
> How can people write clean code when they have no consistency in how long 
> their scripts will run (or if they will run at all)?
> 
> Why is this any different?

For what it's worth we set all "user-agent specified amount of time" 
times as close to 0 as we can in our implementation. There's always a 
tiny amount of delay in cross-thread communication, in the order of 
fractions of a second.

>> The specification for message ports is still limited to strings. If no 
>> effort is going to be made to allow numbers, arrays, structs and binary 
>> data then I'd suggest Workers be given functions to 
>> serialise/deserialise these objects.
> 
> We're going to add "JSON-serialisable data" support in due course. I'd 
> rather get the rest of the API nailed down first though.

For what it's worth we support the ECMAScript JSON object inside the 
worker (along with things like Math and Date) which means that you can 
manually JSON-ify you objects when communicating.

>> WorkerUtils does not implement document.cookie. I imagine this would be 
>> very useful in conjunction with cleanup code to flag if a cleanup 
>> operation failed to complete. Storage and Database interfaces are too 
>> heavy for the purpose of simple data like this.
> 
> It's not clear which document the cookie would be for. localStorage is 
> as light-weight than cookies (lighter-weight, arguably), though, so that 
> should be enough, no?

If you really need cookie information you can always call postMessage 
and ask for it.

Actually, i think we should remove the location accessor as well. I 
can't think of a common enough use case that warrants an explicit API. 
You can always transfer the data through postMessage.

/ Jonas


From ian at hixie.ch  Thu Nov 13 20:44:20 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 14 Nov 2008 04:44:20 +0000 (UTC)
Subject: [whatwg] Combining the DedicatedWorker and
	SharedWorker	interfaces
In-Reply-To: <491D0079.2060505@sicking.cc>
References: <278fd46c0811032308j628ed10au92a6f948389628fb@mail.gmail.com> 
	<4910C8AF.3000404@sicking.cc>
	<F663827F-B945-4254-B37E-48419938D9C4@webkit.org>
	<278fd46c0811051206w609d524dy3b01dc6a812c4a11@mail.gmail.com> 
	<ADFDC6FD-9323-4784-93B7-452DDE514500@webkit.org>
	<491229C8.8080205@sicking.cc>
	<AD719EFA-2C8C-42C3-8CE9-226E3F7C4F3B@webkit.org> 
	<63df84f0811130212n3462ae98tc975f8557cf64d4@mail.gmail.com>
	<278fd46c0811131253p3357f223uf54ff2e655a9cf1d@mail.gmail.com>
	<491CA84A.6020005@sicking.cc>
	<3ABCAB85-91D0-42C6-BBDF-84656A026A12@webkit.org>
	<491D0079.2060505@sicking.cc>
Message-ID: <Pine.LNX.4.62.0811140440420.1041@hixie.dreamhostps.com>

On Thu, 13 Nov 2008, Jonas Sicking wrote:
> 
> Honestly I'm not really sure why the spec says that you need a list at 
> all, other than maybe to talk about GC (which i've many times mentioned 
> I think the spec should not need to "define").

I remembered what it was that I was trying to remember the last time we 
spoke about this -- the case that the spec is trying to define that