From jonas at sicking.cc  Mon Dec  1 00:10:26 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 1 Dec 2008 00:10:26 -0800
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <492FCF33.70203@lachy.id.au>
References: <op.tlq7qta564w2qv@id-c0020> <op.tw9073vw7a8kvn@hp-a0a83fcd39d2>
	<46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
	<48641CBB.8010204@sicking.cc>
	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>
	<492DA279.1070207@sicking.cc> <492FCF33.70203@lachy.id.au>
Message-ID: <63df84f0812010010p2047b309h6bcebce4d05312cb@mail.gmail.com>

On Fri, Nov 28, 2008 at 3:00 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Jonas Sicking wrote:
>>
>> Ian Hickson wrote:
>>>
>>> On Thu, 26 Jun 2008, Jonas Sicking wrote:
>>>>
>>>> What I did notice in our code though is how we deal with the case when
>>>> there are multiple <map>s with the same name. In this case we generally use
>>>> the first <map>. But if the first <map> is empty, we use the first non-empty
>>>> <map>. This was done for compatibility with some sites. See
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=264624
>>>>
>>>> I have no idea if this matters today or not.
>>>
>>> I couldn't reproduce this behavior.
>>
>> Try the following markup in firefox:
>>
>> <map name="foo"></map>
>> <map name="foo">
>>  <area shape=circle coords="10,10,10" href="http://www.mozilla.com">
>> </map>
>> <img src="http://www.mozilla.org/images/feature-logos1.png"
>>     usemap="#foo" width="20" height="20">
>
> This only seems to occur in quirks mode, not in standards mode.  But neither
> Opera, Safari or IE8 have the same behaviour.  Additionally, the site
> reported in the bug you mentioned no longer suffers from the bug. Therefore,
> it doesn't appear to be necessary that we should require that behaviour.

Ah, it does indeed only happen in quirks mode (ugh, i hate it when
quirks mode things spread into code that I work on ;) ). If no other
browser is doing it in standards mode either I'm more than happy to
not have it in the spec.

/ Jonas


From jonas at sicking.cc  Mon Dec  1 00:28:34 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 1 Dec 2008 00:28:34 -0800
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<4831FB7C14654D82B37CFB56FDE4D58B@POCZTOWIEC>
	<Pine.LNX.4.62.0811140407090.1237@hixie.dreamhostps.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
Message-ID: <63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>

On Sun, Nov 30, 2008 at 11:05 PM, Chris Double
<chris.double at double.co.nz> wrote:
> On Mon, Dec 1, 2008 at 7:11 PM, Peter Kasting <pkasting at google.com> wrote:
>> I don't think it is the end of the world if this attribute goes in, but I
>> see very little benefit to it, and I am always for removing items with
>> marginal utility.
>
> I'm inclined to agree. I think it's odd that an attribute is being
> added to fix video's encoded incorrectly. Why can't the author of the
> video fix the actual video?
>
> One of the arguments for captions being embedded in video's rather
> than having some way of defining captions by the page author was that
> it's important not to use HTML to fix broken videos, and allow
> captions to travel with the file. The same argument could be made for
> pixel ratio. Fixing it in the HTML means everyone linking to the file
> using <video> will need to remember to add pixelratio to their HTML.
> Better to fix the file.
>
> Can someone provide examples of videos on the web that are currently
> broken, and a pixel ratio that would fix it? As an HTML author that
> wants to embed a video on my website I don't think I'd have any idea
> how to come up with a pixel ratio to fix it.

Another thing, if I as a website developer find a video that was
encoded with the wrong pixel ratio, wouldn't the simplest, and most
intuitive, way to fix it be to simply set a width and height on video
until it looked approximately correct? Yes, it's a hack, and should
not discouraged, but so is pixelratio.

(haven't followed this discussion in detail so appologies if
width/height has been disqualified already)

/ Jonas


From pentasis at lavabit.com  Mon Dec  1 00:28:56 2008
From: pentasis at lavabit.com (Pentasis)
Date: Mon, 1 Dec 2008 10:28:56 +0200
Subject: [whatwg] Question regarding accessibility for img
In-Reply-To: <4932F001.2010801@googlemail.com>
References: <AD48EFCEB13D43A19146E9FFD7A7F9AD@Sanktum01>
	<E31C3362-612D-420A-AFB3-1A2107872BA0@googlemail.com>
	<4932F001.2010801@googlemail.com>
Message-ID: <6F6ECDCAE06B43C4B76598018ED31D94@Sanktum01>

From: "Benjamin Hawkes-Lewis" <bhawkeslewis at googlemail.com>
To: "Geoffrey Sneddon" <foolistbar at googlemail.com>
Cc: "Pentasis" <pentasis at lavabit.com>; <whatwg at lists.whatwg.org>
Sent: Sunday, November 30, 2008 9:56 PM
Subject: Re: [whatwg] Question regarding accessibility for img


> Geoffrey Sneddon wrote:
>>
>> On 30 Nov 2008, at 16:40, Pentasis wrote:
>>
>>> I notice that it says in the spec under the img-section:
>>>
>>> "There has been some suggestion that the longdesc attribute from HTML4, 
>>> or some other mechanism that is more powerful than alt="", should be 
>>> included. This has not yet been considered."
>>>
>>> May I ask why it has not been considered (yet)?
>>
>> Because there's an issues list of several thousand issues, and as such 
>> not all issues have been considered. If we could do everything at once 
>> we'd have a spec instantly. :)
>
> Perhaps also worth noting that there's already been a quite epic amount of 
> discussion of LONGDESC, if you care to search the archives. I suppose the 
> text might be more accurate if it said "yet been decided".
>
> A rough summary of the currently dominant view in WHATWG would be that 
> visible descriptions are more useful than invisible descriptions and that 
> in any case LONGDESC is poisoned by real-world abuse ( 
> http://blog.whatwg.org/the-longdesc-lottery ).
>
> --
> Benjamin Hawkes-Lewis

Just a random thought (not a major discussion point afaic):
As I understand it, "best-practice" would now dictate that the image is 
simply explained in the actual content. I agree with this on the most part, 
but I can image the explanation and the image being seperated in "distance" 
from each other. Would it be helpfull for screenreaders to include a 
anchor-point on the image that points towards the explanatory text in such 
cases (which COULD be done with the longdesc), or would you think that be 
overkill?

Bert 




From ian at hixie.ch  Mon Dec  1 00:36:01 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 08:36:01 +0000 (UTC)
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <63df84f0812010010p2047b309h6bcebce4d05312cb@mail.gmail.com>
References: <op.tlq7qta564w2qv@id-c0020> <op.tw9073vw7a8kvn@hp-a0a83fcd39d2>
	<46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
	<48641CBB.8010204@sicking.cc>
	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>
	<492DA279.1070207@sicking.cc> <492FCF33.70203@lachy.id.au>
	<63df84f0812010010p2047b309h6bcebce4d05312cb@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812010835440.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008, Jonas Sicking wrote:
> >>
> >> Try the following markup in firefox:
> >>
> >> <map name="foo"></map>
> >> <map name="foo">
> >>  <area shape=circle coords="10,10,10" href="http://www.mozilla.com">
> >> </map>
> >> <img src="http://www.mozilla.org/images/feature-logos1.png"
> >>     usemap="#foo" width="20" height="20">
> >
> > This only seems to occur in quirks mode, not in standards mode.  But neither
> > Opera, Safari or IE8 have the same behaviour.  Additionally, the site
> > reported in the bug you mentioned no longer suffers from the bug. Therefore,
> > it doesn't appear to be necessary that we should require that behaviour.
> 
> Ah, it does indeed only happen in quirks mode (ugh, i hate it when 
> quirks mode things spread into code that I work on ;) ). If no other 
> browser is doing it in standards mode either I'm more than happy to not 
> have it in the spec.

The spec is including quirks-mode requirements; do other browsers do it in 
quirks mode?

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


From ian at hixie.ch  Mon Dec  1 00:37:18 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 08:37:18 +0000 (UTC)
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<4831FB7C14654D82B37CFB56FDE4D58B@POCZTOWIEC>
	<Pine.LNX.4.62.0811140407090.1237@hixie.dreamhostps.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008, Jonas Sicking wrote:
> 
> Another thing, if I as a website developer find a video that was encoded 
> with the wrong pixel ratio, wouldn't the simplest, and most intuitive, 
> way to fix it be to simply set a width and height on video until it 
> looked approximately correct? Yes, it's a hack, and should not 
> discouraged, but so is pixelratio.
> 
> (haven't followed this discussion in detail so appologies if 
> width/height has been disqualified already)

width/height on <video> doesn't stretch, so that you can play videos of 
varying aspect ratios in the same surface without rendering issues.

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


From jonas at sicking.cc  Mon Dec  1 01:09:17 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 1 Dec 2008 01:09:17 -0800
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
Message-ID: <63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>

On Mon, Dec 1, 2008 at 12:37 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 1 Dec 2008, Jonas Sicking wrote:
>>
>> Another thing, if I as a website developer find a video that was encoded
>> with the wrong pixel ratio, wouldn't the simplest, and most intuitive,
>> way to fix it be to simply set a width and height on video until it
>> looked approximately correct? Yes, it's a hack, and should not
>> discouraged, but so is pixelratio.
>>
>> (haven't followed this discussion in detail so appologies if
>> width/height has been disqualified already)
>
> width/height on <video> doesn't stretch, so that you can play videos of
> varying aspect ratios in the same surface without rendering issues.

Ah, makes sense. Wasn't there once upon a time a CSS draft that let
you specify how replaced elements should stretch in situations like
this? So you could choose if it should zoom-to-fit (like it sounds
like <video> does) or stretch-to-fit (like <img> does), zoom-to-fill
as well as a few other things. I can't seem to find it though...

I guess my point is, can we let CSS deal with this? If it indeed needs
to be dealt with.

/ Jonas


From ian at hixie.ch  Mon Dec  1 02:15:26 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 10:15:26 +0000 (UTC)
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com> 
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com> 
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com> 
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com> 
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com> 
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com> 
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com> 
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com> 
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com> 
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>

On Sun, 30 Nov 2008, Peter Kasting wrote:
> >
> > I don't understand why this attribute would cause problems. Can you 
> > elaborate?
> 
> * Authors specify the wrong ratio, causing videos to look worse * 
> Authors, blindly copy-and-pasting, believe this attribute is required 
> and specify it everywhere, increasing the likelihood of both of these 
> bullet points
> 
> If you think the likelihood of the first bullet is low, consider the 
> confusion evident on this thread, and then extend that to authors who 
> have even less of a clue.  The attribute is confusing because your 
> intended use -- as a hack that people shouldn't use -- is confusing.
> 
> Videos encoded at the wrong aspect ratio are a real problem, but they 
> are one of an extremely large number of real problems, most of which we 
> (rightly) are not trying to solve.  I think you have given a few reasons 
> why we _aren't_ trying to solve others.  I don't understand why we're 
> trying to solve this one.
> 
> I don't think it is the end of the world if this attribute goes in, but 
> I see very little benefit to it, and I am always for removing items with 
> marginal utility.

On Mon, 1 Dec 2008, Chris Double wrote:
> 
> I'm inclined to agree. I think it's odd that an attribute is being added 
> to fix video's encoded incorrectly. Why can't the author of the video 
> fix the actual video?
> 
> One of the arguments for captions being embedded in video's rather than 
> having some way of defining captions by the page author was that it's 
> important not to use HTML to fix broken videos, and allow captions to 
> travel with the file. The same argument could be made for pixel ratio. 
> Fixing it in the HTML means everyone linking to the file using <video> 
> will need to remember to add pixelratio to their HTML. Better to fix the 
> file.

On Mon, 1 Dec 2008, Jonas Sicking wrote:
> 
> Ah, makes sense. Wasn't there once upon a time a CSS draft that let you 
> specify how replaced elements should stretch in situations like this? So 
> you could choose if it should zoom-to-fit (like it sounds like <video> 
> does) or stretch-to-fit (like <img> does), zoom-to-fill as well as a few 
> other things. I can't seem to find it though...
> 
> I guess my point is, can we let CSS deal with this? If it indeed needs 
> to be dealt with.

Fair enough. I've removed the pixelratio attribute.

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


From ian at hixie.ch  Mon Dec  1 02:28:57 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 10:28:57 +0000 (UTC)
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
Message-ID: <Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>

On Sun, 23 Nov 2008, Maik Merten wrote:
> 
> currently seeking in the media elements is done by manipulating the 
> currentTime attribute. This expects an absolute time offset in seconds. 
> This works fine as long as the duration (in absolute time) of the media 
> file is known and doesn't work at all in other cases.

For non-infinite streams, the duration is defined to be known. That is, 
the user agent is required to find the duration and set the "duration" 
attribute accordingly.


> Some media formats don't store the duration of the media file anywhere. 
> A client can only determine the duration of the media file by 
> byte-seeking near the end of the file and finding a timestamp near/at 
> the end. This isn't a problem whatsoever on local files, but in remote 
> setups this puts additional load on the server and the connection. If 
> one would like to avoid this, meaning no duration is known, seeking in 
> absolute time cannot work.

One is not allowed to avoid this per spec today, short of using a codec 
that doesn't have this problem.


> While getting the absolute duration is often a problem retrieving the 
> length of the media file is is no problem. I propose seeking with 
> relative positions, e.g. values between zero and one. This way the 
> client can determine if to seek in absolute time (if the duration is 
> known) or to just jump into to a position of the bytestream (if the 
> length in bytes is known).

You can jump to a position that's a fraction of the whole clip by setting 
'currentTime' to a fractional multiple of 'duration'.


>  - make currentTime readonly, still have it report playback position in 
> absolute time. This information should be available in all media formats 
> due to timestamps in the stream.
> 
>  - introduce a seek() method, taking a relative value ranging from zero 
> to one. This allows both accurate seeking if the duration is known and 
> less precise seeking otherwise if only the length of the file is known 
> in storage units. This is still way better than not being able to seek 
> at all.

Why should currentTime be readonly?


>  - make duration report either the duration in absolute time (if known) 
> or the length of the file in storage units. This enables computation of 
> a relative playback position even when no duration is known, if the byte 
> position of the stream is known (low precision fallback - still better 
> than nothing at all).

The duration in absolute time is required to be determined before the 


>  - introduce a readonly storagePosition attribute. Meant to compute a 
> relative position if the duration is only known in storage units.

We just got rid of bufferingBytes and totalBytes because browser vendors 
want to return times only, not data based on bytes.


On Sun, 23 Nov 2008, Eric Carlson wrote:
> 
> Reporting the absolute time of the current sample won't help when the 
> first sample of the file doesn't have a timestamp of zero. It will be 
> even more confusing for files with portions removed or added without 
> fixing time stamps - for example a movie created by concatenating 
> different files.

The spec is written with the assumption that all the offsets of the 
resource have unique timestamps, and that the timestamps are in monotonic 
increasing order without discontinuous jumps, but it doesn't assume that 
the initial position is zero.

Should I put a requirement in the spec to the effect that discontinuous or 
duplicate timelines must be normalised in some way?


> As I noted when this subject came up a few weeks ago, the right way to 
> deal with media formats that don't store duration is to estimate the 
> duration of the whole file by extrapolating from the known, exact, 
> duration of the portion(s) that have been processed. While the initial 
> estimate won't always be correct for variable bit-rate formats, the 
> estimate will become more and more accurate as it is iteratively refined 
> by processing more media data. The spec defines the "durationchange" for 
> just exactly this scenario.

Indeed.


On Mon, 24 Nov 2008, Silvia Pfeiffer wrote:
> 
> I don't see addition of a duration attribute as much of a problem. We 
> have width and height for images, and sizes for fonts, too, and web 
> developers have learnt how to deal with these in various entities (px, 
> em, pt). I would not have a problem giving web developers the 
> opportunity to report the real duration of a video in an attribute in 
> either bytes or seconds (might be better called: length), which would 
> allow a renderer to display an accurate timeline. It is help for a 
> display mechanism just as width and height are.
> 
> In case of contradiction between the attribute and the actual decoded 
> length, a renderer can still override the length attribute at the time 
> the real length is known. In case of contradiction between the attribute 
> and the estimated length of a video, the renderer should make a call 
> based on the probability of the estimate being correct.
> 
> In may in fact be rather confusing to users if a video player keeps 
> changing the duration of a video file as it plays it back.
> 
> I think such an attribute can help get this right earlier.

If we had kept pixelratio="", duration="" might make some sense (maybe, 
though I am still a little skeptical). But with the removal of 
pixelratio="", there's really no parallel for duration="". It seems to me 
that the UAs can do a fine job estimating the duration in the cases where 
it's necessary.

Frankly, I'd rather just that the video data included the duration. It 
seems a bit weird for a video resource to not know its own length. It 
would be a bit like an image file not self-describing its dimensions, and 
just having the decoder work it out based on some markers at the end of 
each line of pixels.


On Sun, 23 Nov 2008, Eric Carlson wrote:
>
> In the case of a file with video or VBR audio the true duration 
> literally isn't actually known until *every* frame has been examined.
> 
> When would you have the UA decide to switch from the attribute to the to 
> the real duration? What would you have the UA do if the user seeks to 
> time 90 seconds when attribute says a file is 100 seconds long, but the 
> file actually has a duration of 80?

What would the UA do to know it has a duration of 80s? Would it have to 
read the whole file?

If so, why can't the UA just seek to the end (and read every frame), get 
the duration, and just be done with it?


On Tue, 25 Nov 2008, Silvia Pfeiffer wrote:
> 
> The browser would need to have it's own estimate of reliability of the 
> length attribute. If there is a high probability that the length 
> attribute is wrong, e.g. we have already played beyond the given length, 
> or we have obviously too much data to decode for the given length, it 
> would ignore the length attribute. I would however hope that web 
> developers generally test their pages and the length attribute to make 
> sure the display is correct. If that data is provided through a CMS, 
> then the information should be correct anyway.

My experience with content on the Web suggests you are optimistic. :-)


On Mon, 24 Nov 2008, Dave Singer wrote:
>
> I don't think you mean 'relative' here, which I would take to be "go 
> forward 10 seconds", but 'proportional', "please go to 60% of the way 
> through".
> 
> IF we are to do this, I would have thought it would be by adding units 
> to the "where to seek to" argument:
> 
> * go to this time in NPT (normal play time, which runs from 0 to media
> duration)
> * go to this SMPTE time code
> * go by this relative distance in NPT times
> 
> * go to this proportional time
> * go to this proportional byte distance
> * go by this relative byte distance

Woah. Not in v1.


> Note that proportional distances are not well defined for some streams 
> (e.g. indefinite ones).
> 
> We'd have to define what bytes are counted and what aren't, especially 
> if a URL offers a set of sub-streams only some of which a client would 
> normally choose to have sent to it for playing.

These are other good reasons not to have a byte-based seeking mechanism.


On Tue, 25 Nov 2008, Silvia Pfeiffer wrote:
> 
> Live streams are somewhat bad to deal with anyway, because a timeline is 
> badly defined on such. All you could really do is show the past and have 
> a "continues" pointer at the end. Most live streams (e.g. the recent 
> YouTube live concert) simply don't show a timeline and disallow people 
> to jump around in the presentation.

The API defined in the HTML5 spec seems to support such streams fine. It 
even allows the UA to start dropping data at the start of the buffer. 
Effectively, it works like a TiVo.


On Tue, 25 Nov 2008, Maik Merten wrote:
> 
> This applet does not seek to the end of the stream to retrieve a 
> timestamp there.

It should. :-)


On Wed, 26 Nov 2008, Chris Double wrote:
> 
> I won't be estimating the duration - the user experience of a 
> fluctuating duration is terrible. For now for Ogg files, I'm seeking to 
> the end and getting the duration. I may check for X-Content-Duration 
> which I believe mod_annodex and soon oggz-chop support.

Cool.


> For the few servers that don't support seeking, duration is not 
> available.

Note that that is non-conforming at the moment. You have to have a 
duration available (though it can be +Infinity if you think that the 
resource is a stream, and can be an estimate, so long as you keep updating 
it as your information gets better.)

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


From lachlan.hunt at lachy.id.au  Mon Dec  1 02:57:07 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Mon, 01 Dec 2008 11:57:07 +0100
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <Pine.LNX.4.62.0812010835440.17401@hixie.dreamhostps.com>
References: <op.tlq7qta564w2qv@id-c0020>
	<op.tw9073vw7a8kvn@hp-a0a83fcd39d2>	<46C973D5.6020704@sicking.cc>	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>	<46CA29B5.6080101@sicking.cc>	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>	<48641CBB.8010204@sicking.cc>	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>	<492DA279.1070207@sicking.cc>
	<492FCF33.70203@lachy.id.au>	<63df84f0812010010p2047b309h6bcebce4d05312cb@mail.gmail.com>
	<Pine.LNX.4.62.0812010835440.17401@hixie.dreamhostps.com>
Message-ID: <4933C303.30505@lachy.id.au>

Ian Hickson wrote:
> On Mon, 1 Dec 2008, Jonas Sicking wrote:
>>>> Try the following markup in firefox:
>>>>
>>>> <map name="foo"></map>
>>>> <map name="foo">
>>>>  <area shape=circle coords="10,10,10" href="http://www.mozilla.com">
>>>> </map>
>>>> <img src="http://www.mozilla.org/images/feature-logos1.png"
>>>>     usemap="#foo" width="20" height="20">
>>> 
>>> This only seems to occur in quirks mode, not in standards mode.  But neither
>>> Opera, Safari or IE8 have the same behaviour.  Additionally, the site
>>> reported in the bug you mentioned no longer suffers from the bug. Therefore,
>>> it doesn't appear to be necessary that we should require that behaviour.
>> 
>> Ah, it does indeed only happen in quirks mode (ugh, i hate it when 
>> quirks mode things spread into code that I work on ;) ). If no other 
>> browser is doing it in standards mode either I'm more than happy to not 
>> have it in the spec.
> 
> The spec is including quirks-mode requirements; do other browsers do it in 
> quirks mode?

As I already said above, "neither Opera, Safari or IE8 have the same 
behaviour."  I tested both quirks and standards mode.

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


From philipj at opera.com  Mon Dec  1 03:05:54 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 01 Dec 2008 12:05:54 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
Message-ID: <1228129554.8038.9.camel@localhost>

Now that the pixelratio override is gone, shouldn't the influence of
pixel aspect ratio on the layout be removed also? I would prefer if the
default were to stretch to fit if both width/height are given, just like
for img. Letterboxing/pillarboxing should be the special case, is the
idea that we should have the equivalent of SVG:s preserveAspectRatio
either via CSS or HTML?

Philip

On Mon, 2008-12-01 at 10:15 +0000, Ian Hickson wrote:
> On Sun, 30 Nov 2008, Peter Kasting wrote:
> > >
> > > I don't understand why this attribute would cause problems. Can you 
> > > elaborate?
> > 
> > * Authors specify the wrong ratio, causing videos to look worse * 
> > Authors, blindly copy-and-pasting, believe this attribute is required 
> > and specify it everywhere, increasing the likelihood of both of these 
> > bullet points
> > 
> > If you think the likelihood of the first bullet is low, consider the 
> > confusion evident on this thread, and then extend that to authors who 
> > have even less of a clue.  The attribute is confusing because your 
> > intended use -- as a hack that people shouldn't use -- is confusing.
> > 
> > Videos encoded at the wrong aspect ratio are a real problem, but they 
> > are one of an extremely large number of real problems, most of which we 
> > (rightly) are not trying to solve.  I think you have given a few reasons 
> > why we _aren't_ trying to solve others.  I don't understand why we're 
> > trying to solve this one.
> > 
> > I don't think it is the end of the world if this attribute goes in, but 
> > I see very little benefit to it, and I am always for removing items with 
> > marginal utility.
> 
> On Mon, 1 Dec 2008, Chris Double wrote:
> > 
> > I'm inclined to agree. I think it's odd that an attribute is being added 
> > to fix video's encoded incorrectly. Why can't the author of the video 
> > fix the actual video?
> > 
> > One of the arguments for captions being embedded in video's rather than 
> > having some way of defining captions by the page author was that it's 
> > important not to use HTML to fix broken videos, and allow captions to 
> > travel with the file. The same argument could be made for pixel ratio. 
> > Fixing it in the HTML means everyone linking to the file using <video> 
> > will need to remember to add pixelratio to their HTML. Better to fix the 
> > file.
> 
> On Mon, 1 Dec 2008, Jonas Sicking wrote:
> > 
> > Ah, makes sense. Wasn't there once upon a time a CSS draft that let you 
> > specify how replaced elements should stretch in situations like this? So 
> > you could choose if it should zoom-to-fit (like it sounds like <video> 
> > does) or stretch-to-fit (like <img> does), zoom-to-fill as well as a few 
> > other things. I can't seem to find it though...
> > 
> > I guess my point is, can we let CSS deal with this? If it indeed needs 
> > to be dealt with.
> 
> Fair enough. I've removed the pixelratio attribute.
> 
-- 
Philip J?genstedt
Opera Software



From ian at hixie.ch  Mon Dec  1 03:26:11 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 11:26:11 +0000 (UTC)
Subject: [whatwg] Video metadata attributes clarification
In-Reply-To: <20081125021220.GC26161@flim.org>
References: <20081125021220.GC26161@flim.org>
Message-ID: <Pine.LNX.4.62.0812011125160.17414@hixie.dreamhostps.com>

On Tue, 25 Nov 2008, Matthew Gregan wrote:
> 
> I'm seeking clarification on when the videoWidth and videoHeight 
> attributes are expected to become valid.  Actually it'd probably be 
> useful to have all of the "metadata attributes" listed explicitly 
> somewhere so that it's clear exactly what is expected to be valid when 
> readyState is HAVE_METADATA.

I've revamped the requirements around that section to make it clearer.

Please let me know if there are still ambiguities.

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


From ian at hixie.ch  Mon Dec  1 04:37:03 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 12:37:03 +0000 (UTC)
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <4933C303.30505@lachy.id.au>
References: <op.tlq7qta564w2qv@id-c0020> <op.tw9073vw7a8kvn@hp-a0a83fcd39d2>
	<46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
	<48641CBB.8010204@sicking.cc>
	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>
	<492DA279.1070207@sicking.cc> <492FCF33.70203@lachy.id.au>
	<63df84f0812010010p2047b309h6bcebce4d05312cb@mail.gmail.com>
	<Pine.LNX.4.62.0812010835440.17401@hixie.dreamhostps.com>
	<4933C303.30505@lachy.id.au>
Message-ID: <Pine.LNX.4.62.0812011236140.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008, Lachlan Hunt wrote:
> Ian Hickson wrote:
> > On Mon, 1 Dec 2008, Jonas Sicking wrote:
> > > > > Try the following markup in firefox:
> > > > > 
> > > > > <map name="foo"></map>
> > > > > <map name="foo">
> > > > >  <area shape=circle coords="10,10,10" href="http://www.mozilla.com">
> > > > > </map>
> > > > > <img src="http://www.mozilla.org/images/feature-logos1.png"
> > > > >     usemap="#foo" width="20" height="20">
> > > > 
> > > > This only seems to occur in quirks mode, not in standards mode.  But
> > > > neither
> > > > Opera, Safari or IE8 have the same behaviour.  Additionally, the site
> > > > reported in the bug you mentioned no longer suffers from the bug.
> > > > Therefore,
> > > > it doesn't appear to be necessary that we should require that behaviour.
> > > 
> > > Ah, it does indeed only happen in quirks mode (ugh, i hate it when quirks
> > > mode things spread into code that I work on ;) ). If no other browser is
> > > doing it in standards mode either I'm more than happy to not have it in
> > > the spec.
> > 
> > The spec is including quirks-mode requirements; do other browsers do it in
> > quirks mode?
> 
> As I already said above, "neither Opera, Safari or IE8 have the same
> behaviour."  I tested both quirks and standards mode.

In that case, it truly seems like something where Gecko should just be 
simplified.

Jonas: are there pages that depend on this? If we could remove that quirk, 
that'd be awesome...

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


From ian at hixie.ch  Mon Dec  1 04:39:29 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 12:39:29 +0000 (UTC)
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <1228129554.8038.9.camel@localhost>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com> 
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com> 
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com> 
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com> 
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com> 
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com> 
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com> 
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com> 
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com> 
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com> 
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com> 
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
Message-ID: <Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008, Philip J?genstedt wrote:
>
> Now that the pixelratio override is gone, shouldn't the influence of 
> pixel aspect ratio on the layout be removed also?

It is, isn't it? What did I leave in?


> I would prefer if the default were to stretch to fit if both 
> width/height are given, just like for img. Letterboxing/pillarboxing 
> should be the special case, is the idea that we should have the 
> equivalent of SVG:s preserveAspectRatio either via CSS or HTML?

We definitely don't want to stretch the video. One of the important use 
cases if having a video playback area and then playing videos with 
different aspect ratios in that playback area. It should all just work.

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

From maikmerten at googlemail.com  Mon Dec  1 05:06:36 2008
From: maikmerten at googlemail.com (Maik Merten)
Date: Mon, 01 Dec 2008 14:06:36 +0100
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
Message-ID: <4933E15C.9000303@googlemail.com>

Ian Hickson schrieb:
> You can jump to a position that's a fraction of the whole clip by setting 
> 'currentTime' to a fractional multiple of 'duration'.

Right, I was thinking of what happens if no duration could be determined 
with acceptable effort. However, by now I happen to think that 
determining the duration where possible (even if its not completely 
straightforward) is useful enough to require it.


>>  - make currentTime readonly, still have it report playback position in 
>> absolute time. This information should be available in all media formats 
>> due to timestamps in the stream.
>>
>>  - introduce a seek() method, taking a relative value ranging from zero 
>> to one. This allows both accurate seeking if the duration is known and 
>> less precise seeking otherwise if only the length of the file is known 
>> in storage units. This is still way better than not being able to seek 
>> at all.
> 
> Why should currentTime be readonly?

Because seek() would already to trigger seeking (is there a different 
usecase for a writeable currentTime?). Anyway, I don't suggest paying 
attention to my proposals anymore - after some consideration and 
experimentation I don't think they improve anything ;-)

> On Tue, 25 Nov 2008, Maik Merten wrote:
>> This applet does not seek to the end of the stream to retrieve a 
>> timestamp there.
> 
> It should. :-)

And it now does :-)

http://svn.wikimedia.org/viewvc/mediawiki/trunk/cortado/src/com/fluendo/player/DurationScanner.java?view=log

Byte-position based estimates etc. etc. just didn't work out, so I 
finally gave in ( ;-) ) and wrote the ~200 lines of code to actually Do 
Things Approximately Properly(tm).

Seems I saw an implementation problem where none exists.


> 
> On Wed, 26 Nov 2008, Chris Double wrote:
>> I won't be estimating the duration - the user experience of a 
>> fluctuating duration is terrible. For now for Ogg files, I'm seeking to 
>> the end and getting the duration. I may check for X-Content-Duration 
>> which I believe mod_annodex and soon oggz-chop support.
> 
> Cool.

I now finally arrived at the same conclusions.


Maik


From j at oil21.org  Mon Dec  1 05:55:34 2008
From: j at oil21.org (j at oil21.org)
Date: Mon, 01 Dec 2008 14:55:34 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
Message-ID: <1228139734.6840.91.camel@BlackBook>

On Mon, 2008-12-01 at 12:39 +0000, Ian Hickson wrote:
> We definitely don't want to stretch the video. One of the important use 
> cases if having a video playback area and then playing videos with 
> different aspect ratios in that playback area. It should all just work.
why should this be different for images and video?
there are ways to center elements inside a "playback area".

how would i stretch a video if its always displayed in the aspect ratio
from the container, i.e. to have an animation where the video is a dot
first, than gets stretched to a thin 5 x 480 element and than unfolds to
its full dimensions 640x480.

+1 for stretch to fit if both width/height.

j




From philipj at opera.com  Mon Dec  1 08:04:35 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 01 Dec 2008 17:04:35 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
Message-ID: <1228147475.11030.53.camel@localhost>

On Mon, 2008-12-01 at 12:39 +0000, Ian Hickson wrote:
> On Mon, 1 Dec 2008, Philip Jgenstedt wrote:
> >
> > Now that the pixelratio override is gone, shouldn't the influence of 
> > pixel aspect ratio on the layout be removed also?
> 
> It is, isn't it? What did I leave in?

"Video content should be rendered inside the element's playback area
such that the video content is shown centered in the playback area at
the largest possible size that fits completely within it, with the video
content's aspect ratio being preserved. Thus, if the aspect ratio of the
playback area does not match the aspect ratio of the video, the video
will be shown letterboxed or pillarboxed. Areas of the element's
playback area that do not contain the video represent nothing."

> > I would prefer if the default were to stretch to fit if both 
> > width/height are given, just like for img. Letterboxing/pillarboxing 
> > should be the special case, is the idea that we should have the 
> > equivalent of SVG:s preserveAspectRatio either via CSS or HTML?
> 
> We definitely don't want to stretch the video. One of the important use 
> cases if having a video playback area and then playing videos with 
> different aspect ratios in that playback area. It should all just work.

I'm having a hard time seeing how this is a use case for video and not
for img. If one wants the intrinsic width/height to be used, then simply
don't set width/height. Otherwise, just setting just one of width/height
or using CSS max-width/max-height should do the trick.

This is strange:

<video src="circle.mpg" width="400" height="400"> <!-- circle -->
<video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->

<img src="circle.jpg" width="400" height="400"> <!-- circle -->
<img src="circle.jpg" width="400" height="300"> <!-- oval -->

I think it would be much more consistent if these elements behaved in
the same way. As it stands, after the pixelratio was removed, there is
no way to display a circle as an oval or vice versa, which means it is
both impossible to fix an incorrect aspect ratio or to stretch the video
for some other purpose.

So, what is the difference between images and moving images?

-- 
Philip J?genstedt
Opera Software



From alex.baldacchino at email.it  Mon Dec  1 08:27:01 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Mon, 01 Dec 2008 17:27:01 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	
	<4932C182.5010905@email.it>	
	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	
	<4932CC01.9010301@email.it>	
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	
	<4933547C.2010501@email.it>
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
Message-ID: <49341055.1030809@email.it>

Tab Atkins Jr. ha scritto:
> [[off list]]
>
>   
>> Well, in fact, the above could be done as well by 'playing' with anchors
>> (but is it still possible to set an anchor somewhere in the document, such
>> as <a id="foo" />? I haven't found examples for that, perhaps I'm missing
>> something...).
>>     
>
> Yes, a hash link (<a href="#foo">) will scroll to the element with an
> id=foo.  If coding properly, you'll virtually *never* use an <a> for
> an actual *anchor*, but rather will target the most semantically
> appropriate element, such as a heading or a container with the
> appropriate @id.
>
> ~TJ
>   
Thanks! That's what I was missing in the specicification (I should give 
it a more accurate reading). Does it applies to every element, covering 
the <cite> element too? If so, there is no need for new attribute to 
relate a quoted content to its cited source (especially to relate 
several quotations to a single, or a main, complete reference), 
something like:

<p>An interesting element is the <code>&lt;cite&gt;</code> element. It's 
definition is: <q cite="#cite">The |<code>cite</code>| element 
represents the title of a work (e.g. a book, a paper, an essay, a poem, 
a score, a song, a script, a film, a TV show, a game, a sculpture, a 
painting, a theatre production, a play, an opera, a musical, an 
exhibition, etc). This can be a work that is being quoted or referenced 
in detail (i.e. a citation), or it can just be a work that is mentioned 
in passing.</q></p>

<p>The <code>cite</code> element semantics finds a good placing inside a 
bibliographic citation, but only refers to the title of the work, not to 
the entire citation. In fact, it is sayd: <q cite="#cite">The 
|<code>cite</code>| element is obviously a key part of any citation in a 
bibliography, but it is only used to mark the title</q> [...]</p>
[...]
<p>A complete reference for the <code>cite</code> element is found in 
WHATWG <a 
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/"><cite>HTML 
5</cite></a> draft reccomendation, section <a 
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-cite-element"><cite 
id="cite">4.6.3 The <code>cite</code> element</cite></a>

should work fine, while in a scientific paper something like

...<a href="#whref">[whnt02]</a>...

might be an instance of:

<p><b>[whnt02]</b>: <cite id="whref">A new theory on White Holes: 
universe regeneration proved.</cite>, John Doe and Jack Someone, 2013, 
Science Paper Hall, IBAN:'example_iban_code'</p>

in a similar way as

... <a href="#jd">John Doe</a>...

is an instance of:

<p>The name <dfn id="jd">John Doe</dfn> is the one commonly used to 
indicate a person whose identity is unknown; may be found in some 
examples to indicate a generic person involved in some context, to 
indicate whoever else could be involved too, or to focus the attention 
on the context itself or its related subject, despite any real person 
involved or the likelyhood for the facts to happen.</p>

In conclusion, what I was suggesting is yet possible, if I'm not 
misanderstandig (again?), without any need for additional attributes. 
The reverse realtionship (from a <cite> to one or more 
<q>/<blockquote>), instead, might be more difficoult, but I agree with 
Ian Hickson that some 'real world' need should arise before addressing such.

BR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Meetic: il leader italiano ed europeo per trovare l'anima gemella online. Provalo ora
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8291&d=1-12


From lachlan.hunt at lachy.id.au  Mon Dec  1 09:19:38 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Mon, 01 Dec 2008 18:19:38 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <1228147475.11030.53.camel@localhost>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>	<1228129554.8038.9.camel@localhost>	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost>
Message-ID: <49341CAA.70001@lachy.id.au>

Philip J?genstedt wrote:
> On Mon, 2008-12-01 at 12:39 +0000, Ian Hickson wrote:
>> We definitely don't want to stretch the video. One of the important use 
>> cases if having a video playback area and then playing videos with 
>> different aspect ratios in that playback area. It should all just work.
> 
> I'm having a hard time seeing how this is a use case for video and not
> for img. If one wants the intrinsic width/height to be used, then simply
> don't set width/height. Otherwise, just setting just one of width/height
> or using CSS max-width/max-height should do the trick.
> 
> This is strange:
> 
> <video src="circle.mpg" width="400" height="400"> <!-- circle -->
> <video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->

This is effectively how YouTube behaves now with their recent change to 
a widescreen player.  It would look terrible if 4:3 videos were 
stretched to fill the 16:9 viewport, instead of just using black bars on 
the side.  Even before when they were still using a 4:3 player, 
widescreen videos were rendered as letterbox.

> <img src="circle.jpg" width="400" height="400"> <!-- circle -->
> <img src="circle.jpg" width="400" height="300"> <!-- oval -->
> 
> I think it would be much more consistent if these elements behaved in
> the same way.

What is the use case for wanting a video to be stretched?

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


From pol at apple.com  Mon Dec  1 12:14:54 2008
From: pol at apple.com (Pierre-Olivier Latour)
Date: Mon, 1 Dec 2008 12:14:54 -0800
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <49341CAA.70001@lachy.id.au>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au>
Message-ID: <CB464D8D-D081-4A3E-BE7E-8E620B1AD83A@apple.com>

>> <img src="circle.jpg" width="400" height="400"> <!-- circle -->
>> <img src="circle.jpg" width="400" height="300"> <!-- oval -->
>> I think it would be much more consistent if these elements behaved in
>> the same way.
>
> What is the use case for wanting a video to be stretched?


I can only think of the case when you need to post-fix a video which  
wasn't encoded with the proper pixel aspect ratio. And we already  
covered the likelihood of encountering this case extensively. So I  
guess what's left is purely a convention decision:
- should <video> behaves like <img> by default and have a special  
attribute to scale proportionally,
- or should <video> scale proportionally by default, and maybe have  
some way of defining a stretching behavior?

Eric & I would recommend the later because based on past experience,  
users often specify the wrong width & height for the element, and if  
we stretch by default, then we would often fall off the fast path of  
the media engine (scaling anamorphically can be very expensive). At  
the end of the day, being consistent with <img> wouldn't be worth the  
potential other issues.

Regarding the stretch attribute, we should have this functionally  
available to users but preferably at the CSS level.

________________________________
Pierre-Olivier Latour - pol at apple.com
Rich Media Team - Apple, Inc.






From mart at degeneration.co.uk  Mon Dec  1 12:23:36 2008
From: mart at degeneration.co.uk (Martin Atkins)
Date: Mon, 01 Dec 2008 12:23:36 -0800
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <CB464D8D-D081-4A3E-BE7E-8E620B1AD83A@apple.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>	<1228129554.8038.9.camel@localhost>	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>	<1228147475.11030.53.camel@localhost>
	<49341CAA.70001@lachy.id.au>
	<CB464D8D-D081-4A3E-BE7E-8E620B1AD83A@apple.com>
Message-ID: <493447C8.2030600@degeneration.co.uk>

Pierre-Olivier Latour wrote:
> 
> Regarding the stretch attribute, we should have this functionally 
> available to users but preferably at the CSS level.
> 

It would also be useful if this mechanism were available for images. A 
bunch of times I've written code to proportionally scale images to 
create smaller versions, and I'd much rather just set this with CSS.

This would also go some way to increase the consistency, since the 
difference between IMG and VIDEO would be merely a difference in the 
default stylesheet rules for each element.



From philipj at opera.com  Mon Dec  1 13:07:01 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 01 Dec 2008 22:07:01 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <49341CAA.70001@lachy.id.au>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost>  <49341CAA.70001@lachy.id.au>
Message-ID: <1228165621.7291.52.camel@localhost>

On Mon, 2008-12-01 at 18:19 +0100, Lachlan Hunt wrote:
> Philip J?genstedt wrote:
> > On Mon, 2008-12-01 at 12:39 +0000, Ian Hickson wrote:
> >> We definitely don't want to stretch the video. One of the important use 
> >> cases if having a video playback area and then playing videos with 
> >> different aspect ratios in that playback area. It should all just work.
> > 
> > I'm having a hard time seeing how this is a use case for video and not
> > for img. If one wants the intrinsic width/height to be used, then simply
> > don't set width/height. Otherwise, just setting just one of width/height
> > or using CSS max-width/max-height should do the trick.
> > 
> > This is strange:
> > 
> > <video src="circle.mpg" width="400" height="400"> <!-- circle -->
> > <video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->
> 
> This is effectively how YouTube behaves now with their recent change to 
> a widescreen player.  It would look terrible if 4:3 videos were 
> stretched to fill the 16:9 viewport, instead of just using black bars on 
> the side.  Even before when they were still using a 4:3 player, 
> widescreen videos were rendered as letterbox.

The strange part isn't that the video is pillarboxed, but that it's
impossible to not do it and that it's inconsistent with <img>.

> > <img src="circle.jpg" width="400" height="400"> <!-- circle -->
> > <img src="circle.jpg" width="400" height="300"> <!-- oval -->
> > 
> > I think it would be much more consistent if these elements behaved in
> > the same way.
> 
> What is the use case for wanting a video to be stretched?

The use case for stretching moving images (<video>) is exactly the same
as for stretching animations (<img src=animation.gif>) or static images
(<img src=static.jpg>). While I think that fixing incorrect aspect ratio
is the most probable use, consistency and generality is the real issue
here. With an image of size 800x600 it's possible to display at any
size, even those which don't match the aspect 4:3. With moving images
(video) we can't influence it at all.

The previous solution was the pixelratio attribute, but I have 2 other
possible solutions:

<video src="4x3.mpg" width="1920" height="1080" keepaspect>

The video would be pillarboxed.

<video src="4x3.mpg" width="1920" height="1080">

The video would be stretched and have incorrect aspect, just like

<img src="4x3.jpg" width="1920" height="1080">

This way it's easy to stretch or to keep aspect, whichever you want.

Given the number of people who watch 4:3 video stretched to a 16:9
display without even noticing/caring that the aspect ratio is wrong, I
don't think we can trust that the aspect ratio of all videos is always
going to be correctly encoded and simple say that this should be fixed
by reencoding the video -- that's not even an option if the source file
is not available and reencoding is good for quality.

But to reiterate, this is mainly about generality and consistency.

Are there any other suggestions? Could this perhaps be done with CSS so
that the same thing could be done with <img>? It is in fact rather
difficult to scale something to fit inside a box using only CSS right
now. It would be rather sad to see <img> and <video> be so inconsistent
when 

-- 
Philip J?genstedt
Opera Software



From philipj at opera.com  Mon Dec  1 13:13:14 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 01 Dec 2008 22:13:14 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <49341CAA.70001@lachy.id.au>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost>  <49341CAA.70001@lachy.id.au>
Message-ID: <1228165994.7291.58.camel@localhost>

Sorry, my 2:nd suggestion at the bottom...

On Mon, 2008-12-01 at 18:19 +0100, Lachlan Hunt wrote:
> Philip J?genstedt wrote:
> > On Mon, 2008-12-01 at 12:39 +0000, Ian Hickson wrote:
> >> We definitely don't want to stretch the video. One of the important use 
> >> cases if having a video playback area and then playing videos with 
> >> different aspect ratios in that playback area. It should all just work.
> > 
> > I'm having a hard time seeing how this is a use case for video and not
> > for img. If one wants the intrinsic width/height to be used, then simply
> > don't set width/height. Otherwise, just setting just one of width/height
> > or using CSS max-width/max-height should do the trick.
> > 
> > This is strange:
> > 
> > <video src="circle.mpg" width="400" height="400"> <!-- circle -->
> > <video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->
> 
> This is effectively how YouTube behaves now with their recent change to 
> a widescreen player.  It would look terrible if 4:3 videos were 
> stretched to fill the 16:9 viewport, instead of just using black bars on 
> the side.  Even before when they were still using a 4:3 player, 
> widescreen videos were rendered as letterbox.

The strange part isn't that the video is pillarboxed, but that it's
impossible to not do it and that it's inconsistent with <img>.

> > <img src="circle.jpg" width="400" height="400"> <!-- circle -->
> > <img src="circle.jpg" width="400" height="300"> <!-- oval -->
> > 
> > I think it would be much more consistent if these elements behaved in
> > the same way.
> 
> What is the use case for wanting a video to be stretched?

The use case for stretching moving images (<video>) is exactly the same
as for stretching animations (<img src=animation.gif>) or static images
(<img src=static.jpg>). While I think that fixing incorrect aspect ratio
is the most probable use, consistency and generality is the real issue
here. With an image of size 800x600 it's possible to display at any
size, even those which don't match the aspect 4:3. With moving images
(video) we can't influence it at all.

The previous solution was the pixelratio attribute, but I have 2 other
possible solutions:

<video src="4x3.mpg" width="1920" height="1080" keepaspect>

The video would be pillarboxed.

<video src="4x3.mpg" width="1920" height="1080">

The video would be stretched and have incorrect aspect, just like

<img src="4x3.jpg" width="1920" height="1080">

This way it's easy to stretch or to keep aspect, whichever you want.

Given the number of people who watch 4:3 video stretched to a 16:9
display without even noticing/caring that the aspect ratio is wrong, I
don't think we can trust that the aspect ratio of all videos is always
going to be correctly encoded and simple say that this should be fixed
by reencoding the video -- that's not even an option if the source file
is not available and reencoding is good for quality.

But to reiterate, this is mainly about generality and consistency.

Another way could be using CSS so that the same thing could be done
with <img>. It is in fact rather difficult to scale something to fit
inside a box using only CSS right now, so a general solution for it
would be nice. Possibly <video style="scaling:keep-aspect"> or
something like that? This way one could let the default value differ
between <img> and <video> if the aspect-preserving
(letterboxing/pillarboxing) is judged to be much more common than the
"aspect-fixing" mode.

Comments?

-- 
Philip J?genstedt
Opera Software



From philipj at opera.com  Mon Dec  1 13:19:27 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Mon, 01 Dec 2008 22:19:27 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <493447C8.2030600@degeneration.co.uk>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au>
	<CB464D8D-D081-4A3E-BE7E-8E620B1AD83A@apple.com>
	<493447C8.2030600@degeneration.co.uk>
Message-ID: <1228166367.11854.0.camel@localhost>

Well, it looks like you beat me to it, I should have read all the mail
before replying :)

Philip

On Mon, 2008-12-01 at 12:23 -0800, Martin Atkins wrote:
> Pierre-Olivier Latour wrote:
> > 
> > Regarding the stretch attribute, we should have this functionally 
> > available to users but preferably at the CSS level.
> > 
> 
> It would also be useful if this mechanism were available for images. A 
> bunch of times I've written code to proportionally scale images to 
> create smaller versions, and I'd much rather just set this with CSS.
> 
> This would also go some way to increase the consistency, since the 
> difference between IMG and VIDEO would be merely a difference in the 
> default stylesheet rules for each element.



From ian at hixie.ch  Mon Dec  1 14:06:06 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 22:06:06 +0000 (UTC)
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <1228165994.7291.58.camel@localhost>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com> 
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com> 
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com> 
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com> 
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com> 
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com> 
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com> 
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com> 
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com> 
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com> 
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com> 
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com> 
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost>  <49341CAA.70001@lachy.id.au>
	<1228165994.7291.58.camel@localhost>
Message-ID: <Pine.LNX.4.62.0812012155190.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008 j at oil21.org wrote:
>
> why should this be different for images and video?

Why should it be the same, other than consistency? I wouldn't make <img> 
stretch either if I was defining it today. Allowing stretching of images 
enabled a lot of problems, such as images at the wrong ratio, 
presentational use of images, etc.


> there are ways to center elements inside a "playback area".

Why makes things more complicated than necessary?


> how would i stretch a video if its always displayed in the aspect ratio 
> from the container, i.e. to have an animation where the video is a dot 
> first, than gets stretched to a thin 5 x 480 element and than unfolds to 
> its full dimensions 640x480.

Animations of that nature should be done either using SVG or CSS 
transforms, not at the HTML level.


On Mon, 1 Dec 2008, Philip J?genstedt wrote:
> > >
> > > Now that the pixelratio override is gone, shouldn't the influence of 
> > > pixel aspect ratio on the layout be removed also?
> > 
> > It is, isn't it? What did I leave in?
> 
> "Video content should be rendered inside the element's playback area 
> such that the video content is shown centered in the playback area at 
> the largest possible size that fits completely within it, with the video 
> content's aspect ratio being preserved. Thus, if the aspect ratio of the 
> playback area does not match the aspect ratio of the video, the video 
> will be shown letterboxed or pillarboxed. Areas of the element's 
> playback area that do not contain the video represent nothing."

That's what it said before we added pixelratio="".


> > We definitely don't want to stretch the video. One of the important 
> > use cases if having a video playback area and then playing videos with 
> > different aspect ratios in that playback area. It should all just 
> > work.
> 
> I'm having a hard time seeing how this is a use case for video and not 
> for img.

I don't understand how it's a use case for <img> either.


> If one wants the intrinsic width/height to be used, then simply don't 
> set width/height. Otherwise, just setting just one of width/height or 
> using CSS max-width/max-height should do the trick.

The idea is that generally you don't want the intrinsic size to be used, 
you want a consistent size to be used, and you would set it from CSS.


> This is strange:
> 
> <video src="circle.mpg" width="400" height="400"> <!-- circle -->
> <video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->
> 
> <img src="circle.jpg" width="400" height="400"> <!-- circle -->
> <img src="circle.jpg" width="400" height="300"> <!-- oval -->
> 
> I think it would be much more consistent if these elements behaved in 
> the same way.

I don't think consistency here is an issue. Or if you like, consider it 
as being consistent with <iframe>:

   <iframe src="circle.html" width="400" height="400"> <!-- circle -->
   <iframe src="circle.html" width="400" height="300"> <!-- pillarbox -->


> As it stands, after the pixelratio was removed, there is no way to 
> display a circle as an oval or vice versa, which means it is both 
> impossible to fix an incorrect aspect ratio or to stretch the video for 
> some other purpose.

Right; we established that the use cases for stretching the video were not 
convincing, that's why I removed pixelratio="".


On Mon, 1 Dec 2008, Lachlan Hunt wrote:
> 
> This is effectively how YouTube behaves now with their recent change to 
> a widescreen player.  It would look terrible if 4:3 videos were 
> stretched to fill the 16:9 viewport, instead of just using black bars on 
> the side.  Even before when they were still using a 4:3 player, 
> widescreen videos were rendered as letterbox.

True.


On Mon, 1 Dec 2008, Pierre-Olivier Latour wrote:
> 
> I can only think of the case when you need to post-fix a video which 
> wasn't encoded with the proper pixel aspect ratio. And we already 
> covered the likelihood of encountering this case extensively. So I guess 
> what's left is purely a convention decision:
>
> - should <video> behaves like <img> by default and have a special 
> attribute to scale proportionally,
>
> - or should <video> scale proportionally by default, and maybe have some 
> way of defining a stretching behavior?
> 
> Eric & I would recommend the later because based on past experience, 
> users often specify the wrong width & height for the element, and if we 
> stretch by default, then we would often fall off the fast path of the 
> media engine (scaling anamorphically can be very expensive). At the end 
> of the day, being consistent with <img> wouldn't be worth the potential 
> other issues.
> 
> Regarding the stretch attribute, we should have this functionally 
> available to users but preferably at the CSS level.

I agree that something like stretch or pixelratio should probably be added 
in a future version, but since we just removed pixelratio="" I don't think 
it is something we want to add now.


On Mon, 1 Dec 2008, Martin Atkins wrote:
> 
> It would also be useful if this mechanism were available for images. A 
> bunch of times I've written code to proportionally scale images to 
> create smaller versions, and I'd much rather just set this with CSS.
> 
> This would also go some way to increase the consistency, since the 
> difference between IMG and VIDEO would be merely a difference in the 
> default stylesheet rules for each element.

True.


On Mon, 1 Dec 2008, Philip J?genstedt wrote:
> 
> The strange part isn't that the video is pillarboxed, but that it's 
> impossible to not do it and that it's inconsistent with <img>.

There are inconsistencies all over the place already. This doesn't add a 
new one, since <img>, <iframe>, and <video> already act differently in so 
many ways.


> The use case for stretching moving images (<video>) is exactly the same 
> as for stretching animations (<img src=animation.gif>) or static images 
> (<img src=static.jpg>). While I think that fixing incorrect aspect ratio 
> is the most probable use, consistency and generality is the real issue 
> here. With an image of size 800x600 it's possible to display at any 
> size, even those which don't match the aspect 4:3. With moving images 
> (video) we can't influence it at all.

If consistency is the only use case, then I don't think that's convincing.


> The previous solution was the pixelratio attribute, but I have 2 other
> possible solutions:
> 
> <video src="4x3.mpg" width="1920" height="1080" keepaspect>
> 
> The video would be pillarboxed.
> 
> <video src="4x3.mpg" width="1920" height="1080">
> 
> The video would be stretched and have incorrect aspect, just like
> 
> <img src="4x3.jpg" width="1920" height="1080">
> 
> This way it's easy to stretch or to keep aspect, whichever you want.

I fear that if we do this, authors will screw up the ratio a lot. The 
whole point of <video> is to not provide too many ways that authors can 
screw things up.


> Given the number of people who watch 4:3 video stretched to a 16:9 
> display without even noticing/caring that the aspect ratio is wrong, I 
> don't think we can trust that the aspect ratio of all videos is always 
> going to be correctly encoded and simple say that this should be fixed 
> by reencoding the video -- that's not even an option if the source file 
> is not available and reencoding is good for quality.

Making it easy for authors to screw it up more isn't a way to solve this. :-)

pixelratio="" was an ok solution because it was unlikely to be used much, 
but height/width will be used all over the place if we allow it.


On Mon, 1 Dec 2008, Philip J?genstedt wrote:
> 
> Another way could be using CSS so that the same thing could be done with 
> <img>. It is in fact rather difficult to scale something to fit inside a 
> box using only CSS right now, so a general solution for it would be 
> nice. Possibly <video style="scaling:keep-aspect"> or something like 
> that? This way one could let the default value differ between <img> and 
> <video> if the aspect-preserving (letterboxing/pillarboxing) is judged 
> to be much more common than the "aspect-fixing" mode.

I agree that CSS (maybe taking something from SVG and making it more 
general) would be a good way to address this.

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

From lachlan.hunt at lachy.id.au  Mon Dec  1 14:07:19 2008
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Mon, 01 Dec 2008 23:07:19 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <1228165994.7291.58.camel@localhost>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>	<1228129554.8038.9.camel@localhost>	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>	<1228147475.11030.53.camel@localhost>
	<49341CAA.70001@lachy.id.au> <1228165994.7291.58.camel@localhost>
Message-ID: <49346017.7020905@lachy.id.au>

Philip J?genstedt wrote:
> The use case for stretching moving images (<video>) is exactly the 
> same as for stretching animations (<img src=animation.gif>) or static 
> images (<img src=static.jpg>).

Consistency is not a use case.  For images, we're constrained by 
backwards compatibility requirements to stretch them, rather than keep 
aspect ratios, regardless of what use cases there may or may not be for 
doing so.  For video, we are not constrained by such backwards 
compatibility and we have the opportunity to specify the most rational 
alternative as the default.

> While I think that fixing incorrect aspect ratio is the most probable 
> use, consistency and generality is the real issue here.

Given that the pixelratio attribute was dropped in part due to a lack of 
compelling use cases, I don't think the same use case will be compelling 
for this either.

If there are real use cases for stretching video, then they should be 
judged on their own merits, rather than just falling back to the 
consistency argument.

> With an image of size 800x600 it's possible to display at any size, 
> even those which don't match the aspect 4:3. With moving images 
> (video) we can't influence it at all.
> 
> The previous solution was the pixelratio attribute, but I have 2 
> other possible solutions:
> 
> <video src="4x3.mpg" width="1920" height="1080" keepaspect>
> 
> The video would be pillarboxed.

Retaining the aspect ratio needs to be the default because based on 
experience with video on the web today, e.g. on YouTube, and also based 
on the behaviour of common media players, like VLC, QuickTime, Windows 
Media, etc.  When a user resizes their video player, the video generally 
maintains the aspect ratio and gets black bars; (or in QuickTime's case, 
the window size is constrained by the video's aspect ratio).  There are 
menu options in VLC, and possibly others, to set the aspect ratio of a 
video to a selection of common aspect ratios, but there is no arbitrary 
scaling (at least, not that I'm aware of).

> <video src="4x3.mpg" width="1920" height="1080">
> 
> The video would be stretched and have incorrect aspect

And if a user chooses to put the video in full screen, then what? Should 
it maintian that incorrect aspect ratio?  Should it stretch to fill the 
whole screen, regardless of what type of monitor the user is using, or 
should it use the video's default aspect ratio?

> Given the number of people who watch 4:3 video stretched to a 16:9 
> display without even noticing/caring that the aspect ratio is wrong,

While I'm aware that there are such people, largely because they don't 
know how to configure their TV's properly or because their TV's are 
broken by design, there are many others who do notice the difference 
(including myself).  From my experience, stretching a 4:3 picture to 
fill a 16:9 screen is enough to make people on the screen look weird and 
out of proportion.  It's less noticeable with cartoons, but in general, 
it's very noticeable and annoying.  We should inflict such annoyances 
upon end users if it avoidable; at least not by default.

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


From ian at hixie.ch  Mon Dec  1 14:13:25 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Dec 2008 22:13:25 +0000 (UTC)
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <49341055.1030809@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com> 
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>
	<4932C182.5010905@email.it>
	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>
	<4932CC01.9010301@email.it>
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>
	<4933547C.2010501@email.it>
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
	<49341055.1030809@email.it>
Message-ID: <Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008, Calogero Alex Baldacchino wrote:
> >
> > Yes, a hash link (<a href="#foo">) will scroll to the element with an 
> > id=foo.  If coding properly, you'll virtually *never* use an <a> for 
> > an actual *anchor*, but rather will target the most semantically 
> > appropriate element, such as a heading or a container with the 
> > appropriate @id.
>
> Thanks! That's what I was missing in the specicification (I should give it a
> more accurate reading). Does it applies to every element, covering the <cite>
> element too?

See:
   http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid

Let me know if that doesn't address your use case.

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


From robert at ocallahan.org  Mon Dec  1 14:33:53 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 2 Dec 2008 11:33:53 +1300
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <CB464D8D-D081-4A3E-BE7E-8E620B1AD83A@apple.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au>
	<CB464D8D-D081-4A3E-BE7E-8E620B1AD83A@apple.com>
Message-ID: <11e306600812011433p41782317tb27f1e312ac65184@mail.gmail.com>

BTW, using CSS transforms (not a standard yet, but implemented in Webkit and
Gecko now), you can stretch <video> (or anything else) any way you want.

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/20081202/934f0114/attachment.htm>

From silviapfeiffer1 at gmail.com  Mon Dec  1 16:02:56 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 2 Dec 2008 11:02:56 +1100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <49341CAA.70001@lachy.id.au>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au>
Message-ID: <2c0e02830812011602r618a3462k7c4977428e91d6ad@mail.gmail.com>

On Tue, Dec 2, 2008 at 4:19 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Philip J?genstedt wrote:
>>
>> On Mon, 2008-12-01 at 12:39 +0000, Ian Hickson wrote:
>>>
>>
>> <video src="circle.mpg" width="400" height="400"> <!-- circle -->
>> <video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->
>
> This is effectively how YouTube behaves now with their recent change to a
> widescreen player.  It would look terrible if 4:3 videos were stretched to
> fill the 16:9 viewport, instead of just using black bars on the side.  Even
> before when they were still using a 4:3 player, widescreen videos were
> rendered as letterbox.

Not all video players behave like the YouTube one though. Many stretch
with the width/height attributes.

I would support an explicit keepaspectratio attribute, which turns the
width/height from a video width/height to a viewport.
In fact, such an attribute would be awesome for images, too.
It could be a CSS attribute or an explicit video element attribute - I
am not fussed.

Regards,
Silvia.


From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Dec  1 16:10:50 2008
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Tue, 02 Dec 2008 01:10:50 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <2c0e02830812011602r618a3462k7c4977428e91d6ad@mail.gmail.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au>
	<2c0e02830812011602r618a3462k7c4977428e91d6ad@mail.gmail.com>
Message-ID: <1228176650.27713.501.camel@desudesudesu>

Am Dienstag, den 02.12.2008, 11:02 +1100 schrieb Silvia Pfeiffer:
> I would support an explicit keepaspectratio attribute, which turns the
> width/height from a video width/height to a viewport.
> In fact, such an attribute would be awesome for images, too.
> It could be a CSS attribute or an explicit video element attribute - I
> am not fussed.
Better make it CSS ? this is as presentational as it can get.


Cheers,
-- 
Nils Dagsson Moskopp
<http://dieweltistgarnichtso.net>



From philipj at opera.com  Mon Dec  1 16:19:18 2008
From: philipj at opera.com (Philip =?ISO-8859-1?Q?J=E4genstedt?=)
Date: Tue, 02 Dec 2008 01:19:18 +0100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <49346017.7020905@lachy.id.au>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com>
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com>
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com>
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com>
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com>
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com>
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au>
	<1228165994.7291.58.camel@localhost>  <49346017.7020905@lachy.id.au>
Message-ID: <1228177158.11854.56.camel@localhost>

On Mon, 2008-12-01 at 23:07 +0100, Lachlan Hunt wrote:
> > Given the number of people who watch 4:3 video stretched to a 16:9 
> > display without even noticing/caring that the aspect ratio is wrong,
> 
> While I'm aware that there are such people, largely because they don't 
> know how to configure their TV's properly or because their TV's are 
> broken by design, there are many others who do notice the difference 
> (including myself).  From my experience, stretching a 4:3 picture to 
> fill a 16:9 screen is enough to make people on the screen look weird and 
> out of proportion.  It's less noticeable with cartoons, but in general, 
> it's very noticeable and annoying.  We should inflict such annoyances 
> upon end users if it avoidable; at least not by default.

The point wasn't that it is OK for UA:s to distort video because there
are people who don't notice, but that some people do/will encode video
with the wrong aspect ratio without noticing/caring. The general
consensus seems to be that this isn't worth the effort fixing.

But in any event, if a CSS solution is in fact possible that would be
much better than any video-specific solution. I don't think CSS
transforms can do it though, unless someone can give an example?

-- 
Philip J?genstedt
Opera Software



From silviapfeiffer1 at gmail.com  Mon Dec  1 16:29:31 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 2 Dec 2008 11:29:31 +1100
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <2c0e02830812011602r618a3462k7c4977428e91d6ad@mail.gmail.com>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com>
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com>
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com>
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com>
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com>
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au>
	<2c0e02830812011602r618a3462k7c4977428e91d6ad@mail.gmail.com>
Message-ID: <2c0e02830812011629w508630f3gb3f87b0780443666@mail.gmail.com>

On Tue, Dec 2, 2008 at 11:02 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> On Tue, Dec 2, 2008 at 4:19 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
>> Philip J?genstedt wrote:
>>>
>>> On Mon, 2008-12-01 at 12:39 +0000, Ian Hickson wrote:
>>>>
>>>
>>> <video src="circle.mpg" width="400" height="400"> <!-- circle -->
>>> <video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->
>>
>> This is effectively how YouTube behaves now with their recent change to a
>> widescreen player.  It would look terrible if 4:3 videos were stretched to
>> fill the 16:9 viewport, instead of just using black bars on the side.  Even
>> before when they were still using a 4:3 player, widescreen videos were
>> rendered as letterbox.
>
> Not all video players behave like the YouTube one though. Many stretch
> with the width/height attributes.

I checked this out a little more, since I remembered using the JW
player for some flv videos and they were stretched to the size of the
player no matter what their original encoded size.

According to this thread http://www.jeroenwijering.com/?thread=13766
it depends on whether the video metadata contains the original
width/height of the video. If it doesn't have that, the JW player
stretches to whatever is given. Jeroen might have changed that by now,
since it seems that many players now decode a few frames of video to
determine the original width/height of the video if this information
is not provided in the video metadata.

There are tools to include such metadata into the video headers for
the different video formats that exist and I am sure someone like
YouTube will make sure that metadata is available. However, I would
not expect the common user to be clever enough to make sure their
videos provide this data.

This raises a few questions:
* Do we want to prescribe the use of the width/height metadata for
determining the video size inside the viewport?
* How often is the widht/height metadata in videos encoded with wrong values?
* Do we want to force all video players to decode a few frames and get
the correct width/height values to then adapt to the viewport?
* Do we have use cases for overriding correct aspect ratio displays by
users? (and should that then go into a CSS control?)

I would much prefer the default video display to get it right inside a
viewport, than to risk relying on users to get the aspect ratio right.

Also, the viewport approach makes it easier to have a consistently
sized video player rather than adapting the video player to the
video's actual size and thus potentially constantly switching between
4:3 and 16:9.

So (contrary to what I wrote just before), I think the attribute
should not be a "keepaspectratio" attribute but rather something like
"fillviewport" and it should probably be a CSS attribute.

Cheers,
Silvia.


From ian at hixie.ch  Mon Dec  1 17:24:51 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 01:24:51 +0000 (UTC)
Subject: [whatwg] video tag: pixel aspect ratio
In-Reply-To: <1228177158.11854.56.camel@localhost>
References: <98c2a8300810140939g48734d2cw7837ee568ab27255@mail.gmail.com> 
	<BB1F7605-C03E-4C6C-992A-09309B34FFA9@apple.com> 
	<Pine.LNX.4.62.0811170156000.1237@hixie.dreamhostps.com> 
	<9D4E2546-8ADF-48B5-BCFC-BDF0E1FC6960@apple.com> 
	<2c0e02830811171737n41acd35fl981434ef59138acd@mail.gmail.com> 
	<Pine.LNX.4.62.0812010450570.17414@hixie.dreamhostps.com> 
	<d62cf1d10811302211idd63139x6eefa2da358e2ece@mail.gmail.com> 
	<c2e346f90811302305o3b3655fag59b928fa26a1473@mail.gmail.com> 
	<63df84f0812010028p21506091s6b80a0b9d21ecd26@mail.gmail.com> 
	<Pine.LNX.4.62.0812010836190.17401@hixie.dreamhostps.com> 
	<63df84f0812010109g36842b03i18c5e02fd84122de@mail.gmail.com> 
	<Pine.LNX.4.62.0812011001310.17401@hixie.dreamhostps.com> 
	<1228129554.8038.9.camel@localhost>
	<Pine.LNX.4.62.0812011237200.17401@hixie.dreamhostps.com>
	<1228147475.11030.53.camel@localhost> <49341CAA.70001@lachy.id.au> 
	<1228165994.7291.58.camel@localhost>  <49346017.7020905@lachy.id.au>
	<1228177158.11854.56.camel@localhost>
Message-ID: <Pine.LNX.4.62.0812020105560.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Silvia Pfeiffer wrote:
> 
> Not all video players behave like the YouTube one though. Many stretch 
> with the width/height attributes.

Yeah, it's really annoying. :-)


> I would support an explicit keepaspectratio attribute, which turns the 
> width/height from a video width/height to a viewport. In fact, such an 
> attribute would be awesome for images, too. It could be a CSS attribute 
> or an explicit video element attribute - I am not fussed.

I think that this belongs in CSS, for the reason Nils gave:

On Tue, 2 Dec 2008, Nils Dagsson Moskopp wrote:
>
> Better make it CSS ??? this is as presentational as it can get.


On Tue, 2 Dec 2008, Silvia Pfeiffer wrote:
>
> This raises a few questions:
> * Do we want to prescribe the use of the width/height metadata for
> determining the video size inside the viewport?

We already do.


> * How often is the widht/height metadata in videos encoded with wrong values?

Relatively often, IMHO, that's why I wanted pixelratio="". But we've 
established that this is not something we're addressing in v1.


> * Do we want to force all video players to decode a few frames and get
> the correct width/height values to then adapt to the viewport?

We already force them to decode the end of the stream to get the right 
duration, having them decode one frame so that they can render that frame 
seems reasonable enough.


> * Do we have use cases for overriding correct aspect ratio displays by 
> users? (and should that then go into a CSS control?)

There are always use cases for presentational effects, and those indeed 
belong in CSS.


> I would much prefer the default video display to get it right inside a 
> viewport, than to risk relying on users to get the aspect ratio right.

Indeed.


> Also, the viewport approach makes it easier to have a consistently sized 
> video player rather than adapting the video player to the video's actual 
> size and thus potentially constantly switching between 4:3 and 16:9.

Right.


> So (contrary to what I wrote just before), I think the attribute should 
> not be a "keepaspectratio" attribute but rather something like 
> "fillviewport" and it should probably be a CSS attribute.

Agreed.


On Tue, 2 Dec 2008, Philip J?genstedt wrote:
> 
> The point wasn't that it is OK for UA:s to distort video because there 
> are people who don't notice, but that some people do/will encode video 
> with the wrong aspect ratio without noticing/caring. The general 
> consensus seems to be that this isn't worth the effort fixing.

Right, that's why we dropped pixelratio="". :-)


> But in any event, if a CSS solution is in fact possible that would be 
> much better than any video-specific solution. I don't think CSS 
> transforms can do it though, unless someone can give an example?

Well, CSS transforms don't officially exist yet, but you could use a 
scale() or scaleX() transform:

   http://webkit.org/specs/CSSVisualEffects/CSSTransforms.html

-- 
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  Mon Dec  1 17:40:58 2008
From: chris.double at double.co.nz (Chris Double)
Date: Tue, 2 Dec 2008 14:40:58 +1300
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
Message-ID: <c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>

On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson <ian at hixie.ch> wrote:
>> For the few servers that don't support seeking, duration is not
>> available.
>
> Note that that is non-conforming at the moment. You have to have a
> duration available (though it can be +Infinity if you think that the
> resource is a stream, and can be an estimate, so long as you keep updating
> it as your information gets better.)

I think the spec should be changed to allow duration to be NaN in the
case where it cannot be determined.

Chris.
-- 
http://www.bluishcoder.co.nz


From jonas at sicking.cc  Mon Dec  1 17:52:47 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 1 Dec 2008 17:52:47 -0800
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <Pine.LNX.4.62.0812011236140.17401@hixie.dreamhostps.com>
References: <op.tlq7qta564w2qv@id-c0020>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
	<48641CBB.8010204@sicking.cc>
	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>
	<492DA279.1070207@sicking.cc> <492FCF33.70203@lachy.id.au>
	<63df84f0812010010p2047b309h6bcebce4d05312cb@mail.gmail.com>
	<Pine.LNX.4.62.0812010835440.17401@hixie.dreamhostps.com>
	<4933C303.30505@lachy.id.au>
	<Pine.LNX.4.62.0812011236140.17401@hixie.dreamhostps.com>
Message-ID: <63df84f0812011752o3b4631a9rb73e91944dca036e@mail.gmail.com>

On Mon, Dec 1, 2008 at 4:37 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 1 Dec 2008, Lachlan Hunt wrote:
>> Ian Hickson wrote:
>> > On Mon, 1 Dec 2008, Jonas Sicking wrote:
>> > > > > Try the following markup in firefox:
>> > > > >
>> > > > > <map name="foo"></map>
>> > > > > <map name="foo">
>> > > > >  <area shape=circle coords="10,10,10" href="http://www.mozilla.com">
>> > > > > </map>
>> > > > > <img src="http://www.mozilla.org/images/feature-logos1.png"
>> > > > >     usemap="#foo" width="20" height="20">
>> > > >
>> > > > This only seems to occur in quirks mode, not in standards mode.  But
>> > > > neither
>> > > > Opera, Safari or IE8 have the same behaviour.  Additionally, the site
>> > > > reported in the bug you mentioned no longer suffers from the bug.
>> > > > Therefore,
>> > > > it doesn't appear to be necessary that we should require that behaviour.
>> > >
>> > > Ah, it does indeed only happen in quirks mode (ugh, i hate it when quirks
>> > > mode things spread into code that I work on ;) ). If no other browser is
>> > > doing it in standards mode either I'm more than happy to not have it in
>> > > the spec.
>> >
>> > The spec is including quirks-mode requirements; do other browsers do it in
>> > quirks mode?
>>
>> As I already said above, "neither Opera, Safari or IE8 have the same
>> behaviour."  I tested both quirks and standards mode.
>
> In that case, it truly seems like something where Gecko should just be
> simplified.
>
> Jonas: are there pages that depend on this? If we could remove that quirk,
> that'd be awesome...

I don't know more than what's in that bug [1], but if IE8 indeed has
dropped this quirk then I'm more than happy to do the same in firefox.

/ Jonas

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=264624


From ian at hixie.ch  Mon Dec  1 18:06:09 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 02:06:09 +0000 (UTC)
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36> 
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
	<c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Chris Double wrote:
> On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> For the few servers that don't support seeking, duration is not 
> >> available.
> >
> > Note that that is non-conforming at the moment. You have to have a 
> > duration available (though it can be +Infinity if you think that the 
> > resource is a stream, and can be an estimate, so long as you keep 
> > updating it as your information gets better.)
> 
> I think the spec should be changed to allow duration to be NaN in the 
> case where it cannot be determined.

We removed some other features (e.g. bufferedBytes and totalBytes) because 
implementors said they would always provide accurate values in the 
buffered and duration attributes. If we allow duration to be NaN, then 
we'd have to re-add the other features again.

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


From ian at hixie.ch  Mon Dec  1 18:08:44 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 02:08:44 +0000 (UTC)
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <63df84f0812011752o3b4631a9rb73e91944dca036e@mail.gmail.com>
References: <op.tlq7qta564w2qv@id-c0020>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
	<48641CBB.8010204@sicking.cc>
	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>
	<492DA279.1070207@sicking.cc> <492FCF33.70203@lachy.id.au> 
	<63df84f0812010010p2047b309h6bcebce4d05312cb@mail.gmail.com> 
	<Pine.LNX.4.62.0812010835440.17401@hixie.dreamhostps.com>
	<4933C303.30505@lachy.id.au>
	<Pine.LNX.4.62.0812011236140.17401@hixie.dreamhostps.com>
	<63df84f0812011752o3b4631a9rb73e91944dca036e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812020208180.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008, Jonas Sicking wrote:
> >
> > Jonas: are there pages that depend on this? If we could remove that 
> > quirk, that'd be awesome...
> 
> I don't know more than what's in that bug [1], but if IE8 indeed has 
> dropped this quirk then I'm more than happy to do the same in firefox.

Ok. I'm going to go forward on the assumption that we don't need this 
quirk in HTML5. Let me know if this should change.

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


From singer at apple.com  Mon Dec  1 18:08:33 2008
From: singer at apple.com (Dave Singer)
Date: Mon, 1 Dec 2008 18:08:33 -0800
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
	<c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>
	<Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
Message-ID: <p06240863c55a490b535e@[17.202.35.52]>

At 2:06  +0000 2/12/08, Ian Hickson wrote:
>On Tue, 2 Dec 2008, Chris Double wrote:
>>  On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson <ian at hixie.ch> wrote:
>>  >> For the few servers that don't support seeking, duration is not
>>  >> available.
>>  >
>>  > Note that that is non-conforming at the moment. You have to have a
>>  > duration available (though it can be +Infinity if you think that the
>>  > resource is a stream, and can be an estimate, so long as you keep
>>  > updating it as your information gets better.)
>>
>>  I think the spec should be changed to allow duration to be NaN in the
>>  case where it cannot be determined.
>
>We removed some other features (e.g. bufferedBytes and totalBytes) because
>implementors said they would always provide accurate values in the
>buffered and duration attributes. If we allow duration to be NaN, then
>we'd have to re-add the other features again.

what is the duration of an indefinite stream (e.g. live or simulated live)?
-- 
David Singer
Multimedia Standards, Apple Inc.


From chris.double at double.co.nz  Mon Dec  1 18:10:17 2008
From: chris.double at double.co.nz (Chris Double)
Date: Tue, 2 Dec 2008 15:10:17 +1300
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
	<c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>
	<Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
Message-ID: <c2e346f90812011810p6292c1c6l471fcd352ad9ecca@mail.gmail.com>

On Tue, Dec 2, 2008 at 3:06 PM, Ian Hickson <ian at hixie.ch> wrote:
> We removed some other features (e.g. bufferedBytes and totalBytes) because
> implementors said they would always provide accurate values in the
> buffered and duration attributes. If we allow duration to be NaN, then
> we'd have to re-add the other features again.

It's not possible to always provide accurate values for duration -
we've already discussed that and you suggested estimating. I don't see
that as an accurate value. Can you link to the post where implementors
said they would always provide accurate values? The only accurate
value I can provide with Ogg is the exact duration if the http server
supports byte range requests, or some other out of band duration
metadata (X-Content-Duration, etc). Without byte range requests,
accurate duration is not possible.

Chris.
-- 
http://www.bluishcoder.co.nz


From ian at hixie.ch  Mon Dec  1 18:13:13 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 02:13:13 +0000 (UTC)
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <p06240863c55a490b535e@[17.202.35.52]>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
	<c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>
	<Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
	<p06240863c55a490b535e@[17.202.35.52]>
Message-ID: <Pine.LNX.4.62.0812020213020.17401@hixie.dreamhostps.com>

On Mon, 1 Dec 2008, Dave Singer wrote:
> 
> what is the duration of an indefinite stream (e.g. live or simulated 
> live)?

The spec defines that as +Infinity.

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


From singer at apple.com  Mon Dec  1 18:17:21 2008
From: singer at apple.com (Dave Singer)
Date: Mon, 1 Dec 2008 18:17:21 -0800
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <Pine.LNX.4.62.0812020213020.17401@hixie.dreamhostps.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
	<c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>
	<Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
	<p06240863c55a490b535e@[17.202.35.52]>
	<Pine.LNX.4.62.0812020213020.17401@hixie.dreamhostps.com>
Message-ID: <p06240865c55a4b25d164@[17.202.35.52]>

At 2:13  +0000 2/12/08, Ian Hickson wrote:
>On Mon, 1 Dec 2008, Dave Singer wrote:
>>
>>  what is the duration of an indefinite stream (e.g. live or simulated
>>  live)?
>
>The spec defines that as +Infinity.

then I think we're fine as we are.
-- 
David Singer
Multimedia Standards, Apple Inc.


From ian at hixie.ch  Mon Dec  1 18:21:29 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 02:21:29 +0000 (UTC)
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <c2e346f90812011810p6292c1c6l471fcd352ad9ecca@mail.gmail.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36> 
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com> 
	<c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com> 
	<Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
	<c2e346f90812011810p6292c1c6l471fcd352ad9ecca@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812020213220.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Chris Double wrote:
> 
> It's not possible to always provide accurate values for duration - we've 
> already discussed that and you suggested estimating. I don't see that as 
> an accurate value.

The spec does allow for estimations and provides for the estimate being 
revised dynamically.


> Can you link to the post where implementors said they would always 
> provide accurate values?

The attributes were removed based on:
   http://lists.w3.org/Archives/Public/public-html/2008Nov/0131.html


> The only accurate value I can provide with Ogg is the exact duration if 
> the http server supports byte range requests, or some other out of band 
> duration metadata (X-Content-Duration, etc). Without byte range 
> requests, accurate duration is not possible.

That's fine, just update it as you get more info.

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


From ian at hixie.ch  Mon Dec  1 18:54:16 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 02:54:16 +0000 (UTC)
Subject: [whatwg] "end body tag" parsing clarification
In-Reply-To: <49115D0C.8010906@kvaleberg.no>
References: <49115D0C.8010906@kvaleberg.no>
Message-ID: <Pine.LNX.4.62.0812020254030.17414@hixie.dreamhostps.com>

On Wed, 5 Nov 2008, Tommy Thorsen wrote:
>
> 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?

Wow yeah, that makes no sense. Removed. Thanks!

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


From ian at hixie.ch  Mon Dec  1 19:06:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 03:06:15 +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.0812020254300.17414@hixie.dreamhostps.com>

On Thu, 6 Nov 2008, Tommy Thorsen wrote:
> 
> 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.

This is great feedback!


> 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.
> 
> 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 concurr that this is closer to what we need. I have updated the spec 
accordingly.


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

Yes, please do!

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


From ian at hixie.ch  Mon Dec  1 19:08:53 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 03:08:53 +0000 (UTC)
Subject: [whatwg] li start tag algorithm clarification.
In-Reply-To: <491827D0.7020008@kvaleberg.no>
References: <491827D0.7020008@kvaleberg.no>
Message-ID: <Pine.LNX.4.62.0812020307500.17414@hixie.dreamhostps.com>

On Mon, 10 Nov 2008, Tommy Thorsen wrote:
>
> 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"').

I don't like using numbers because the numbers change and I forget to 
update them and this causes all kinds of really hard to debug bugs.

I've annotated the last step as being "the last step" so that it's clear. 
Let me know if it's still ambiguous.

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


From ian at hixie.ch  Mon Dec  1 19:53:53 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 03:53:53 +0000 (UTC)
Subject: [whatwg] Handling <title> inside <body>
In-Reply-To: <4919653A.1040209@kvaleberg.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>
	<4919653A.1040209@kvaleberg.com>
Message-ID: <Pine.LNX.4.62.0812020351260.17414@hixie.dreamhostps.com>

On Tue, 11 Nov 2008, Tommy Thorsen wrote:
>
> 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.

What HTML5 does here is compatible with what IE8 does, so I'd rather stick 
with that.


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

Per HTML5, this wouldn't actually put a <title> element in the <select> 
(it's the same as the original example). You should test it with 
document.createElement and select.appendChild.

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


From ian at hixie.ch  Mon Dec  1 19:58:48 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 03:58:48 +0000 (UTC)
Subject: [whatwg] script tag handling in "after head"
In-Reply-To: <49196C08.8020307@kvaleberg.com>
References: <49196C08.8020307@kvaleberg.com>
Message-ID: <Pine.LNX.4.62.0812020355360.17414@hixie.dreamhostps.com>

On Tue, 11 Nov 2008, Tommy Thorsen wrote:
>
> 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...

That seems reasonable. Another approach would be to pop the head element 
pointer after the end tag in the "in CDATA/RCDATA" insertion mode. I've 
gone with your approach.

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


From ian at hixie.ch  Mon Dec  1 20:05:59 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 04:05:59 +0000 (UTC)
Subject: [whatwg] Scoping elements and nested paragraphs
In-Reply-To: <491AA68F.7070807@kvaleberg.com>
References: <491AA68F.7070807@kvaleberg.com>
Message-ID: <Pine.LNX.4.62.0812020404480.17414@hixie.dreamhostps.com>

On Wed, 12 Nov 2008, 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>
> 
> 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.
> ---

I don't really see this as a critical issue; did this break any pages? 
Since WebKit does what HTML5 does here, I've left the spec as is.

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


From eric.carlson at apple.com  Mon Dec  1 20:51:39 2008
From: eric.carlson at apple.com (Eric Carlson)
Date: Mon, 01 Dec 2008 20:51:39 -0800
Subject: [whatwg] media elements: Relative seeking
In-Reply-To: <c2e346f90812011810p6292c1c6l471fcd352ad9ecca@mail.gmail.com>
References: <1a9dab7e7c85cc84fc3533193cc2895a@151.56.229.36>
	<Pine.LNX.4.62.0812010755500.17414@hixie.dreamhostps.com>
	<c2e346f90812011740n76c2ade4h6c59f2f9bf2abeac@mail.gmail.com>
	<Pine.LNX.4.62.0812020204380.17401@hixie.dreamhostps.com>
	<c2e346f90812011810p6292c1c6l471fcd352ad9ecca@mail.gmail.com>
Message-ID: <F3DA3F63-B775-46CF-9699-E293390CC290@apple.com>


On Dec 1, 2008, at 6:10 PM, Chris Double wrote:

>  The only accurate value I can provide with Ogg is the exact  
> duration if the http server supports byte range requests, or some  
> other out of band duration metadata (X-Content-Duration, etc).  
> Without byte range requests, accurate duration is not possible.
>
   While you can seek to the end of an Ogg file to get duration from  
the last frame's time stamp, you can't do that with every file type.

   For example, an MPEG audio elementary stream (eg. MP3) isn't a file  
format, it is just the raw output from a decoder, and there are no  
time stamps at all so the only way to get an accurate file duration is  
to sum the duration of every sample. It is *possible* to include an  
indication of duration in the file [1][2], but a player must be  
prepared to handle files without any indication as well as files in  
which the stored duration(s) are inconsistent with the observed  
duration.

   As I have noted before, an estimated duration based on the  
calculated duration of the portion(s) of a file that have been  
processed, iteratively refined as more data is seen, works well for  
us. You might try it with files on servers that don't support byte  
range requests, or on machines where you don't want to incur the cost  
of extra network IO.

eric

[1] VBR files can include a header with the number of MPEG audio  
frames in the file. This can be used with the sampling rate to  
calculate the duration.

[2] Some ID3v2 tags include a frame that stores the file duration in  
milliseconds (strangely enough, stored as a string).


From ian at hixie.ch  Mon Dec  1 23:48:15 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 07:48:15 +0000 (UTC)
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <op.ujr3sg0y1ejg13@sandra-svwliu01>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>
	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>
	<op.ujrzdhip1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>
	<op.ujr3sg0y1ejg13@sandra-svwliu01>
Message-ID: <Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>

On Wed, 29 Oct 2008, Michael A. Puls II wrote:
> On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 29 Oct 2008, Michael A. Puls II wrote:
> > > 
> > > What about the method="POST" case where the query string is kept?
> > > 
> > > <form action="mailto:?subject=1+2" method="POST">
> > >     <input type="text" name="body" value="1+2">
> > >     <input type="text" name="other" value="1 2">
> > >     <input type="submit">
> > > </form>
> > > 
> > > When submitting that, I expect to see:
> > > 
> > > mailto:?subject=1%2B2&body=body%3D1%252B2%26other%3D1%25202
> > > 
> > > submitted to the mail client.
> > > 
> > > The current POST section seems to say that this would be submitted
> > > instead:
> > > 
> > > mailto:?subject=1+2&body=body%3D1%252B2%26other%3D1+2
> > > 
> > > In other words, I think spaces in values should be emitted as %20 
> > > for POST too and in the case there's a query string present in the 
> > > action attribute for POST, any + in the hvalues of the query string 
> > > should be normalized to %2B (to be consistent with a + inside a form 
> > > control's value that gets converted to %2B)
> > 
> > The idea is that the same thing as would be posted to an HTTP server 
> > is what is sent using the e-mail body, so I think we'd want the exact 
> > same "+" behavior as normally.
> 
> O.K., but in the case of the + that's in the mailto URI in the action 
> attribute, the author means a '+' and not a space (they're allowed to be 
> left in raw form in a mailto URI). If it gets sent to a server, the + 
> will be treated as a space, which is not what is intended.

I actually can't find where it is defined that the + in an HTTP URI 
represents a space. (I can find where it says that a space is to be 
converted into a +, but not the other way around.)

My understanding, though, is that the convention that + represents a space 
is not part of the URI syntax, but part of the syntax of the format used 
to encode the data into the URI, which for HTTP URIs is generally 
application/x-www-form-urlencoded. But nothing stops this format from 
being used elsewhere, e.g. in the body of an e-mail or a POST submission.


> The workaround is of course for the author to make sure to encode that + 
> as %2B (or never use anything but action="mailto:" even for POST). But, 
> for good measure, it seems like the UA should fix that if the + will 
> ever end up in an HTTP URI.

I don't follow.


> Of course right now, browsers only pass the data as a mailto URI to an 
> email program, so the + from the query string will be a + and come out 
> fine in the compose window. As for spaces in form control values coming 
> out as + (for POST) in a programs's body field, that's not as big of a 
> deal as there's no use-case to *see* any of the data *like that* anyway. 
> But it does seem incorrect to encode mailto spaces as + though.

I don't follow.


> However, if for POST, if everything after 'mailto:' in the action 
> attribute was dropped (like get) and all you ever had was 
> mailto:?body=encoded_stuff that was POSTed, then the spec could say that 
> the value you might see in the body field represents *HTTP* url encoded 
> data.

We can't drop everything, because then you'd lost the Subject: line, etc.


> Or, the spec could say that if the protocol in the action attribute is 
> mailto:, +s in the action attribute have to be encoded as %2B and spaces 
> in the action attribute have to be encoded as %20. Then, the validator 
> can catch that and the spec can say (for POST), that the body hvalue 
> that gets generated from the form represents *HTTP* form data. Then, 
> it'll be clear why +s in the value are represented as + instead of %20.

I don't follow here either.


> Or, if it's O.K. for a UA's URI normalizer/resolver to take 
> action="mailto:?subject=1+2 3" and normalize that to 
> "action="mailto:?subject=1%2B2%203" for use with the form's .action 
> getter, I guess that might solve it to.

I think we may be talking at cross-purposes... which requirements in the 
spec are you referring to?

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


From ian at hixie.ch  Tue Dec  2 00:01:50 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 08:01:50 +0000 (UTC)
Subject: [whatwg] Select elements and radio button/checkbox groups [Was:
 Form Control Group Labels]
In-Reply-To: <490831A5.3060703@gmx.ch>
References: <BAY109-F101C1F09B6FFB148A288F5B4F80@phx.gbl>
	<Pine.LNX.4.62.0810280926050.1237@hixie.dreamhostps.com>
	<a9699fd20810281008i220aeb49t643d4ff1db90d932@mail.gmail.com>
	<490760E2.7080408@googlemail.com>
	<Pine.LNX.4.62.0810282225010.1237@hixie.dreamhostps.com>
	<490831A5.3060703@gmx.ch>
Message-ID: <Pine.LNX.4.62.0812020748320.17414@hixie.dreamhostps.com>

On Wed, 29 Oct 2008, Markus Ernst wrote:
> Ian Hickson schrieb:
> > On Tue, 28 Oct 2008, Markus Ernst wrote:
> > >
> > > I consider a total re-thinking of select, input type="checkbox" and 
> > > input type="radio" elements as highly desirable, though I see that 
> > > this might cause more serious backwards compatiblity problems than 
> > > for example removing the font tag. One possible solution could be 
> > > using the select tag with a type attribute:
> > > 
> > > <label for="gender">Gender:</label>
> > > <select id="gender" name="gender" type="boxgroup">
> > >   <option value=""> </option>
> > >   <option value="m">Male</option>
> > >   <option value="f">Female</option>
> > > </select>
> > 
> > I don't understand what problem you are trying to solve here.
> 
> Changing a group of radio buttons resp. checkboxes into a select 
> element, or vice-versa, needs a non-trivial amount of work. This applies 
> to both HTML coding and DOM access.

Why is that a problem? Is converting one to the other a common occurance?

I'm not really convinced it's that much work. Assuming that the radio 
buttons and/or checkboxes are written in a consistent manner, which they 
usually are, a simple regexp search-and-replace on the source is usually 
enough to convert them.


> Consider a form with some quite big radio button groups, and now you 
> have do add some more options. After you are done, your boss says: "Ok, 
> great work... but this looks too ugly now, just change it into those 
> dropdown kind of things."

A few seconds with Emacs or any other editor with real search-and-replace 
tools and you're done.


> Also, if you want to achieve the same via DOM access requires quite some 
> coding amount, you have to build a totally different tree of elements, 
> instead of one line:
>
> document.getElementById("gender").type = "dropdown";

Changing the few lines of code it takes to write a bunch of radio buttons 
into the few lines of code it takes to write a <select> is easy.


> To illustrate this, have a look unordered and ordered lists, which are 
> similar, too. Consider ul and ol would have the same kind of different 
> syntaxes; say, the ul element would work like we know it, but to make an 
> ordered list we would have to write something like:
> 
> <p type="orderedlist">
>   <listposition value="list position 1">
>   <listposition value="list position 2">
> </p>
> 
> Now simply changing an ordered into an unordered list would cause an 
> annoying amount of re-writing, such as changing a radio button group 
> into a select element does.

I agree entirely that if one is designing the language from scratch it 
makes sense to be consistent. I'm not sure it makes sense to retroactively 
change the language to impose consistency on it.

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


From tommy at kvaleberg.com  Tue Dec  2 00:05:44 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Tue, 02 Dec 2008 09:05:44 +0100
Subject: [whatwg] Scoping elements and nested paragraphs
In-Reply-To: <Pine.LNX.4.62.0812020404480.17414@hixie.dreamhostps.com>
References: <491AA68F.7070807@kvaleberg.com>
	<Pine.LNX.4.62.0812020404480.17414@hixie.dreamhostps.com>
Message-ID: <4934EC58.2050700@kvaleberg.com>

Ian Hickson wrote:
> On Wed, 12 Nov 2008, 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>
>>
>> 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.
>> ---
>>     
>
> I don't really see this as a critical issue; did this break any pages? 
> Since WebKit does what HTML5 does here, I've left the spec as is.
>
>   

This does not, as far as I know, break any real pages. We did discuss 
the issue in the irc-channel after I sent this mail 
(http://krijnhoetmer.nl/irc-logs/whatwg/20081112#l-285 and onwards) and 
we came to the same conclusion as you. I've reverted the change I did to 
our parser so that we follow the specification.

regards,
Tommy


From ian at hixie.ch  Tue Dec  2 00:14:17 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 08:14:17 +0000 (UTC)
Subject: [whatwg] Web Forms: change event
In-Reply-To: <490938F1.7030006@gmail.com>
References: <46669958.1020608@zoid.nl>
	<Pine.LNX.4.62.0810290040420.1237@hixie.dreamhostps.com>
	<490938F1.7030006@gmail.com>
Message-ID: <Pine.LNX.4.62.0812020810120.17414@hixie.dreamhostps.com>

On Wed, 29 Oct 2008, Garrett Smith wrote:
> > 
> > I've used different wording in HTML5, let me know if it's confusing 
> > still (it probably is), and what it should say instead.
> 
> Link or text?

I don't like giving links or text because if you can't find the text, then 
that is valuable information in itself as it shows I should reorganise the 
spec in some way.


> It would be useful to have x-browser way to get a select change event.

Isn't onchange="" that?


> It is generally desirable to have a select fire the event when the value 
> has changed, even if it still has focus.

So... Does the spec work as written?

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


From ian at hixie.ch  Tue Dec  2 00:17:56 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 08:17:56 +0000 (UTC)
Subject: [whatwg] HTML5 and URI Templates
In-Reply-To: <490CE611.3090306@berkeley.edu>
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>
	<Pine.LNX.4.62.0811012000280.1237@hixie.dreamhostps.com>
	<490CE611.3090306@berkeley.edu>
Message-ID: <Pine.LNX.4.62.0812020815350.17414@hixie.dreamhostps.com>

On Sat, 1 Nov 2008, Erik Wilde wrote:
> > >
> > > 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.
> 
> i think this is the fundamental problem. you can do redirects if you 
> have everything under one control, the service provider and the one 
> building the forms. if this is not the case, then there is no way you 
> can do redirects. there is a service with a given URI scheme, and you 
> have to use it like that. can you build a form for it?

Just build a redirector on the same site as you build the form.


> anyway, like i said above, html5 might decide not to be interested in 
> that functionality or might regard it as out of scope. all i want to say 
> here is that to see the value in that proposal, it is important to 
> depart from the traditional view of form clients and services always 
> being created by one entity.

I think it's an interesting proposal, but it doesn't seem ground-breaking 
enough to really warrant additions in HTML5 at this point.

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


From aaronlev at moonset.net  Tue Dec  2 00:39:06 2008
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Tue, 02 Dec 2008 09:39:06 +0100
Subject: [whatwg] Early feedback on header association algorithm
In-Reply-To: <9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
References: <4908A0B9.9090705@moonset.net>	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
Message-ID: <4934F42A.703@moonset.net>

Maybe there is a deeper problem if copy & paste doesn't work right 
because of IDs?

Or maybe there should be a node.getDescendantById() method?

I don't know. It just seems odd to implement something special here for 
that.

- Aaron

On 11/22/2008 3:06 PM, Henri Sivonen wrote:
> On Nov 22, 2008, at 15:50, Henri Sivonen wrote:
>
>> On Oct 29, 2008, at 19:43, Aaron Leventhal wrote:
>>
>>> 1. On this part:
>>>       "If there is a header cell in the table 
>>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#concept-table> 
>>> whose corresponding |th 
>>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-th-element>| 
>>> element has an ID that is equal to the value of id, then assign the 
>>> first such header cell in tree order to the data cell. "
>>> I don't want to implement a special local table only 
>>> getElementByIdInTable. I'd rather have this reworded to something like
>>> "If there is an element in the document with a corresponding ID (via 
>>> getElementById) equal to the value of /id/, and it is a header cell 
>>> in the current table, then assign it to the data cell."
>>
>>
>> While implementing a special lookup method is something that one 
>> would want to avoid, using getElementById has two problems:
>>
>> 1) It makes the association brittle under copy and paste. Consider a 
>> case where a page author creates a table with internal id references 
>> and then a maintainer duplicates the table and edits the contents of 
>> the copy table. Now the table coming later in the document order is 
>> inaccessible but this brokenness is unobvious to a person who isn't 
>> accessing the page with AT.
>>
>> 2) It makes the reporting of table relationships not form a coherent 
>> table. Consider a program that instead of allowing the user to 
>> traverse the table an arc at a time tries to pull all the arcs from 
>> the accessibility API and reconstruct the table in its own process 
>> space. If there are arcs between tables, the result is not a table 
>> structure at all.
>
>
> Oops. I didn't read the text I quoted properly. Sorry. #2 was already 
> dealt with.
>
> However, wouldn't testing if the cell is in the current table already 
> go a long way towards the complexity of implementing 
> getElementByIdInTable?
>




From julian.reschke at gmx.de  Tue Dec  2 00:54:34 2008
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue, 02 Dec 2008 09:54:34 +0100
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>	<op.ujrzdhip1ejg13@sandra-svwliu01>	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>	<op.ujr3sg0y1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
Message-ID: <4934F7CA.5070702@gmx.de>

Ian Hickson wrote:
> ...
> I actually can't find where it is defined that the + in an HTTP URI 
> represents a space. (I can find where it says that a space is to be 
> converted into a +, but not the other way around.)

Where does it say that? Surely not RFC 2616? RFC 3986?

> My understanding, though, is that the convention that + represents a space 
> is not part of the URI syntax, but part of the syntax of the format used 
> to encode the data into the URI, which for HTTP URIs is generally 
> application/x-www-form-urlencoded. But nothing stops this format from 

Yes: <http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1>

> being used elsewhere, e.g. in the body of an e-mail or a POST submission.

I could be used, but I'm not sure it should. What's the advantage over 
representing SP as %20?

 > ...

BR, Julian


From ian at hixie.ch  Tue Dec  2 01:04:44 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 09:04:44 +0000 (UTC)
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <4934F7CA.5070702@gmx.de>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>
	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>
	<op.ujrzdhip1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>
	<op.ujr3sg0y1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
	<4934F7CA.5070702@gmx.de>
Message-ID: <Pine.LNX.4.62.0812020859500.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> > ...
> > I actually can't find where it is defined that the + in an HTTP 
> > URI represents a space. (I can find where it says that a space is to 
> > be converted into a +, but not the other way around.)
> 
> Where does it say that? Surely not RFC 2616? RFC 3986?

HTML4; you cited the exact reference below.

> > My understanding, though, is that the convention that + represents a 
> > space is not part of the URI syntax, but part of the syntax of the 
> > format used to encode the data into the URI, which for HTTP URIs is 
> > generally application/x-www-form-urlencoded. But nothing stops this 
> > format from
> 
> Yes: <http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1>
> 
> > being used elsewhere, e.g. in the body of an e-mail or a POST 
> > submission.
> 
> I could be used, but I'm not sure it should. What's the advantage over 
> representing SP as %20?

None whatsoever, as far as I can tell. That's why people normally use 
text/plain.

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


From shadow2531 at gmail.com  Tue Dec  2 01:34:44 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Tue, 02 Dec 2008 04:34:44 -0500
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>
	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>
	<op.ujrzdhip1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>
	<op.ujr3sg0y1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
Message-ID: <op.uli3jseb1ejg13@sandra-svwliu01>

On Tue, 02 Dec 2008 02:48:15 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 29 Oct 2008, Michael A. Puls II wrote:
>> On Wed, 29 Oct 2008 03:42:17 -0400, Ian Hickson <ian at hixie.ch> wrote:
>> > On Wed, 29 Oct 2008, Michael A. Puls II wrote:
>> > >
>> > > What about the method="POST" case where the query string is kept?
>> > >
>> > > <form action="mailto:?subject=1+2" method="POST">
>> > >     <input type="text" name="body" value="1+2">
>> > >     <input type="text" name="other" value="1 2">
>> > >     <input type="submit">
>> > > </form>
>> > >
>> > > When submitting that, I expect to see:
>> > >
>> > > mailto:?subject=1%2B2&body=body%3D1%252B2%26other%3D1%25202
>> > >
>> > > submitted to the mail client.
>> > >
>> > > The current POST section seems to say that this would be submitted
>> > > instead:
>> > >
>> > > mailto:?subject=1+2&body=body%3D1%252B2%26other%3D1+2
>> > >
>> > > In other words, I think spaces in values should be emitted as %20
>> > > for POST too and in the case there's a query string present in the
>> > > action attribute for POST, any + in the hvalues of the query string
>> > > should be normalized to %2B (to be consistent with a + inside a form
>> > > control's value that gets converted to %2B)
>> >
>> > The idea is that the same thing as would be posted to an HTTP server
>> > is what is sent using the e-mail body, so I think we'd want the exact
>> > same "+" behavior as normally.
>>
>> O.K., but in the case of the + that's in the mailto URI in the action
>> attribute, the author means a '+' and not a space (they're allowed to be
>> left in raw form in a mailto URI). If it gets sent to a server, the +
>> will be treated as a space, which is not what is intended.
>
> I actually can't find where it is defined that the + in an HTTP URI
> represents a space. (I can find where it says that a space is to be
> converted into a +, but not the other way around.)
>
> My understanding, though, is that the convention that + represents a  
> space
> is not part of the URI syntax, but part of the syntax of the format used
> to encode the data into the URI, which for HTTP URIs is generally
> application/x-www-form-urlencoded. But nothing stops this format from
> being used elsewhere, e.g. in the body of an e-mail or a POST submission.
>
>
>> The workaround is of course for the author to make sure to encode that +
>> as %2B (or never use anything but action="mailto:" even for POST). But,
>> for good measure, it seems like the UA should fix that if the + will
>> ever end up in an HTTP URI.
>
> I don't follow.
>
>
>> Of course right now, browsers only pass the data as a mailto URI to an
>> email program, so the + from the query string will be a + and come out
>> fine in the compose window. As for spaces in form control values coming
>> out as + (for POST) in a programs's body field, that's not as big of a
>> deal as there's no use-case to *see* any of the data *like that* anyway.
>> But it does seem incorrect to encode mailto spaces as + though.
>
> I don't follow.
>
>
>> However, if for POST, if everything after 'mailto:' in the action
>> attribute was dropped (like get) and all you ever had was
>> mailto:?body=encoded_stuff that was POSTed, then the spec could say that
>> the value you might see in the body field represents *HTTP* url encoded
>> data.
>
> We can't drop everything, because then you'd lost the Subject: line, etc.
>
>
>> Or, the spec could say that if the protocol in the action attribute is
>> mailto:, +s in the action attribute have to be encoded as %2B and spaces
>> in the action attribute have to be encoded as %20. Then, the validator
>> can catch that and the spec can say (for POST), that the body hvalue
>> that gets generated from the form represents *HTTP* form data. Then,
>> it'll be clear why +s in the value are represented as + instead of %20.
>
> I don't follow here either.
>
>
>> Or, if it's O.K. for a UA's URI normalizer/resolver to take
>> action="mailto:?subject=1+2 3" and normalize that to
>> "action="mailto:?subject=1%2B2%203" for use with the form's .action
>> getter, I guess that might solve it to.
>
> I think we may be talking at cross-purposes... which requirements in the
> spec are you referring to?
>

I'll try to explain more.

Consider this form:

<form action="mailto:?subject=1+2" action="POST">
    <input type="submit" value="Compose">
</form>

(which contains a valid mailto URI meaning that "1+2" should be the value of the subject)

Imagine in your browser that it supports setting the default mailto URI handler to Gmail (a web-based client that uses *http* URIs).

If you submit that form, you'd get <https://mail.google.com/mail/?compose=1&view=cm&fs=1&su=1+2>
, which if you try, you'll see emits "1 2" instead of "1+2" in the subject field.

Basically, HTML is trying to say that "+" is equal to " ", but mailto URI hnames and hvalues are not application/x-www-form-urlencoded. They're close, but have less reserved characters.

So, the browser has to convert the + to %2B before submitting (because the value will end up in an http URI, in this case) to Gmail so the correct value ends up in the subject field. (This isn't a problem for non-web-based email clients because they don't treat hnames and hvalues in mailto URIs as application/x-www-form-urlencoded).

If you specify action="mailto:?subject=1%2B2", you avoid the problem and there are ways that Gmail could avoid the problem. Yet, the problem will still be there.

So, basically, the problem is, RFC2368 says '+' is a '+' and a space is "%20". HTML says that for the value in action="", '+' is a space, "%20" is a space and "%2B" is a '+'. 

So, when you put a mailto URI in the action attribute, you have a conflict of specs. If application/x-www-form-urlencoded gets priority over RFC2368 in this case, that's fine. I just think it needs to be spelled out in the HTML spec more.

Personally, I'd suggest the UA should do this for action="mailto:":

if (form.action.search(/mailto:/i) == 0 && form.method == "post") {
    form.action = form.action.replace(/\+/g, "%2B");
}

, then things will come out fine in both web-based and non-web-based clients if the author of the markup didn't know they had to convert the regular mailto URI to an HTML action attribute mailto URI.

-- 
Michael


From ian at hixie.ch  Tue Dec  2 01:52:10 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 09:52:10 +0000 (UTC)
Subject: [whatwg] More template feedback
In-Reply-To: <42913609-202D-45E4-8BDB-948E8E58C55C@subbu.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>
	<02dd01c93bc5$6e75cda0$6702a8c0@Guides.local>
	<15C6CE72-1963-4A41-93B8-A95F685326CB@mnot.net>
	<032001c93bf2$d433d1a0$6702a8c0@Guides.local>
	<DB78BE7C-1D9F-47B3-AD6D-3F77BC85A118@subbu.org>
	<490C8B5B.3040207@berkeley.edu>
	<18871997-C2DF-4138-A83A-7A4E3CD9FE81@subbu.org>
	<490CA20A.7090901@berkeley.edu>
	<2B7EC41B-E92C-4A94-B485-D1956E5CBE8E@subbu.org>
	<49109C1D.1070100@berkeley.edu>
	<009b01c93f1a$8a09d6d0$6702a8c0@Guides.local>
	<42913609-202D-45E4-8BDB-948E8E58C55C@subbu.org>
Message-ID: <Pine.LNX.4.62.0812020818090.17414@hixie.dreamhostps.com>


(trimmed cc list so that I'm not cross-posting to half a dozen lists)

On Sat, 1 Nov 2008, Mike Schinkel wrote:
> 
> If URI Templates are added I can see them be immediately incorporated 
> into CMS like Drupal, WordPress and Joomla (I use the former two so I'll 
> add it if nobody else does) and frameworks like Ruby on Rails, Django, 
> and CakePHP. Most (all?) of those frameworks use clean URLs but can't 
> use forms w/o using Javascript and URI templates would be a cleaner and 
> simplier approach that it would be crazy for people NOT to use it.

This only works if the form data is in the format you need it in. Say that 
you have a calendar-like feature -- if the server uses

   .../year/month/day/...

...as the URL form, you can't just convert an <input type=date> value into 
that URL, so you still have to have script or server-side redirection or 
some logic in the templating language -- and short of making it turing 
complete, the templating language won't ever be a complete solution.


On Sat, 1 Nov 2008, Mike Schinkel wrote:
>
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F
> 
> In my case, unfortunately, I don't have anyone paying me to participate 
> so my own personal financial requirements don't allow me to perform the 
> exhaustive research you are requesting. By requiring that you 
> effectively disenfranchise all those like myself who are not paid to 
> participate and thus have only a limited amount of time to be involved.

As I have not always been paid to participate in the standards process, I 
can say from personal experience that it is quite possible to spend free 
time doing this if one wants to. It's not that much work.


> > Why isn't the current form submission mechanism, with a redirect on 
> > the server-side, not acceptable?
> 
> Two main reasons:
> 
> 1.) Use cases where the person writing the form is not technically in 
> control of the server and where Javascript is unavailable and the 
> percentage of places where these use-cases exist are growing rapidly 
> because of social media and content management systems.

What are the places that allow you to write forms but don't allow you to 
write scripts on either the client or the server?


> 2.) Performance best practices frown on it: 
> http://developer.yahoo.com/performance/rules.html#redirects 

Sre, that's what the scripts are for -- making it faster if possible.


> I keep saying "where Javascript is unavailable and the percentage of 
> places where these use-cases exist are growing rapidly because of social 
> media and content management systems" but you are not acknowledging. Are 
> you implicitly discrediting that as a concern, or have you missed those 
> comments of mine?

I don't see evidence that there are places that let you do forms and 
service interaction but don't let you have scripts or server-side scripts. 
Indeed, at this point writing server-side script is easy and cheap, with 
services like Dreamhost, Google App Engine, etc.


> > Because it adds significant complexity to the browser platform, 
> > without really adding new functionality.
> 
> Significant? Srsly?  Seems to me we are talking about simply a URI 
> Template variable substitution.  Since it is *easy* to do in Javascript 
> how can it be adding "significant complexity" to the browser platform?  
> It seems your two points are in direct contradiction; how are they not?

A script can implement a hard-coded conversion, it doesn't have to 
implement templating. Templates themselves are a non-trivial feature in 
terms of complexity.


> > And are you really expecting search engines to fill in forms that 
> > would use templates?
> 
> YES!!  Why would they not, if they could?

How would they know what to say?


> > Something that can't be done without the feature.
> 
> When the use-case is no access to the server and only Javascript then 
> this use-case can't be done.
> 
> When the members of the web team say NO REDIRECTs on performance 
> grounds, it can't be done.

You don't have to do redirects, just support two URIs, one for the 
permalinks (nice URIs) one for form submissions (parsing query data).


> > Something that allows authors to write applications that make users 
> > say "wow!", which they can't do today.
> 
> URI Templates in forms would make core devs on content management 
> systems and frameworks go WOW once they realized what it can empower.  
> I'm soliciting such feedback on Twitter: 
> http://twitter.com/mikeschinkel/status/985784895

The response was not overwhelming.


> > What if the user types something that isn't supported by weather.com, 
> > like the string "x"?
> 
> HTTP handles that elegantly; 404.

With all due respect, that is hardly elegant.


> > 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>
> 
> So obvious it hurts: Because I don't current control Weather's server 
> and they have no http://www.weather.com/search/enhanced URL.

Yes they do. Did you try it? It works just like yours would, except with 
better error-handling.


> > 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.
> 
> "Normal forms?"  Google is not going to try to parse out javascript code 
> that is custom to a website nor "user added" form attributes.

No, but it can use unscripted forms today the same as it could use 
templated forms. 


> Also, adding a template attribute to a form element w/o it being in spec 
> causes it to fail validation; I thought validation was a holy grail but 
> you are instead suggesting we write HTML that doesn't validate?  Why 
> only argue for validation when it is convenient?

Validation is a tool, not a holy grail.

(If you wanted to use a script, you could use data-template="" to store 
the template. That would validate.)


> > 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.
> 
> What's more important; critical in 5% of cases or nice-to-have in 50% of 
> cases?

I don't understand the relevance of the question.


On Wed, 5 Nov 2008, Mike Schinkel wrote:
>
> Well said; I concur with this analysis and this goal completely. Adding 
> URI Template support to HTML forms reduces the disparity between what 
> can be done with a "website" and what must be done with an "RESTful API 
> server" per se.

It seems like you are arguing here that HTTP URIs with query parameters 
aren't RESTful, which seems like an odd position.

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


From ian at hixie.ch  Tue Dec  2 02:00:11 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 10:00:11 +0000 (UTC)
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <op.uli3jseb1ejg13@sandra-svwliu01>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>
	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>
	<op.ujrzdhip1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>
	<op.ujr3sg0y1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
	<op.uli3jseb1ejg13@sandra-svwliu01>
Message-ID: <Pine.LNX.4.62.0812020957400.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Michael A. Puls II wrote:
> 
> Consider this form:
> 
> <form action="mailto:?subject=1+2" action="POST">
>    <input type="submit" value="Compose">
> </form>
> 
> (which contains a valid mailto URI meaning that "1+2" should be the 
> value of the subject)
> 
> Imagine in your browser that it supports setting the default mailto URI 
> handler to Gmail (a web-based client that uses *http* URIs).
> 
> If you submit that form, you'd get
> <https://mail.google.com/mail/?compose=1&view=cm&fs=1&su=1+2>

Why? How so?

Are you referring to the registerProtocolHandler() API, to mailto: form 
submission, or to something else?

Could you lay out the steps that take us from a form submission using a 
mailto: URL to an HTTPS request to GMail?

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


From ian at hixie.ch  Tue Dec  2 02:31:07 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 10:31:07 +0000 (UTC)
Subject: [whatwg] Errormessages in forms
In-Reply-To: <op.ukgc9yk8o84pey@pc08.ebrana.cz>
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>
	<op.ukgc9yk8o84pey@pc08.ebrana.cz>
Message-ID: <Pine.LNX.4.62.0812021028240.17414@hixie.dreamhostps.com>

On Tue, 11 Nov 2008, Old?ich Vete?n?k wrote:
> 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.

Well, in the snippet above, the following seems adequate:

   <label> Instructions <input name=idfield>
           Type in dd-mm-yyy format</label>

...and the custom error message should be set from script, using 
addCustomValidity(). How is that not accessible? It seems fine to me. The 
AT can read the whole label when entering the field, and the error message 
handling is done by the UA.


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

That seems like an extreme case where even having the elements wouldn't 
really help that much.

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

From ian at hixie.ch  Tue Dec  2 02:44:11 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 10:44:11 +0000 (UTC)
Subject: [whatwg] <input placeholder="">
In-Reply-To: <dd0fbad0811251324t5fc283e7w63e054ff69704686@mail.gmail.com>
References: <BAY109-F34060C84B5AB9C6274445FB41D0@phx.gbl>
	<op.tgvhccg3ir1lcs@daemontooth.bredbandsbolaget.se>
	<Pine.LNX.4.62.0810231147010.1237@hixie.dreamhostps.com>
	<39BEE8AF-F05F-44C3-8434-A8CA362F10F4@phroggy.com>
	<dd0fbad0810231219w2e885b38y8ab38ca9f2f57312@mail.gmail.com>
	<Pine.LNX.4.62.0811170238330.1237@hixie.dreamhostps.com>
	<0f7f0b616f8de6ff3395176311b72de0@myrealbox.com>
	<dd0fbad0811251324t5fc283e7w63e054ff69704686@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812021041100.17414@hixie.dreamhostps.com>

On Mon, 17 Nov 2008, Ojan Vafai wrote:
> 
> This is a useful property on any text input element. Seems like it 
> should apply to textareas as well as contentEditable elements and 
> iframes with designMode on. I can point to real-world examples of the 
> latter if need be. I think it's acceptable that it be a plain-text 
> string in all cases, but that it ought to also be CSS styleable. I don't 
> know if html5 is the right place to spec that. WebKit currently uses the 
> input::-webkit-input-placeholder.

I think for contentEditable it's definitely not something we want to 
support natively; I've no idea how that would even work. I'd recommend 
doing it in CSS, using generated content based on the title="" attribute 
or some such.

For <textarea>, a placeholder value seems odd. Do you have examples of 
people doing that?


On Tue, 25 Nov 2008, Matthew Paul Thomas wrote:
> 
> I was asking, obviously, what use is a default value if you can't edit 
> it. If an enabled text field had a displayed value= but the value was 
> not actually editable, that would be unpleasantly surprising.
> 
> That problem applies just as much to <input placeholder="foo"> as it 
> would have done to <input value="foo" clearonfocus>: depending on 
> whether the placeholder text is greyed out, it would make the field 
> either look like it has a value when it actually doesn't, or look 
> disabled when it actually isn't. It would also hide the label or hint 
> for the field for *precisely* the period when you need it most. I'm not 
> aware of any possible presentation that avoids both (or even one of!) 
> those problems, and previously HTML5 has shied away from expecting 
> browsers to implement things that have no known reasonable presentation.
> 
> I appreciate that Web authors currently go to some scripting lengths to 
> position labels for text fields inside the fields, and I think it's 
> quite appropriate that they should have to go to those lengths, because 
> it makes bad design more difficult. I would rather see, as I've 
> previously suggested, markup for associating form controls with hints 
> outside them in a similar way as labels can be associated now.

I understand your position, but it seems that the industry has moved 
towards this as a pretty standard feature of user interfaces now, for 
better or worse.

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


From ian at hixie.ch  Tue Dec  2 02:47:48 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 10:47:48 +0000 (UTC)
Subject: [whatwg] Review of the 3.16 section and the HTMLInputElement
 interface
In-Reply-To: <fe7db4750811171048k174bf88aq8902b77b130a6efd@mail.gmail.com>
References: <fe7db4750802101511r55df51a1r7c61631ba5c967b7@mail.gmail.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> 
	<Pine.LNX.4.62.0811120014110.1041@hixie.dreamhostps.com>
	<fe7db4750811171048k174bf88aq8902b77b130a6efd@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812021044380.17414@hixie.dreamhostps.com>

On Mon, 17 Nov 2008, Samuel Santos wrote:
> On Wed, Nov 12, 2008 at 12:14 AM, Ian Hickson <ian at hixie.ch> wrote:
> > 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, I've find it really hard to convince someone from english speaking 
> countries that this is an issue. But it really is. As is the limitation 
> of decoration of this control.

As I noted above, I recommend asking browser vendors to implement this.


> What I'm really trying here is to have a valid option in HTML5 so we don't
> have to rely on techniques like these:
> - http://swfupload.org/
> - http://www.quirksmode.org/dom/inputfile.html

This is a security nightmare waiting to happen -- I'm surprised browsers 
let you even change the opacity.

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


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

On Fri, 28 Nov 2008, Anne van Kesteren wrote:
> On Sat, 08 Nov 2008 18:46:48 +0100, Ian Hickson <ian at hixie.ch> wrote:
> > 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?
> 
> How would you disable <td contenteditable> or <div contenteditable> with 
> that strategy and have td:disabled and div:disabled (or something very 
> close to it) work?

It would require something similar to what I had in mind for the very 
neglected Web Controls 1.0 draft, i.e. an API that sets when an element 
is disabled or editable or whatever, that all the other attributes and 
form controls are defined in terms of. (This would also have been a better 
way of doing what ARIA does.)

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


From vetesnik at mrmil.cz  Tue Dec  2 03:18:53 2008
From: vetesnik at mrmil.cz (=?iso-8859-2?B?T2xk+GljaCBWZXRluW7taw==?=)
Date: Tue, 02 Dec 2008 12:18:53 +0100
Subject: [whatwg] Errormessages in forms
In-Reply-To: <Pine.LNX.4.62.0812021028240.17414@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>
	<op.ukgc9yk8o84pey@pc08.ebrana.cz>
	<Pine.LNX.4.62.0812021028240.17414@hixie.dreamhostps.com>
Message-ID: <op.uli8drnao84pey@pc08.ebrana.cz>

Dne Tue, 02 Dec 2008 11:31:07 +0100 Ian Hickson <ian at hixie.ch> napsal/-a:

> Well, in the snippet above, the following seems adequate:
>   <label> Instructions <input name=idfield>
>            Type in dd-mm-yyy format</label>
> ...and the custom error message should be set from script, using
> addCustomValidity(). How is that not accessible? It seems fine to me. The
> AT can read the whole label when entering the field, and the error  
> message handling is done by the UA.

Alright, I agree, I don't have a problem with it. But is it possible to  
create a detailed documentation for this, including "How do I code it  
right?," with wrong good and examples? In my opinion, if there was a good,  
clear and understandable (for human regular beings that is) documentantion  
which developers could refer to, and if it succeeded in getting known  
widely, it could improve the overall knowledge and accessibility. It  
reminds of the longdesc attribute - it's useful but nobody really knows  
how to make it right.

- Ollie


From t.broyer at gmail.com  Tue Dec  2 03:18:47 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Tue, 2 Dec 2008 12:18:47 +0100
Subject: [whatwg] <input placeholder="">
In-Reply-To: <Pine.LNX.4.62.0812021041100.17414@hixie.dreamhostps.com>
References: <BAY109-F34060C84B5AB9C6274445FB41D0@phx.gbl>
	<op.tgvhccg3ir1lcs@daemontooth.bredbandsbolaget.se>
	<Pine.LNX.4.62.0810231147010.1237@hixie.dreamhostps.com>
	<39BEE8AF-F05F-44C3-8434-A8CA362F10F4@phroggy.com>
	<dd0fbad0810231219w2e885b38y8ab38ca9f2f57312@mail.gmail.com>
	<Pine.LNX.4.62.0811170238330.1237@hixie.dreamhostps.com>
	<0f7f0b616f8de6ff3395176311b72de0@myrealbox.com>
	<dd0fbad0811251324t5fc283e7w63e054ff69704686@mail.gmail.com>
	<Pine.LNX.4.62.0812021041100.17414@hixie.dreamhostps.com>
Message-ID: <a9699fd20812020318g7937a1fbtfa9920831a2e5015@mail.gmail.com>

On Tue, Dec 2, 2008 at 11:44 AM, Ian Hickson wrote:
>
> For <textarea>, a placeholder value seems odd. Do you have examples of
> people doing that?

Google Code hosting for adding a comment on an issue:
http://code.google.com/p/support/issues/detail?id=1#makechanges


-- 
Thomas Broyer


From ian at hixie.ch  Tue Dec  2 03:27:52 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 11:27:52 +0000 (UTC)
Subject: [whatwg] CSRFs and Origin header and <form>s
In-Reply-To: <7789133a0811292342x668ed89dx6471229526b8e502@mail.gmail.com>
References: <48756D1A.5010106@sicking.cc>
	<Pine.LNX.4.62.0811300401070.17414@hixie.dreamhostps.com>
	<7789133a0811292204m3f0c04cfnd05c91f9f2d7489b@mail.gmail.com> 
	<Pine.LNX.4.62.0811300607080.17401@hixie.dreamhostps.com> 
	<7789133a0811292238q6c8b583cr29941c733de9c33@mail.gmail.com> 
	<Pine.LNX.4.62.0811300723380.17401@hixie.dreamhostps.com>
	<7789133a0811292342x668ed89dx6471229526b8e502@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812021126510.17414@hixie.dreamhostps.com>


I've added the Origin header to all non-GET browsing context navigation 
and to ping="" processing.

http://html5.org/tools/web-apps-tracker?from=2524&to=2525

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


From shadow2531 at gmail.com  Tue Dec  2 03:45:58 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Tue, 02 Dec 2008 06:45:58 -0500
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <Pine.LNX.4.62.0812020957400.17401@hixie.dreamhostps.com>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>
	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>
	<op.ujrzdhip1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>
	<op.ujr3sg0y1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
	<op.uli3jseb1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020957400.17401@hixie.dreamhostps.com>
Message-ID: <op.uli9lsgs1ejg13@sandra-svwliu01>

On Tue, 02 Dec 2008 05:00:11 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 2 Dec 2008, Michael A. Puls II wrote:
>>
>> Consider this form:
>>
>> <form action="mailto:?subject=1+2" action="POST">
>>    <input type="submit" value="Compose">
>> </form>
>>
>> (which contains a valid mailto URI meaning that "1+2" should be the
>> value of the subject)
>>
>> Imagine in your browser that it supports setting the default mailto URI
>> handler to Gmail (a web-based client that uses *http* URIs).
>>
>> If you submit that form, you'd get
>> <https://mail.google.com/mail/?compose=1&view=cm&fs=1&su=1+2>
>
> Why? How so?
>
> Are you referring to the registerProtocolHandler() API, to mailto: form
> submission, or to something else?

Thanks

I'm talking about a UA associating mailto: links and mailto: form submission with webmail clients (like Gmail for example) by whatever means, just like UAs can do with Thunderbird for example.

This could be done with registerProtocolHandler, but the webmail would have to accept a uri= in its compose URI query string and the function (at least the internal one) couldn't be domain-restricted.

Gmail (and most webmails) currently don't support a uri=, but I have a specific proposal for Gmail if I can find someone to submit it to.

To support Gmail now, registerProtocolHandler would have to be like:

registerProtocolHandler("mailto", function(e) {
    var uri = e.uri;
    // parse the URI to get the individual to, cc, bcc, subject and body hvalues
    // and use them to build a Gmail compose URI
    // Plus, escapeUnsafe and invalid characters and %HH
    // Plus, join multiple occurences of an hvalue
    // using a different algorithm depending on 
    // the type of hvalue.
}, "Compose in Gmail?");

Anyway, goto <http://shadow2531.com/opera/testcases/mailto/register_protocol_handler.html> and click on the first link. If Gmail worked like that, it could totally work around the '+' issue and support a registerProtocolHandler-like function. Of course, Gmail could simply not decode + to ' ' for its to, cc, bcc, body and su hvalues that it currently supports. Then though, there'd still be a bunch of other webmails that'd need to do it also. But, take a look at the source of the pages and the included JS. They show the things that are necessary to implement parsing in a compatible way and will help with your following question.

> Could you lay out the steps that take us from a form submission using a
> mailto: URL to an HTTPS request to GMail?

Maybe this will help:

Download <http://shadow2531.com/opera/userjs/BeforeMailtoURL.js> to a folder.
Edit it and set supportForms to true.

In Opera, goto tools -> preferences -> advanced -> content -> javascript options and set your UserJS folder to the folder BeforeMailtoURL.js is in.

Log in to <http://mail.google.com/>.

Goto <http://shadow2531.com/opera/testcases/mailto/003-post.html> and <http://shadow2531.com/opera/testcases/mailto/003.html> and click compose.

In BeforeMailtoURL.js, you can look at "createMailtoURIFromEnabledFormControls(form)", "if (supportForms)", the MailtoURIParser class and the format() function. And, look at the "if (form.method == "post")" part to see how I convert '+' to "%2B" in the action attribute to avoid this problem. (Note that the way I parse the form isn't complete. Wish: Forms should have a generateDataset() so UAs can do if for you.)

Checking <http://shadow2531.com/opera/testcases/mailto/modern_mailto_uri_scheme.html#forms> and the whole page might help too.

But, basically, with webmail clients, you have to be careful and encode '+' as %2B in all parts of the submitted mailto data, including parts that come from the action attribute.

So, as a suggestion:

On the authoring side, making <form action="mailto:?subject=1+2" method="post"> invalid and <form action="mailto:?subject=1%2B2" method="post"> valid would help.

On a handling side for "mailto:", saying the UA should convert the + to %2B *if* the submitted data will end up in an http URI, might help. This is good because I believe UAs will do this regardless of the spec if they need to support Webmails. Having it specified or hinted at though would be nice.

-- 
Michael


From jgraham at opera.com  Tue Dec  2 04:06:12 2008
From: jgraham at opera.com (James Graham)
Date: Tue, 02 Dec 2008 13:06:12 +0100
Subject: [whatwg] size attribute
Message-ID: <op.uljakmov59ke82@jgraham-desktop>

The phrase "The size attribute gives the number of characters that, in a  
visual rendering, the user agent is to allow the user to see while editing  
the element's value." is phrased misleadingly like a UA conformance  
criterion even though it is not. It doesn't account for the fact that a  
stylesheet may allow the user to see more or fewer characters, or that, in  
a proportional font, the number of characters seen will vary based on the  
control value.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


From ian at hixie.ch  Tue Dec  2 04:16:51 2008
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Dec 2008 12:16:51 +0000 (UTC)
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <op.uli9lsgs1ejg13@sandra-svwliu01>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>
	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>
	<op.ujrzdhip1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>
	<op.ujr3sg0y1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
	<op.uli3jseb1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020957400.17401@hixie.dreamhostps.com>
	<op.uli9lsgs1ejg13@sandra-svwliu01>
Message-ID: <Pine.LNX.4.62.0812021211580.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Michael A. Puls II wrote:
> 
> I'm talking about a UA associating mailto: links and mailto: form 
> submission with webmail clients (like Gmail for example) by whatever 
> means, just like UAs can do with Thunderbird for example.
> 
> This could be done with registerProtocolHandler, but the webmail would 
> have to accept a uri= in its compose URI query string and the function 
> (at least the internal one) couldn't be domain-restricted.
> 
> Gmail (and most webmails) currently don't support a uri=, but I have a 
> specific proposal for Gmail if I can find someone to submit it to.

GMail supports registerProtocolHandler, just use:

   https://mail.google.com/mail/?extsrc=mailto&url=%s


> Anyway, goto 
> <http://shadow2531.com/opera/testcases/mailto/register_protocol_handler.html> 
> and click on the first link. If Gmail worked like that, it could totally 
> work around the '+' issue and support a registerProtocolHandler-like 
> function. Of course, Gmail could simply not decode + to ' ' for its to, 
> cc, bcc, body and su hvalues that it currently supports. Then though, 
> there'd still be a bunch of other webmails that'd need to do it also. 
> But, take a look at the source of the pages and the included JS. They 
> show the things that are necessary to implement parsing in a compatible 
> way and will help with your following question.

I'm very confused. registerProtocolHandler() says to escape the mailto: 
URL, so no "+" characters make it through.

If a tool is processing a mailto: URL manually converting it to an HTTP 
URL, then it has to escape "+" characters too.


> > Could you lay out the steps that take us from a form submission using a
> > mailto: URL to an HTTPS request to GMail?
> 
> Maybe this will help:
> 
> Download <http://shadow2531.com/opera/userjs/BeforeMailtoURL.js> to a folder.
> Edit it and set supportForms to true.
> 
> In Opera, goto tools -> preferences -> advanced -> content -> javascript
> options and set your UserJS folder to the folder BeforeMailtoURL.js is in.
> 
> Log in to <http://mail.google.com/>.
> 
> Goto <http://shadow2531.com/opera/testcases/mailto/003-post.html> and
> <http://shadow2531.com/opera/testcases/mailto/003.html> and click compose.
> 
> In BeforeMailtoURL.js, you can look at
> "createMailtoURIFromEnabledFormControls(form)", "if (supportForms)", the
> MailtoURIParser class and the format() function. And, look at the "if
> (form.method == "post")" part to see how I convert '+' to "%2B" in the action
> attribute to avoid this problem. (Note that the way I parse the form isn't
> complete. Wish: Forms should have a generateDataset() so UAs can do if for
> you.)

Right, if you convert a mailto: URL to an http: URL, you have to convert 
the bytes to be in the right format. So what? That's not a bug, it's what 
happens when you have different semantics in different formats and you 
translate from one to another.


> So, as a suggestion:
> 
> On the authoring side, making <form action="mailto:?subject=1+2" 
> method="post"> invalid and <form action="mailto:?subject=1%2B2" 
> method="post"> valid would help.

That would be a change to the mailto: URL scheme, which is out of scope 
for HTML5.


> On a handling side for "mailto:", saying the UA should convert the + to 
> %2B *if* the submitted data will end up in an http URI, might help.

As far as I can tell, the spec already says that for all cases where this 
might happen.

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


From shadow2531 at gmail.com  Tue Dec  2 04:42:14 2008
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Tue, 02 Dec 2008 07:42:14 -0500
Subject: [whatwg] [WF2] action="mailto:" - encoding spaces
In-Reply-To: <Pine.LNX.4.62.0812021211580.17401@hixie.dreamhostps.com>
References: <6b9c91b20701301917m55912c6vf2627a8e332c814d@mail.gmail.com>
	<Pine.LNX.4.62.0810281959560.1237@hixie.dreamhostps.com>
	<op.ujrzdhip1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0810290740420.1041@hixie.dreamhostps.com>
	<op.ujr3sg0y1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020727170.17414@hixie.dreamhostps.com>
	<op.uli3jseb1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812020957400.17401@hixie.dreamhostps.com>
	<op.uli9lsgs1ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0812021211580.17401@hixie.dreamhostps.com>
Message-ID: <op.uljb8ou71ejg13@sandra-svwliu01>

On Tue, 02 Dec 2008 07:16:51 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 2 Dec 2008, Michael A. Puls II wrote:
>>
>> I'm talking about a UA associating mailto: links and mailto: form
>> submission with webmail clients (like Gmail for example) by whatever
>> means, just like UAs can do with Thunderbird for example.
>>
>> This could be done with registerProtocolHandler, but the webmail would
>> have to accept a uri= in its compose URI query string and the function
>> (at least the internal one) couldn't be domain-restricted.
>>
>> Gmail (and most webmails) currently don't support a uri=, but I have a
>> specific proposal for Gmail if I can find someone to submit it to.
>
> GMail supports registerProtocolHandler, just use:
>
>    https://mail.google.com/mail/?extsrc=mailto&url=%s

Cool thanks.

>> Anyway, goto
>> <http://shadow2531.com/opera/testcases/mailto/register_protocol_handler.html>
>> and click on the first link. If Gmail worked like that, it could totally
>> work around the '+' issue and support a registerProtocolHandler-like
>> function. Of course, Gmail could simply not decode + to ' ' for its to,
>> cc, bcc, body and su hvalues that it currently supports. Then though,
>> there'd still be a bunch of other webmails that'd need to do it also.
>> But, take a look at the source of the pages and the included JS. They
>> show the things that are necessary to implement parsing in a compatible
>> way and will help with your following question.
>
> I'm very confused. registerProtocolHandler() says to escape the mailto:
> URL, so no "+" characters make it through.

That's what I was saying.

> If a tool is processing a mailto: URL manually converting it to an HTTP
> URL, then it has to escape "+" characters too.
>
>
>> > Could you lay out the steps that take us from a form submission using  
>> a
>> > mailto: URL to an HTTPS request to GMail?
>>
>> Maybe this will help:
>>
>> Download <http://shadow2531.com/opera/userjs/BeforeMailtoURL.js> to a  
>> folder.
>> Edit it and set supportForms to true.
>>
>> In Opera, goto tools -> preferences -> advanced -> content -> javascript
>> options and set your UserJS folder to the folder BeforeMailtoURL.js is  
>> in.
>>
>> Log in to <http://mail.google.com/>.
>>
>> Goto <http://shadow2531.com/opera/testcases/mailto/003-post.html> and
>> <http://shadow2531.com/opera/testcases/mailto/003.html> and click  
>> compose.
>>
>> In BeforeMailtoURL.js, you can look at
>> "createMailtoURIFromEnabledFormControls(form)", "if (supportForms)", the
>> MailtoURIParser class and the format() function. And, look at the "if
>> (form.method == "post")" part to see how I convert '+' to "%2B" in the  
>> action
>> attribute to avoid this problem. (Note that the way I parse the form  
>> isn't
>> complete. Wish: Forms should have a generateDataset() so UAs can do if  
>> for
>> you.)
>
> Right, if you convert a mailto: URL to an http: URL, you have to convert
> the bytes to be in the right format. So what? That's not a bug, it's what
> happens when you have different semantics in different formats and you
> translate from one to another.

What I'm saying is that in this case, I shouldn't have to convert '+' to '%2B'. It should be part of of action attribute normalization so that it matches how control values are encoded. Basically, I was looking for consistency here.

For mailto:

<form action="mailto:?subject=1+2" method="POST"></form>

should be like

<form action="mailto:" method="GET"><input name="subject" value="1+2"></form>

in this case, where 1%2B2 is emitted for subject.

Converting '+' to %2B in the action attribute of the POST example doesn't violate the mailto URI spec any more than converting the '+' in the GET example to %2B.

But, since this can be avoided on the authoring side and on the implementation side, I'll leave it at that.

Thanks

-- 
Michael


From timeless at gmail.com  Tue Dec  2 07:07:30 2008
From: timeless at gmail.com (timeless)
Date: Tue, 2 Dec 2008 17:07:30 +0200
Subject: [whatwg] Early feedback on header association algorithm
In-Reply-To: <4934F42A.703@moonset.net>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
Message-ID: <26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>

On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal <aaronlev at moonset.net> wrote:
> Maybe there is a deeper problem if copy & paste doesn't work right because
> of IDs?
>
> Or maybe there should be a node.getDescendantById() method?

maybe, but not with that name.

 Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22 seconds)
 Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41 seconds)

the wikipedia links are confusing enough

http://en.wikipedia.org/wiki/Descendant links to:
http://en.wiktionary.org/wiki/descendent
which has an also link to http://en.wiktionary.org/wiki/descendant
which has a 'US' audio file

So the web says that '-dant' is favored 2:1 over '-dent', which is a
fairly bad margin considering the spelling errors we've seen in
html/http.

I'd sooner see Node.getElementById and risk the confusion of it
returning fewer nodes than Document.getElementById.


From ojan at chromium.org  Tue Dec  2 10:52:12 2008
From: ojan at chromium.org (Ojan Vafai)
Date: Tue, 2 Dec 2008 10:52:12 -0800
Subject: [whatwg] <input placeholder="">
In-Reply-To: <Pine.LNX.4.62.0812021041100.17414@hixie.dreamhostps.com>
References: <BAY109-F34060C84B5AB9C6274445FB41D0@phx.gbl>
	<op.tgvhccg3ir1lcs@daemontooth.bredbandsbolaget.se>
	<Pine.LNX.4.62.0810231147010.1237@hixie.dreamhostps.com>
	<39BEE8AF-F05F-44C3-8434-A8CA362F10F4@phroggy.com>
	<dd0fbad0810231219w2e885b38y8ab38ca9f2f57312@mail.gmail.com>
	<Pine.LNX.4.62.0811170238330.1237@hixie.dreamhostps.com>
	<0f7f0b616f8de6ff3395176311b72de0@myrealbox.com>
	<dd0fbad0811251324t5fc283e7w63e054ff69704686@mail.gmail.com>
	<Pine.LNX.4.62.0812021041100.17414@hixie.dreamhostps.com>
Message-ID: <78dc8440812021052y418f2c92m86c4e8263ed834de@mail.gmail.com>

On Tue, Dec 2, 2008 at 2:44 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 17 Nov 2008, Ojan Vafai wrote:
> > This is a useful property on any text input element. Seems like it
> > should apply to textareas as well as contentEditable elements and
> > iframes with designMode on. I can point to real-world examples of the
> > latter if need be. I think it's acceptable that it be a plain-text
> > string in all cases, but that it ought to also be CSS styleable. I don't
> > know if html5 is the right place to spec that. WebKit currently uses the
> > input::-webkit-input-placeholder.
>
> I think for contentEditable it's definitely not something we want to
> support natively; I've no idea how that would even work. I'd recommend
> doing it in CSS, using generated content based on the title="" attribute
> or some such.
>

I don't follow. What's the difficulty with supporting placeholder for
contentEditable? The point is that you want it to correspond to focus state,
so generated content doesn't really help you much there. You still end up
with complicated code that's hard to get right. For example, I only know of
Google properties that do this (GoogleBase, Groups, Page Creator and
Presentations).


> For <textarea>, a placeholder value seems odd. Do you have examples of
> people doing that?
>

I don't have examples other than Thomas's, however, a quick google
search<http://www.google.com/search?rlz=1C1GGLD_enUS289US301&sourceid=chrome&ie=UTF-8&q=textarea+with+placeholder+text>does
point to a lot of tutorial sites for adding placeholder text to
textareas. I don't quite see what's odd about it though. It's just another
case where you want to communicate what the user should put into an
text-entry area and it has all the same complexity to the web developer that
a text input has.

Ojan


> On Tue, 25 Nov 2008, Matthew Paul Thomas wrote:
> >
> > I was asking, obviously, what use is a default value if you can't edit
> > it. If an enabled text field had a displayed value= but the value was
> > not actually editable, that would be unpleasantly surprising.
> >
> > That problem applies just as much to <input placeholder="foo"> as it
> > would have done to <input value="foo" clearonfocus>: depending on
> > whether the placeholder text is greyed out, it would make the field
> > either look like it has a value when it actually doesn't, or look
> > disabled when it actually isn't. It would also hide the label or hint
> > for the field for *precisely* the period when you need it most. I'm not
> > aware of any possible presentation that avoids both (or even one of!)
> > those problems, and previously HTML5 has shied away from expecting
> > browsers to implement things that have no known reasonable presentation.
> >
> > I appreciate that Web authors currently go to some scripting lengths to
> > position labels for text fields inside the fields, and I think it's
> > quite appropriate that they should have to go to those lengths, because
> > it makes bad design more difficult. I would rather see, as I've
> > previously suggested, markup for associating form controls with hints
> > outside them in a similar way as labels can be associated now.
>
> I understand your position, but it seems that the industry has moved
> towards this as a pretty standard feature of user interfaces now, for
> better or worse.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081202/7a815ca1/attachment.htm>

From alex.baldacchino at email.it  Tue Dec  2 12:07:48 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Tue, 02 Dec 2008 21:07:48 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>
	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
Message-ID: <49359594.4060502@email.it>

Ian Hickson ha scritto:
> On Mon, 1 Dec 2008, Calogero Alex Baldacchino wrote:
>   
>>> Yes, a hash link (<a href="#foo">) will scroll to the element with an 
>>> id=foo.  If coding properly, you'll virtually *never* use an <a> for 
>>> an actual *anchor*, but rather will target the most semantically 
>>> appropriate element, such as a heading or a container with the 
>>> appropriate @id.
>>>       
>> Thanks! That's what I was missing in the specicification (I should give it a
>> more accurate reading). Does it applies to every element, covering the <cite>
>> element too?
>>     
>
> See:
>    http://www.whatwg.org/specs/web-apps/current-work/#scroll-to-fragid
>
> Let me know if that doesn't address your use case.
>
> Cheers,
>   
Indeed it does, and I found such behaviour more consistent than letting 
just the a element with a 'name' or an 'id' being an anchor for 
navigating to a fragment :-)

However, now I have a question. The 3rd step of the algorithm to 
determine "the indicated part of the document" says,

"If there is an element in the DOM that has an ID exactly equal to 
/fragid/, then the first such element in tree order is the indicated 
part of the document; stop the algorithm here."

Shouldn't the id be unique in the whole document? Section 3.3.3.2 says,

"The||| id |attribute represents its element's unique identifier. The 
value must be unique in the subtree within which the element finds 
itself and must contain at least one character. The value must not 
contain any space characters."

then follows,

"If the value is not the empty string, user agents must associate the 
element with the given value (exactly, including any space characters) 
[...]"

First of all, isn't it a bit conflicting? Space characters are legal or 
not? If not, perhaps that might say "discarding any space characters" 
for graceful degradation, or, at the beginning of the paragraph, "If the 
value is not the empty string and does not contain any space characters, 
[...]" if such an id is illegal (for graceful degradation sake, when 
more than one token may be created by skipping any space character, 
either the first token might be chosen, or each token could represent a 
different id, but the latter would require an explicit dealing with 
multiple ids the same way multiple classes are dealt with...). The rest 
of the paragraph says,

"for the purposes of ID matching within the subtree the element finds 
itself (e.g. for selectors in CSS or for the |getElementById()| method 
in the DOM)."

I guess the above covers, for instance, the case of a document holding 
an element with id="foo" and an iframe whose content document holds 
another element with the very same id; but speaking about subtrees might 
suggest the following is legal:

<body>
<div><p id="foo">something</p><p>something else</p></div>
<div><p>something else from <cite id="foo">Whatever Example</cite></p></div>
</body>

since we can separate two different subtrees where the id 'foo' is 
unique. Perhaps that could be true for CSS selectors isolating the 
proper subtree (honestly, I don't remember if actually that's legal in 
CSS, though I've always thought it isn't), but might conflict with the 
DOM, because the method 'getElementById' is defined only for the 
Document interface and from this point of view both elements stay in the 
same document subtree, consisting of the whole document tree. About such 
a case, DOM level 3 Core says, "If more than one element has an ID 
attribute with that value, what is returned is undefined."; as a 
consequence, if the desired behaviour were to select the first matching 
id (for consistence with the use of the first matching id as a fragment 
identifier for HTML documents), or anyway to establish a well defined 
behavior in the case of more than one element with the very same id (I 
don't think we should leave the choice of what to do to the 
implementation, because I don't think we want every browsers potentially 
to deal with clashing ids in a different, browser specific manner), I 
suppose the 'getElementById' method should be redefined accordingly; but 
such can't be done at the level of the 'Document' interface untill 
eventually a 4th specification for its core interfaces, which is out of 
HTML 5 scope.

A solution would be adding 'getElementById' to the HTMLDocument 
interface, but such might be a trouble, since HTMLDocument no more 
inherits from Document, so I can see two possible scenarios. In the 
worst one, a user agent is implemented in a language not supporting 
multiple inerithance, so either the two methods should be implemented in 
the same object with different names (this is bad to expose the 
interface for bindings to script languages supporting inerithance and 
function override), or two different objects should be created, one to 
deal with HTML documents, the other for generic (i.e. xml) documents 
(this is bad in general); in both cases, the above means doubling the 
code and the maintenance needs. In the other scenario, multiple 
inheritance helps us, yet two methods must be defined (but this is a 
minor concern here), and some special care is needed when casting to the 
proper interface to use the proper method and avoid side-effects and 
unwanted behaviours, because without a 'direct' lineage of inheritance 
we cannot avail of polymorphism and late binding without a proper 
casting (this is the main issue with multiple inheritance when it comes 
with doubled fields and methods: everything works, whatever you do, but 
perhaps in the wrong way).

Furthermore, I think any pathways reaching an element, whether through 
CSS or through DOM, must be consistent with each other (I consider this 
as the best way to limit the likelihood of side effects), so if the 
above code is good for CSS selectors capable to target the proper 
subtrees individually, that should be good for the DOM as well, meaning 
not only that 'document.getElementById("foo")' should have a well 
defined behaviour (i.e. picking the first element with a matching id), 
but also that the same subtree individuation and consequent element 
targeting should be possible through the DOM too, that is, there should 
also be a 'getElementById' method in the HTMLElement interface, 
searching for a matching id in the subtree having a given element as its 
root node.

Otherwise, just let the id attribute be unique in the whole document, 
label any duplicate one as illegal and treat it as the empty string, so 
that one only method is enough and the DOM 3 undefined behaviour for 
'getElementById' is no more problematic, being fired by non-allowed DOM 
structures (as don't care conditions). Such would be the easiest choice, 
although there might be any good reason to prefer allowing replicated 
ids inside the same document.

BR, Alex.

---
P.S. The [SELECTORS] reference ( 
http://www.whatwg.org/specs/web-apps/current-work/#refsSELECTORS ) seems 
to be a broken link.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Polizza auto?
* Garanzia furto e incendio per un anno al vantaggioso prezzo di 30 euro tasse incluse!
* Scopri subito l'offerta!
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8425&d=2-12


From bhawkeslewis at googlemail.com  Tue Dec  2 14:47:29 2008
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Tue, 02 Dec 2008 22:47:29 +0000
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <49359594.4060502@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
	<49359594.4060502@email.it>
Message-ID: <4935BB01.9000203@googlemail.com>

Calogero Alex Baldacchino wrote:
> However, now I have a question. The 3rd step of the algorithm to 
> determine "the indicated part of the document" says,
> 
> "If there is an element in the DOM that has an ID exactly equal to 
> /fragid/, then the first such element in tree order is the indicated 
> part of the document; stop the algorithm here."
> 
> Shouldn't the id be unique in the whole document? Section 3.3.3.2 says,
> 
> "The||| id |attribute represents its element's unique identifier. The 
> value must be unique in the subtree within which the element finds 
> itself and must contain at least one character. The value must not 
> contain any space characters."
> 
> then follows,
> 
> "If the value is not the empty string, user agents must associate the 
> element with the given value (exactly, including any space characters) 
> [...]"

I think you're confusing parsing rules that conforming user agents must 
follow to associate identifiers with elements (even when ids are 
duplicated) with the authoring rules that conforming documents must 
follow (ids must be unique). In general, the rules that user agents must 
follow have to deal with non-conforming documents (i.e. the vast 
majority of the web) too. They are generally patterned after the 
(unwritten) rules that existing user agents follow, for backwards 
compatibility reasons. Duplicated id attributes, sadly, are not that rare.

--
Benjamin Hawkes-Lewis


From jonas at sicking.cc  Tue Dec  2 17:12:42 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 02 Dec 2008 17:12:42 -0800
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <492DA279.1070207@sicking.cc>
References: <op.tlq7qta564w2qv@id-c0020>
	<6b9c91b20701061647y7496258cyc73e82da837edce2@mail.gmail.com>
	<Pine.LNX.4.64.0708080557210.9521@dhalsim.dreamhost.com>
	<6b9c91b20708081121n1aebc059u65cd4754cd5f0af@mail.gmail.com>
	<op.twr91vqm7a8kvn@hp-a0a83fcd39d2> <46C72E3F.5020606@sicking.cc>
	<op.tw9073vw7a8kvn@hp-a0a83fcd39d2> <46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
	<48641CBB.8010204@sicking.cc>
	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>
	<492DA279.1070207@sicking.cc>
Message-ID: <4935DD0A.3020401@sicking.cc>

Jonas Sicking wrote:
> Ian Hickson wrote:
>> On Thu, 26 Jun 2008, Jonas Sicking wrote:
>>>> On Sat, 18 Aug 2007, Jonas Sicking wrote:
>>>>> Since ID is case sensitive everywhere else, I don't see a reason to 
>>>>> make
>>>>> an exception from that rule here. That seems to unnecessarily 
>>>>> complicate
>>>>> implementation as well as introduce weird inconsistencies for authors.
>>>> It already is inconsistent for usemap="". At least for legacy Web 
>>>> content I don't think we can do much about it. At that point, I'd 
>>>> rather just extend that to XHTML than to keep another difference.
>>> In mozilla for HTML we only look at the name attribute, and only do 
>>> so case insensitively. For XHTML we only look at the id attribute, 
>>> and are always case sensitive.
>>>
>>> We have had a number of bugs filed on id not working on HTML, (with 
>>> most of them pointing at the XHTML spec as a reason it should work) 
>>> but they all use the same casing for the usemap attribute and the id 
>>> attribute.
>>>
>>> Do you have any data showing that using case sensitive matching for 
>>> the id attribute would break compatibility with any pages?
>>
>> I do not. It seems like something where being incompatible with what 
>> IE does is unnecessary, though.
> 
> I just did a little bit of testing, but it seems like IE *always* treat 
> id's in a case insensitive manner, including for getElementById. If we 
> are duplicating that quirk then we should do it consistently, not just 
> for image maps.
> 
> However I don't think we should.

Just wanted to point out that this part of the message never got replied to.

/ Jonas


From ian at hixie.ch  Tue Dec  2 17:32:21 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 3 Dec 2008 01:32:21 +0000 (UTC)
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <49359594.4060502@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com> 
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>
	<4932C182.5010905@email.it>
	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>
	<4932CC01.9010301@email.it>
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>
	<4933547C.2010501@email.it>
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
	<49341055.1030809@email.it>
	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
	<49359594.4060502@email.it>
Message-ID: <Pine.LNX.4.62.0812030129020.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Calogero Alex Baldacchino wrote:
>
> Indeed it does, and I found such behaviour more consistent than letting 
> just the a element with a 'name' or an 'id' being an anchor for 
> navigating to a fragment :-)
> 
> However, now I have a question. The 3rd step of the algorithm to 
> determine "the indicated part of the document" says,
> 
> "If there is an element in the DOM that has an ID exactly equal to 
> /fragid/, then the first such element in tree order is the indicated 
> part of the document; stop the algorithm here."
> 
> Shouldn't the id be unique in the whole document? Section 3.3.3.2 says,
>
> "The||| id |attribute represents its element's unique identifier. The 
> value must be unique in the subtree within which the element finds 
> itself and must contain at least one character. The value must not 
> contain any space characters."
> 
> then follows,
> 
> "If the value is not the empty string, user agents must associate the 
> element with the given value (exactly, including any space characters) 
> [...]"
> 
> First of all, isn't it a bit conflicting? Space characters are legal or 
> not?

They are not legal. Duplicate IDs are similarly not legal.

We still have to define what happens when people break the rules, though, 
it happens all the time.


> "for the purposes of ID matching within the subtree the element finds 
> itself (e.g. for selectors in CSS or for the |getElementById()| method 
> in the DOM)."
> 
> I guess the above covers, for instance, the case of a document holding 
> an element with id="foo" and an iframe whose content document holds 
> another element with the very same id; but speaking about subtrees might 
> suggest the following is legal:
> 
> <body>
> <div><p id="foo">something</p><p>something else</p></div>
> <div><p>something else from <cite id="foo">Whatever Example</cite></p></div>
> </body>
> 
> since we can separate two different subtrees where the id 'foo' is unique.

Both of those IDs are in the same subtree, so it's not legal.


> Otherwise, just let the id attribute be unique in the whole document, 
> label any duplicate one as illegal and treat it as the empty string, so 
> that one only method is enough and the DOM 3 undefined behaviour for 
> 'getElementById' is no more problematic, being fired by non-allowed DOM 
> structures (as don't care conditions). Such would be the easiest choice, 
> although there might be any good reason to prefer allowing replicated 
> ids inside the same document.

Exactly how getElementById() works is out of scope for HTML5, but in the 
Web DOM Core spec that Simon is working on I imagine he has specced that 
it will pick the first element with a matching ID or some such behavior.

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


From ian at hixie.ch  Tue Dec  2 17:34:17 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 3 Dec 2008 01:34:17 +0000 (UTC)
Subject: [whatwg] usemap="" and related issues
In-Reply-To: <4935DD0A.3020401@sicking.cc>
References: <op.tlq7qta564w2qv@id-c0020>
	<6b9c91b20701061647y7496258cyc73e82da837edce2@mail.gmail.com>
	<Pine.LNX.4.64.0708080557210.9521@dhalsim.dreamhost.com>
	<6b9c91b20708081121n1aebc059u65cd4754cd5f0af@mail.gmail.com>
	<op.twr91vqm7a8kvn@hp-a0a83fcd39d2> <46C72E3F.5020606@sicking.cc>
	<op.tw9073vw7a8kvn@hp-a0a83fcd39d2> <46C973D5.6020704@sicking.cc>
	<op.txcwqkfa64w2qv@annevk-t60.oslo.opera.com>
	<46CA29B5.6080101@sicking.cc>
	<Pine.LNX.4.62.0806050049110.8559@hixie.dreamhostps.com>
	<48641CBB.8010204@sicking.cc>
	<Pine.LNX.4.62.0811260651000.17414@hixie.dreamhostps.com>
	<492DA279.1070207@sicking.cc> <4935DD0A.3020401@sicking.cc>
Message-ID: <Pine.LNX.4.62.0812030133310.17401@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Jonas Sicking wrote:
> > 
> > I just did a little bit of testing, but it seems like IE *always* 
> > treat id's in a case insensitive manner, including for getElementById. 
> > If we are duplicating that quirk then we should do it consistently, 
> > not just for image maps.
> > 
> > However I don't think we should.
> 
> Just wanted to point out that this part of the message never got replied 
> to.

Indeed your entire message didn't get replied to you, it's still an 
outstanding e-mail:

   http://www.whatwg.org/issues/#graphics-usemap

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


From alex.baldacchino at email.it  Tue Dec  2 21:48:34 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 03 Dec 2008 06:48:34 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <4935BB01.9000203@googlemail.com>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	<49359594.4060502@email.it>
	<4935BB01.9000203@googlemail.com>
Message-ID: <49361DB2.1010103@email.it>

Benjamin Hawkes-Lewis ha scritto:
> Calogero Alex Baldacchino wrote:
>> [...]
>>
>
> I think you're confusing parsing rules that conforming user agents 
> must follow to associate identifiers with elements (even when ids are 
> duplicated) with the authoring rules that conforming documents must 
> follow (ids must be unique).

Ok, so what's what?

When you read "The value must not contain any space characters.", is it 
an authoring rule for conforming documents, for you? Ok.

When you read "*If the value is not the empty string, user agents must 
associate the element with the given value (exactly, including any space 
characters)* for the purposes of ID matching within the subtree the 
element finds itself (e.g. for selectors in CSS or for the 
|getElementById()| method in the DOM).", is it a parsing rule for 
conforming user agents, for you? Ok. But, isn't it worth to spend a word 
everywhere in the spec to tell when it's a quirck for backward 
compatibility, which might go away in the future, and when it's not, 
because that's not needed? And when it's a drawback from the past, 
shouldn't it be considered in every aspect? After all, wasn't one of the 
main goals of html 5 to turn unwritten and browser-specific rules into 
written and standard behaviours?

I mean, if you allow spacing characters inside an id value, as a parsing 
rule, you can face something like '<div id="foo bar" >', that is an id 
consisting of more than one token. Is it good to leave it in untouched? 
Yes? Ok, but what does it mean for CSS's, since there is a reference to 
them as one reason to allow space characters? That is, can a browser 
handle an id selector starting with the '#' character and being broken 
by a blank space? Or better, is it legal in CSS? Honestly, again, I 
don't remember well, I've never tried something like that (since makes 
no sense at me), and I think that's illegal. But let's say that's 
illegal for conforming style sheets, but existing user agents may or may 
not allow that, each one with its own behaviour. If we "close one eye" 
for '<div id="foo bar" >' in a piece of HTML 5 code, but leave its CSS 
counterpart to a free implementation, we'll solve half of the problem 
(where the problem is turning unwritten rules to written, and possibly 
improved, standards), won't we? But any kind of "CSS quirks" would be 
out of an HTML specification, and I believe '<div id="foo bar" >' is a 
trouble (if instead "foo bar" is not a valid id selector for CSS in any 
browser, that means we're allowing user agents to parse as valid an id 
which is inconsistent with CSS, and so CSS selectors cannot be a reason 
to allow space characters inside an id string - at least, with respect 
to any direct reference to the identifier value). But it might be a 
trouble per se, even only for html conformance by user agents, since an 
URL fragment might contain escaped space characters, but an escaped 
space isn't the same thing as the space character itself, so the rule of 
exact matching, applied to space characters inside an id, may be a 
trouble without extensively considering the '<div id="foo bar" >' case.

Now, let's say, instead, that a user agent, conforming with HTML 5 
specifications, must cut off any token after the first one (I know 
actually "foo bar" is taken as is), that is <div id="foo bar"> becomes 
<div id="foo "> and <div id=" foo "> is valid too. In such a case, 
skipping any spaces too, and stating the same behaviour for strings 
passed to .getElementById() could be nice as a graceful degradation for 
documents non-conforming with the rule "the value [of an id attribute] 
must not contain any space characters", but such might fail with CSS 
selectors such as 'div[id="foo bar"]'.

Perhaps a compromise, if acceptable for backward compatibility, might be:
- when the id value must be compared to a fragment identifier, strip any 
trailing space characters; if the match fails, escape any other space 
characters both in the id value and in the fragid and try again;
- when an attribute is defined to hold an url and its value has spaces 
in its path/query/fragment, escape them before resolving the url (not 
sure if needed);
- for the purpose of ID matching through the DOM 'getElementById' 
method, leave the id value untouched;
- for the purpose of ID matching through CSS selectors accessing it as 
an attribute, leave the id value untouched;
- for the purpose of ID matching through CSS selectors directly 
accessing it (e.g. '#foo') either choose the first sequence of 
non-spacing characters or let the match fail (I can't decide what's 
better, but perhaps the former would fail as well, since I guess anyone 
coding <div id="foo bar"> not only as a fragment identifier, but also 
for styling, might have the nice idea to write "#foo bar { font-weight : 
bold; }" as well).

Anyway, if the id value is also a fragment identifier, which might have 
space characters (since parsing rules prescribe to add such characters 
to the unreserved production), does the (authoring) rule "the value must 
not contain any space characters" make sense?

Now let's come to the duplicated ids issue. Again, what's what? When 
it's said, "The id attribute represents its element's unique identifier. 
*The value must be unique in the subtree within which the element finds 
itself and must contain at least one character.*", I think that's what 
you call an authoring rule. So, I don't think it was so bad to ask for a 
clarification on the subtree nature. And if a subtree happened to match, 
eventually, an element subtree inside a document, was the suggestion for 
a getElementById method on the HTMLElement interface so awful? 
Otherwise, let's consider (again) the second paragraph:

"If the value is not the empty string, user agents must associate the 
element with the given value (exactly, including any space characters) 
*for the purposes of ID matching within the subtree the element finds 
itself (e.g. for selectors in CSS or for the |getElementById()| method 
in the DOM).*"

It's a parsing rule, isn't it? But it tells also the id must be unique 
in the whole document for the purpose of ID matching through the 
getElementById() method in the DOM, because the only object capable to 
get an element by its id is an instance of the Document interface. So, 
any choice should be taken on what to do with duplicated ids. Solving 
the question at the parser level (i.e. defaulting any duplicated id to 
the empty string) would be consistent with both the fragment identifier 
behaviour (only the first occurrence is valid) and the uniqueness rule, 
but might brake some semantics (i.e. an hyperlink used to create an 
instance of a <dfn>, or a <blockquote> with a cite attribute referencing 
a <cite> element, both with a duplicated id not being the first 
occurrence). On the other hand, leaving the duplicated id in the 
document requires some changes in the Document's getElementById() 
method, since the W3C DOM Core does not define a unique behaviour in 
such a case, and I've expressed a few dubts on solving this by adding an 
equivalent method on the HTMLDocument interface; anyway the 
getElementById() behaviour must be defined for such situations, and 
having it to pick the first match may be a solution (but might cause 
side/unwanted effects if misused in actual documents, and leaves no 
chance to access directly to any element with a duplicated id, but if 
I'm not careful when choosing an ID, I can complain just with myself... 
- anyway, the uniqueness fulfillment might become problematic when 
dinamically putting together pieces of code, perhaps from different 
sources, e.g. using XMLHTTPRequests, or because of externally syndicated 
contet, but this is in the scope of careful programming).

 From the point of view of CSS, both choices may be consistent with 
coupled rules such as "#foo { font-size : 13; }" and #foo { font-size : 
14; }", since both would refer to the same element because of cascading 
rules; on the other side, something like 'div[id="foo"] {/*something 
here*/}' or a direct reference to an ID selector as a descendant of 
different elements might perhaps isolate different elements in the 
document (whether to allow such or not is outside html scope - but are 
such cases in the wild?), and for the purpose of compatibility with 
document styled that way, leaving duplicated ids in the document would 
be a better choice. But, in such cases, shouldn't the DOM elements 
selection be consistent with the CSS elements selection (i.e. to avoid 
side-effects when CSS rules manipulate the DOM itself)? That is, if 
through CSS it were possible to reach elements with duplicated ids in 
different subtrees of a document tree (according to the definition of 
all nodes descendant of a non-leaf node as being part of its subtree) 
and to manipulate their content, shouldn't it be possible through the 
DOM too?

Anyway, I'm not so much confused, no more than usual :-P

BR, Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CheBanca! La prima banca che ti d? gli interessi in anticipo.
* Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7917&d=3-12


From alex.baldacchino at email.it  Tue Dec  2 22:01:55 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 03 Dec 2008 07:01:55 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <Pine.LNX.4.62.0812030129020.17401@hixie.dreamhostps.com>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	<49359594.4060502@email.it>
	<Pine.LNX.4.62.0812030129020.17401@hixie.dreamhostps.com>
Message-ID: <493620D3.6020905@email.it>

Ian Hickson ha scritto:
> Exactly how getElementById() works is out of scope for HTML5, but in the 
> Web DOM Core spec that Simon is working on I imagine he has specced that 
> it will pick the first element with a matching ID or some such behavior.
>
> Cheers,
>   
Is it thought as a somewhat break with w3c DOM Core (e.g. redefining 
interfaces with somehow different properties), as a substitute, or there 
will be continuity (e.g. inheriting and overriding methods to redefine 
their behaviours)?
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Partecipa al concorso Sheba!				
* In palio speciali premi e tanti prodotti Sheba per il tuo gatto! Gioca ora e vinci!				
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8431&d=3-12


From ian at hixie.ch  Tue Dec  2 22:08:35 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 3 Dec 2008 06:08:35 +0000 (UTC)
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <49361DB2.1010103@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>
	<4932C182.5010905@email.it>
	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>
	<4932CC01.9010301@email.it>
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>
	<4933547C.2010501@email.it>
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
	<49341055.1030809@email.it>
	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
	<49359594.4060502@email.it>
	<4935BB01.9000203@googlemail.com> <49361DB2.1010103@email.it>
Message-ID: <Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>

On Wed, 3 Dec 2008, Calogero Alex Baldacchino wrote:
> 
> When you read "The value must not contain any space characters.", is it 
> an authoring rule for conforming documents, for you? Ok.

Right, statements that place requirements on what the values must be are 
authoring requirements.


> When you read "*If the value is not the empty string, user agents must 
> associate the element with the given value (exactly, including any space 
> characters)* for the purposes of ID matching within the subtree the 
> element finds itself (e.g. for selectors in CSS or for the 
> |getElementById()| method in the DOM).", is it a parsing rule for 
> conforming user agents, for you? Ok.

Right, rules that say how to handle values are rules for implementors.


> But, isn't it worth to spend a word everywhere in the spec to tell when 
> it's a quirck for backward compatibility, which might go away in the 
> future, and when it's not, because that's not needed?

None of the implementation requirements in HTML5 will go away in the 
future. We will always have to define how implementation are to handle all 
inputs, today, tomorrow, and 100 years from now. Authors aren't going to 
stop writing invalid documents, unfortunately; and even if they did, the 
documents that exist today aren't going anywhere. (One of the goals of the 
HTML5 project is to document how someone in 2100 AD, or even 21000 AD, 
should handle Web pages of today, so that today's heritage isn't lost.)


> I mean, if you allow spacing characters inside an id value, as a parsing rule,
> you can face something like '<div id="foo bar" >', that is an id consisting of
> more than one token. Is it good to leave it in untouched? Yes? Ok, but what
> does it mean for CSS's, since there is a reference to them as one reason to
> allow space characters? That is, can a browser handle an id selector starting
> with the '#' character and being broken by a blank space?

Sure:

   #foo\ bar { ... }

...would match an element with id="foo bar".


> Or better, is it legal in CSS?

CSS doesn't care about the syntax of IDs, any string (except the empty 
string) can be used as an ID from CSS. However, CSS questions are out of 
scope for this mailing list, so I'll leave it at that.


> Now, let's say, instead, that a user agent, conforming with HTML 5 
> specifications, must cut off any token after the first one (I know 
> actually "foo bar" is taken as is), that is <div id="foo bar"> becomes 
> <div id="foo "> and <div id=" foo "> is valid too. In such a case, 
> skipping any spaces too, and stating the same behaviour for strings 
> passed to .getElementById() could be nice as a graceful degradation for 
> documents non-conforming with the rule "the value [of an id attribute] 
> must not contain any space characters", but such might fail with CSS 
> selectors such as 'div[id="foo bar"]'.

I don't follow you there. What problem are you trying to solve?


> Perhaps a compromise, if acceptable for backward compatibility, might be:
> - when the id value must be compared to a fragment identifier, strip any
> trailing space characters; if the match fails, escape any other space
> characters both in the id value and in the fragid and try again;

Why not just do what we do now, and treat the attribute as-is?


> - when an attribute is defined to hold an url and its value has spaces in its
> path/query/fragment, escape them before resolving the url (not sure if
> needed);

Again, aren't the current rules for handling URLs as defined in HTML5 
enough?


> - for the purpose of ID matching through the DOM 'getElementById' method,
> leave the id value untouched;
> - for the purpose of ID matching through CSS selectors accessing it as an
> attribute, leave the id value untouched;
> - for the purpose of ID matching through CSS selectors directly accessing it
> (e.g. '#foo') either choose the first sequence of non-spacing characters or
> let the match fail (I can't decide what's better, but perhaps the former would
> fail as well, since I guess anyone coding <div id="foo bar"> not only as a
> fragment identifier, but also for styling, might have the nice idea to write
> "#foo bar { font-weight : bold; }" as well).

These are out of scope for this working group, but if you think CSS or the 
DOM should change, then I recommend bringing up these issues with those 
groups.


> Anyway, if the id value is also a fragment identifier, which might have 
> space characters (since parsing rules prescribe to add such characters 
> to the unreserved production), does the (authoring) rule "the value must 
> not contain any space characters" make sense?

Sure, why wouldn't it make sense? If IDs have spaces in them, you can't 
refer to them from space-separated lists of IDs, so to avoid authoring 
problems, authors will want to be told when they acidentally use spaces.


> Now let's come to the duplicated ids issue. Again, what's what? When 
> it's said, "The id attribute represents its element's unique identifier. 
> *The value must be unique in the subtree within which the element finds 
> itself and must contain at least one character.*", I think that's what 
> you call an authoring rule. So, I don't think it was so bad to ask for a 
> clarification on the subtree nature. And if a subtree happened to match, 
> eventually, an element subtree inside a document, was the suggestion for 
> a getElementById method on the HTMLElement interface so awful? 

What terminology would you prefer rather than "subtree"? (We can't say 
document, since we are also trying to define conformance rules for 
disconnected subtrees handled from scripts.)


> Otherwise, let's consider (again) the second paragraph:
> 
> "If the value is not the empty string, user agents must associate the element
> with the given value (exactly, including any space characters) *for the
> purposes of ID matching within the subtree the element finds itself (e.g. for
> selectors in CSS or for the |getElementById()| method in the DOM).*"
> 
> It's a parsing rule, isn't it? But it tells also the id must be unique 
> in the whole document for the purpose of ID matching through the 
> getElementById() method in the DOM, because the only object capable to 
> get an element by its id is an instance of the Document interface. So, 
> any choice should be taken on what to do with duplicated ids. Solving 
> the question at the parser level (i.e. defaulting any duplicated id to 
> the empty string) would be consistent with both the fragment identifier 
> behaviour (only the first occurrence is valid) and the uniqueness rule, 
> but might brake some semantics (i.e. an hyperlink used to create an 
> instance of a <dfn>, or a <blockquote> with a cite attribute referencing 
> a <cite> element, both with a duplicated id not being the first 
> occurrence). On the other hand, leaving the duplicated id in the 
> document requires some changes in the Document's getElementById() 
> method, since the W3C DOM Core does not define a unique behaviour in 
> such a case, and I've expressed a few dubts on solving this by adding an 
> equivalent method on the HTMLDocument interface; anyway the 
> getElementById() behaviour must be defined for such situations, and 
> having it to pick the first match may be a solution (but might cause 
> side/unwanted effects if misused in actual documents, and leaves no 
> chance to access directly to any element with a duplicated id, but if 
> I'm not careful when choosing an ID, I can complain just with myself... 
> - anyway, the uniqueness fulfillment might become problematic when 
> dinamically putting together pieces of code, perhaps from different 
> sources, e.g. using XMLHTTPRequests, or because of externally syndicated 
> contet, but this is in the scope of careful programming).

The getElementById() method will be defined more precisely than the vague 
wording in the DOM specs. I believe Simon Pieters is working on that.


> From the point of view of CSS, both choices may be consistent with 
> coupled rules such as "#foo { font-size : 13; }" and #foo { font-size : 
> 14; }", since both would refer to the same element because of cascading 
> rules; on the other side, something like 'div[id="foo"] {/*something 
> here*/}' or a direct reference to an ID selector as a descendant of 
> different elements might perhaps isolate different elements in the 
> document (whether to allow such or not is outside html scope - but are 
> such cases in the wild?), and for the purpose of compatibility with 
> document styled that way, leaving duplicated ids in the document would 
> be a better choice. But, in such cases, shouldn't the DOM elements 
> selection be consistent with the CSS elements selection (i.e. to avoid 
> side-effects when CSS rules manipulate the DOM itself)? That is, if 
> through CSS it were possible to reach elements with duplicated ids in 
> different subtrees of a document tree (according to the definition of 
> all nodes descendant of a non-leaf node as being part of its subtree) 
> and to manipulate their content, shouldn't it be possible through the 
> DOM too?

CSS doesn't search for a single match for IDs, it just looks for whether 
an element matches the selector or not. So it doesn't care if there are 
duplicates. But anyway, CSS is out of scope for this mailing list.

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


From ian at hixie.ch  Tue Dec  2 22:09:29 2008
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 3 Dec 2008 06:09:29 +0000 (UTC)
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <493620D3.6020905@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com> 
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>
	<4932C182.5010905@email.it>
	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>
	<4932CC01.9010301@email.it>
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>
	<4933547C.2010501@email.it>
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
	<49341055.1030809@email.it>
	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
	<49359594.4060502@email.it>
	<Pine.LNX.4.62.0812030129020.17401@hixie.dreamhostps.com>
	<493620D3.6020905@email.it>
Message-ID: <Pine.LNX.4.62.0812030608500.17401@hixie.dreamhostps.com>

On Wed, 3 Dec 2008, Calogero Alex Baldacchino wrote:
> Ian Hickson ha scritto:
> > Exactly how getElementById() works is out of scope for HTML5, but in the Web
> > DOM Core spec that Simon is working on I imagine he has specced that it will
> > pick the first element with a matching ID or some such behavior.
>
> Is it thought as a somewhat break with w3c DOM Core (e.g. redefining 
> interfaces with somehow different properties), as a substitute, or there 
> will be continuity (e.g. inheriting and overriding methods to redefine 
> their behaviours)?

It's intended as a replacement for DOM3 Core, I believe.

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


From jonas at sicking.cc  Wed Dec  3 11:39:09 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 3 Dec 2008 11:39:09 -0800
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <49359594.4060502@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>
	<4932C182.5010905@email.it>
	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>
	<4932CC01.9010301@email.it>
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>
	<4933547C.2010501@email.it>
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
	<49341055.1030809@email.it>
	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
	<49359594.4060502@email.it>
Message-ID: <63df84f0812031139t10aac92fs670247b9a6a39d1@mail.gmail.com>

> Otherwise, just let the id attribute be unique in the whole document, label
> any duplicate one as illegal and treat it as the empty string, so that one
> only method is enough and the DOM 3 undefined behaviour for 'getElementById'
> is no more problematic, being fired by non-allowed DOM structures (as don't
> care conditions). Such would be the easiest choice, although there might be
> any good reason to prefer allowing replicated ids inside the same document.

Note that having multiple IDs is quite common on real-world pages.
Especially ones that actively modify the DOM since often subtrees
containing nodes with IDs are cloned and reinserted. So if we do this
I expect quite a few pages to break.

In firefox we now always return the first element with the requested
ID. I think IE does the same. This seems equally reliably and much
less likely to cause page breakage or interoperability issues.

As for CSS, I believe in firefox we make all elements with a given ID
match the #foo selector. I don't have a strong feeling if this is the
correct thing to do, or just make the first one match. The only
concern I have is performance.

/ Jonas


From alex.baldacchino at email.it  Wed Dec  3 13:01:43 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 03 Dec 2008 22:01:43 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	<49359594.4060502@email.it>	<4935BB01.9000203@googlemail.com>
	<49361DB2.1010103@email.it>
	<Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>
Message-ID: <4936F3B7.5030908@email.it>

Ian Hickson ha scritto:
> On Wed, 3 Dec 2008, Calogero Alex Baldacchino wrote:
>   
>> But, isn't it worth to spend a word everywhere in the spec to tell when 
>> it's a quirck for backward compatibility, which might go away in the 
>> future, and when it's not, because that's not needed?
>>     
>
> None of the implementation requirements in HTML5 will go away in the 
> future. We will always have to define how implementation are to handle all 
> inputs, today, tomorrow, and 100 years from now. Authors aren't going to 
> stop writing invalid documents, unfortunately; and even if they did, the 
> documents that exist today aren't going anywhere. (One of the goals of the 
> HTML5 project is to document how someone in 2100 AD, or even 21000 AD, 
> should handle Web pages of today, so that today's heritage isn't lost.)
>
>
>   

Ok, and agreed. Due to the nature of the web (and of web authors' 
practices), a strict conformance requirement (such as it might be for a 
C compiler) will never be a good idea.

>> I mean, if you allow spacing characters inside an id value, as a parsing rule,
>> you can face something like '<div id="foo bar" >', that is an id consisting of
>> more than one token. Is it good to leave it in untouched? Yes? Ok, but what
>> does it mean for CSS's, since there is a reference to them as one reason to
>> allow space characters? That is, can a browser handle an id selector starting
>> with the '#' character and being broken by a blank space?
>>     
>
> Sure:
>
>    #foo\ bar { ... }
>
> ...would match an element with id="foo bar".
>
>
>   

Right, now I remember... sorry for my mess...

>> Now, let's say, instead, that a user agent, conforming with HTML 5 
>> specifications, must cut off any token after the first one (I know 
>> actually "foo bar" is taken as is), that is <div id="foo bar"> becomes 
>> <div id="foo "> and <div id=" foo "> is valid too. In such a case, 
>> skipping any spaces too, and stating the same behaviour for strings 
>> passed to .getElementById() could be nice as a graceful degradation for 
>> documents non-conforming with the rule "the value [of an id attribute] 
>> must not contain any space characters", but such might fail with CSS 
>> selectors such as 'div[id="foo bar"]'.
>>     
>
> I don't follow you there. What problem are you trying to solve?
>
>   

Just trying to explain why I was suggesting such a behaviour (= 
stripping space characters) in my first message about that. I was 
wrongly ignoring the case of id="foo bar" and just concerning on id="  
foo ", but not confusing authoring and parsing rules (even if I admit 
sometimes I've strict conformance in mind). If the latter were the only 
"naughty boy" out there, perhaps stripping spaces might have had some 
sense (though not the best choice without touching other things maybe 
out of scope).
>   
>> Perhaps a compromise, if acceptable for backward compatibility, might be:
>> - when the id value must be compared to a fragment identifier, strip any
>> trailing space characters; if the match fails, escape any other space
>> characters both in the id value and in the fragid and try again;
>>     
>
> Why not just do what we do now, and treat the attribute as-is?
>
>
>   
>> - when an attribute is defined to hold an url and its value has spaces in its
>> path/query/fragment, escape them before resolving the url (not sure if
>> needed);
>>     
>
> Again, aren't the current rules for handling URLs as defined in HTML5 
> enough?
>
>   
>   

Maybe the first is wrong, and I'm still unsure of the second. My concern 
is, a character-by-character comparison between an id value and a 
fragment identifier may fail several ways. What for href="#foo bar " and 
id="foo bar "? Actual rules would strip the trailing space only for the 
href, so the matching would fail (but we might survive broken links). 
Escaping both, then comparing would succed, as well as first escaping 
then unescaping the href value before comparing (should it be pointed 
out, somewhere, that a fragment identifier must be unescaped before 
comparing to an id or a name? is it and I've missed it? - having space 
characters in the unreserved production means thy don't need to be 
escaped, but does it mean also they must be decoded from their 
pct-production, after parsing and for resolving?). As well, stripping 
the trailing spaces in both cases would succed, but would fail when 
comparing id="foo bar " with href="#foo bar%20" (which is a valid url, 
according with actual parsing rules), even with escaping rules (in this 
case the id value trailing space must stay there). And what about 
id="foo%20bar" in http://foo.example.org/foo.html  and  href="#foo bar" 
on the same page, or on a page having the same base URL, or a base 
element with href="http://foo.example.org/foo.html" ? My point is, since 
comparisons for matching purpose happen after the URL parsing and 
resolution, and the id value is not involved in such steps, 
character-by-character comparisons may fail without a prior 
normalization of both th fragment-identifier an the id value (or one of 
them). However, if the above is yet solved with parsing and resolving 
rules and I've misunderstood the spec, I retire all and apologize. Or, 
perhaps, must a valid url with a valid fragment, which is equivalent but 
not exactly matching an id value, be considered as a broken link?

>
>   
>> Anyway, if the id value is also a fragment identifier, which might have 
>> space characters (since parsing rules prescribe to add such characters 
>> to the unreserved production), does the (authoring) rule "the value must 
>> not contain any space characters" make sense?
>>     
>
> Sure, why wouldn't it make sense? If IDs have spaces in them, you can't 
> refer to them from space-separated lists of IDs, so to avoid authoring 
> problems, authors will want to be told when they acidentally use spaces.
>
>
>   

I'll try and make that point a bit clearer, since the reference to url 
parsing rules was wrong - the question is another.

That's because of the double nature of the id attribute as both an ID 
and a fragment identifier: according to RFC 3986, unless I have 
misunderstood anything there, after dividing an URI into its component, 
pct-triplets may be safely decoded (and should be to correctly interpret 
each component), thus "%20foo%20bar%20" and " foo bar " are equivalent 
and both valid as conforming dereferenced <fragment-identifier> 
components (while only the former is conforming as a part of a complete 
URI, since for rfc3986 spaces are not 'unreserved'), but the latter is a 
non conforming ID according to the rule "an id value must not contain 
any space characters", which is a somewhat restriction to the 
fragment-identifier conformance. As far as conforming user agents leave 
it as is, that's not a concern; anyway, formally, is it something to be 
solved or pointed out somehow, in the spec? When a validator/an 
authoring tool finds something like,

<!-- The following section is a review of Los Angeles inside an article 
about California
        - just to create a context for the example -->
<section id="Los Angeles" >
...
</section>

shall it only report the id value as mistaken, or has it to say also 
it's a valid fragment identifier if the author is setting the id as an 
anchor?

>
> What terminology would you prefer rather than "subtree"? (We can't say 
> document, since we are also trying to define conformance rules for 
> disconnected subtrees handled from scripts.)
>
>
>   

Uhm, it may depend on what kinds of manipulations you have in mind, 
whether the disconnected subtree must be anyway a whole document to 
fulfil the uniqueness rule, and perhaps also on what the subtree concept 
might be turned into by future DOM Core versions, so maybe just a 
clarification on what a subtree is with respect to both the document (as 
a tree) and the scripts handling possibilities might be enough, instead 
of searching a new terminology, just to 'scope' the id visibility. I 
mean, if the ID matching is relevant for scripts accessing the matching 
element through the getElementById() method, actually a document tree is 
always overlapping the concept of subtree, and a disconnected subtree 
must be a document without a browsing context; otherwise, if other dom 
manipulations are involved the concept of subtree may change, for 
instance a script might implement its own scanning routine, treating an 
id attribute as any other attribute and leading to the concept that any 
non-leaf node may be the root of a subtree (that is identifying a 
subtree with any possible document fragment); furthermore, a possible 
future version of DOM Core interfaces might move the getElementById 
method to the Node interface, leading to the same result. Thus, a 
generic definition of 'subtree' (or no definition, or a definition 
relying upon a specific DOM feature or on script handling) might result 
in a variable concept with a variable scope for the ID uniqueness, but 
might make sense in a working draft until at least a first definition of 
the Web DOM Core specification, or waiting for any reason arising to 
restrict or enlarge the concept; otherwise, if that's been stated with a 
large consensus that a subtree is always a document tree, the term might 
be changed into the expression "a document, with or without a browsing 
context", or (equivalently) be defined as "a document subtree having a 
node of type document as its root" (to cover the case of dynamically 
created documents). Otherwise, if a subtree can be either a whole 
document, or a document subtree detached from its owner document (i.e. a 
node removed from a document with its descendants, or a tree of nodes 
whose ownerDocument property is not defined or null), it might be 
defined just as such, leaving the term 'subtree' wherever it is now (but 
would such a manipulation be consistent with the - authoring - 
uniqueness rule when the subtree is inserted into an actual document?).
> The getElementById() method will be defined more precisely than the vague 
> wording in the DOM specs. I believe Simon Pieters is working on that.
>
>
>   

I acknowledge this.

> CSS doesn't search for a single match for IDs, it just looks for whether 
> an element matches the selector or not. So it doesn't care if there are 
> duplicates. But anyway, CSS is out of scope for this mailing list.
>
>   

I agree, and just wondered whether it may or may not be a concern for 
consistent manipulation through both the DOM and the CSS, but I can't 
focus a concrete example where such a concern might arise, not being a 
side effect of a bad programming out of scope for both CSS and DOM, and 
I also acknowledge that might be in the scope of Web DOM Core, since 
it's been established it's out of scope for HTML specific DOM (which 
doesn't define any basic elements properties and access methods, but 
just html-specifically targeted ones, and I found this is consistent 
with the choice to define some stand-alone interfaces instead of always 
inheriting from the basic counterparts).

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Attiva Carta Eureka! Credito fino a 3.000?, rate da 20? e zero costi di attivazione. Conviene!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8429&d=3-12


From alex.baldacchino at email.it  Wed Dec  3 13:11:52 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 03 Dec 2008 22:11:52 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <Pine.LNX.4.62.0812030608500.17401@hixie.dreamhostps.com>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	<49359594.4060502@email.it>	<Pine.LNX.4.62.0812030129020.17401@hixie.dreamhostps.com>	<493620D3.6020905@email.it>
	<Pine.LNX.4.62.0812030608500.17401@hixie.dreamhostps.com>
Message-ID: <4936F618.9070902@email.it>

Ian Hickson ha scritto:
>
>
> It's intended as a replacement for DOM3 Core, I believe.
>
>   
Then, I hope in a convergence with the W3C, as it's one of the goal of 
the WHATWG. I believe neither organizations wish a heavy standard 
fragmentation.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Dalla top ten al tuo cellulare. Scarica le superhit!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8268&d=3-12


From alex.baldacchino at email.it  Wed Dec  3 14:52:31 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 03 Dec 2008 23:52:31 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <4936F6BA.5080604@sicking.cc>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	
	<4932C182.5010905@email.it>	
	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	
	<4932CC01.9010301@email.it>	
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	
	<4933547C.2010501@email.it>	
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	
	<49341055.1030809@email.it>	
	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	
	<49359594.4060502@email.it>
	<63df84f0812031139t10aac92fs670247b9a6a39d1@mail.gmail.com>
	<4936F4FE.204@email.it> <4936F6BA.5080604@sicking.cc>
Message-ID: <49370DAF.4080303@email.it>


 Jonas Sicking ha scritto:
 >
 > In firefox we now always return the first element with the requested
 > ID. I think IE does the same. This seems equally reliably and much
 > less likely to cause page breakage or interoperability issues.
 >  
 >

That's reasonable, and I pointed out that should be standardized 
(expressing a few doubts on the opportunity to do so through the HTML 
DOM), but now acknowledge that's out of scope for HTML 5.

 >
 > As for CSS, I believe in firefox we make all elements with a given ID
 > match the #foo selector. I don't have a strong feeling if this is the
 > correct thing to do, or just make the first one match. The only
 > concern I have is performance.
 >
 > / Jonas
 >  

That's reasonable too, and I was wondering about possible consistence 
issues with the DOM, but acknowledge as above that such would be out of 
scope for html 5.

 Regards, Alex.


 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Polizza auto?
* Garanzia furto e incendio per un anno al vantaggioso prezzo di 30 euro tasse incluse!
* Scopri subito l'offerta!
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8425&d=3-12


From shess at google.com  Wed Dec  3 15:50:42 2008
From: shess at google.com (Scott Hess)
Date: Wed, 3 Dec 2008 15:50:42 -0800
Subject: [whatwg] Database feedback
In-Reply-To: <278fd46c0811260858n33df3fe9pe60d775c64f7e55e@mail.gmail.com>
References: <278fd46c0808041324i63b2c93eofc32f8b5a58bdefc@mail.gmail.com>
	<Pine.LNX.4.62.0811261059020.17414@hixie.dreamhostps.com>
	<278fd46c0811260858n33df3fe9pe60d775c64f7e55e@mail.gmail.com>
Message-ID: <696e4b7c0812031550h51d49293j2fbf832b4e67b383@mail.gmail.com>

On Wed, Nov 26, 2008 at 8:58 AM, Aaron Boodman <aa at google.com> wrote:
> On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson <ian at hixie.ch> wrote:
>> We could have a .writeTransaction() and a .readTransaction(), where the
>> former always run in isolation.
>>
>> Any preferences?
>
> My preference is for separating read transactions from write
> transactions. Then the API could throw if you tried to write in a read
> transaction.

In SQLite the lock is upgraded as-needed, and it does cause confusion.
 The following can fail to get the write lock at the marked statement:

  BEGIN DEFERRED;
     SELECT x, y, z FROM t WHERE q = ?;
     INSERT INTO j VALUES (?, ?, ?);   -- *mark*
  COMMIT;

In SQLite BEGIN is the same as BEGIN DEFERRED.  Gears changes the
default for BEGIN to BEGIN IMMEDIATE, which acquires the lock right
away.  If a developer wants to do a read-only transaction, they can
explicitly execute BEGIN DEFERRED.

In any case, my point is that upgrading mid-stream seems to be a point
of confusion for people.  You can explain what's happening, and they
will understand it, but the case comes up seldom enough that most
people never internalize it.  Requiring an explicit decision up front
makes things clear, and doesn't absurdly widen the API.

I would lean towards .transaction() and .readTransaction(), though.
Acquiring the lock immediately is almost always the right thing to do.
 You can code a join to get consistent data from multiple tables, but
you cannot code a single statement to insert data consistently into
multiple tables (ignoring triggers), which is why read-only explicit
transactions are rare, and write-only explicit transactions are
common.  I'd say that write-mostly transactions (one or two reads
followed by a bunch of writes) are probably also more common than
read-only transactions.

-scott


From derernst at gmx.ch  Thu Dec  4 02:25:21 2008
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 04 Dec 2008 11:25:21 +0100
Subject: [whatwg] Select elements and radio button/checkbox groups [Was:
 Form Control Group Labels]
In-Reply-To: <Pine.LNX.4.62.0812020748320.17414@hixie.dreamhostps.com>
References: <BAY109-F101C1F09B6FFB148A288F5B4F80@phx.gbl>
	<Pine.LNX.4.62.0810280926050.1237@hixie.dreamhostps.com>
	<a9699fd20810281008i220aeb49t643d4ff1db90d932@mail.gmail.com>
	<490760E2.7080408@googlemail.com>
	<Pine.LNX.4.62.0810282225010.1237@hixie.dreamhostps.com>
	<490831A5.3060703@gmx.ch>
	<Pine.LNX.4.62.0812020748320.17414@hixie.dreamhostps.com>
Message-ID: <4937B011.7060500@gmx.ch>

Ian Hickson schrieb:
[...]
> Why is that a problem? Is converting one to the other a common occurance?
> 
> I'm not really convinced it's that much work. Assuming that the radio 
> buttons and/or checkboxes are written in a consistent manner, which they 
> usually are, a simple regexp search-and-replace on the source is usually 
> enough to convert them.
[...]
> A few seconds with Emacs or any other editor with real search-and-replace 
> tools and you're done.
[...]
> Changing the few lines of code it takes to write a bunch of radio buttons 
> into the few lines of code it takes to write a <select> is easy.
[...]
> I agree entirely that if one is designing the language from scratch it 
> makes sense to be consistent. I'm not sure it makes sense to retroactively 
> change the language to impose consistency on it.

Well, as far as I get the various discussions in the WHATWG list, many 
of them are about one of the following:
- Making things easier
- Introducing features into HTML that are commonly solved by client-side 
(e.g. the extensions to the input element) or server-side scripting 
(e.g. solving the login/logout problem in HTML)
- Improving language consistency (e.g. the discussions about elements 
such as abbr, dfn, small, b etc.)

So I don't think that your arguments do not necessarily make my thoughts 
obsolete. Anyway I see the facts that WF2 is declared feature complete, 
that backwards compatibility has a very high priority, and that making 
form controls more consistent may not be crucial for WF2.

So let me, as a conclusion, repeat two points out of the suggestions I 
made earlier, which I think would be quite helpful, and which do not 
cause backwards compatibility problems, as they degrade to the default 
behaviour of the elements in older UAs. After that I will not insist in 
this topic anymore... :-)

1. Introduce a type attribute to the select element, which can change 
the output into a list of radio buttons (in normal mode) resp. 
checkboxes (in multiple mode).

2. Introduce a multiline attribute to input type="text", possibly 
supplemented by a rows attribute.


From tommy at kvaleberg.com  Thu Dec  4 02:34:56 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Thu, 04 Dec 2008 11:34:56 +0100
Subject: [whatwg] Handling </br> in the "after head" insertion mode
Message-ID: <4937B250.1050801@kvaleberg.com>

Consider the following simple markup:

<!doctype html></br>

If I run it through my parser, which is implemented after the html5 
algorithm, the resulting dom is as follows:

<html>
    <head>
    <body>

The br end tag is a bit special, and should be handled as if it was a br 
start tag. What happens here is as follows: The "before head" insertion 
mode will, upon receiving a br end tag, create a head node and switch to 
the "in head" insertion mode. "in head" will close the head node and 
move on to the "after head" insertion mode. I was expecting "after head" 
to see the </br> and do like it does on a start tag, which is to create 
a body node and move to the "in body" state, but the </br> is just ignored.

I've changed my implementation of "after head" to handle </br> just like 
the "in head" insertion mode, which is:

    An end tag whose tag name is "br"
        Act as described in the "anything else" entry below.

This results in the following dom, for the example above:

<html>
    <head>
    <body>
       <br>

This matches Internet Explorer and Opera, but not Firefox and Safari. 
Then again, it looks like Firefox and Safari ignore all </br> tags.


Regards,
Tommy


From timeless at gmail.com  Thu Dec  4 02:51:05 2008
From: timeless at gmail.com (timeless)
Date: Thu, 4 Dec 2008 12:51:05 +0200
Subject: [whatwg] Handling </br> in the "after head" insertion mode
In-Reply-To: <4937B250.1050801@kvaleberg.com>
References: <4937B250.1050801@kvaleberg.com>
Message-ID: <26b395e60812040251g9fe8143p6cd2e77c46863d02@mail.gmail.com>

On Thu, Dec 4, 2008 at 12:34 PM, Tommy Thorsen <tommy at kvaleberg.com> wrote:
> This matches Internet Explorer and Opera, but not Firefox and Safari. Then
> again, it looks like Firefox and Safari ignore all </br> tags.

if we're both able to get away with ignoring all </br> tags, wouldn't
the ideal forward path be to make always ignored?


From annevk at opera.com  Thu Dec  4 02:54:22 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 04 Dec 2008 11:54:22 +0100
Subject: [whatwg] Handling </br> in the "after head" insertion mode
In-Reply-To: <26b395e60812040251g9fe8143p6cd2e77c46863d02@mail.gmail.com>
References: <4937B250.1050801@kvaleberg.com>
	<26b395e60812040251g9fe8143p6cd2e77c46863d02@mail.gmail.com>
Message-ID: <op.ulmwkwdv64w2qv@annevk-t60.oslo.opera.com>

On Thu, 04 Dec 2008 11:51:05 +0100, timeless <timeless at gmail.com> wrote:
> On Thu, Dec 4, 2008 at 12:34 PM, Tommy Thorsen <tommy at kvaleberg.com>  
> wrote:
>> This matches Internet Explorer and Opera, but not Firefox and Safari.  
>> Then
>> again, it looks like Firefox and Safari ignore all </br> tags.
>
> if we're both able to get away with ignoring all </br> tags, wouldn't
> the ideal forward path be to make always ignored?

Firefox and Safari do not ignore it in quirks mode. I rather keep the  
amount of differences between quirks and standards mode to a minimum (by  
doing what Opera and Internet Explorer do) than increase it.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From hsivonen at iki.fi  Thu Dec  4 03:12:10 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Thu, 4 Dec 2008 13:12:10 +0200
Subject: [whatwg] Handling </br> in the "after head" insertion mode
In-Reply-To: <op.ulmwkwdv64w2qv@annevk-t60.oslo.opera.com>
References: <4937B250.1050801@kvaleberg.com>
	<26b395e60812040251g9fe8143p6cd2e77c46863d02@mail.gmail.com>
	<op.ulmwkwdv64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <687E1DF4-85F0-452A-B57E-606399054981@iki.fi>

One option would be making the tokenizer check if an end tag has the  
name 'br' and turn it into a start tag in the tokenizer. This assumes  
that SVG and MathML won't be able to introduce an element whose local  
name is 'br' anyway.

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




From tommy at kvaleberg.com  Thu Dec  4 03:17:39 2008
From: tommy at kvaleberg.com (Tommy Thorsen)
Date: Thu, 04 Dec 2008 12:17:39 +0100
Subject: [whatwg] Handling </br> in the "after head" insertion mode
In-Reply-To: <op.ulmwkwdv64w2qv@annevk-t60.oslo.opera.com>
References: <4937B250.1050801@kvaleberg.com>
	<26b395e60812040251g9fe8143p6cd2e77c46863d02@mail.gmail.com>
	<op.ulmwkwdv64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <4937BC53.1090303@kvaleberg.com>

Anne van Kesteren wrote:
> On Thu, 04 Dec 2008 11:51:05 +0100, timeless <timeless at gmail.com> wrote:
>> On Thu, Dec 4, 2008 at 12:34 PM, Tommy Thorsen <tommy at kvaleberg.com> 
>> wrote:
>>> This matches Internet Explorer and Opera, but not Firefox and 
>>> Safari. Then
>>> again, it looks like Firefox and Safari ignore all </br> tags.
>>
>> if we're both able to get away with ignoring all </br> tags, wouldn't
>> the ideal forward path be to make always ignored?
>
> Firefox and Safari do not ignore it in quirks mode. I rather keep the 
> amount of differences between quirks and standards mode to a minimum 
> (by doing what Opera and Internet Explorer do) than increase it.
>

Aha, I hadn't even thought about quirks vs. non-quirks. I definitely 
agree that keeping the differences to a minimum is a good thing.

Also, it's not like the specified parsing algorithm ignores </br> 
completely. All the insertion modes from "before html" to "in body" have 
special handling for it, except "after head". This makes it look more 
like someone just forgot to put that </br> handling in "after head" than 
like a deliberate decision to ignore the </br>.

For the record, the following markup:

<!doctype html><body></br>

results in:

<html>
    <head>
    <body>
       <br>

with the current algorithm, because the "in body" insertion mode treats 
</br> as if it was a <br>.



From derernst at gmx.ch  Thu Dec  4 03:45:17 2008
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 04 Dec 2008 12:45:17 +0100
Subject: [whatwg] Select elements and radio button/checkbox groups [Was:
 Form Control Group Labels]
In-Reply-To: <6ea53250810291037p6e44bbd7qae3ebd3404c6fc0f@mail.gmail.com>
References: <BAY109-F101C1F09B6FFB148A288F5B4F80@phx.gbl>	<Pine.LNX.4.62.0810280926050.1237@hixie.dreamhostps.com>	<a9699fd20810281008i220aeb49t643d4ff1db90d932@mail.gmail.com>	<490760E2.7080408@googlemail.com>	<Pine.LNX.4.62.0810282225010.1237@hixie.dreamhostps.com>	<490831A5.3060703@gmx.ch>
	<6ea53250810291037p6e44bbd7qae3ebd3404c6fc0f@mail.gmail.com>
Message-ID: <4937C2CD.6040300@gmx.ch>

Eduard Pascual schrieb am 29.10.2008 18:37:
> On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst <derernst at gmx.ch> wrote:
>> Consider a form with some quite big radio button groups, and now you have do
>> add some more options. After you are done, your boss says: "Ok, great
>> work... but this looks too ugly now, just change it into those dropdown kind
>> of things."
> Honestly, this seems like a presentational issue to me. Isn't CSS3's
> Basic UI module (http://www.w3.org/TR/css3-ui/) enough to handle that?
> Correct me if I'm wrong, but it seems that the properties there would
> allow you to present a radiobutton group as a dropdown menu, and
> vice-versa.

This CSS3 module is indeed an interesting approach, anyway I don't see 
in this spec how possible conflicts between the form structure and it's 
presentation can be avoided or handled. Start with:

<select name="gender">
   <option value="f">Female</option>
   <option value="m">Male</option>
</select>

Now you can easily change the presentation into a radio button group, 
which is fine:

<select name="gender" style="appearance:radio-group">

But then an author does this:

<select name="gender" style="appearance:checkbox-group">

Now there is a conflict, as the form structure allows only a single 
selection, while the presentation allows a multiple one. This does not 
only affect the rendering of the element and the reaction to user 
actions, but is even likely to break the handling of the submitted 
value, as server-side handlers often expect either a single value or an 
array of values and are not configured to cope with both of them.

Now consider some elements written by an even more stupid author:

<select name="gender" style="appearance:password">

<input name="field10" type="text" style="appearance:radio-group">

<fieldset style="appearance:field">
   [some checkboxes...]

...


From t.broyer at gmail.com  Thu Dec  4 07:06:28 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Thu, 4 Dec 2008 16:06:28 +0100
Subject: [whatwg] Select elements and radio button/checkbox groups [Was:
	Form Control Group Labels]
In-Reply-To: <4937C2CD.6040300@gmx.ch>
References: <BAY109-F101C1F09B6FFB148A288F5B4F80@phx.gbl>
	<Pine.LNX.4.62.0810280926050.1237@hixie.dreamhostps.com>
	<a9699fd20810281008i220aeb49t643d4ff1db90d932@mail.gmail.com>
	<490760E2.7080408@googlemail.com>
	<Pine.LNX.4.62.0810282225010.1237@hixie.dreamhostps.com>
	<490831A5.3060703@gmx.ch>
	<6ea53250810291037p6e44bbd7qae3ebd3404c6fc0f@mail.gmail.com>
	<4937C2CD.6040300@gmx.ch>
Message-ID: <a9699fd20812040706w2afeb017xce482a9162c6d963@mail.gmail.com>

On Thu, Dec 4, 2008 at 12:45 PM, Markus Ernst wrote:
> Eduard Pascual schrieb am 29.10.2008 18:37:
>>
>> On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst <derernst at gmx.ch> wrote:
>>>
>>> Consider a form with some quite big radio button groups, and now you have
>>> do
>>> add some more options. After you are done, your boss says: "Ok, great
>>> work... but this looks too ugly now, just change it into those dropdown
>>> kind
>>> of things."
>>
>> Honestly, this seems like a presentational issue to me. Isn't CSS3's
>> Basic UI module (http://www.w3.org/TR/css3-ui/) enough to handle that?
>> Correct me if I'm wrong, but it seems that the properties there would
>> allow you to present a radiobutton group as a dropdown menu, and
>> vice-versa.
>
> This CSS3 module is indeed an interesting approach, anyway I don't see in
> this spec how possible conflicts between the form structure and it's
> presentation can be avoided or handled. Start with:
>
> <select name="gender">
>  <option value="f">Female</option>
>  <option value="m">Male</option>
> </select>
>
> Now you can easily change the presentation into a radio button group, which
> is fine:
>
> <select name="gender" style="appearance:radio-group">
>
> But then an author does this:
>
> <select name="gender" style="appearance:checkbox-group">
>
> Now there is a conflict, as the form structure allows only a single
> selection, while the presentation allows a multiple one. This does not only
> affect the rendering of the element and the reaction to user actions, but is
> even likely to break the handling of the submitted value, as server-side
> handlers often expect either a single value or an array of values and are
> not configured to cope with both of them.

appearance != behavior

CSS3-UI is clear about it:
"""Similarly, the HTML4 <SELECT> element for example, provides a list
or menu of choices to the user. The meaning of the HTML4 <SELECT>
element is that it allows the user to make a choice, to choose
something among several alternatives. This says nothing about its look
and feel, and in fact, the "concept" of a HTML4 <SELECT> could be
visually implemented as a list-box, a popup-menu, or a group of
radio-buttons. Or a group of HTML4 checkboxes (<INPUT
type="checkbox">) could be styled to appear as a group of
radio-buttons, and yet, since those elements are still semantic
checkboxes, they can still be individually checked or unchecked,
rather than acquiring any kind of radio-button group semantic where
only one can be checked.
Each example of presentation has a different look and feel, but
maintains its original meaning, a choice (or choices) among several
alternatives. This proposal addresses only the former (look and feel),
not the latter (meaning)."""
 ? http://www.w3.org/TR/css3-ui/#scope

(the rest of this section brings some additional info of interest in
this discussion, I won't quote it all here)

> Now consider some elements written by an even more stupid author:
>
> <select name="gender" style="appearance:password">
>
> <input name="field10" type="text" style="appearance:radio-group">
>
> <fieldset style="appearance:field">
>  [some checkboxes...]

I guess the UA would, respectively, "draw a password field" (and set
the "password" font and the "text" cursor), "draw the 'frame' that
generally groups radio buttons" and "draw a text field". The "option"
and "optgroup" child elements of the "select" would still be rendered
as "appearance: menu-item" (though without the "popup menu" behavior)
and the checkboxes within the fieldset as "appearance: checkbox"
inside the field. It wouldn't change the fact that the "select"
options are selectable one at a time, that the field's value be
editable and that the checkboxes be checkable.

That would be very bad-looking though ;-)

-- 
Thomas Broyer

From alex.baldacchino at email.it  Thu Dec  4 10:14:46 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Thu, 04 Dec 2008 19:14:46 +0100
Subject: [whatwg] Handling </br> in the "after head" insertion mode
In-Reply-To: <4937BC53.1090303@kvaleberg.com>
References: <4937B250.1050801@kvaleberg.com>	<26b395e60812040251g9fe8143p6cd2e77c46863d02@mail.gmail.com>	<op.ulmwkwdv64w2qv@annevk-t60.oslo.opera.com>
	<4937BC53.1090303@kvaleberg.com>
Message-ID: <49381E16.9020807@email.it>

Tommy Thorsen ha scritto:
>
> For the record, the following markup:
>
> <!doctype html><body></br>
>
> results in:
>
> <html>
>    <head>
>    <body>
>       <br>
>
> with the current algorithm, because the "in body" insertion mode 
> treats </br> as if it was a <br>.
>
Maybe not fully in topic.

Section 4.5.3 says,

"|br| elements must be empty. Any content inside |br| elements must not 
be considered part of the surrounding text."

The first part is clearly an authoring rule. But the second part cannot 
be such as well clearly, because an author might feel that as a 
reference to a parsing rule discarding anything like <br>Something</br> 
(but it isn't). Yet, that can't be a parsing rule, since in contrast 
with the "in body" insertion mode (but not only that), which would turn 
it into <br>Something<br>, thus presenting the content to the end user 
(and obviously that's unlikely anyone visiting a web page would check 
the html code looking for content to ignore :-P). For the purpose of 
validation, the first part should be enough (that is, when a </br> end 
tag is found, an error may be prompted to the author). Perhaps, should 
the second sentence be modified with references to scripts (e.g. to tell 
it is wrong to use a br .innerHTML or .appendChild() to modify the 
document) and to styles (e.g. to tell it's wrong to expect any font 
property will affect the sorrounding text), to make it more clearly an 
authoring rule? Or perhaps changed into an exemple of bad markup? Or 
removed, if source of confusion with parsing rules?

Otherwise, I don't follow its meaning (perhaps I'm the only confused 
one). I mean, as far as I know, xml derived languages require a closing 
tag for every elements, while html has never had such requirements per 
se, but that's a matter of syntax, not semantics. And, semantically 
speaking, whatever (but a closing tag) follows an element which can't 
have children, in the markup, obviously consists of one or more siblings 
of such element, while its closing tag (again, that's syntax), if 
misplaced, or not provided for by syntax rules at all, causes a parse 
error (which may, or may not, be handled gracefully by the u.a., that's 
a matter of parsing rules). That is, declaring an element as "empty" 
should imply per se that the element cannot have any descendant, so its 
content is not... its content, but a syntax error. Perhaps, defining the 
empty content model such way might avoid misunderstandings. Or am I 
making some mistakes?

Best Regards, Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 RC Auto?
* Con Direct Line risparmi oltre il 30% sulla tua polizza! In pi? per te, 15% di extra sconto! Scopri subito l?offerta! 
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8496&d=4-12


From alex.baldacchino at email.it  Thu Dec  4 16:57:55 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 05 Dec 2008 01:57:55 +0100
Subject: [whatwg] URL parsing and same-document references [was: Re: Citing
 multiple <blockquote> elements in HTML5]
In-Reply-To: <4936F3B7.5030908@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	<49359594.4060502@email.it>	<4935BB01.9000203@googlemail.com>	<49361DB2.1010103@email.it>	<Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>
	<4936F3B7.5030908@email.it>
Message-ID: <49387C93.3010004@email.it>

Calogero Alex Baldacchino ha scritto:   
>
> Maybe the first is wrong, and I'm still unsure of the second. My 
> concern is, a character-by-character comparison between an id value 
> and a fragment identifier may fail several ways. What for href="#foo 
> bar " and id="foo bar "? Actual rules would strip the trailing space 
> only for the href, so the matching would fail (but we might survive 
> broken links). Escaping both, then comparing would succed, as well as 
> first escaping then unescaping the href value before comparing (should 
> it be pointed out, somewhere, that a fragment identifier must be 
> unescaped before comparing to an id or a name? is it and I've missed 
> it? - having space characters in the unreserved production means thy 
> don't need to be escaped, but does it mean also they must be decoded 
> from their pct-production, after parsing and for resolving?). As well, 
> stripping the trailing spaces in both cases would succed, but would 
> fail when comparing id="foo bar " with href="#foo bar%20" (which is a 
> valid url, according with actual parsing rules), even with escaping 
> rules (in this case the id value trailing space must stay there). And 
> what about id="foo%20bar" in http://foo.example.org/foo.html  and  
> href="#foo bar" on the same page, or on a page having the same base 
> URL, or a base element with href="http://foo.example.org/foo.html" ? 
> My point is, since comparisons for matching purpose happen after the 
> URL parsing and resolution, and the id value is not involved in such 
> steps, character-by-character comparisons may fail without a prior 
> normalization of both th fragment-identifier an the id value (or one 
> of them). However, if the above is yet solved with parsing and 
> resolving rules and I've misunderstood the spec, I retire all and 
> apologize. Or, perhaps, must a valid url with a valid fragment, which 
> is equivalent but not exactly matching an id value, be considered as a 
> broken link?
>
Maybe the above needs a further clarification. Let me start from URL 
parsing (and resolving) rules: after the URL is validated, it's divided 
into its components, but nothing is stated about normalization and/or 
%-encoded characters. I think that applying a somewhat normalization may 
be useful to parse equivalent URLs in a consistent manner, helpful when 
dealing with the interfaces for URL manipulation, as described in 
section 2.5.5, and, last but not least, an improvement in relative 
references matching (especially same-document references). A minimum 
requirement, for standardization sake, may consist of decoding any 
%-encoded characters in the <fragment> production, which are part of the 
<unreserved> production as defined in RFC 3986 with the changes defined 
in HTML 5 specification for URLs parsing and restricted to the Unicode 
ranges representing valid characters for an attribute value (those which 
are not prohibited neither as 'text' nor as 'character references'). 
This way, a character-for-character comparison between a fragment 
identifier and an id attribute value, which would have been equivalent 
but not matching without the normalization, should success most of 
times, because, as a consequence of the changes applied by HTML 5 
current specification to the <unreserved> production, such characters 
might or might not be %-encoded in a valid URL, while an id value is 
likely to contain them non-encoded.

After the above <fragment> normalization, a character-for-character 
comparison would fail if the id value contained any %-encoded triplet 
representing a decoded character, such as "foo%20bar". Anyway, such may 
be a weird thing to deal with, since it can be the %-encoded form of 
"foo bar", but also the decoded form of "foo%2520bar". In other words, 
if we apply the same normalization to two complete URLs, then we compare 
them, the result is quite reliable, but if we start from a component 
(such as a fragment identifier stored in an id attribute value) it's not 
easy to tell whether any normalization has been applied and which one, 
so there are always chances for false positives or false negatives to 
happen. According with RFC 3986, section "4.4. Same-Document Reference", 
the correct interpretation of a URI as a same-document reference cannot 
be hold as guaranteed, thus the mismatch between, for instance, the  
decoded fragment identifier "foo bar" and the id attribute value 
"foo%20bar", in front of (as I think) a wide majority of good matches, 
can be reasonable. Anyway, a kind of double check might be considered, 
such as:

- comparing the %-unescaped fragment identifier with the ID of each 
element in the DOM;
- upon failure, applying a %-unescape algorithm to the ID, then 
comparing again with the fragment identifier and, if matching, marking 
the element as a 'possible choice';
- upon a perfect (exact) match, without unescaping the evaluated element 
ID, choosing such element as the referenced document part (actually 
defined as "the indicated part of the document" in the spec) and stopping;
- without any perfect match in the whole document, choosing the first 
'possible choice', if any;
- without any match at all, the search for the referenced document part 
fails.

With respect to a "single check" for an exact match, the overall 
computational time should increase linearly, thus not being a 
performance issue.

Best regards, Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 RC Auto?
* Con Direct Line risparmi oltre il 30% sulla tua polizza! In pi? per te, 15% di extra sconto! Scopri subito l?offerta! 
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8496&d=5-12


From aaronlev at moonset.net  Fri Dec  5 07:09:59 2008
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Fri, 05 Dec 2008 16:09:59 +0100
Subject: [whatwg] Early feedback on header association algorithm
In-Reply-To: <26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
References: <4908A0B9.9090705@moonset.net>	
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
Message-ID: <49394447.5040101@moonset.net>

How about node.getElementByIdInSubtree?

On 12/2/2008 4:07 PM, timeless wrote:
> On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal<aaronlev at moonset.net>  wrote:
>    
>> Maybe there is a deeper problem if copy&  paste doesn't work right because
>> of IDs?
>>
>> Or maybe there should be a node.getDescendantById() method?
>>      
>
> maybe, but not with that name.
>
>   Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22 seconds)
>   Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41 seconds)
>
> the wikipedia links are confusing enough
>
> http://en.wikipedia.org/wiki/Descendant links to:
> http://en.wiktionary.org/wiki/descendent
> which has an also link to http://en.wiktionary.org/wiki/descendant
> which has a 'US' audio file
>
> So the web says that '-dant' is favored 2:1 over '-dent', which is a
> fairly bad margin considering the spelling errors we've seen in
> html/http.
>
> I'd sooner see Node.getElementById and risk the confusion of it
> returning fewer nodes than Document.getElementById.
>
>
>    




From alex.baldacchino at email.it  Fri Dec  5 10:19:04 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 05 Dec 2008 19:19:04 +0100
Subject: [whatwg] Early feedback on header association algorithm
In-Reply-To: <49394447.5040101@moonset.net>
References: <4908A0B9.9090705@moonset.net>		<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>		<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>		<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net>
Message-ID: <49397098.2090000@email.it>

Aaron Leventhal ha scritto:
> How about node.getElementByIdInSubtree?
>
> On 12/2/2008 4:07 PM, timeless wrote:
>> On Tue, Dec 2, 2008 at 10:39 AM, Aaron 
>> Leventhal<aaronlev at moonset.net>  wrote:
>>   
>>> Maybe there is a deeper problem if copy&  paste doesn't work right 
>>> because
>>> of IDs?
>>>
>>> Or maybe there should be a node.getDescendantById() method?
>>>      
>>
>> maybe, but not with that name.
>>
>>   Results 1 - 10 of about 4,480,000 for Descendent [definition]. 
>> (0.22 seconds)
>>   Results 1 - 10 of about 8,370,000 for Descendant [definition]. 
>> (0.41 seconds)
>>
>> the wikipedia links are confusing enough
>>
>> http://en.wikipedia.org/wiki/Descendant links to:
>> http://en.wiktionary.org/wiki/descendent
>> which has an also link to http://en.wiktionary.org/wiki/descendant
>> which has a 'US' audio file
>>
>> So the web says that '-dant' is favored 2:1 over '-dent', which is a
>> fairly bad margin considering the spelling errors we've seen in
>> html/http.
>>
>> I'd sooner see Node.getElementById and risk the confusion of it
>> returning fewer nodes than Document.getElementById.
>>
>>
>>    
>
>

That's about the same then moving the getElementById method from the 
Document interface to the Node interface
 (Document inherits from Node, so the actual traversed subtree would 
change basing on the node where the method is invocked, that is 
'anElement = document.getElementById("anEl")' would work as always, 
while anElement.getElementById("anEl") would look for a descendant of 
'anElement' with the same id), because, essentially, IDs are a common 
feature of all document types, despite the actual name of the attribute 
representing an ID, so an eventual .getElementByIdInSubtree() method 
should be defined on a somewhat DOM Core interface, and so would be out 
of scope for HTML 5 (as I've been told .getElementById is - there is a 
'Web DOM Core' specification under construction). But the term 'Subtree' 
arises a problem with HTML 5: actually, the id attribute is defined as 
the element unique ID in the *subtree* whithin which the element is 
found. That is, the term subtree refers to a whole document tree, but 
also to a disconnected subtree handled by a script (and I haven't yet 
understood if such definition refers to a document fragment containing 
nodes detached by any document, or a whole document without a browsing 
context).

Perhaps the possible confusion arising if moving .getElementById() to 
the Node interface might be avoided by leaving it on the document 
interface, and overloading it with, for instance,

Element   getElementById(in DOMString elementId, in Node rootElement);

so a call to document.getElementById would behave as always (or better, 
as it will be redefined in Web DOM Core, that should be 'pick the first 
element with a matching id'), and would coincide with a call to 
document.getElementById("something", document); while a call to 
document.getElementById("something", anElement) would search a matching 
ID among the descendants of 'anElement', whether anElement be a node of 
the current document, or a node removed by any document or created by a 
script, or a node in another document and both the current document and 
the current script context are enabled to access it (but a 'script 
context' is an HTML 5 related concept, so it might be generalized as a 
"DOM access context").

Regards, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Personalizza il tuo cellulare con tantissimi temi!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8275&d=5-12


From mjs at apple.com  Fri Dec  5 10:25:38 2008
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 05 Dec 2008 10:25:38 -0800
Subject: [whatwg] Early feedback on header association algorithm
In-Reply-To: <49394447.5040101@moonset.net>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net>
Message-ID: <6C2BF167-8A21-487D-88F2-3DEE1D2DE40A@apple.com>


On Dec 5, 2008, at 7:09 AM, Aaron Leventhal wrote:

> How about node.getElementByIdInSubtree?

In other cases where a getElement[s]By method is available on both  
Document and other nodes, it has the same name in both cases  
(getElementsByTagName, getElementsByClassName).

Regards,
Maciej

>
>
> On 12/2/2008 4:07 PM, timeless wrote:
>> On Tue, Dec 2, 2008 at 10:39 AM, Aaron  
>> Leventhal<aaronlev at moonset.net>  wrote:
>>
>>> Maybe there is a deeper problem if copy&  paste doesn't work right  
>>> because
>>> of IDs?
>>>
>>> Or maybe there should be a node.getDescendantById() method?
>>>
>>
>> maybe, but not with that name.
>>
>>  Results 1 - 10 of about 4,480,000 for Descendent [definition].  
>> (0.22 seconds)
>>  Results 1 - 10 of about 8,370,000 for Descendant [definition].  
>> (0.41 seconds)
>>
>> the wikipedia links are confusing enough
>>
>> http://en.wikipedia.org/wiki/Descendant links to:
>> http://en.wiktionary.org/wiki/descendent
>> which has an also link to http://en.wiktionary.org/wiki/descendant
>> which has a 'US' audio file
>>
>> So the web says that '-dant' is favored 2:1 over '-dent', which is a
>> fairly bad margin considering the spelling errors we've seen in
>> html/http.
>>
>> I'd sooner see Node.getElementById and risk the confusion of it
>> returning fewer nodes than Document.getElementById.
>>
>>
>>
>
>



From simonp at opera.com  Fri Dec  5 21:37:42 2008
From: simonp at opera.com (Simon Pieters)
Date: Sat, 06 Dec 2008 06:37:42 +0100
Subject: [whatwg] Use cases for Node.getElementById (was: Re: Early feedback
 on header association algorithm)
In-Reply-To: <49397098.2090000@email.it>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>
Message-ID: <op.ulp68waoidj3kv@hp-a0a83fcd39d2>

On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino  
<alex.baldacchino at email.it> wrote:

> That's about the same then moving the getElementById method from the  
> Document interface to the Node interface
>  (Document inherits from Node, so the actual traversed subtree would  
> change basing on the node where the method is invocked, that is  
> 'anElement = document.getElementById("anEl")' would work as always,  
> while anElement.getElementById("anEl") would look for a descendant of  
> 'anElement' with the same id), because, essentially, IDs are a common  
> feature of all document types, despite the actual name of the attribute  
> representing an ID, so an eventual .getElementByIdInSubtree() method  
> should be defined on a somewhat DOM Core interface, and so would be out  
> of scope for HTML 5 (as I've been told .getElementById is - there is a  
> 'Web DOM Core' specification under construction).

(I'm currently the editor of that proposal, currently located at  
http://simon.html5.org/specs/web-dom-core )


> But the term 'Subtree' arises a problem with HTML 5: actually, the id  
> attribute is defined as the element unique ID in the *subtree* whithin  
> which the element is found. That is, the term subtree refers to a whole  
> document tree, but also to a disconnected subtree handled by a script  
> (and I haven't yet understood if such definition refers to a document  
> fragment containing nodes detached by any document, or a whole document  
> without a browsing context).

AIUI, it could also be a disconnected element.


> Perhaps the possible confusion arising if moving .getElementById() to  
> the Node interface might be avoided by leaving it on the document  
> interface, and overloading it with, for instance,
>
> Element   getElementById(in DOMString elementId, in Node rootElement);

You mean that it would only be possible to look for elements that are in  
the document (effectively adding it purely for the case when there are  
duplicate IDs in a document -- which is invalid)?


> so a call to document.getElementById would behave as always (or better,  
> as it will be redefined in Web DOM Core, that should be 'pick the first  
> element with a matching id'), and would coincide with a call to  
> document.getElementById("something", document); while a call to  
> document.getElementById("something", anElement) would search a matching  
> ID among the descendants of 'anElement', whether anElement be a node of  
> the current document, or a node removed by any document or created by a  
> script, or a node in another document and both the current document and  
> the current script context are enabled to access it (but a 'script  
> context' is an HTML 5 related concept, so it might be generalized as a  
> "DOM access context").

Hmm. If you allow it to work on disconnected nodes, why involve the  
'document' at all instead of using Node.getElementById? I think that's  
adding to the confusion. :-)

Anyway, apart from implementing the HTML5 table heading algorithm in  
JavaScript, what are the use cases for this? Given that there's  
Element|Document|DocumentFragment.querySelector('#id') which will return  
the first element with that ID in the given subtree, and that  
Node.getElementById seems to mostly encourage using duplicate IDs, I'm  
reluctant to add it to Web DOM Core. UAs can still have such a method  
internally if they need it.

-- 
Simon Pieters
Opera Software


From hsivonen at iki.fi  Fri Dec  5 22:55:22 2008
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sat, 6 Dec 2008 08:55:22 +0200
Subject: [whatwg] Early feedback on header association algorithm
In-Reply-To: <49394447.5040101@moonset.net>
References: <4908A0B9.9090705@moonset.net>	
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net>
Message-ID: <3F6228ED-3EEE-4BC2-914C-FE4AC8CADDB8@iki.fi>

On Dec 5, 2008, at 17:09, Aaron Leventhal wrote:

> How about node.getElementByIdInSubtree?


It's not sufficient to get an element in a subtree. What's needed is  
getting a cell in the same table--filtering out nested tables.

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




From alex.baldacchino at email.it  Sat Dec  6 19:09:01 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sun, 07 Dec 2008 04:09:01 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <op.ulp68waoidj3kv@hp-a0a83fcd39d2>
References: <4908A0B9.9090705@moonset.net>	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	<49394447.5040101@moonset.net>
	<49397098.2090000@email.it> <op.ulp68waoidj3kv@hp-a0a83fcd39d2>
Message-ID: <493B3E4D.2040507@email.it>

Simon Pieters ha scritto:
> On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino 
> <alex.baldacchino at email.it> wrote:
>
>> [...]
>
> (I'm currently the editor of that proposal, currently located at 
> http://simon.html5.org/specs/web-dom-core )
>

I'm reading it :-)

And I have a few questions. First, is it meant as the reference DOM Core 
for HTML 5 only, or in general (for other kinds of markup too)?

The 'children' attribute on the Element interface, being an 
HTMLCollection instance, suggests me the former might be the answer; 
otherwise, either the reference to a specific document DOM interface, or 
(in the case such interface were moved into Web DOM Core) the reference 
to a specific dom in the name of the interface might perhaps be 
problematic (formally, at least). I guess such attribute has been 
declared on the Element interface instead of the HTMLElement one because 
actually this is the most common implementation in current browsers. 
Anyway, let me suggest (just as a hint, after all a working draft is the 
right phase to explore any alternative) something like an 
ElementCollection interface with the same properties of HTMLCollection, 
making the latter just inheriting from the former as if it were an alias 
(the same way DocumentFragment inherits from Node). On any browser 
implementing 'children' as an HTMLCollection (without any hierarchy), 
this shouldn't be a problem for scripts, since a script language usually 
provides runtime inferred types; for languages with strong types (and 
perhaps here we're moving from scripts to plugins), the access strategy 
may be implementation specific but, as far as the hierarchy of 
interfaces (ElementCollection -> HTMLCollection) does not change the 
properties of an object implementing the HTMLCollection, that shouldn't 
be a lot to work around. For instance, a Java applet (as well as any 
other object implementing LiveConnect) should work fine using the 
JSObject without any modify, while a direct access to the DOM would need 
a DOMServiceProvider implementation (I'm not aware of any granting 
access to the 'children' attribute, or better, to any non-W3C DOM 
properties, but I guess as soon as your proposal became a recommendation 
at least Sun would update such in Java APIs); for such purpose, 
suggesting that any object provided by the user agent as implementing 
either interface should be wrapped by an object also implementing the 
other, for backward compatibility, might be enough (anyway, this is no 
more than a hint, a very early feedback).

I see the Element interface no more contains methods to handle Attr 
nodes: since those are described as not being child nodes of an Element, 
in W3C specifications, there will be any other way to handle attributes 
as nodes, the 'nature' of Attr nodes is going to change, or is there a 
too little use (and/or support) of them, such that the Attr interface 
might be quite close to its 'end of life'? Apart from that, I've also 
noted the 'isId' attribute has been removed from Attr; I was thinking 
just to that when I've read, in HTML 5 spec, that "This specification 
doesn't preclude an element having multiple IDs, if other mechanisms 
(e.g. DOM Core methods) can set an element's ID in a way that doesn't 
conflict with the id attribute". For this purpose, either the 'isId' 
property of an Attr node, or a mechanism to set an Element's attribute 
as an alternative ID (or both) might be helpful (anyway, having more 
then one unique identifier to handle for each element|| in a document 
might cause an increase in duplicated IDs).

The above takes me to the '.getElementsByClassName()' method: if it were 
to be moved from HTML 5 spec to Web DOM Core API, and if the latter is 
meant as some kind of replacement for W3C DOM level 3, perhaps, for 
generality sake, such method might be defined as referring to a property 
named CLASS (along the same lines as ID), pointing out that such 
property might not be binded to an attribute named 'class' (just to make 
the spec ready in case the need to support such sort of document arose 
in the near future, without having to change web dom core, or to derive 
a new version, only for this reason).

But now let's come to your questions (sorry for the digression, 
sometimes I can't help starting this way...)

>
>> But the term 'Subtree' arises a problem with HTML 5: actually, the id 
>> attribute is defined as the element unique ID in the *subtree* 
>> whithin which the element is found. That is, the term subtree refers 
>> to a whole document tree, but also to a disconnected subtree handled 
>> by a script (and I haven't yet understood if such definition refers 
>> to a document fragment containing nodes detached by any document, or 
>> a whole document without a browsing context).
>
> AIUI, it could also be a disconnected element.
>

And I've suggested, in another mail, to clarify it, i.e. telling a 
subtree is either a whole document (to make clearer that '<body><div 
id="the_id" >....</div> <div> ... <div id="the_id" /> </div> </body>' is 
always illegal, regardless the possibility to separate two different 
subtrees in the same document where the id 'the_id' is unique), or a 
group of one or more 'related' disconnected nodes (i.e. a node removed 
from a document with its descendants, a cloned node, a newly created 
one, and so on, that is, in practice, about any tree of nodes without an 
ownerDocument).

However, how is the ID uniqueness to be related to current APIs with 
respect to a disconnected subtree? I mean, if such were relevant for any 
method, such as a .getElementById variant handling disconnected 
elements, the "uniqueness rule" would be quite self-explaining: either 
such a method fails in front of duplicated IDs, or it returns the very 
first match (or does whatever else is established to degrade 
gracefully). But if the subtree traversal/id searching implementation is 
up to a script programmer, the 'id' attribute may be seen as any other 
attribute, and the programmer may opt for considering the uniqueness of 
IDs as non relevant to his/her code in 'off-document' manipulations, 
until the subtree is inserted into a document. Thus, maybe, IDs 
uniqueness should be related to anything being under direct control of 
current APIs (such as documents).

For the rest, my considerations on [whatever].getElementById() were 
general, not referred to a concrete use case (partly being driven by the 
above thoughts), and, for what concerns the email you've replied, 
started from the following:

On 12/2/2008 4:07 PM, timeless wrote:
> On Tue, Dec 2, 2008 at 10:39 AM, Aaron 
> Leventhal<aaronlev at moonset.net>  wrote:
>   
>> Maybe there is a deeper problem if copy&  paste doesn't work right 
>> because
>> of IDs?
>>
>> Or maybe there should be a node.getDescendantById() method?
>>      
>
> maybe, but not with that name.
>
>   Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22 
> seconds)
>   Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41 
> seconds)
>
> the wikipedia links are confusing enough
>
> http://en.wikipedia.org/wiki/Descendant links to:
> http://en.wiktionary.org/wiki/descendent
> which has an also link to http://en.wiktionary.org/wiki/descendant
> which has a 'US' audio file
>
> So the web says that '-dant' is favored 2:1 over '-dent', which is a
> fairly bad margin considering the spelling errors we've seen in
> html/http.
>
> I'd sooner see Node.getElementById and risk *the confusion of it
> returning fewer nodes than Document.getElementById.*
>
>

I guessed the confusion he was concerning might be caused by the general 
confidence people have with .getElementById working on the whole 
document, so that someone might think, after discovering somehow there 
is a getElementById method on every Node (or better, on every element in 
an HTML document), such being working on the whole document as well, 
thus expecting more non null results than a Node.getElementById method 
might return, in general (people anyway should be confident with 
Document.getElementsByTagName working on the whole document while 
Element.getElementsByTagName working on an element descendants... but 
without a crystal ball to guess it, who knows...). Thus, if the above 
were the case, I've suggested something like 
document.getElementById("the_id", startNode), to focus (perhaps!) the 
attention of the average programmer (the same who might have thought 
'anElement.getElementById' being the same as 'document.getElementById') 
on the different behaviour, by 'forcing' the indication of a new 
argument specifying where to start the search (that is, something 
totally new to the programmer).

I agree that encouraging duplicate IDs is not any good idea, and 
whatever method looking for IDs in a document subtree might take to 
that. I really don't like the bare idea of a duplicated ID -- it's a 
somewhat conflicting logic -- and I'm tempted to say a duplicate should 
always break correct execution, especially when the duplicate comes from 
an 'error' in scripting (as when inserting a cloned node without caring 
of side-effects), because, at first glance, I'd regard a duplicate ID as 
whatever else bug making a stand-alone application crashing because of 
side-effects (of course, I'm not telling the browser should crash!), 
and, after all, a gracefully degrading .getElementById (returning the 
very first matching element) cannot prevent side-effects. But I really 
understand, also, duplicate IDs are a common problem asking for a 
solution, or at least a standard graceful degradation (such as the one 
stated for document.getElementById(elementId)).

 From this point of view, and also having in mind a disconnected subtree 
to deal with through the API, maybe something like 
document.getElementById(elementId, rootElement) might make sense if it 
worked _only_ on disconnected subtrees, by first checking whether the 
passed node (or the first descendent not being a document fragment node) 
is effectively disconnected (not in the document), then returning the 
matching element (if any), or null if the traversed subtree is instead 
in the document tree (or even ending with an exception, to encourage a 
greater attention and immediately tell the reason of the failure -- 
returning null might be ambiguous, since that's the same result when no 
matching element is found).

But such method might be confusing, I agree (perhaps might confusion be 
avoided by calling the method getExternalElementById?), and might also 
provide a quite easy way to look for duplicate IDs (e.g. by creating a 
fake document and calling that method on a subtree of another, 
manipulated document -- but such would be a bit tricky, and if I do 
something tricky, I should know that's not the better way to achieve 
some result).

---

Now, let me fly back again off topic on Web DOM Core. Sometime elements 
are conceived to be somewhat leaf elements, conceptually not being 
enabled to have any sort of descendants (this is the case for <br> or 
<base>, i.e., in HTML); yet they're Elements, and Nodes (and 
HTMLElements), thus having attributes and methods allowing, in theory, 
some weird manipulation. I don't know what every browser currently does 
(honestly, I've never tried -- this is a recent doubt of mine), but I 
guess the result might vary from one UA to another, and something 
inappropriate might happen (in any case, there is no standard way to 
block such). Perhaps, a new (readonly) property might be defined on Node 
telling the node is a "definitive leaf", so that whatever 
property/method might be declared as inaccessible/failing (e.g. throwing 
an exception) if the 'isLeaf' property were true -- such an attribute 
cannot be neither an Element, nor an HTMLElement, nor an HTMLElement 
derived interface property, since there are methods on the Node 
interface involved too, and as well the nodeType attribute wouldn't cope 
well with this, because that should work for instances of the same type, 
or regardless the type -- in other words, when trying and changing the 
descendant hierarchy of a node with a true value for such an attribute, 
the result should be an illegal hierarchy. Do you think such might be 
worth to be considered?

(before I forget it, current definition of legal hierarchy seems to cut 
out some legal cases, such as, for instance, an Element with no Text 
child nodes, and the alike -- perhaps, should it be converted into a 
list of illegal hierarchies? the resulting list would cover fewer cases 
than a complete list of legal scenarios - if I haven't misunderstood it).

Best Regards,
Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CAPODANNO A RIMINI HOTEL 2 STELLE
* 2 notti pernottamento con colazione a buffet euro 70,00, 3 notti euro 90,00
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8500&d=7-12


From joao.eiras at gmail.com  Sun Dec  7 06:41:06 2008
From: joao.eiras at gmail.com (=?iso-8859-15?Q?Jo=E3o_Eiras?=)
Date: Sun, 07 Dec 2008 14:41:06 -0000
Subject: [whatwg] Use cases for Node.getElementById (was: Re: Early
 feedback on header association algorithm)
In-Reply-To: <op.ulp68waoidj3kv@hp-a0a83fcd39d2>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>
	<op.ulp68waoidj3kv@hp-a0a83fcd39d2>
Message-ID: <op.ulsq1yeqjz3wb9@umang>


IMO, anyone suggesting a Node.getElementById clearly does not know very  
well how getElementById is supposed to work.
There are ways to transverse a DOM tree currently, either DOM properties  
and methods, XPath, selectors API and such.
Considering ids are required to be unique in the context of a single  
document, implementations can, and do, implement id lookup using optimized  
data structures like a hash table, which is much more performant than  
doing transversal.
So if there is a special node in a document, add an id to it and get its  
reference will be performant (ideally O(1)).

If the uniqueness requirement is removed, then getElementById looses its  
whole meaning and should actually be removed from the specification  
entirely, else then we would need more bloat like getElementById or  
getElementListById and whatever.

If you really need to get the element with id in a subtree, connected or  
disconnected from the main tree, one can use selectors API, DOM  
transversal, XPath, etc.

So, IMO the DOM spec is just fine. What is asked for Node.getElementById  
is already supported by other APIs.



From alex.baldacchino at email.it  Sun Dec  7 11:07:24 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sun, 07 Dec 2008 20:07:24 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <op.ulsq1yeqjz3wb9@umang>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>
	<op.ulp68waoidj3kv@hp-a0a83fcd39d2> <op.ulsq1yeqjz3wb9@umang>
Message-ID: <493C1EEC.6070805@email.it>

Jo?o Eiras ha scritto:
>
> IMO, anyone suggesting a Node.getElementById clearly does not know 
> very well how getElementById is supposed to work.
> There are ways to transverse a DOM tree currently, either DOM 
> properties and methods, XPath, selectors API and such.
> Considering ids are required to be unique in the context of a single 
> document, implementations can, and do, implement id lookup using 
> optimized data structures like a hash table, which is much more 
> performant than doing transversal.
> So if there is a special node in a document, add an id to it and get 
> its reference will be performant (ideally O(1)).

Such a hash table cannot prevent at all the need of traversing the DOM 
tree for the purpose of a _correct_ implementation of .getElementById. A 
DOM tree is a live structure, so the hash table must be checked and 
updated each time a node is removed AND each time a node is inserted, 
for a couple of reasons, and such update may request some kind of tree 
traversing (i.e. to compare nodes relative position). Actually, 
getElementById is being defined as returning the _first_ element with a 
matching ID, as a graceful degradation in case of duplicate IDs and to 
give a better standard (= unique) definition of the expected behavior in 
front of duplicate IDs, than what stated in DOM 3 Core (which leaves 
such behavior unspecified -- it's said to be undefined -- and possibly 
implementation or document specific); this means that, upon insertion of 
a new element, this one might be the new 'first' element with a certain 
id, so its order must be checked and the hash table updated accordingly. 
When an element is removed, independently of the previous scenario, if 
it was in the hash table it might be just removed from the table a well, 
but such wouldn't work fine, because there might be a descendant, or an 
otherwise following element with the same id: after the removal, such 
element would pass from the 'illegal' state of being a duplicate-ID 
element, to the 'legal' state of being the current element to be 
returned by getElementById => the existence of such an element must be 
checked and the hash table updated accordingly. If there are far more 
insertions and/or removals of elements with the id attribute set, than 
calls to getElementById, the advantage of a live hash table vs 
traversing as needed can be quite lost; anyway, a traversal can be quite 
fast, especially if the DOM structure is implemented as a balanced 
binary tree (and I hope you don't wish to implement any kind of 
non-binary tree as the base tree structure).

>
> If the uniqueness requirement is removed, then getElementById looses 
> its whole meaning and should actually be removed from the 
> specification entirely, else then we would need more bloat like 
> getElementById or getElementListById and whatever.

Do you thing that getElementsByTagName and getElementsByClassName are 
bloaty and useless too? However, my point was, and is, another (I'm not 
for Node.getElementById - nor I am strongly against it).

>
> If you really need to get the element with id in a subtree, connected 
> or disconnected from the main tree, one can use selectors API, DOM 
> transversal, XPath, etc.

Currently, the id uniqueness is defined such as constraining not only a 
whole document, but also a disconnected subtree. Then, what API is such 
constraint relevant for? If none, is it worth to declare such constraint 
for disconnected subtrees? Or, is there any need for an API directly 
handling IDs in disconnected subtrees?

In other words, what's being constrained by the id uniqueness in a 
disconnected subtree? A disconnected subtree may be a subtree of another 
document, different from the one currently handled by a script; in this 
case, the id uniqueness is relevant for the actual document containing 
the subtree (while any other document shouldn't be affected by 
cross-document IDs clashes). Otherwise, it may be a subtree external to 
any document, and in such case, perhaps, it might be out of scope for 
HTML 5 documents specification. I'm starting to think that at most it 
might be said, for disconnected subtrees outside any actual html 
document but consisting of html elements, that any API dealing with 
unique identifiers in a disconnected subtree of html elements must treat 
the value of any such element's id attribute as the element default ID 
(the id value uniqueness being a consequence of both its nature as ID 
property and the nature of an API methods targeting an element ID 
property, but not imposed by the specifications, since currently there 
is no such method in the scope of HTML 5 DOM). As a consequence, the id 
value uniqueness might be in scope for a DOM Core specification 
explicitly willing to handle ID properties in a disconnected (and 
'document-less') subtree of Elements, just because the id value 
represent (at least) the first attribute of an HTML element to be 
evaluated looking for an ID property.

Regard, Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Check-up finanziario di Intesa Sanpaolo. Prenotalo subito online, ? gratis e senza impegno.
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8437&d=7-12


From alex.baldacchino at email.it  Sun Dec  7 18:20:18 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Mon, 08 Dec 2008 03:20:18 +0100
Subject: [whatwg] Citing multiple <blockquote> elements in HTML5
In-Reply-To: <Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	<49359594.4060502@email.it>	<4935BB01.9000203@googlemail.com>
	<49361DB2.1010103@email.it>
	<Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>
Message-ID: <493C8462.7040400@email.it>

Ian Hickson ha scritto:
> What terminology would you prefer rather than "subtree"? (We can't say 
> document, since we are also trying to define conformance rules for 
> disconnected subtrees handled from scripts.)
>   

I was thinking again on that. Let me suggest something like the 
following (and just do suggest, I'm far from wishing to impose my point 
of view, and don't want to be pedantic, but I belive deeply exploring 
every alternative may improve the specification).

"The _id_ attribute represents an element unique identifier in the 
subtree within which the element finds itself and must contain at least 
one character. In this context, a subtree is either a whole document 
tree, or a tree of Node instances containing HTMLElements and 
disconnected from any HTML document; a subtree of a document tree is 
contained in a subtree of the first type, thus id values must be unique 
in the containing document (e.g. a duplicate id inside a document tree 
is always illegal, even if a branch of the document can be isolated 
where the id is unique, unless such branch is removed from the document).

This specification requires the _id_ attribute value to be unique in a 
subtree of the former type, thus a subtree of the latter type (e.g. a 
document fragment manipulated by a script) to be inserted into an HTML 
document must fulfil such requirement, as well as any other requirements 
defined in this specification for conformance purpose. Any API dealing 
with ID properties in any type of subtree must consider the _id_ 
attribute value of an HTMLElement as the element's default ID property; 
however, this specification doesn't preclude an element having multiple 
IDs, if other, API-specific mechanisms can set an element's ID in a way 
that doesn't conflict with the id attribute" - then the rest.

One rational for the above is that, formally, a subtree disconnected 
from any actual HTML document might be out of scope for current 
specification, which defines conformance rules for HTML documents and 
related contexts (such as a script context or a browsing context, both 
applying to a 'connected' subtree, as far as I've understood), while a 
subtree which is disconnected from a specific HTML document, but is 
contained into another one (thus coinciding with the containing document 
tree) is yet covered by the constraint for whole documents.

Another rational is that current specification, while relying on at 
least one method affected by IDs uniqueness in a document tree (that is, 
DOM Core Document.getElementById), does not provide, nor refers to, any 
API which might be directly affected by the uniqueness of an id 
attribute value in a disconnected subtree, thus such an API may be 
indirectly related to id values uniqueness if ID properties are relevant 
for its facilities, but the subtree itself cannot be constrained by 
conformance rules before its insertion into an actual HTML document.

A further rational is that a disconnected subtree might contain Node 
instances not implementing the HTMLElement interface, such as a 
DocumentFragment node, but also MathML/SVG elements, which might be 
embedded content elements coming from an HTML document tree, but also 
from a document of a different kind where the embedded content was 
represented by HTML elements, thus, without a sure knowledge on the 
subtree origin, applying an HTML-specific conformance rule might not be 
a correct choice, until the subtree is to be inserted into an HTML document.

For the question related to space characters inside an id value, I'd 
suggest,

"An ID property is not expected to contain space characters, so the 
value of an _id_ attribute should not contain any space characters. 
However, an id attribute can hold a decoded fragment identifier value 
for the purpose of same-document references, thus space characters are 
tolerated for the purpose of conformance, in order to avoid applying 
restrictions to an otherwise legal fragment identifier value not being 
part of a _URL_."

Everything, of course, IMHO.

Best regards,
Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CAPODANNO A RICCIONE
* Speciale Capodanno Bambini con Animazione e Baby Sitter.
* Un bimbo fino a 6 anni GRATIS.
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8503&d=8-12


From simonp at opera.com  Sun Dec  7 22:11:41 2008
From: simonp at opera.com (Simon Pieters)
Date: Mon, 08 Dec 2008 07:11:41 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <493B3E4D.2040507@email.it>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>
	<op.ulp68waoidj3kv@hp-a0a83fcd39d2> <493B3E4D.2040507@email.it>
Message-ID: <op.ultx5rlkidj3kv@zcorpandell.linkoping.osa>

On Sun, 07 Dec 2008 04:09:01 +0100, Calogero Alex Baldacchino  
<alex.baldacchino at email.it> wrote:

> I'm reading it :-)
>
> And I have a few questions. First, is it meant as the reference DOM Core  
> for HTML 5 only, or in general (for other kinds of markup too)?

In general.


> The 'children' attribute on the Element interface, being an  
> HTMLCollection instance, suggests me the former might be the answer;  
> otherwise, either the reference to a specific document DOM interface, or  
> (in the case such interface were moved into Web DOM Core) the reference  
> to a specific dom in the name of the interface might perhaps be  
> problematic (formally, at least).

Is it the name "HTMLCollection" that is the problem?


> I guess such attribute has been declared on the Element interface  
> instead of the HTMLElement one because actually this is the most common  
> implementation in current browsers.

Right. Also because it seems useful for not just HTML.


> Anyway, let me suggest (just as a hint, after all a working draft is the  
> right phase to explore any alternative) something like an  
> ElementCollection interface with the same properties of HTMLCollection,  
> making the latter just inheriting from the former as if it were an alias  
> (the same way DocumentFragment inherits from Node). On any browser  
> implementing 'children' as an HTMLCollection (without any hierarchy),  
> this shouldn't be a problem for scripts, since a script language usually  
> provides runtime inferred types; for languages with strong types (and  
> perhaps here we're moving from scripts to plugins), the access strategy  
> may be implementation specific but, as far as the hierarchy of  
> interfaces (ElementCollection -> HTMLCollection) does not change the  
> properties of an object implementing the HTMLCollection, that shouldn't  
> be a lot to work around. For instance, a Java applet (as well as any  
> other object implementing LiveConnect) should work fine using the  
> JSObject without any modify, while a direct access to the DOM would need  
> a DOMServiceProvider implementation (I'm not aware of any granting  
> access to the 'children' attribute, or better, to any non-W3C DOM  
> properties, but I guess as soon as your proposal became a recommendation  
> at least Sun would update such in Java APIs); for such purpose,  
> suggesting that any object provided by the user agent as implementing  
> either interface should be wrapped by an object also implementing the  
> other, for backward compatibility, might be enough (anyway, this is no  
> more than a hint, a very early feedback).

This seems like adding complexity for political reasons.


> I see the Element interface no more contains methods to handle Attr  
> nodes: since those are described as not being child nodes of an Element,  
> in W3C specifications, there will be any other way to handle attributes  
> as nodes, the 'nature' of Attr nodes is going to change, or is there a  
> too little use (and/or support) of them, such that the Attr interface  
> might be quite close to its 'end of life'?

I'm not sure what to do with attributes. I'd like to drop support for  
attribute nodes (being moved around, etc), if possible, but keep the  
.attributes list and be able to use .value etc on each attribute.


> Apart from that, I've also noted the 'isId' attribute has been removed  
> from Attr;

Right, it hasn't been implemented in the top 4 browsers and it seems like  
a not-so-useful feature to have.


> I was thinking just to that when I've read, in HTML 5 spec, that "This  
> specification doesn't preclude an element having multiple IDs, if other  
> mechanisms (e.g. DOM Core methods) can set an element's ID in a way that  
> doesn't conflict with the id attribute".

It says this, AIUI, because other specs do make it possible, not because  
it's a good idea that it is possible. Personally I think it should not be  
possible (specifically I think 'id' should be like 'xml:id' is and all  
other ways to get an ID-like attribute should be dropped).


> For this purpose, either the 'isId' property of an Attr node, or a  
> mechanism to set an Element's attribute as an alternative ID (or both)  
> might be helpful (anyway, having more then one unique identifier to  
> handle for each element|| in a document might cause an increase in  
> duplicated IDs).

It's not clear to me why it would be helpful.


> The above takes me to the '.getElementsByClassName()' method: if it were  
> to be moved from HTML 5 spec to Web DOM Core API, and if the latter is  
> meant as some kind of replacement for W3C DOM level 3, perhaps, for  
> generality sake, such method might be defined as referring to a property  
> named CLASS (along the same lines as ID), pointing out that such  
> property might not be binded to an attribute named 'class' (just to make  
> the spec ready in case the need to support such sort of document arose  
> in the near future, without having to change web dom core, or to derive  
> a new version, only for this reason).

That's how it's defined in HTML5 already.


> But now let's come to your questions (sorry for the digression,  
> sometimes I can't help starting this way...)
>
>>
>>> But the term 'Subtree' arises a problem with HTML 5: actually, the id  
>>> attribute is defined as the element unique ID in the *subtree* whithin  
>>> which the element is found. That is, the term subtree refers to a  
>>> whole document tree, but also to a disconnected subtree handled by a  
>>> script (and I haven't yet understood if such definition refers to a  
>>> document fragment containing nodes detached by any document, or a  
>>> whole document without a browsing context).
>>
>> AIUI, it could also be a disconnected element.
>>
>
> And I've suggested, in another mail, to clarify it, i.e. telling a  
> subtree is either a whole document (to make clearer that '<body><div  
> id="the_id" >....</div> <div> ... <div id="the_id" /> </div> </body>' is  
> always illegal, regardless the possibility to separate two different  
> subtrees in the same document where the id 'the_id' is unique),

AIUI, the 'subtree' in HTML5 means the tree from the top-most ancestor.  
The spec could be clearer about this.


> or a group of one or more 'related' disconnected nodes (i.e. a node  
> removed from a document with its descendants, a cloned node, a newly  
> created one, and so on, that is, in practice, about any tree of nodes  
> without an ownerDocument).

Don't nodes always have an ownerDocument?


> However, how is the ID uniqueness to be related to current APIs with  
> respect to a disconnected subtree? I mean, if such were relevant for any  
> method, such as a .getElementById variant handling disconnected  
> elements, the "uniqueness rule" would be quite self-explaining: either  
> such a method fails in front of duplicated IDs, or it returns the very  
> first match (or does whatever else is established to degrade  
> gracefully). But if the subtree traversal/id searching implementation is  
> up to a script programmer, the 'id' attribute may be seen as any other  
> attribute, and the programmer may opt for considering the uniqueness of  
> IDs as non relevant to his/her code in 'off-document' manipulations,  
> until the subtree is inserted into a document. Thus, maybe, IDs  
> uniqueness should be related to anything being under direct control of  
> current APIs (such as documents).

Are you arguing that HTML5 should remove the requirement about unique IDs  
for nodes not in a document?


> For the rest, my considerations on [whatever].getElementById() were  
> general, not referred to a concrete use case (partly being driven by the  
> above thoughts),

Ok.


> and, for what concerns the email you've replied, started from the  
> following:
>
> On 12/2/2008 4:07 PM, timeless wrote:
>> On Tue, Dec 2, 2008 at 10:39 AM, Aaron Leventhal<aaronlev at moonset.net>   
>> wrote:
>>
>>> Maybe there is a deeper problem if copy&  paste doesn't work right  
>>> because
>>> of IDs?
>>>
>>> Or maybe there should be a node.getDescendantById() method?
>>>
>>
>> maybe, but not with that name.
>>
>>   Results 1 - 10 of about 4,480,000 for Descendent [definition]. (0.22  
>> seconds)
>>   Results 1 - 10 of about 8,370,000 for Descendant [definition]. (0.41  
>> seconds)
>>
>> the wikipedia links are confusing enough
>>
>> http://en.wikipedia.org/wiki/Descendant links to:
>> http://en.wiktionary.org/wiki/descendent
>> which has an also link to http://en.wiktionary.org/wiki/descendant
>> which has a 'US' audio file
>>
>> So the web says that '-dant' is favored 2:1 over '-dent', which is a
>> fairly bad margin considering the spelling errors we've seen in
>> html/http.
>>
>> I'd sooner see Node.getElementById and risk *the confusion of it
>> returning fewer nodes than Document.getElementById.*
>>
>>
>
> I guessed the confusion he was concerning might be caused by the general  
> confidence people have with .getElementById working on the whole  
> document, so that someone might think, after discovering somehow there  
> is a getElementById method on every Node (or better, on every element in  
> an HTML document), such being working on the whole document as well,  
> thus expecting more non null results than a Node.getElementById method  
> might return, in general (people anyway should be confident with  
> Document.getElementsByTagName working on the whole document while  
> Element.getElementsByTagName working on an element descendants... but  
> without a crystal ball to guess it, who knows...). Thus, if the above  
> were the case, I've suggested something like  
> document.getElementById("the_id", startNode), to focus (perhaps!) the  
> attention of the average programmer (the same who might have thought  
> 'anElement.getElementById' being the same as 'document.getElementById')  
> on the different behaviour, by 'forcing' the indication of a new  
> argument specifying where to start the search (that is, something  
> totally new to the programmer).
>
> I agree that encouraging duplicate IDs is not any good idea, and  
> whatever method looking for IDs in a document subtree might take to  
> that. I really don't like the bare idea of a duplicated ID -- it's a  
> somewhat conflicting logic -- and I'm tempted to say a duplicate should  
> always break correct execution, especially when the duplicate comes from  
> an 'error' in scripting (as when inserting a cloned node without caring  
> of side-effects), because, at first glance, I'd regard a duplicate ID as  
> whatever else bug making a stand-alone application crashing because of  
> side-effects (of course, I'm not telling the browser should crash!),  
> and, after all, a gracefully degrading .getElementById (returning the  
> very first matching element) cannot prevent side-effects. But I really  
> understand, also, duplicate IDs are a common problem asking for a  
> solution, or at least a standard graceful degradation (such as the one  
> stated for document.getElementById(elementId)).
>
>  From this point of view, and also having in mind a disconnected subtree  
> to deal with through the API, maybe something like  
> document.getElementById(elementId, rootElement) might make sense if it  
> worked _only_ on disconnected subtrees, by first checking whether the  
> passed node (or the first descendent not being a document fragment node)  
> is effectively disconnected (not in the document), then returning the  
> matching element (if any), or null if the traversed subtree is instead  
> in the document tree (or even ending with an exception, to encourage a  
> greater attention and immediately tell the reason of the failure --  
> returning null might be ambiguous, since that's the same result when no  
> matching element is found).
>
> But such method might be confusing, I agree (perhaps might confusion be  
> avoided by calling the method getExternalElementById?), and might also  
> provide a quite easy way to look for duplicate IDs (e.g. by creating a  
> fake document and calling that method on a subtree of another,  
> manipulated document -- but such would be a bit tricky, and if I do  
> something tricky, I should know that's not the better way to achieve  
> some result).

I guess the best way to avoid confusion is to not add the feature at all.  
:-)


> ---
>
> Now, let me fly back again off topic on Web DOM Core. Sometime elements  
> are conceived to be somewhat leaf elements, conceptually not being  
> enabled to have any sort of descendants (this is the case for <br> or  
> <base>, i.e., in HTML); yet they're Elements, and Nodes (and  
> HTMLElements), thus having attributes and methods allowing, in theory,  
> some weird manipulation.

Right. <br> can have children by using XHTML or by DOM manipulation.


> I don't know what every browser currently does (honestly, I've never  
> tried -- this is a recent doubt of mine),

Opera, Firefox and Safari don't throw. IE does.


> but I guess the result might vary from one UA to another, and something  
> inappropriate might happen (in any case, there is no standard way to  
> block such). Perhaps, a new (readonly) property might be defined on Node  
> telling the node is a "definitive leaf", so that whatever  
> property/method might be declared as inaccessible/failing (e.g. throwing  
> an exception) if the 'isLeaf' property were true -- such an attribute  
> cannot be neither an Element, nor an HTMLElement, nor an HTMLElement  
> derived interface property, since there are methods on the Node  
> interface involved too, and as well the nodeType attribute wouldn't cope  
> well with this, because that should work for instances of the same type,  
> or regardless the type -- in other words, when trying and changing the  
> descendant hierarchy of a node with a true value for such an attribute,  
> the result should be an illegal hierarchy. Do you think such might be  
> worth to be considered?

I don't understand why it would be useful.


> (before I forget it, current definition of legal hierarchy seems to cut  
> out some legal cases, such as, for instance, an Element with no Text  
> child nodes, and the alike -- perhaps, should it be converted into a  
> list of illegal hierarchies? the resulting list would cover fewer cases  
> than a complete list of legal scenarios - if I haven't misunderstood it).

Um. Yeah. Actually it rules out everything (a node can't be a Document and  
a Text node at the same time, for instance). I think i'll move the  
checking into each algorithm that's adding stuff to the tree instead (in  
due course).


Thanks for the feedback,
-- 
Simon Pieters
Opera Software


From aaronlev at moonset.net  Mon Dec  8 02:39:23 2008
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Mon, 08 Dec 2008 11:39:23 +0100
Subject: [whatwg] Early feedback on header association algorithm
In-Reply-To: <3F6228ED-3EEE-4BC2-914C-FE4AC8CADDB8@iki.fi>
References: <4908A0B9.9090705@moonset.net>		<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>		<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>		<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	<49394447.5040101@moonset.net>
	<3F6228ED-3EEE-4BC2-914C-FE4AC8CADDB8@iki.fi>
Message-ID: <493CF95B.5070108@moonset.net>

IMO it's not worth all the extra code and confusion to write a special 
table (but not inner table) ID getter.

- Aaron

On 12/6/2008 7:55 AM, Henri Sivonen wrote:
> On Dec 5, 2008, at 17:09, Aaron Leventhal wrote:
>
>> How about node.getElementByIdInSubtree?
>
>
> It's not sufficient to get an element in a subtree. What's needed is 
> getting a cell in the same table--filtering out nested tables.
>




From aaronlev at moonset.net  Mon Dec  8 02:46:52 2008
From: aaronlev at moonset.net (Aaron Leventhal)
Date: Mon, 08 Dec 2008 11:46:52 +0100
Subject: [whatwg] Question about allowed <ol> and <ul> descendants
Message-ID: <493CFB1C.8010409@moonset.net>

http://dev.w3.org/html5/spec/Overview.html#the-ol-element

 > Categories:Flow content 
<http://dev.w3.org/html5/spec/Overview.html#flow-content-0>
 > Contexts in which this element may be used: Where flow content 
<http://dev.w3.org/html5/spec/Overview.html#flow-content-0> is expected.
 > Content model: Zero or more |li 
<http://dev.w3.org/html5/spec/Overview.html#the-li-element>| elements.

Is there a conflict between these things? It seems that the <ul> and 
<ol> elements allow flow content.
On the one hand, that seems to allow many kinds of descendants, such as 
child lists. However, the content model says that only <li> children are 
expected.

What about nested lists, like this?
<ol>
<li>Apples</li>
<li>Oranges
<ol>
<li>Seeded</li>
<li>Navel</li>
</ol>
</li>
</ol>

I would think that's allowed. So, what kinds of content are allowed 
inside of <ol> and <ul>?

- Aaron




From annevk at opera.com  Mon Dec  8 02:54:50 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Mon, 08 Dec 2008 11:54:50 +0100
Subject: [whatwg] Question about allowed <ol> and <ul> descendants
In-Reply-To: <493CFB1C.8010409@moonset.net>
References: <493CFB1C.8010409@moonset.net>
Message-ID: <op.ulua9oef64w2qv@annevk-t60.oslo.opera.com>

On Mon, 08 Dec 2008 11:46:52 +0100, Aaron Leventhal <aaronlev at moonset.net>  
wrote:
> http://dev.w3.org/html5/spec/Overview.html#the-ol-element
>  > Categories:Flow content  
> <http://dev.w3.org/html5/spec/Overview.html#flow-content-0>
>  > Contexts in which this element may be used: Where flow content  
> <http://dev.w3.org/html5/spec/Overview.html#flow-content-0> is expected.
>  > Content model: Zero or more |li  
> <http://dev.w3.org/html5/spec/Overview.html#the-li-element>| elements.
>
> Is there a conflict between these things? It seems that the <ul> and  
> <ol> elements allow flow content.

No they don't. They are "flow content" and can be put where "flow content"  
can be put, but they can only contain <li> elements for the moment.


> On the one hand, that seems to allow many kinds of descendants, such as  
> child lists. However, the content model says that only <li> children are  
> expected.
>
> What about nested lists, like this?
> <ol>
> <li>Apples</li>
> <li>Oranges
> <ol>
> <li>Seeded</li>
> <li>Navel</li>
> </ol>
> </li>
> </ol>
>
> I would think that's allowed. So, what kinds of content are allowed  
> inside of <ol> and <ul>?

If you want to nest lists the <ol> or <ul> should go inside a <li>, ever  
since lists have been invented. ;-)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From alex.baldacchino at email.it  Mon Dec  8 13:30:32 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Mon, 08 Dec 2008 22:30:32 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <op.ultx5rlkidj3kv@zcorpandell.linkoping.osa>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>
	<op.ulp68waoidj3kv@hp-a0a83fcd39d2> <493B3E4D.2040507@email.it>
	<op.ultx5rlkidj3kv@zcorpandell.linkoping.osa>
Message-ID: <493D91F8.4090607@email.it>

Simon Pieters ha scritto:
> On Sun, 07 Dec 2008 04:09:01 +0100, Calogero Alex Baldacchino 
> <alex.baldacchino at email.it> wrote:
>
>> I'm reading it :-)
>>
>> And I have a few questions. First, is it meant as the reference DOM 
>> Core for HTML 5 only, or in general (for other kinds of markup too)?
>
> In general.

Ok.

>
>
> Is it the name "HTMLCollection" that is the problem?
>

Perhaps. I don't know and can't guess how much 'political consensus' 
might be needed to make the specification fly (especially if trying a 
convergence with w3c). Maybe, the support of the main browsers vendors 
is more than enough, and a name is not much of a problem in practice. 
Anyway, since that's just a formal/political matter, that may be solved 
when and if needed, I've just pointed out a possible solution (but I'm 
sure you don't need my suggestions to get there, or to find a better one 
:-P).

>
>> I guess such attribute has been declared on the Element interface 
>> instead of the HTMLElement one because actually this is the most 
>> common implementation in current browsers.
>
> Right. Also because it seems useful for not just HTML.
>

Well, on one hand it duplicates a NodeList of child nodes, but on the 
other hand only Element nodes are listed, and this can be useful in 
practice, I agree. :-)

>
>> Anyway, let me suggest [..]
>
> This seems like adding complexity for political reasons.
>

Hmm, for a script no complexity would be added (I mean, a script engine 
embedded in a UA would implement the same interface as the UA, but the 
script code would work fine because of runtime inferred types -- the 
instanceof operator, in ECMAScript, might fail indeed, but such may fail 
anyway in IE, which seems not to expose the DOM hierarchy of an object). 
LiveConnect should work fine as well; any other access to the DOM 
through a plugin may require a whole implementation to make new DOM 
property types/interfaces available as compile-time known 
types/interfaces (I'm not sure, but I think that Java, actually, doesn't 
provide access to non w3c dom 2 properties -- true, at least, for some 
versions of the VM and related DOMAccessProvider objects; I don't know 
if there are third parties implementations allowing that -- and I also 
guess some non-standard interface might be adopted, in implementations, 
to give access to every properties of an html document without having 
always to cast to the proper interface, since HTMLDocument no more 
inherits from Document). Such an implementation might require objects 
wrapping at some point (e.g. to maintain consistency between 
corresponding data types), thus adding a constraint to anything likely 
yet needed shouldn't be too expensive for the implementors. Anyway, yes, 
that's mainly a formal/political need, and obviously can be added as 
needed (as above, :-P)

>
>
> I'm not sure what to do with attributes. I'd like to drop support for 
> attribute nodes (being moved around, etc), if possible, but keep the 
> .attributes list and be able to use .value etc on each attribute.
>

Good question. Unless moving .value/.name on the Node interface (which I 
guess might be problematic for backward compatibility), a Node-derived 
interface is needed to accomplish that, unless changing the list 
'nature' as well (but with similar issues, and not solving the need for 
an interface defining the .value and .name interface)...

>
>> I was thinking just to that when I've read, in HTML 5 spec, that 
>> "This specification doesn't preclude an element having multiple IDs, 
>> if other mechanisms (e.g. DOM Core methods) can set an element's ID 
>> in a way that doesn't conflict with the id attribute".
>
> It says this, AIUI, because other specs do make it possible, not 
> because it's a good idea that it is possible.

I understand it the same way (and guess such specs might allow custom ID 
attributes).

> Personally I think it should not be possible (specifically I think 
> 'id' should be like 'xml:id' is and all other ways to get an ID-like 
> attribute should be dropped).
>

I agree. But I'm not sure if that's a 'safe' choice in a general DOM 
(maybe it is considering actual needs; if support for those other ways 
were needed in the future, it might always be added in a future 
version/revision of Web DOM Core, and wouldn't conflict with html 5 
spec, in reason of that statement -- backward compatibility'd be no more 
problematic than it is today for new HTML tags, but changes and breaks 
are unavoidable if they're good evolutions - unless there is yet some 
degree of support for ID-like attributes, so the break might be less 
safe, but I guess that's not the case).

>
>> For this purpose, either the 'isId' property of an Attr node, or a 
>> mechanism to set an Element's attribute as an alternative ID (or 
>> both) might be helpful [...]
>
> It's not clear to me why it would be helpful.
>

If ID-like attributes were to be supported, specially user defined ones, 
providing any mechanism to set such attributes and/or check their 
'nature' might be useful both in script (i.e. when manipulating the DOM 
and willing to treat ID-like attributes differently from other 
attributes, in order to just check their nature instead of looking for 
matching names) and perhaps for the DOM itself (anyway, methods such 
.getElementById() would need only an implementation-level knowledge of 
the attribute nature - that is, just to rely on an internal property, 
but exposing such a property wouldn't be a ugly choice). However, if 
ID-like attributes won't be supported, there is no need for any suitable 
mechanism to handle them, of course.

>
>> The above takes me to the '.getElementsByClassName()' method: if it 
>> were to be moved from HTML 5 spec to Web DOM Core API, and if the 
>> latter is meant as some kind of replacement for W3C DOM level 3, 
>> perhaps, for generality sake, such method might be defined as 
>> referring to a property named CLASS (along the same lines as ID), 
>> pointing out that such property might not be binded to an attribute 
>> named 'class' (just to make the spec ready in case the need to 
>> support such sort of document arose in the near future, without 
>> having to change web dom core, or to derive a new version, only for 
>> this reason).
>
> That's how it's defined in HTML5 already.
>

Indeed, HTML5 defines such method behaviour without referring to the 
actual class-attribute, but in the end explicitly refers to it for HTML, 
MathML and SVG elements. Maybe that part might be modified when moving 
the method from HTML5 spec to a more general DOM spec, and I wondered 
whether pointing out that a class-attribute may have any name different 
from 'class' (perhaps leaving the reference to a somewhat document type 
as an example), the same way DOM 3 Core does it for IDs, might have been 
a nice formalism.

>
> AIUI, the 'subtree' in HTML5 means the tree from the top-most 
> ancestor. The spec could be clearer about this.
>

Yes, that's its meaning. In a previous mail, Ian Hickson answered me 
such term was chosen to formalize conformance for disconnected trees 
handled by scripts.

>
> Don't nodes always have an ownerDocument?
>

Yes, the always have one... I don't know where my head was when writing 
that... I should have referred to the parentNode property (which is null 
for removed an cloned nodes, for instance), and/or the topmost node not 
being a (html)document node.

>
> Are you arguing that HTML5 should remove the requirement about unique 
> IDs for nodes not in a document?
>

Let me clarify I'm not aiming to argue with anyone about anything. I'm 
just trying and showing an alternative point of view, hoping it may be 
helpful in the process of spec definition.

I'm not sure if a conformance rule for an HTML document may apply in 
such a case, even because a disconnected subtree might come from a 
non-HTML document (I'm not necessarily referring to an existing one, 
since HTML5 spec is thought to define conformance rules also for future 
UAs willing to handle 'older' html5 documents: such UAs might support 
any kind of document embedding html tags the same way html5 allows 
embedding MathML and SVG tags, and such a 'new' kind of document might 
have relaxed requirements for ids, thus I think HTML5 rules should not 
conflict with such, or better, should not define rules for HTML elements 
possibly originated outside an HTML document). Anyway, an ID is an ID 
and an HTML element's  id attribute represents the default ID property 
for its element in any kind of subtree, so, perhaps, indicating such as 
relevant for any api dealing with ID properties, and requiring 
conformance with HTML rules for any subtree to be inserted in any HTML 
document (where duplicate IDs are illegal), instead of declaring 
id-attribute values as always unique, might be reasonable. That's all 
(and I understand, perhaps that's splitting hairs).

>
> I guess the best way to avoid confusion is to not add the feature at 
> all. :-)
>

That's ok for me. Unless a real need for handling unique IDs in 
disconnected subtree arose, avoiding that is a good choice. :-)

>
>> [...]
>
> Right. <br> can have children by using XHTML or by DOM manipulation.
>
>
>> I don't know what every browser currently does (honestly, I've never 
>> tried -- this is a recent doubt of mine),
>
> Opera, Firefox and Safari don't throw. IE does.
>
>
>> but I guess the result might vary from one UA to another, and 
>> something inappropriate might happen (in any case, there is no 
>> standard way to block such). Perhaps, a new (readonly) property might 
>> be defined on Node telling the node is a "definitive leaf", so that 
>> whatever property/method might be declared as inaccessible/failing 
>> (e.g. throwing an exception) if the 'isLeaf' property were true -- 
>> such an attribute cannot be neither an Element, nor an HTMLElement, 
>> nor an HTMLElement derived interface property, since there are 
>> methods on the Node interface involved too, and as well the nodeType 
>> attribute wouldn't cope well with this, because that should work for 
>> instances of the same type, or regardless the type -- in other words, 
>> when trying and changing the descendant hierarchy of a node with a 
>> true value for such an attribute, the result should be an illegal 
>> hierarchy. Do you think such might be worth to be considered?
>
> I don't understand why it would be useful.
>

Well, in case the IE behaviour were chosen as standard (and only in this 
case -- which might be consistent with HTML5 empty content model), 
implementations would likely use an internal property to check when 
deciding whether to block an element subtree creation/manipulation or 
not. Exposing such a property might be useful to check the nature of an 
element in a script, but maybe also to formalize the chosen standard 
behaviour.

>
> Um. Yeah. Actually it rules out everything (a node can't be a Document 
> and a Text node at the same time, for instance). I think i'll move the 
> checking into each algorithm that's adding stuff to the tree instead 
> (in due course).
>

Such will work fine. :-)

Anyway, most checking will be the same, thus your original idea to 
isolate such requirements in a unique list was nice (just needed to 
become a list of what must not happen to have a legal hierarchy to 
work). I think both choices are fine :-)

>
> Thanks for the feedback,

Happy to be helpful somehow, if I can. :-)
Regards, Alex.

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CAPODANNO A RIMINI HOTEL 2 STELLE
* 2 notti pernottamento con colazione a buffet euro 70,00, 3 notti euro 90,00
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8501&d=8-12


From jonas at sicking.cc  Mon Dec  8 14:31:53 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 08 Dec 2008 14:31:53 -0800
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <op.ultx5rlkidj3kv@zcorpandell.linkoping.osa>
References: <4908A0B9.9090705@moonset.net>	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	<49394447.5040101@moonset.net>
	<49397098.2090000@email.it>	<op.ulp68waoidj3kv@hp-a0a83fcd39d2>
	<493B3E4D.2040507@email.it>
	<op.ultx5rlkidj3kv@zcorpandell.linkoping.osa>
Message-ID: <493DA059.90103@sicking.cc>

>> I see the Element interface no more contains methods to handle Attr 
>> nodes: since those are described as not being child nodes of an 
>> Element, in W3C specifications, there will be any other way to handle 
>> attributes as nodes, the 'nature' of Attr nodes is going to change, or 
>> is there a too little use (and/or support) of them, such that the Attr 
>> interface might be quite close to its 'end of life'?
> 
> I'm not sure what to do with attributes. I'd like to drop support for 
> attribute nodes (being moved around, etc), if possible, but keep the 
> .attributes list and be able to use .value etc on each attribute.

Oooh, this is an interesting idea. It'd be great if we could make 
attributes not be nodes but rather some other type of object.

Ideally I'd like for them to not exist at all, and have people just use 
getAttribute(NS) instead. I've never thought that their usefulness 
outweighed their complexity.

/ Jonas


From ian at hixie.ch  Mon Dec  8 15:23:52 2008
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 8 Dec 2008 23:23:52 +0000 (UTC)
Subject: [whatwg] Question about allowed <ol> and <ul> descendants
In-Reply-To: <op.ulua9oef64w2qv@annevk-t60.oslo.opera.com>
References: <493CFB1C.8010409@moonset.net>
	<op.ulua9oef64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0812082323080.30197@hixie.dreamhostps.com>

On Mon, 8 Dec 2008, Anne van Kesteren wrote:
>
> > What about nested lists, like this?
> > <ol>
> > <li>Apples</li>
> > <li>Oranges
> > <ol>
> > <li>Seeded</li>
> > <li>Navel</li>
> > </ol>
> > </li>
> > </ol>
> > 
> > I would think that's allowed. So, what kinds of content are allowed 
> > inside of <ol> and <ul>?
> 
> If you want to nest lists the <ol> or <ul> should go inside a <li>, ever 
> since lists have been invented. ;-)

What Anne said. If you think about it, a list inside a list is just an 
item in that list. I don't know what it would mean to nest lists without 
them actually being part of an item of the parent list.

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


From alex.baldacchino at email.it  Mon Dec  8 15:47:11 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Tue, 09 Dec 2008 00:47:11 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <493DA059.90103@sicking.cc>
References: <4908A0B9.9090705@moonset.net>	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	<49394447.5040101@moonset.net>
	<49397098.2090000@email.it>	<op.ulp68waoidj3kv@hp-a0a83fcd39d2>
	<493B3E4D.2040507@email.it>
	<op.ultx5rlkidj3kv@zcorpandell.linkoping.osa>
	<493DA059.90103@sicking.cc>
Message-ID: <493DB1FF.5040402@email.it>

Jonas Sicking ha scritto:
>>> I see the Element interface no more contains methods to handle Attr 
>>> nodes: since those are described as not being child nodes of an 
>>> Element, in W3C specifications, there will be any other way to 
>>> handle attributes as nodes, the 'nature' of Attr nodes is going to 
>>> change, or is there a too little use (and/or support) of them, such 
>>> that the Attr interface might be quite close to its 'end of life'?
>>
>> I'm not sure what to do with attributes. I'd like to drop support for 
>> attribute nodes (being moved around, etc), if possible, but keep the 
>> .attributes list and be able to use .value etc on each attribute.
>
> Oooh, this is an interesting idea. It'd be great if we could make 
> attributes not be nodes but rather some other type of object.
>
> Ideally I'd like for them to not exist at all, and have people just 
> use getAttribute(NS) instead. I've never thought that their usefulness 
> outweighed their complexity.
>
> / Jonas

Effectively, Attrs are nodes, but aren't used as 'normal' nodes; that's 
complex. Perhaps they might have been defined as not inheriting from 
Node since their introduction. If creating two new interfaces, one 
replacing Attrs (perhaps called Attr as well, but not inheriting from 
Node), the other to list attributes (AttributeCollection?), doesn't rise 
any issue on backward compatibility, or it solves more problems than it 
may create, that's not a bad idea. :-)

For sure, getting/setting an attribute as a property of an element, 
through getter/setter methods taking and returning strings is easier and 
perhaps the best choice in most cases, but there might be use cases 
where the possibility to access an element's attributes as a list is 
worth it, so, perhaps, should the drop of Attr be filed for a deep 
analysis and a possible actuation in a successive version of Web DOM 
Core (maybe modifying the Attr interface in the current)?
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Gioca e vinci con Sheba!				
* Partecipa a concorso "I sensi di un'intesa perfetta" vinci fantastici premi per il tuo gatto!				
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8433&d=9-12


From silviapfeiffer1 at gmail.com  Mon Dec  8 17:27:08 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 9 Dec 2008 12:27:08 +1100
Subject: [whatwg] Thoughts on video accessibility
Message-ID: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>

Hi everybody,

For the last 2 months, I have been investigating means of satisfying
video accessibility needs through Ogg in Mozilla/Firefox for HTML5.

You will find a lot of information about our work at
https://wiki.mozilla.org/Accessibility/Video_Accessibility and in the
archives of the Ogg accessibility mailing list at
http://lists.xiph.org/mailman/listinfo/accessibility .

I wanted to give some feedback here on our findings, since some of
them will have an impact on the HTML5 specification.


What are we talking about
-----------------------------------
When I say "video accessibility", I'm actually only talking about
time-aligned text formats and not e.g. captions as bitmaps or audio
annotations as wave files.
Since we analysed how to attach time-aligned text formats with video
in a Web Browser, we also did not want to restrict ourselves to only
closed captions and subtitles.
It made sense to extend this to any type of time-aligned text on can
think about, including textual audio annotations (to be consumed by
the blind through a screenreader or braille output), karaoke, speech
bubbles, hyperlinked text annotations, and others. There is a list at
http://wiki.xiph.org/index.php/OggText#Categories_of_Text_Codecs which
gives you a more complete picture.


How is it currently done
-------------------------------
When looking at the existing situation around time-aligned text for
video, I found a very diverse set ot formats and means of doing it.

First of all, most media players allow you to load a video file and a
caption/subtitle file for it in two separate steps. The reason is that
most subtitles are produced by other people than the original content
and this allows the player to synchronise them together. This is
particularly the case with the vast majority of SRT and SUB subtitle
files, but is also the case for SMIL- and DFXP-based subtitle files.

>From a media file format POV, some formats have a means of
multiplexing time-aligned text into the format, e.g. QuickTime has
QTText and Flash has cuepoints. Others prefer to use external
references, e.g. WindowsMedia and SAMI or SMIL files, RealMedia and
SMIL files.

For mobile applications, a subset of DFXP has been defined in 3GPP
TimedText, which is actually being encapsulated into QuickTime QTText
using some extensions, and can be encapsulated into MP4 using the
MPEG-4 TTXT specification.

As can be seen, the current situation is such that time-aligned text
is being handled both in-stream and out-of-band and there are indeed
requirements for both situations.


Requirements
-------------------
Not to go into much detail here, but I have seen extensive arguments
made on both sides of the equation for and against in-stream text
tracks.
One particular argument for in-stream text is that of downloading the
video from some place and keeping all its information together in one
file such that when it is distributed again, it retains that
information.
One particular argument for out-of-band text is the ability to add
text tracks at a later stage, from another site, and even from a web
service (e.g. a translation web service that uses an existing caption
file and translates it into another language).
In view of these requirements, I strongly believe we need to enable
people to do both: provide time-aligned text through
external/out-of-band resources and through in-stream, where the
container format allows this.


Proposal for out-of-band approach
----------------------------------------------
I'd like to stimulate a discussion here about how we can support
out-of-band time-aligned text for video in HTML5.
I have seen previous proposals, such as the "track" element at
http://esw.w3.org/topic/HTML/MultimediaAccessibilty#head-a83ba3666e7a437bf966c6bb210cec392dc6ca53
and would like to propose the following specification.

Take this as an example:

<video src="http://example.com/video.ogv" controls>
 <text category="CC" lang="en" type="text/x-srt" src="caption.srt"></text>
 <text category="SUB" lang="de" type="application/ttaf+xml"
src="german.dfxp"></text>
 <text category="SUB" lang="jp" type="application/smil"
src="japanese.smil"></text>
 <text category="SUB" lang="fr" type="text/x-srt"
src="translation_webservice/fr/caption.srt"></text>
</video>

* "text" elements are subelements of the "video" element and therefore
clearly related to one video (even if it comes in different formats).
[BTW: I'm happy to rename this to textarea or whatever else people
prefer to call it].

* the "category" tag (could also be renamed "role" if we prefer)
allows us to specify what text category we are dealing with and allows
the web browser to determine how to display it (there would be default
display for the different categories and css would allow to override
these).

* the "lang" tag would allow the specification of alternative
resources based on language, which allows the browser to select one by
default based on browser preferences, and also to turn those tracks on
by default that a particular user requires (e.g. because they are
blind and have preset the browser accordingly)

* the "type" tag allows specification of what actual time-aligned text
format is being used in this instance; again, it will allow the
browser to determine whether it is able to decode the file and thus
make it availalbe through an interface or not.

* the "src" attribute obviously points to the time-aligned text
resource. This could be a file, a script that extracts data from a
database, or even a web service that dynamically creates the data
based on some input.

This provides for a lot of flexibility and is somewhat independent of
the media file format, while still enabling the Web browser to deal
with the text (as long as it can decode it).

What do people think?

Regards,
Silvia.

BTW: We are in parallel working on getting time-aligned text support
into Ogg - see the spec at http://wiki.xiph.org/index.php/OggText . It
will provide a similarly flexible approach for any kind of text format
as this element does. This means that mapping into the DOM would work
in a similar way from within Ogg as it would from a "text" element as
defined above.


From mart at degeneration.co.uk  Mon Dec  8 18:08:57 2008
From: mart at degeneration.co.uk (Martin Atkins)
Date: Mon, 08 Dec 2008 18:08:57 -0800
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
Message-ID: <493DD339.5040604@degeneration.co.uk>

Silvia Pfeiffer wrote:
> 
> Take this as an example:
> 
> <video src="http://example.com/video.ogv" controls>
>  <text category="CC" lang="en" type="text/x-srt" src="caption.srt"></text>
>  <text category="SUB" lang="de" type="application/ttaf+xml"
> src="german.dfxp"></text>
>  <text category="SUB" lang="jp" type="application/smil"
> src="japanese.smil"></text>
>  <text category="SUB" lang="fr" type="text/x-srt"
> src="translation_webservice/fr/caption.srt"></text>
> </video>
> 

Could this combining of resources be achieved instead with SMIL or some 
other existing format?

If there is already a format for doing this then I think HTML should 
avoid re-inventing it unless HTML's version is better in some way.

On the other hand, if what is invented for HTML is indeed better in some 
way, it's likely to also be valuable outside of HTML, for example in 
situations where SMIL is used today. (For example, loading a video and 
its subtitles directly into a standalone player without needing to 
manually load both streams.)

What are the advantages of doing this directly in HTML rather than 
having the "src" attribute point at some sort of compound media document?




From ddailey at zoominternet.net  Mon Dec  8 18:38:44 2008
From: ddailey at zoominternet.net (ddailey)
Date: Mon, 8 Dec 2008 21:38:44 -0500
Subject: [whatwg] Use cases for Node.getElementById
References: <4908A0B9.9090705@moonset.net>	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	<49394447.5040101@moonset.net><49397098.2090000@email.it>	<op.ulp68waoidj3kv@hp-a0a83fcd39d2><493B3E4D.2040507@email.it><op.ultx5rlkidj3kv@zcorpandell.linkoping.osa><493DA059.90103@sicking.cc>
	<493DB1FF.5040402@email.it>
Message-ID: <FAC8E49B131148819343E63E8C6F7B23@disxgdg31szkx7>

There are lots of times in which I've needed to examine one document by use 
of a script that resides inside another. Using lists of attributes to do 
that has been rather important, though if those lists were accessible as 
properties of objects rather than as nodes themselves (as in some sort of 
multinary relation rather than as a tree structure) that would be fine as 
well. Learners of this stuff seem to have trouble with the fact that lists 
cannot be indexed through array notation -- i.e., that nodes[1] cannot be 
used in place of nodes.item(i) in some namespaces, but apparently can in 
HTML.

Though I have only played a little with compound documents or with document 
fragments, it seems like viewing all nodes as accessible through 
getElementById is awfully dependent on how one finds the "document" 
associated with the appropriate segment of a mixed NS document. In SVG 
nestled inside HTML, for example, implementations have differed in terms of 
how that document is retrieved as a function of browser, and the type of tag 
(object, iframe, frame, or embed) in which the svg is placed. The ability to 
"root" one's search directly at a certain level in the parent DOM, might 
help in cases where mixed name spaces could lead to conflicts of the 
assumption of unique id's.

Perhaps this has been addressed already, since I'm pretty sure the folks 
involved in this conversation know more about what they are talking about 
than I do.

cheers
David

----- Original Message ----- 
From: "Calogero Alex Baldacchino" <alex.baldacchino at email.it>
To: "Jonas Sicking" <jonas at sicking.cc>
Cc: "WHAT Working Group" <whatwg at lists.whatwg.org>; "Simon Pieters" 
<simonp at opera.com>
Sent: Monday, December 08, 2008 6:47 PM
Subject: Re: [whatwg] Use cases for Node.getElementById


> Jonas Sicking ha scritto:
>>>> I see the Element interface no more contains methods to handle Attr 
>>>> nodes: since those are described as not being child nodes of an 
>>>> Element, in W3C specifications, there will be any other way to handle 
>>>> attributes as nodes, the 'nature' of Attr nodes is going to change, or 
>>>> is there a too little use (and/or support) of them, such that the Attr 
>>>> interface might be quite close to its 'end of life'?
>>>
>>> I'm not sure what to do with attributes. I'd like to drop support for 
>>> attribute nodes (being moved around, etc), if possible, but keep the 
>>> .attributes list and be able to use .value etc on each attribute.
>>
>> Oooh, this is an interesting idea. It'd be great if we could make 
>> attributes not be nodes but rather some other type of object.
>>
>> Ideally I'd like for them to not exist at all, and have people just use 
>> getAttribute(NS) instead. I've never thought that their usefulness 
>> outweighed their complexity.
>>
>> / Jonas
>
> Effectively, Attrs are nodes, but aren't used as 'normal' nodes; that's 
> complex. Perhaps they might have been defined as not inheriting from Node 
> since their introduction. If creating two new interfaces, one replacing 
> Attrs (perhaps called Attr as well, but not inheriting from Node), the 
> other to list attributes (AttributeCollection?), doesn't rise any issue on 
> backward compatibility, or it solves more problems than it may create, 
> that's not a bad idea. :-)
>
> For sure, getting/setting an attribute as a property of an element, 
> through getter/setter methods taking and returning strings is easier and 
> perhaps the best choice in most cases, but there might be use cases where 
> the possibility to access an element's attributes as a list is worth it, 
> so, perhaps, should the drop of Attr be filed for a deep analysis and a 
> possible actuation in a successive version of Web DOM Core (maybe 
> modifying the Attr interface in the current)?
>
>
> --
> Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP 
> autenticato? GRATIS solo con Email.it http://www.email.it/f
>
> Sponsor:
> Gioca e vinci con Sheba! * Partecipa a concorso "I sensi di un'intesa 
> perfetta" vinci fantastici premi per il tuo gatto! * Clicca qui: 
> http://adv.email.it/cgi-bin/foclick.cgi?mid=8433&d=9-12
>
> 



From giles at xiph.org  Mon Dec  8 18:46:51 2008
From: giles at xiph.org (Ralph Giles)
Date: Mon, 8 Dec 2008 18:46:51 -0800
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <493DD339.5040604@degeneration.co.uk>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
Message-ID: <5d88ef650812081846n6c5cefs25642edc13773e68@mail.gmail.com>

On Mon, Dec 8, 2008 at 6:08 PM, Martin Atkins <mart at degeneration.co.uk> wrote:

> What are the advantages of doing this directly in HTML rather than having
> the "src" attribute point at some sort of compound media document?

The general point here is that subtitle data is in current practice
often created and stored in external files. This is, in part, because
of poor support for embedded tracks in web video applications, but
also arises naturally in production workflow. Moreover, because they
are text, subtitle data is much more likely to be stored in a database
with other text-based content while audio and video is treated as
binary blobs. This scheme is intended to support such hybrid systems.

There is generally a tension between authors wanting to easily
manipulate and add tracks, users wanting a self-contained file, and
search engines wanting stand-alone access to just the text. Because
splitting and merging media files requires special tools, our thinking
in the Ogg accessibility group has been that we need to support both
embedded and external references for text tracks in html. Users (and
their tools) can then choose what methods they want to use in
particular circumstances.

We're also interested in a more sophisticated mechanism for
communicating track assortments between a server and a client, but in
the particular case of text tracks for accessiblity, I think having a
simple, explicit mechanism at the html level is worthwhile.

 -r


From silviapfeiffer1 at gmail.com  Mon Dec  8 20:56:12 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 9 Dec 2008 15:56:12 +1100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <493DD339.5040604@degeneration.co.uk>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
Message-ID: <2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>

On Tue, Dec 9, 2008 at 1:08 PM, Martin Atkins <mart at degeneration.co.uk> wrote:
> Silvia Pfeiffer wrote:
>>
>> Take this as an example:
>>
>> <video src="http://example.com/video.ogv" controls>
>>  <text category="CC" lang="en" type="text/x-srt" src="caption.srt"></text>
>>  <text category="SUB" lang="de" type="application/ttaf+xml"
>> src="german.dfxp"></text>
>>  <text category="SUB" lang="jp" type="application/smil"
>> src="japanese.smil"></text>
>>  <text category="SUB" lang="fr" type="text/x-srt"
>> src="translation_webservice/fr/caption.srt"></text>
>> </video>
>>
>
> Could this combining of resources be achieved instead with SMIL or some
> other existing format?


So, are you suggesting to use something like this:

<video srcdesc="http://example.com/video.smil" controls>
</video>

where the Web client would retrieve the smil file and find all the
references to actual resources inside the SMIL file, then do another
retrieval action to actually retrieve the data it wants?

This is indeed an alternative, which would require to have a smil file
specification that describes the composition of tracks of a single
linear video. It is indeed what we have experimented with in the Ogg
community and have come up with ROE
(http://wiki.xiph.org/index.php/ROE).

<video roe="http://example.com/video.xml" controls>
</video>

When we defined ROE, we were trying to use a tightly defined subpart
of SMIL for it. This however did not work, because some of the
required attributes do not exist in SMIL (e.g. profile, category,
distinction, inline), SMIL was too expressive (e.g. needed to
explicitly separate audio, video, when mediaSource will do fine) and
SMIL required the use of other elements that were really unnecessary.
So, instead of butchering up a sub-version of SMIL that would work
(and look really ugly), we defined a new xml specification that would
satisfy the exact requirements we had.


> If there is already a format for doing this then I think HTML should avoid
> re-inventing it unless HTML's version is better in some way.

I think both have their uses.

We are using the ROE file to describe the (possibly only virtually
existing) media resource on the server. It gives the Web client an
opportunity to request a media resource with only a particular set of
tracks (allows for content adaptation). This results in a single media
file, dynamically created on the Web server, delivered in one
connection, and decoded by the Web browser into its constituent
tracks, which is each displayed in a different, but temporally
synchronised means.

In contrast, the proposed html5 solution requires the Web brower to
set up multiple connections, one each to the resources that it
requires. The decoding and display is then dependent on multiple
connections having delivered enough data to provide for a synchronised
playback. It also allows downloading the full text files first and
display some text ahead of time (as is usual e.g. in a transcript),
while in a multiplexed file the text data is often only retrieved
consecutively in sync with the decoding of the a+v tracks.


>What are the advantages of doing this directly in HTML rather than having the "src" attribute point at some sort of compound media
> document?

I guess, an argument can be made that a user agent could use ROE to
get to the individual streams and download the resources in multiple
connections itself, which would have the exact same effect as the
proposed HTML5 syntax. ROE currently goes beyond just text tracks and
allows description of multiple media and text tracks. You however
wouldn't want a Web browser to have to create multiple connections to
different audio and video resources and have to synchronise them
locally. Text is different in this respect, because it's with almost
certainty a small enough file to be fully received before even the
beginning of a video file has loaded. So, if we used ROE for such a
content selection task, I would courage to only use it for text
tracks.


I'm interested to hear people's opinions on these ideas. I agree with
Ralph and think having a simple, explicit mechanism at the html level
is worthwhile - and very open and explicit to a web author. Having a
redirection through a ROE-type file on the server is more opaque, but
maybe more consistent with existing similar approaches as taken by
RealNetworks in rm files and WindowsMedia files in asx files.

Cheers,
Silvia.


From mart at degeneration.co.uk  Mon Dec  8 21:20:10 2008
From: mart at degeneration.co.uk (Martin Atkins)
Date: Mon, 08 Dec 2008 21:20:10 -0800
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>	
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
Message-ID: <493E000A.7000207@degeneration.co.uk>

Silvia Pfeiffer wrote:
> 
> I'm interested to hear people's opinions on these ideas. I agree with
> Ralph and think having a simple, explicit mechanism at the html level
> is worthwhile - and very open and explicit to a web author. Having a
> redirection through a ROE-type file on the server is more opaque, but
> maybe more consistent with existing similar approaches as taken by
> RealNetworks in rm files and WindowsMedia files in asx files.
> 

This (having a separate document that references other streams) is what 
I was thinking of. I guess which is more natural depends on who is doing 
the assembling. If it is the HTML author that takes the individual 
pieces and links them together then doing it in the HTML is probably 
easiest.

My concern is that if the only thing linking the various streams 
together is the HTML document then the streams are less useful outside 
of a web browser context. If there is a separate resource containing the 
description of how to assemble the result from multiple resources then 
this resource will be useful to non-browser video playback clients. If 
an existing format is used then it can be linked to as fallback for 
users of downlevel browsers and will hopefully open in a standalone 
video player. If the only linking information is in the HTML document 
then the best you can do as fallback is link to the video stream, 
requiring the user to go find the text streams and load them manually.





From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Dec  8 22:13:53 2008
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Tue, 09 Dec 2008 06:13:53 +0000
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <493E000A.7000207@degeneration.co.uk>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
Message-ID: <1228803233.27713.777.camel@desudesudesu>

Am Montag, den 08.12.2008, 21:20 -0800 schrieb Martin Atkins:
> My concern is that if the only thing linking the various streams 
> together is the HTML document then the streams are less useful outside 
> of a web browser context. If there is a separate resource containing the 
> description of how to assemble the result from multiple resources then 
> this resource will be useful to non-browser video playback clients. If 
> an existing format is used then it can be linked to as fallback for 
> users of downlevel browsers and will hopefully open in a standalone 
> video player. If the only linking information is in the HTML document 
> then the best you can do as fallback is link to the video stream, 
> requiring the user to go find the text streams and load them manually.
Funny, I just recently talked with someone about that. He suggested
something along a "DNS for subtitles", e.g. having a hash value / UUID
embedded inside the stream and looking that up. So for example
<urn:caption:dd23d31a1158052b4e68899e1a991df102d82e52/de> could hold
German annstations and subtitles for the media file with that hash.

-- 
Nils Dagsson Moskopp
<http://dieweltistgarnichtso.net>



From giles at xiph.org  Tue Dec  9 00:17:29 2008
From: giles at xiph.org (Ralph Giles)
Date: Tue, 9 Dec 2008 00:17:29 -0800
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <493E000A.7000207@degeneration.co.uk>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
Message-ID: <5d88ef650812090017h3d6bbf67p53bc9ef4ff5bba19@mail.gmail.com>

On Mon, Dec 8, 2008 at 9:20 PM, Martin Atkins <mart at degeneration.co.uk> wrote:

> My concern is that if the only thing linking the various streams together is
> the HTML document then the streams are less useful outside of a web browser
> context.

Absolutely. This proposal places an additional burden on the user to
download and integrate multiple resources. This trade-off to supports
applications where having the text available separately is valuable.

 -r


From robert at ocallahan.org  Tue Dec  9 00:33:50 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 9 Dec 2008 21:33:50 +1300
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <493E000A.7000207@degeneration.co.uk>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
Message-ID: <11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>

On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> Silvia Pfeiffer wrote:
>
>>
>> I'm interested to hear people's opinions on these ideas. I agree with
>> Ralph and think having a simple, explicit mechanism at the html level
>> is worthwhile - and very open and explicit to a web author. Having a
>> redirection through a ROE-type file on the server is more opaque, but
>> maybe more consistent with existing similar approaches as taken by
>> RealNetworks in rm files and WindowsMedia files in asx files.
>>
>>
> This (having a separate document that references other streams) is what I
> was thinking of. I guess which is more natural depends on who is doing the
> assembling. If it is the HTML author that takes the individual pieces and
> links them together then doing it in the HTML is probably easiest.
>

For what it's worth, loading an intermediate document of some new type which
references other streams to be loaded adds a lot of complexity to the
browser implementation. It creates new states that the decoder can be in,
and introduces new failure modes. It creates new timing issues and possibly
new security issues.

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/20081209/d603fb8a/attachment.htm>

From douglas at openplans.org  Tue Dec  9 06:42:23 2008
From: douglas at openplans.org (Douglas Mayle)
Date: Tue, 9 Dec 2008 09:42:23 -0500
Subject: [whatwg] Web Workers Draft
Message-ID: <32651264-00F1-47D9-B7D3-46335770164C@openplans.org>

Hello,
	I was taking a look at the Web Workers Draft ( http://www.whatwg.org/specs/web-workers/current-work/ 
  ), and I couldn't find any mention of cross domain workers.  I've  
read a bit about relaxing domain restrictions on documents, but  
worker's don't seem to have a document object.  I also see the details  
about location, but I haven't found any information about relaxing the  
origin.  Is there any plan to allow cross-domain workers?  I'm  
currently using them in Gears to enable a shared storage solution, and  
would like to be able to migrate one day to official standards.

Thanks,
Douglas Mayle
The Open Planning Project
http://topp.openplans.org


From t.broyer at gmail.com  Tue Dec  9 06:58:20 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Tue, 9 Dec 2008 15:58:20 +0100
Subject: [whatwg] Web Workers Draft
In-Reply-To: <32651264-00F1-47D9-B7D3-46335770164C@openplans.org>
References: <32651264-00F1-47D9-B7D3-46335770164C@openplans.org>
Message-ID: <a9699fd20812090658q5c325a5ag91adf299098c904b@mail.gmail.com>

On Tue, Dec 9, 2008 at 3:42 PM, Douglas Mayle wrote:
> Hello,
>        I was taking a look at the Web Workers Draft (
> http://www.whatwg.org/specs/web-workers/current-work/ ), and I couldn't find
> any mention of cross domain workers.  I've read a bit about relaxing domain
> restrictions on documents, but worker's don't seem to have a document
> object.  I also see the details about location, but I haven't found any
> information about relaxing the origin.  Is there any plan to allow
> cross-domain workers?

Sort of: http://html5.org/tools/web-workers-tracker?from=73&to=74
(this is the last change to date).


-- 
Thomas Broyer


From douglas at openplans.org  Tue Dec  9 06:58:35 2008
From: douglas at openplans.org (Douglas Mayle)
Date: Tue, 9 Dec 2008 09:58:35 -0500
Subject: [whatwg] Web Workers Draft
In-Reply-To: <32651264-00F1-47D9-B7D3-46335770164C@openplans.org>
References: <32651264-00F1-47D9-B7D3-46335770164C@openplans.org>
Message-ID: <5BF5ED21-3FA8-438A-AA6C-25551E5C2474@openplans.org>

After sending this, it occurs to me that at the worst, I could have a  
separate document to marshal access to a cross domain web worker.   
It's an extra hoop to jump through, but at least it would work.

Douglas Mayle
The Open Planning Project
http://topp.openplans.org

On Dec 9, 2008, at 9:42 AM, Douglas Mayle wrote:

> Hello,
> 	I was taking a look at the Web Workers Draft ( http://www.whatwg.org/specs/web-workers/current-work/ 
>  ), and I couldn't find any mention of cross domain workers.  I've  
> read a bit about relaxing domain restrictions on documents, but  
> worker's don't seem to have a document object.  I also see the  
> details about location, but I haven't found any information about  
> relaxing the origin.  Is there any plan to allow cross-domain  
> workers?  I'm currently using them in Gears to enable a shared  
> storage solution, and would like to be able to migrate one day to  
> official standards.
>
> Thanks,
> Douglas Mayle
> The Open Planning Project
> http://topp.openplans.org



From silviapfeiffer1 at gmail.com  Tue Dec  9 08:49:26 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 10 Dec 2008 03:49:26 +1100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
Message-ID: <2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>

I heard some complaints about there not being any implementation of
the suggestions I made.

So here goes:

1. out-of-band
There is an example of using srt with ogg in a out-of-band approach here:
http://v2v.cc/~j/jquery.srt/
You will need Firefox3.1 to play it.
The syntax of what Jan implemented is different to what I proposed,
but I wanted to take it forward and make it more generic.

2. in-band
There is also a draft implementation of srt inside Ogg through the
OggText specification, but I it's not released yet. It is also not as
relevant to this group as the out-of-band example.

Cheers,
Silvia.



On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>
> wrote:
>>
>> Silvia Pfeiffer wrote:
>>>
>>> I'm interested to hear people's opinions on these ideas. I agree with
>>> Ralph and think having a simple, explicit mechanism at the html level
>>> is worthwhile - and very open and explicit to a web author. Having a
>>> redirection through a ROE-type file on the server is more opaque, but
>>> maybe more consistent with existing similar approaches as taken by
>>> RealNetworks in rm files and WindowsMedia files in asx files.
>>>
>>
>> This (having a separate document that references other streams) is what I
>> was thinking of. I guess which is more natural depends on who is doing the
>> assembling. If it is the HTML author that takes the individual pieces and
>> links them together then doing it in the HTML is probably easiest.
>
>
> For what it's worth, loading an intermediate document of some new type which
> references other streams to be loaded adds a lot of complexity to the
> browser implementation. It creates new states that the decoder can be in,
> and introduces new failure modes. It creates new timing issues and possibly
> new security issues.
>
> 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]
>


From alex.baldacchino at email.it  Tue Dec  9 10:07:29 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Tue, 09 Dec 2008 19:07:29 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <FAC8E49B131148819343E63E8C6F7B23@disxgdg31szkx7>
References: <4908A0B9.9090705@moonset.net>	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	<49394447.5040101@moonset.net><49397098.2090000@email.it>	<op.ulp68waoidj3kv@hp-a0a83fcd39d2><493B3E4D.2040507@email.it><op.ultx5rlkidj3kv@zcorpandell.linkoping.osa><493DA059.90103@sicking.cc>
	<493DB1FF.5040402@email.it>
	<FAC8E49B131148819343E63E8C6F7B23@disxgdg31szkx7>
Message-ID: <493EB3E1.8010402@email.it>

ddailey ha scritto:
> There are lots of times in which I've needed to examine one document 
> by use of a script that resides inside another. Using lists of 
> attributes to do that has been rather important, though if those lists 
> were accessible as properties of objects rather than as nodes 
> themselves (as in some sort of multinary relation rather than as a 
> tree structure) that would be fine as well.

Well, attributes shouldn't be accessible as descendants of an Element in 
a tree structure, but rather as items of a NamedNodeMap, or directly 
through Element.getAttribute()/Element.getAttributeNS(), passing a 
string representing the attribute name and getting the value as a 
string. Thus, they don't need to be instances of Node (that's about 
redefining Attr and a related listing interface to simplify the UA 
handling of attributes, which currently are node but should be handled 
as if they weren't). Any interface replacing Attr, for such purpose, 
should take care of namespaces and prefixes (which is currently done in 
DOM3 Node interface). Dropping the list of attributes as objects would 
require to query each attribute by name, but a list of attributes seems 
to be needed in some use cases; a DOMStringMap might be considered, to 
represent attributes as a list of string couples of names and values, 
but such couldn't handle namespaces, though it might be derived to add 
such capability, nor it could solve the problem to define an interface 
to give access to a tuple of (name, value, namespace) by colling, e.g., 
an item() method, or the alike. Otherwise, if no better alternative can 
be found, Attrs will continue to be Nodes...

> Learners of this stuff seem to have trouble with the fact that lists 
> cannot be indexed through array notation -- i.e., that nodes[1] cannot 
> be used in place of nodes.item(i) in some namespaces, but apparently 
> can in HTML.
>

I guess that's a matter of idl bindings, in part at least, so it might 
be solved with clearer specific bindings, as needed. For instance, all 
properties (attributes and methods) of a collection-like interface can 
be declared [DontEnum], despite of them being defined on the idl or 
being created at runtime (i.e. by listing an item as a named property of 
the object), with the exception of indexed items: this way, a 
collection-like object would always behave as an Array-like object. 
Similarly, the collection might work as an associative array for named 
items (i.e., the_id = attributes["id"] might work as the_id = 
attributes.getNamedItem("id") ), but the binding for such might be more 
complex, involving a redefinition of the bracket property accessor in 
order to look for properties inside an internal list (when it comes to 
implementations, such complexity may disappear or be reduced, for 
instance, in C++ such might involve an "easy" overload of the 
'operator[]' function).

> Though I have only played a little with compound documents or with 
> document fragments, it seems like viewing all nodes as accessible 
> through getElementById is awfully dependent on how one finds the 
> "document" associated with the appropriate segment of a mixed NS 
> document. In SVG nestled inside HTML, for example, implementations 
> have differed in terms of how that document is retrieved as a function 
> of browser, and the type of tag (object, iframe, frame, or embed) in 
> which the svg is placed. The ability to "root" one's search directly 
> at a certain level in the parent DOM, might help in cases where mixed 
> name spaces could lead to conflicts of the assumption of unique id's.

Perhaps, what you're asking for is something like 
Document.getNSElementById(in DOMString namespaceUri, in DOMString 
elementId), to get access to the first element, in a document, whose tag 
name has a prefix corresponding to the queried namespace, or is 
descendant of an element whose tagname is the root element tag name for 
the queried namespace (perhapse suitable for HTML 5 embedding <svg> or 
<math> elements without prefixes). Anyway, you'd have to reach the 
correct document first (but you'd have to do so to get the nested 
content root element even with a getElementById(elementId, rootElement) 
). Such method would involve a separate management of ids, one to ensure 
uniqueness in the whole document (i.e. to return the first match for 
getElementById despite of the element namespace), another to deal with 
each element (either prefixed or just embedded) coming from the same 
namespace as if they were in a separate document where to look for 
unique ids (not to be implemented necessarily this way, just managing a 
global map of unique IDs for all the elements in a document and zero or 
more secondary maps for all the elements corresponding to a particular 
namespace - different from that of the nesting document). Such might add 
some complexity to the user agent, and perhaps won't get consensus from 
implementors, I guess.

Regards, Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Dalla top ten al tuo cellulare. Scarica le superhit!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8268&d=9-12


From alex.baldacchino at email.it  Tue Dec  9 11:59:12 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Tue, 09 Dec 2008 20:59:12 +0100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>	<493DD339.5040604@degeneration.co.uk>	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>	<493E000A.7000207@degeneration.co.uk>	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
	<2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
Message-ID: <493ECE10.7060303@email.it>

Silvia Pfeiffer ha scritto:
> I heard some complaints about there not being any implementation of
> the suggestions I made.
>
> So here goes:
>
> 1. out-of-band
> There is an example of using srt with ogg in a out-of-band approach here:
> http://v2v.cc/~j/jquery.srt/
> You will need Firefox3.1 to play it.
> The syntax of what Jan implemented is different to what I proposed,
> but I wanted to take it forward and make it more generic.
>
> 2. in-band
> There is also a draft implementation of srt inside Ogg through the
> OggText specification, but I it's not released yet. It is also not as
> relevant to this group as the out-of-band example.
>
> Cheers,
> Silvia.
>
>   
As far as I've understood from a first read of your proposal (I'm not 
much inside that matter), current players/codecs implements different 
kinds of bindings with text (either in-band or out-of-band) and supports 
different formats, so perhaps there is place for both mechanisms you're 
proposing:

- the html version, for compatibility with existing media and relative 
external bindings, for servers not supporting the dynamic creation of 
content defined by your ROE format and for people who don't want/can't 
afford to modify the way their medias are served (e.g. they can't access 
to the server where the media is stored and add or modify an xml 
metadata file, but want to try and bind the media with some text they 
can store separately);

- the xml file mainly to drive dynamic content creation, and as a 
gradual replacement of other binding formats.

Any problem arising from the management of separate connections 
(possibly to different domains) to get both the audio/video and the 
textual resources, might perhaps be mitigated by indicating (or 
establishing as default) a time to wait for external text before 
starting the playback (in case the text resource fails to load -- e.g. 
the server is temporarily offline -- and there is enough buffered 
content to start playing before the browser gets any answer for any 
other resource) -- when and if the text arrives, its use might be 
skipped at all, or start by synchronizing with the current point in the 
media; the same way, if any problem loading the text arose after 
starting the playback, the missing parts might just be skipped (such 
would be unlikely to happen if both the media and the text files were 
located on the same server).

Perhaps, it might be useful to provied a way to indicate an alternative 
media to stream, i.e. an .asx or .rm media which is internally binded 
with only one of the supported languages, but the browser fails to bind 
them with the 'primary' media, or in case the ROE format is not 
supported (e.g. introduced in a "v2" of the spec), or the 'primary' 
media is not supported by the browser, but the same content is available 
in several formats (i.e. a lossless compressed version along a lossy 
compressed one - the UA might even choice one basing on the network 
capabilities) -- I know such is possible with source elements, but 
perhaps some considerations are needed on the opportunity to relate 
source element and text bindings, i.e. to tell the UA, by the mean of an 
attribute, whether to verify if the source supports any of the declared 
text resources, preferably one matching the locale, or not (that is, 
specifying if a source is a 'last resort' in case the UA is unable to 
bind any other source with the text -- other sources might be chosen 
anyway, if no 'last resort' source is supported).

Anyway, the use of subtitles in conjunction with screen readers might be 
problematic: a deeper synchronization with the media might be needed in 
order to have the text read just during voice pauses, to describe a mute 
scene, or to entirely substitute the sound, if the text provides a 
translation for the speech (I guess such would be untrivial to do 
without putting one's hands inside the media).

Everything, of course, IMHO.
Regards,
Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CAPODANNO A RIMINI HOTEL 2 STELLE
* 2 notti pernottamento con colazione a buffet euro 70,00, 3 notti euro 90,00
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8500&d=9-12


From silviapfeiffer1 at gmail.com  Tue Dec  9 12:25:19 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 10 Dec 2008 07:25:19 +1100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <493ECE10.7060303@email.it>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
	<2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
	<493ECE10.7060303@email.it>
Message-ID: <2c0e02830812091225y1f1fa2c4xb984b026b79bd8fc@mail.gmail.com>

On Wed, Dec 10, 2008 at 6:59 AM, Calogero Alex Baldacchino
<alex.baldacchino at email.it> wrote:
>
> Anyway, the use of subtitles in conjunction with screen readers might be
> problematic: a deeper synchronization with the media might be needed in
> order to have the text read just during voice pauses, to describe a mute
> scene, or to entirely substitute the sound, if the text provides a
> translation for the speech (I guess such would be untrivial to do without
> putting one's hands inside the media).

I cannot see a problem with conflicts between screen reading a web
page and a video on the web page. A blind user would have turned off
the use of captions by default in his/her browser, since they can hear
very well what is going on, just not see it. As long as the video is
not playing, it is only represented as a video (and maybe a alt text
is read out). When the blind user clicks on the video, audio
annotations will be read out by the screen reader in addition to the
native sound. These would be placed into silence segments.

In the case of a video with a non-native language sound track, it's a
bit more complicated. The native sound would need to be turned off and
the screenreader would need to read out the subtitles in the user's
native language as well as the audio annotations in the breaks. This
many not be easy to set up through preferences in the Web browser, but
it should be possible for the user to manually select the right tracks
and turn off the video sound.

Regards,
Silvia.


From silviapfeiffer1 at gmail.com  Tue Dec  9 12:30:29 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 10 Dec 2008 07:30:29 +1100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
	<2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
Message-ID: <2c0e02830812091230u2f45ceaat635afbe63031a942@mail.gmail.com>

Also, for those interested, metavid and mv_embed are examples of use of ROE:
http://metavid.org/w/index.php/Mv_embed

Metavid uses
  <video roe="my_roe_file.xml">
for clean remote embedding of multiple text/video/audio tracks in a
single xml encapsulation.

An example of such embeds is here: http://metavid-mike.blogspot.com/

Regards,
Silvia.

On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> I heard some complaints about there not being any implementation of
> the suggestions I made.
>
> So here goes:
>
> 1. out-of-band
> There is an example of using srt with ogg in a out-of-band approach here:
> http://v2v.cc/~j/jquery.srt/
> You will need Firefox3.1 to play it.
> The syntax of what Jan implemented is different to what I proposed,
> but I wanted to take it forward and make it more generic.
>
> 2. in-band
> There is also a draft implementation of srt inside Ogg through the
> OggText specification, but I it's not released yet. It is also not as
> relevant to this group as the out-of-band example.
>
> Cheers,
> Silvia.
>
>
>
> On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>> On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>
>> wrote:
>>>
>>> Silvia Pfeiffer wrote:
>>>>
>>>> I'm interested to hear people's opinions on these ideas. I agree with
>>>> Ralph and think having a simple, explicit mechanism at the html level
>>>> is worthwhile - and very open and explicit to a web author. Having a
>>>> redirection through a ROE-type file on the server is more opaque, but
>>>> maybe more consistent with existing similar approaches as taken by
>>>> RealNetworks in rm files and WindowsMedia files in asx files.
>>>>
>>>
>>> This (having a separate document that references other streams) is what I
>>> was thinking of. I guess which is more natural depends on who is doing the
>>> assembling. If it is the HTML author that takes the individual pieces and
>>> links them together then doing it in the HTML is probably easiest.
>>
>>
>> For what it's worth, loading an intermediate document of some new type which
>> references other streams to be loaded adds a lot of complexity to the
>> browser implementation. It creates new states that the decoder can be in,
>> and introduces new failure modes. It creates new timing issues and possibly
>> new security issues.
>>
>> 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]
>>
>


From alex.baldacchino at email.it  Tue Dec  9 17:45:59 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 10 Dec 2008 02:45:59 +0100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812091225y1f1fa2c4xb984b026b79bd8fc@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>	<493DD339.5040604@degeneration.co.uk>	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>	<493E000A.7000207@degeneration.co.uk>	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>	<2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>	<493ECE10.7060303@email.it>
	<2c0e02830812091225y1f1fa2c4xb984b026b79bd8fc@mail.gmail.com>
Message-ID: <493F1F57.8050408@email.it>

Silvia Pfeiffer ha scritto:
> On Wed, Dec 10, 2008 at 6:59 AM, Calogero Alex Baldacchino
> <alex.baldacchino at email.it> wrote:
>   
>> Anyway, the use of subtitles in conjunction with screen readers might be
>> problematic: a deeper synchronization with the media might be needed in
>> order to have the text read just during voice pauses, to describe a mute
>> scene, or to entirely substitute the sound, if the text provides a
>> translation for the speech (I guess such would be untrivial to do without
>> putting one's hands inside the media).
>>     
>
> I cannot see a problem with conflicts between screen reading a web
> page and a video on the web page. A blind user would have turned off
> the use of captions by default in his/her browser, since they can hear
> very well what is going on, just not see it. As long as the video is
> not playing, it is only represented as a video (and maybe a alt text
> is read out). When the blind user clicks on the video, audio
> annotations will be read out by the screen reader in addition to the
> native sound. These would be placed into silence segments.
>
>   

I was thinking on a possible lack of synchronism, with enabled 
annotations, between the screenreader reading them, and the actual 
duration of corresponding silence segments, maybe because of not enough 
brief sentences (e.g. as a consequence of a non well-groomed translation 
in a certain language) and/or a slow reading (depending on the language 
peculiarities, or the user settings, or both, and anyway out of control 
for any UA), resulting in a cross sound between the end part of a read 
out annotation and the beginning of the next non-silence segment, 
perhaps repeatedly during playback. Maybe this is a borderline case.

> In the case of a video with a non-native language sound track, it's a
> bit more complicated. The native sound would need to be turned off and
> the screenreader would need to read out the subtitles in the user's
> native language as well as the audio annotations in the breaks. This
> many not be easy to set up through preferences in the Web browser, but
> it should be possible for the user to manually select the right tracks
> and turn off the video sound.
>
> Regards,
> Silvia.
>   
If the "base" language of the video, or the provided languages, were 
indicated somewhere, in the metadata or in the enclosing xml file, 
perhaps such a switch might be automated (perhaps the corresponding 
preference might be something like "read subtitles when the media does 
not support your language" maybe coupled with the option "don't read 
subtitles when the media supported language(s) can't be identified."). I 
was also thinking about 'implied' subtitles, such as those showed in a 
film when some characters speak in different language from the "base" 
language of the rest of the content; in such a case, if distinguishing 
'implied' subtitles were possible somehow, it might be nice to turn down 
(or off, as needed) the volume and let a voice engine to speak them 
aloud. I guess a UA with an embedded voice technology (such as Opera 
Voice, or FireVox), could do a good job and keep audio and video 
synchronized in most cases, but involving an external software (such as 
a screen reader) the scenario might change (usually a screenreader can't 
be fastened or slowed, and stopping it - when reading annotations - 
after having fed some text, if at all possible, might be untrivial -- 
again, I'm not enough inside this stuff, so I can just suppose some 
borderline scenarios). Anyway, your proposal is nice, and, once 
widespread, screen readers developers might choose to provide some kind 
of support for synchronism (if needed to improve accessibility of 
audio/video contents).

Regards, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Partecipa al concorso Sheba!				
* In palio speciali premi e tanti prodotti Sheba per il tuo gatto! Gioca ora e vinci!				
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8431&d=10-12


From singer at apple.com  Tue Dec  9 20:56:08 2008
From: singer at apple.com (Dave Singer)
Date: Wed, 10 Dec 2008 13:56:08 +0900
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
Message-ID: <p0624084cc564fb45bd80@[17.202.35.52]>

At 21:33  +1300 9/12/08, Robert O'Callahan wrote:
>For what it's worth, loading an intermediate document of some new 
>type which references other streams to be loaded adds a lot of 
>complexity to the browser implementation. It creates new states that 
>the decoder can be in, and introduces new failure modes. It creates 
>new timing issues and possibly new security issues.

I'm not sure I agree;  but if you believe that, we should address it 
no matter which way this discussion goes.  It should absolutely be 
possible to reference a SMIL file, or an MP4 or MOV file with 
external data (to give only two examples) from a <video> or <audio> 
element, and have the DOM, events, states, and APis work correctly.


Also, I should say that we quite deliberately left off associating 
and synchronizing media from our initial proposal for the media 
elements, for two reasons:
a) we believe that SMIL files should be embeddable;
b) it's an easy line to draw;  you want media integration, use a 
media integration language such as SMIL.  If you start adding some 
integration, it's very hard to know where to stop.

As for user or user-agent supplied subtitles etc., that can (of 
course) be a UA feature or option.  If a unique content ID would help 
find such subtitle files, then I am hoping that the media annotations 
group would come up with a workable scheme (something the music 
industry is still, ahem, struggling with).
-- 
David Singer
Multimedia Standards, Apple Inc.


From dhtmlkitchen at gmail.com  Tue Dec  9 21:20:37 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 9 Dec 2008 21:20:37 -0800
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <493B3E4D.2040507@email.it>
References: <4908A0B9.9090705@moonset.net>
	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>
	<op.ulp68waoidj3kv@hp-a0a83fcd39d2> <493B3E4D.2040507@email.it>
Message-ID: <c9e12660812092120l600222b4k48fa6e5071ba409c@mail.gmail.com>

On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino
<alex.baldacchino at email.it> wrote:
> Simon Pieters ha scritto:
>>
>> On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino
>> <alex.baldacchino at email.it> wrote:
>>
>>> [...]
>>
>> (I'm currently the editor of that proposal, currently located at
>> http://simon.html5.org/specs/web-dom-core )
>>
>
> I'm reading it :-)
>
> And I have a few questions.

I did not see a proposal for Element.getElementById.

I would not care about that much.

I woud rather have

Element.getElementsByName.

It is perfectly valid for a doucment to have multiple elements w/the
same name (though not generally a good idea). I've seen this before.

Was this proposed?

Garrett


From annevk at opera.com  Wed Dec 10 06:01:08 2008
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 10 Dec 2008 15:01:08 +0100
Subject: [whatwg] Implement XMLHttpRequest interface subset
	onHTMLDocument
In-Reply-To: <fb8299e10810300021w368b9e28nf773dc73ab457f74@mail.gmail.com>
References: <fb8299e10810291206v6d789194l9dbf5e642c5048b@mail.gmail.com>
	<4F54BEC636854B35AE23B04872D63B9D@POCZTOWIEC>
	<fb8299e10810291219t3ee440c0wf6c35b2e7127aab3@mail.gmail.com>
	<2337294C35E843688470B062BBA6503C@POCZTOWIEC>
	<fb8299e10810291234n2695a9c1nd9b47f4e9631545e@mail.gmail.com>
	<33F436BEAC8947B79203A39CE90739FF@Shepherd.corp>
	<fb8299e10810300021w368b9e28nf773dc73ab457f74@mail.gmail.com>
Message-ID: <op.ulx876li64w2qv@annevk-t60.oslo.opera.com>

On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter  
<weston at shepherd-interactive.com> wrote:
> I have an amendment to my proposal. There was a
> post<http://ajaxian.com/archives/language-jsonp-service>on Ajaxian
> today about a "Language JSONP Service" which "calculates the
> users language based on browser headers". This seems like a terrible
> workaround since the Accept-Language header is sent from the same browser
> that the script is running in; a script shouldn't have to make an HTTP
> request just to find out what the browser's request headers are.

Did you read what kriszyp wrote in a comment to that post?


> Therefore, I propose that in addition to implementing on HTMLDocument the
> XMLHttpRequest interface subset I initially suggested, I see that it  
> would also be very useful for a script to obtain the request headers  
> that were
> sent which resulted in the current document as the response. The current
> version of XMLHttpRequest hints to a future version including a
> getRequestHeader() method, a method which would complement
> getResponseHeader(); there could also be a getAllRequestHeaders() method
> that would correspond to the existing getAllResponseHeaders() method.
> (Obviously it would not make sense to implement the setRequestHeader()
> method.)
>
> If these two methods ( getRequestHeader() and getAllRequestHeaders() )  
> were
> implemented, then there would be no need for a "Language JSONP Service"
> because there would be a better way to get the same result synchronously
> without any HTTP request, for example:
> document.getRequestHeader('Accept-Language')

I think we need more use cases than just this (especially since this one  
seems addressed already) to consider this.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From t.broyer at gmail.com  Wed Dec 10 06:33:10 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Wed, 10 Dec 2008 15:33:10 +0100
Subject: [whatwg] Implement XMLHttpRequest interface subset
	onHTMLDocument
In-Reply-To: <op.ulx876li64w2qv@annevk-t60.oslo.opera.com>
References: <fb8299e10810291206v6d789194l9dbf5e642c5048b@mail.gmail.com>
	<4F54BEC636854B35AE23B04872D63B9D@POCZTOWIEC>
	<fb8299e10810291219t3ee440c0wf6c35b2e7127aab3@mail.gmail.com>
	<2337294C35E843688470B062BBA6503C@POCZTOWIEC>
	<fb8299e10810291234n2695a9c1nd9b47f4e9631545e@mail.gmail.com>
	<33F436BEAC8947B79203A39CE90739FF@Shepherd.corp>
	<fb8299e10810300021w368b9e28nf773dc73ab457f74@mail.gmail.com>
	<op.ulx876li64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <a9699fd20812100633v3d2a5e0cpf2f0bff44c6e56c6@mail.gmail.com>

On Wed, Dec 10, 2008 at 3:01 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter
> <weston at shepherd-interactive.com> wrote:
>>
>> I have an amendment to my proposal. There was a
>> post<http://ajaxian.com/archives/language-jsonp-service>on Ajaxian
>> today about a "Language JSONP Service" which "calculates the
>> users language based on browser headers". This seems like a terrible
>> workaround since the Accept-Language header is sent from the same browser
>> that the script is running in; a script shouldn't have to make an HTTP
>> request just to find out what the browser's request headers are.
>
> Did you read what kriszyp wrote in a comment to that post?

Yes, and the answer to his question is: yes, there is a difference.

First, those client-side properties give you one lang code only, which
is clearly not enough for conneg. Let's say I have a GWT application
available in dutch and english, where dutch is the "default language"
(i.e. prefered over english). My navigator.language returns "fr", but
my Accept-Language reads "fr-fr, fr, en". With navigator.language
only, I'd have the dutch version, with Accept-Language I'd have the
english one.

Second, these client-side properties return the UI language, which is
different from the user-preferred language. FF3.1b2 is now available
in many languages but before that, only english was available.
navigator.language in this case would return "en", despite me having
changed Accept-Language to "fr-fr, fr, en".


-- 
Thomas Broyer


From alex.baldacchino at email.it  Wed Dec 10 08:10:06 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 10 Dec 2008 17:10:06 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <c9e12660812092120l600222b4k48fa6e5071ba409c@mail.gmail.com>
References: <4908A0B9.9090705@moonset.net>	<A62B419C-FFB7-4F24-8BEF-83C0342CFBE7@iki.fi>	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	<4934F42A.703@moonset.net>	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	<49394447.5040101@moonset.net>
	<49397098.2090000@email.it>	<op.ulp68waoidj3kv@hp-a0a83fcd39d2>
	<493B3E4D.2040507@email.it>
	<c9e12660812092120l600222b4k48fa6e5071ba409c@mail.gmail.com>
Message-ID: <493FE9DE.80808@email.it>

Garrett Smith ha scritto:
> On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino
> <alex.baldacchino at email.it> wrote:
>   
>> Simon Pieters ha scritto:
>>     
>>> On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino
>>> <alex.baldacchino at email.it> wrote:
>>>
>>>       
>>>> [...]
>>>>         
>>> (I'm currently the editor of that proposal, currently located at
>>> http://simon.html5.org/specs/web-dom-core )
>>>
>>>       
>> I'm reading it :-)
>>
>> And I have a few questions.
>>     
>
> I did not see a proposal for Element.getElementById.
>
> I would not care about that much.
>
> I woud rather have
>
> Element.getElementsByName.
>
> It is perfectly valid for a doucment to have multiple elements w/the
> same name (though not generally a good idea). I've seen this before.
>
> Was this proposed?
>
> Garrett
>   
I don't remember what spec exactly stated this first, but I remind of a 
previous HTML version declaring the 'name' attribute as unique in the 
'global scope' (or something like that), meaning the whole document; 
then, I remember 'name' was deprecated in favour of 'id'. I think 
'getElementsByName' was retained from the past just because form 
elements scoped input names in a different manner (while the name of an 
anchor, for instance, had to be unique in the whole document), but it 
was a bit conflicting with the uniqueness of (at least some) elements' 
name. Anyway, this is what I remember (current specification no more 
defines a name attribute for every elements - it's not on the 
HTMLElement interface).

However, the issue about Node.getElementById originated by noticing 
problems with duplicate ids in existing pages and the likelihood new 
pages may have duplicate ids (e.g. by repeatedly cloning and inserting 
nodes without caring of all attributes), thinking on the opportunity to 
address such an illegal state somehow. If non-unique identifiers have to 
be a deliberate and 'careful' choise, such to involve a dedicated 
attribute, perhaps the class attribute and [ HTMLDocument | HTMLElement 
| whatever_else_implementing ].getElementsByClassName() methods can 
address that: classes are non-unique not only for the whole document, 
but also for the same element, which may have multiple classes listed in 
its attribute (each class name is unique in the list), so they might be 
used for some non-style-related purposes, just appending a name to the 
list of styling classes (just to give some clearness, though 
unnecessary), and querying it with getElementsByClassName() would work 
the same way as resorting to the 'name' attribute and the 
'getElementsByName()' method (perhaps a bit tricky, but should work fine).

~~~~~~~~~~

@ Simon Pieters (and everyone else on the list, of course).

I was thinking again on 'getElementsByClassName()' moved to Web DOM 
Core: maybe a good place for it might be the Node interface, so to have 
the method working on Documents as well as on Elements; if the 
HTMLCollection interface were moved as well, perhaps such might be the 
return value, instead of a NodeList, since non-element Nodes should 
never be expected to have a class name, I guess (perhaps doing the same 
with getElementsByTagName might be consistent, but maybe problematic 
because of backward compatibility -- while getElementsByClassName would 
be a 'new entry' in the 'reign' of Core interfaces, thus a greater 
degree of freedom might be taken, if reasonable, of course - it may 
depend on a known need for different, specilized algorithms in Document 
and Element nodes, for instance).

Best regards,
Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 RC Auto?
* Con Direct Line garanzia furto e incendio a soli 30 ? per un anno! Non perdere l?occasione!
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8497&d=10-12


From dhtmlkitchen at gmail.com  Wed Dec 10 09:17:40 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 10 Dec 2008 09:17:40 -0800
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <493FE9DE.80808@email.it>
References: <4908A0B9.9090705@moonset.net>
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>
	<4934F42A.703@moonset.net>
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>
	<op.ulp68waoidj3kv@hp-a0a83fcd39d2> <493B3E4D.2040507@email.it>
	<c9e12660812092120l600222b4k48fa6e5071ba409c@mail.gmail.com>
	<493FE9DE.80808@email.it>
Message-ID: <c9e12660812100917k419ab30dh78c237aad189e315@mail.gmail.com>

On Wed, Dec 10, 2008 at 8:10 AM, Calogero Alex Baldacchino
<alex.baldacchino at email.it> wrote:
> Garrett Smith ha scritto:
>>
>> On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino
>> <alex.baldacchino at email.it> wrote:
>>
>>>
>>> Simon Pieters ha scritto:
>>>
>>>>
>>>> On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino
>>>> <alex.baldacchino at email.it> wrote:
>>>>
>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>
>>>> (I'm currently the editor of that proposal, currently located at
>>>> http://simon.html5.org/specs/web-dom-core )
>>>>
>>>>
>>>
>>> I'm reading it :-)
>>>
>>> And I have a few questions.
>>>
>>
>> I did not see a proposal for Element.getElementById.
>>
>> I would not care about that much.
>>
>> I woud rather have
>>
>> Element.getElementsByName.
>>
>> It is perfectly valid for a doucment to have multiple elements w/the
>> same name (though not generally a good idea). I've seen this before.
>>
>> Was this proposed?
>>
>> Garrett
>>
>
> I don't remember what spec exactly stated this first, but I remind of a
> previous HTML version declaring the 'name' attribute as unique in the
> 'global scope' (or something like that),

What?

> meaning the whole document; then, I
> remember 'name' was deprecated in favour of 'id'.

Name is not deprecated. It is, as I said, "perfectly valid". How else
are you going to submit form values?

Garrett


From weston at shepherd-interactive.com  Wed Dec 10 09:28:11 2008
From: weston at shepherd-interactive.com (Weston Ruter)
Date: Wed, 10 Dec 2008 09:28:11 -0800
Subject: [whatwg] Implement XMLHttpRequest interface subset
	onHTMLDocument
In-Reply-To: <op.ulx876li64w2qv@annevk-t60.oslo.opera.com>
References: <fb8299e10810291206v6d789194l9dbf5e642c5048b@mail.gmail.com>
	<4F54BEC636854B35AE23B04872D63B9D@POCZTOWIEC>
	<fb8299e10810291219t3ee440c0wf6c35b2e7127aab3@mail.gmail.com>
	<2337294C35E843688470B062BBA6503C@POCZTOWIEC>
	<fb8299e10810291234n2695a9c1nd9b47f4e9631545e@mail.gmail.com>
	<33F436BEAC8947B79203A39CE90739FF@Shepherd.corp>
	<fb8299e10810300021w368b9e28nf773dc73ab457f74@mail.gmail.com>
	<op.ulx876li64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <fb8299e10812100928u67463832vd25fa946d307013@mail.gmail.com>

On Wed, Dec 10, 2008 at 6:01 AM, Anne van Kesteren <annevk at opera.com> wrote:


> I think we need more use cases than just this (especially since this one
> seems addressed already) to consider this.
>

I agree we need more use cases. You understand that the Accept-Language
header is just one example of a header that needs to be read via scripting;
the use case addressed by "Language JSONP Service" highlights the need for
getRequestHeaders() since its solution is an inefficient (although clever)
hack. Ideally, scripts should be able to access all of the request and
response headers.

Another use case would be getting the "Accept" header to detect if the
client can be served XHTML.

Weston


On Wed, Dec 10, 2008 at 6:01 AM, Anne van Kesteren <annevk at opera.com> wrote:

> On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter <
> weston at shepherd-interactive.com> wrote:
>
>> I have an amendment to my proposal. There was a
>> post<http://ajaxian.com/archives/language-jsonp-service>on Ajaxian
>> today about a "Language JSONP Service" which "calculates the
>> users language based on browser headers". This seems like a terrible
>> workaround since the Accept-Language header is sent from the same browser
>> that the script is running in; a script shouldn't have to make an HTTP
>> request just to find out what the browser's request headers are.
>>
>
> Did you read what kriszyp wrote in a comment to that post?
>
>
>  Therefore, I propose that in addition to implementing on HTMLDocument the
>> XMLHttpRequest interface subset I initially suggested, I see that it would
>> also be very useful for a script to obtain the request headers that were
>> sent which resulted in the current document as the response. The current
>> version of XMLHttpRequest hints to a future version including a
>> getRequestHeader() method, a method which would complement
>> getResponseHeader(); there could also be a getAllRequestHeaders() method
>> that would correspond to the existing getAllResponseHeaders() method.
>> (Obviously it would not make sense to implement the setRequestHeader()
>> method.)
>>
>> If these two methods ( getRequestHeader() and getAllRequestHeaders() )
>> were
>> implemented, then there would be no need for a "Language JSONP Service"
>> because there would be a better way to get the same result synchronously
>> without any HTTP request, for example:
>> document.getRequestHeader('Accept-Language')
>>
>
> I think we need more use cases than just this (especially since this one
> seems addressed already) to consider this.
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081210/1c898b5c/attachment.htm>

From alex.baldacchino at email.it  Wed Dec 10 11:21:21 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 10 Dec 2008 20:21:21 +0100
Subject: [whatwg] Use cases for Node.getElementById
In-Reply-To: <c9e12660812100917k419ab30dh78c237aad189e315@mail.gmail.com>
References: <4908A0B9.9090705@moonset.net>	
	<9684B992-FFA2-4890-ACFA-D96F7610F803@iki.fi>	
	<4934F42A.703@moonset.net>	
	<26b395e60812020707s5989915fg46943b3f22d963b3@mail.gmail.com>	
	<49394447.5040101@moonset.net> <49397098.2090000@email.it>	
	<op.ulp68waoidj3kv@hp-a0a83fcd39d2> <493B3E4D.2040507@email.it>	
	<c9e12660812092120l600222b4k48fa6e5071ba409c@mail.gmail.com>	
	<493FE9DE.80808@email.it>
	<c9e12660812100917k419ab30dh78c237aad189e315@mail.gmail.com>
Message-ID: <494016B1.3020004@email.it>

Garrett Smith ha scritto:
> On Wed, Dec 10, 2008 at 8:10 AM, Calogero Alex Baldacchino
> <alex.baldacchino at email.it> wrote:
>   
>> Garrett Smith ha scritto:
>>     
>>> On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino
>>> <alex.baldacchino at email.it> wrote:
>>>
>>>       
>>>> Simon Pieters ha scritto:
>>>>
>>>>         
>>>>> On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino
>>>>> <alex.baldacchino at email.it> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> [...]
>>>>>>
>>>>>>             
>>>>> (I'm currently the editor of that proposal, currently located at
>>>>> http://simon.html5.org/specs/web-dom-core )
>>>>>
>>>>>
>>>>>           
>>>> I'm reading it :-)
>>>>
>>>> And I have a few questions.
>>>>
>>>>         
>>> I did not see a proposal for Element.getElementById.
>>>
>>> I would not care about that much.
>>>
>>> I woud rather have
>>>
>>> Element.getElementsByName.
>>>
>>> It is perfectly valid for a doucment to have multiple elements w/the
>>> same name (though not generally a good idea). I've seen this before.
>>>
>>> Was this proposed?
>>>
>>> Garrett
>>>
>>>       
>> I don't remember what spec exactly stated this first, but I remind of a
>> previous HTML version declaring the 'name' attribute as unique in the
>> 'global scope' (or something like that),
>>     
>
> What?
>
>   
>> meaning the whole document; then, I
>> remember 'name' was deprecated in favour of 'id'.
>>     
>
> Name is not deprecated. It is, as I said, "perfectly valid". How else
> are you going to submit form values?
>
> Garrett
>   

I was referring to some elements using it as a global identifier, like 
<a> and <img>, and apologize for any lack of clearness.

 From http://www.w3.org/TR/html401/struct/links.html#adef-name-A

"This attribute names the current anchor so that it may be the 
destination of another link. The value of this attribute must be a 
unique anchor name. The scope of this name is the current document. Note 
that this attribute shares the same name space as the id attribute" 
<http://www.w3.org/TR/html401/struct/global.html#adef-id>

 From http://www.w3.org/TR/html401/struct/objects.html#adef-name-IMG

"This attribute names the element so that it may be referred to from 
style sheets or scripts. Note.** This attribute has been included for 
backwards compatibility. Applications should use the id attribute to 
identify elements"

 From http://www.w3.org/TR/html401/struct/links.html#anchors-with-id

"The id and name attributes share the same namespace.This means that 
they cannot both define an anchor with the same name in the same 
document. It is permissible to use both attributes to specify an 
element's unique identifier for the following elements: A, APPLET, FORM, 
FRAME, IFRAME, IMG and MAP. When both attributes are used on a single 
element, their values must be identical."

You'll find neither html 4.01, nor html 5 declare a 'name' attribute for 
every element (some of html 5 elements have lost their older 'name' 
attribute, though it might be handled by the parser for backwards 
compatibility, i.e. for the <a> element representing a fragment of the 
document).
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CheBanca! La prima banca che ti d? gli interessi in anticipo.
* Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7918&d=10-12


From silviapfeiffer1 at gmail.com  Wed Dec 10 14:57:45 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 11 Dec 2008 09:57:45 +1100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
	<2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
Message-ID: <2c0e02830812101457i5d7d3f18nb8ff128187b185d4@mail.gmail.com>

And now we have a first demo of the proposed syntax in action. Michael
Dale implemented SRT support like this:

<video src="sample_fish.ogg" poster="sample_fish.jpg" duration="26">
 	<text category="SUB" lang="en" type="text/x-srt" default="true"
 		title="english SRT subtitles" src="sample_fish_text_en.srt">
 	</text>
 	<text category="SUB" lang="es" type="text/x-srt"
 	 	title="spanish SRT subtitles" src="sample_fish_text_es.srt">
 	</text>
</video>

Michael writes:
> the demo: (tested on IE, Firefox, Safari ... with varying degrees of success ;)
> http://metavid.org/w/extensions/MetavidWiki/skins/mv_embed/example_usage/sample_timed_text.php
(bottom example)
>
> If Firefox exposes timed text tracks in ogg media the script could query
> them and display them alongside any available markup text tracks (but of
> course other browsers like IE wont easily expose those muxed text tracks
> so its likely the least common denominator of text based markup /
> pointers will be dominate for some time)

You will need to click on the "CC" button on the player and click on
"select transcripts" to see the different subtitles in English and
Spanish.

Regards,
Silvia.


On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> I heard some complaints about there not being any implementation of
> the suggestions I made.
>
> So here goes:
>
> 1. out-of-band
> There is an example of using srt with ogg in a out-of-band approach here:
> http://v2v.cc/~j/jquery.srt/
> You will need Firefox3.1 to play it.
> The syntax of what Jan implemented is different to what I proposed,
> but I wanted to take it forward and make it more generic.
>
> 2. in-band
> There is also a draft implementation of srt inside Ogg through the
> OggText specification, but I it's not released yet. It is also not as
> relevant to this group as the out-of-band example.
>
> Cheers,
> Silvia.
>
>
>
> On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>> On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>
>> wrote:
>>>
>>> Silvia Pfeiffer wrote:
>>>>
>>>> I'm interested to hear people's opinions on these ideas. I agree with
>>>> Ralph and think having a simple, explicit mechanism at the html level
>>>> is worthwhile - and very open and explicit to a web author. Having a
>>>> redirection through a ROE-type file on the server is more opaque, but
>>>> maybe more consistent with existing similar approaches as taken by
>>>> RealNetworks in rm files and WindowsMedia files in asx files.
>>>>
>>>
>>> This (having a separate document that references other streams) is what I
>>> was thinking of. I guess which is more natural depends on who is doing the
>>> assembling. If it is the HTML author that takes the individual pieces and
>>> links them together then doing it in the HTML is probably easiest.
>>
>>
>> For what it's worth, loading an intermediate document of some new type which
>> references other streams to be loaded adds a lot of complexity to the
>> browser implementation. It creates new states that the decoder can be in,
>> and introduces new failure modes. It creates new timing issues and possibly
>> new security issues.
>>
>> 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]
>>
>


From dale at ucsc.edu  Wed Dec 10 16:53:22 2008
From: dale at ucsc.edu (Michael Dale)
Date: Wed, 10 Dec 2008 16:53:22 -0800
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812101457i5d7d3f18nb8ff128187b185d4@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>	<493DD339.5040604@degeneration.co.uk>	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>	<493E000A.7000207@degeneration.co.uk>	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>	<2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
	<2c0e02830812101457i5d7d3f18nb8ff128187b185d4@mail.gmail.com>
Message-ID: <49406482.2090005@ucsc.edu>

Yea as Silvia outlines in the intro to this thread we will likely 
continue to see external timed text files "winning out" over muxed timed 
text.

"Its just more flexible" ... Javascript embedding libraries which are 
widely used today for flash video will be even more widely used with the 
emerging browser support of the video tag.

So its not too big a deal... the complexity of transcript formats will 
be handled by dedicated javascript libraries. If the browser does expose 
some timed text tracks muxed with the media then the library will 
integrate that into the interface.

That being said having some semantically meaningful source data 
representation is worthwhile. By supporting these proposed syntax with 
the embedding libraries we are promoting the idea that the syntax will 
eventually be adopted and natively handled by the browser. But in 
practice even if we do get native timed text support a javascript 
library will likely rewrite it to conform the sites layout and skinning 
anyway.

The "take-away" point here is if people do mux text tracks that they 
should be exposed via javascript. Otherwise it will be of very limited 
value in the context of web media.

peace,
--michael

Silvia Pfeiffer wrote:
> And now we have a first demo of the proposed syntax in action. Michael
> Dale implemented SRT support like this:
>
> <video src="sample_fish.ogg" poster="sample_fish.jpg" duration="26">
>  	<text category="SUB" lang="en" type="text/x-srt" default="true"
>  		title="english SRT subtitles" src="sample_fish_text_en.srt">
>  	</text>
>  	<text category="SUB" lang="es" type="text/x-srt"
>  	 	title="spanish SRT subtitles" src="sample_fish_text_es.srt">
>  	</text>
> </video>
>
> Michael writes:
>   
>> the demo: (tested on IE, Firefox, Safari ... with varying degrees of success ;)
>> http://metavid.org/w/extensions/MetavidWiki/skins/mv_embed/example_usage/sample_timed_text.php
>>     
> (bottom example)
>   
>> If Firefox exposes timed text tracks in ogg media the script could query
>> them and display them alongside any available markup text tracks (but of
>> course other browsers like IE wont easily expose those muxed text tracks
>> so its likely the least common denominator of text based markup /
>> pointers will be dominate for some time)
>>     
>
> You will need to click on the "CC" button on the player and click on
> "select transcripts" to see the different subtitles in English and
> Spanish.
>
> Regards,
> Silvia.
>
>
> On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>   
>> I heard some complaints about there not being any implementation of
>> the suggestions I made.
>>
>> So here goes:
>>
>> 1. out-of-band
>> There is an example of using srt with ogg in a out-of-band approach here:
>> http://v2v.cc/~j/jquery.srt/
>> You will need Firefox3.1 to play it.
>> The syntax of what Jan implemented is different to what I proposed,
>> but I wanted to take it forward and make it more generic.
>>
>> 2. in-band
>> There is also a draft implementation of srt inside Ogg through the
>> OggText specification, but I it's not released yet. It is also not as
>> relevant to this group as the out-of-band example.
>>
>> Cheers,
>> Silvia.
>>
>>
>>
>> On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>>     
>>> On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>
>>> wrote:
>>>       
>>>> Silvia Pfeiffer wrote:
>>>>         
>>>>> I'm interested to hear people's opinions on these ideas. I agree with
>>>>> Ralph and think having a simple, explicit mechanism at the html level
>>>>> is worthwhile - and very open and explicit to a web author. Having a
>>>>> redirection through a ROE-type file on the server is more opaque, but
>>>>> maybe more consistent with existing similar approaches as taken by
>>>>> RealNetworks in rm files and WindowsMedia files in asx files.
>>>>>
>>>>>           
>>>> This (having a separate document that references other streams) is what I
>>>> was thinking of. I guess which is more natural depends on who is doing the
>>>> assembling. If it is the HTML author that takes the individual pieces and
>>>> links them together then doing it in the HTML is probably easiest.
>>>>         
>>> For what it's worth, loading an intermediate document of some new type which
>>> references other streams to be loaded adds a lot of complexity to the
>>> browser implementation. It creates new states that the decoder can be in,
>>> and introduces new failure modes. It creates new timing issues and possibly
>>> new security issues.
>>>
>>> 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]
>>>
>>>       



From robert at ocallahan.org  Wed Dec 10 17:40:43 2008
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 11 Dec 2008 14:40:43 +1300
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <p0624084cc564fb45bd80@17.202.35.52>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
	<p0624084cc564fb45bd80@17.202.35.52>
Message-ID: <11e306600812101740w97f60cbl429433b0fcbe1071@mail.gmail.com>

On Wed, Dec 10, 2008 at 5:56 PM, Dave Singer <singer at apple.com> wrote:

> At 21:33  +1300 9/12/08, Robert O'Callahan wrote:
>
>> For what it's worth, loading an intermediate document of some new type
>> which references other streams to be loaded adds a lot of complexity to the
>> browser implementation. It creates new states that the decoder can be in,
>> and introduces new failure modes. It creates new timing issues and possibly
>> new security issues.
>>
>
> I'm not sure I agree;  but if you believe that, we should address it no
> matter which way this discussion goes.  It should absolutely be possible to
> reference a SMIL file, or an MP4 or MOV file with external data (to give
> only two examples) from a <video> or <audio> element, and have the DOM,
> events, states, and APis work correctly.


I agree it should be done eventually, it's just significantly more
complicated than what we have to deal with currently.

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/20081211/805caf8c/attachment.htm>

From singer at apple.com  Wed Dec 10 20:19:06 2008
From: singer at apple.com (Dave Singer)
Date: Thu, 11 Dec 2008 13:19:06 +0900
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <11e306600812101740w97f60cbl429433b0fcbe1071@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
	<p0624084cc564fb45bd80@17.202.35.52>
	<11e306600812101740w97f60cbl429433b0fcbe1071@mail.gmail.com>
Message-ID: <p06240867c56644c0c1ff@[17.202.35.52]>

At 14:40  +1300 11/12/08, Robert O'Callahan wrote:
>On Wed, Dec 10, 2008 at 5:56 PM, Dave Singer 
><<mailto:singer at apple.com>singer at apple.com> wrote:
>
>At 21:33  +1300 9/12/08, Robert O'Callahan wrote:
>
>For what it's worth, loading an intermediate document of some new 
>type which references other streams to be loaded adds a lot of 
>complexity to the browser implementation. It creates new states that 
>the decoder can be in, and introduces new failure modes. It creates 
>new timing issues and possibly new security issues.
>
>
>I'm not sure I agree;  but if you believe that, we should address it 
>no matter which way this discussion goes.  It should absolutely be 
>possible to reference a SMIL file, or an MP4 or MOV file with 
>external data (to give only two examples) from a <video> or <audio> 
>element, and have the DOM, events, states, and APis work correctly.
>
>
>I agree it should be done eventually, it's just significantly more 
>complicated than what we have to deal with currently.

But if the state machine or other aspects are actually wrong for this 
case, then we should fix it now.  We have, for example, tried to keep 
out these kinds of assumptions:
a) all media is downloaded (no, it might be streamed or even arriving 
over non-IP, e.g. a TV broadcast)
b) all delivery methods are self-contained (no, they might reference 
resources as well as contain them)
c) all delivery is sequential in play order (no, some file formats 
decouple data timing and data ordering)

>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]


-- 
David Singer
Multimedia Standards, Apple Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081211/b8e2814d/attachment.htm>

From t.broyer at gmail.com  Thu Dec 11 01:54:40 2008
From: t.broyer at gmail.com (Thomas Broyer)
Date: Thu, 11 Dec 2008 10:54:40 +0100
Subject: [whatwg] Solving the login/logout problem in HTML
In-Reply-To: <Pine.LNX.4.62.0811272025080.17401@hixie.dreamhostps.com>
References: <492DD0D9.4010703@email.it> <op.ulajyicjflu5h5@quark-mac-pro.local>
	<Pine.LNX.4.62.0811272025080.17401@hixie.dreamhostps.com>
Message-ID: <a9699fd20812110154s68e53348g98a6b6d9f1cce617@mail.gmail.com>

[ CC: ietf-http-wg, ietf-http-auth; please follow up to ietf-http-auth only ]
See http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017569.html
The thread started at
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/017413.html

On Wed, Nov 26, 2008 at 12:47 PM, Thomas Broyer wrote:
> On Tue, Nov 25, 2008 at 6:26 AM, Ian Hickson wrote:
>>
>> It seems to me that the first limitation of form authentication could be
>> removed by inventing a new WWW-Authenticate challenge that means "reply to
>> the form in the page". I have now specified such a value in HTML5 (since
>> it is specific to entity bodies that contain HTML forms):
>
> I came to the same conclusion [...]

On Thu, Nov 27, 2008 at 9:38 PM, Ian Hickson wrote:
>
> On Thu, 27 Nov 2008, Julian Reschke wrote:
>>
>> The specification of this scheme (which essentially is a no-op to
>> implement for browser vendors and which already works "almost
>> everywhere") could either happen in the W3C or in the IETF. I'm happy to
>> assist in case the latter alternative is chosen.
>
> I've removed the text from HTML5. If anyone wants to run with this and
> specify it in a separate document, please let me know.
[...]
> Thanks everyone for the feedback on this idea. I recommend that interested
> parties get together and come up with a simple RFC for a better solution.

For the record, my initial thoughts (a year or two ago) was about a
"Cookie" auth scheme:

   challenge        =  "Cookie" cookie-challenge

   cookie-challenge  = 1#( realm | [ form-action ] | cookie-name |
                       [ test-cookie-name ] | [auth-param] )

   form-action       = "form-action" "=" <"> URI <">
   URI               = absoluteURI | abs_path
   cookie-name       = "cookie-name" "=" token
   test-cookie-name  = "test-cookie-name" "=" token

Where "form-action" is the HTML/XForms/whatever form's action URL (so
that you know that a form in the document submitting data to this URL
is (potentially) a "login form"). "form-action" must resolve to an
HTTP/HTTPS URL where the "authority" contains no "userinfo", the
"host" has the same contraints as the "Domain" of a Set-Cookie, and
the "asb_path" has the same constraints as the "Path" of a Set-Cookie.
The "cookie-name" param gives the name of the cookie that will be set
after a submission to "form-action" to maintain the "authenticated
session"; an UA could then accept such a cookie even if configured to
reject cookies or ask the user, because it then knows it's kind of
"credentials" for subsequent requests.
The "test-cookie-name" param names a cookie set within the same HTTP
response that will be checked by "form-action" as a mean to detect if
the UA accepts cookies. An UA could then silently, temporarily accept
such a cookie, even if configured to reject cookies or ask the user,
and send it with the submission to "form-action".

The "path" of the cookie set in the response from "form-action"
defines the protection space.


I also had the idea of somehow relaxing how an UA have to manage those
cookies, and therefore set constraints for servers on how they set
their values. For example, the UA could be allowed to ignore changes
in value: once the cookie has been set, its value is fixed until
expiration; this is to prevent servers using this cookie to store
"session info", particularly in the case the user has configured the
UA to reject cookies altogether; the cookie value is considered an
"authentication token" that does not change over time for a given
"authenticated session" (life time of the cookie).
Also (eventually), when contacting "form-action", the UA shouldn't
(mustn't?) react to authentication challenges (apart from a Cookie
challenge identical to the one received in the previous request).


Example (simplified messages):

  1.  User Agent -> Server

      GET http://www.example.com/acme/ HTTP/1.1

  2.  Server -> User Agent

      HTTP/1.1 401 Unauthorized
      WWW-Authenticate: Cookie realm="Acme"
              form-action="https://secure.example.com/acme/login"
              cookie-name=ACME_TICKET
              test-cookie-name=TEST_ACME
      Set-Cookie: TEST_ACME="test"; Version="1"; Path="/acme";
              Secure; Domain=".example.com"
      Content-Type: text/html

      <title>Unauthorized</title>
      <form action="https://secure.example.com/acme/login" method=POST>
      <input type=hidden name=referer
              value="http://www.example.com/acme/">
      <p><label>Username: <input name=user></label>
      <p><label>Password: <input name=pwd type=password></label>
      <p><button type=submit>Sign in</button>
      <p><a href="/acme/register">Register for an account</a>
      </form>

  3. User Agent -> Server

      POST https://secure.example.com/acme/login HTTP/1.1
      Cookie: $Version="1"; TEST_ACME="test"; $Path="/acme";
              $Domain=".example.com"
      Content-Type: application/x-www-form-urlencoded

      referer=http%3A%2F%2Fwww.example.com%2Facme%2F
      &user= Aladdin&password=open%20sesame

  4.  Server -> User Agent

      HTTP/1.1 303 See Other
      Location: http://www.example.com/acme/
      Set-Cookie: TEST_ACME="test"; Version="1"; Path="/acme";
              Domain=".example.com"; Max-Age=0
      Set-Cookie: ACME_TICKET="sdf354s5c1s8e1s"; Version="1";
              Path="/acme"; Domain=".example.com"

  5.  User Agent -> Server

      GET http://www.example.com/acme/ HTTP/1.1
      Cookie: $Version="1"; ACME_TICKET="sdf354s5c1s8e1s";
              $Path="/acme"; $Domain=".example.com"

  6. Server -> User Agent

      HTTP/1.1 200 OK



-- 
Thomas Broyer


From silviapfeiffer1 at gmail.com  Thu Dec 11 15:11:04 2008
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 12 Dec 2008 10:11:04 +1100
Subject: [whatwg] Thoughts on video accessibility
In-Reply-To: <2c0e02830812101457i5d7d3f18nb8ff128187b185d4@mail.gmail.com>
References: <2c0e02830812081727p6c4e29dbi7ef3a01202f99267@mail.gmail.com>
	<493DD339.5040604@degeneration.co.uk>
	<2c0e02830812082056j62afcccenaa5e2775da07feef@mail.gmail.com>
	<493E000A.7000207@degeneration.co.uk>
	<11e306600812090033j6ff2e443medad484a944149e2@mail.gmail.com>
	<2c0e02830812090849i51df5d17w14b9a47466e494f9@mail.gmail.com>
	<2c0e02830812101457i5d7d3f18nb8ff128187b185d4@mail.gmail.com>
Message-ID: <2c0e02830812111511ya35d1e3v6b9837a42c2451e0@mail.gmail.com>

Another implementation comes from the W3C TimedText working group:

They have a test suite for DFXP files at
http://www.w3.org/2008/12/dfxp-testsuite/web-framework/START.html .

Philippe just announced that he added HTML5 video tag support using
the javascript file that Jan had written for srt support and adapting
it to work like this:

 <video src="example.ogv" id="video" controls>
     <text lang='en' type="application/ttaf+xml"
src="testsuite/Content/Br001.xml"></text>
 </video>

You'll need to use Firefox 3.1 to test it.
If you select the HTML5 DFXP player prototype, you can click on the
tests on the left and it will load the DFXP content.

The adapted javascript is at
http://www.w3.org/2008/12/dfxp-testsuite/web-framework/HTML5_player.js .

It works by mapping DFXP to HTML and DFXP styling attributes to CSS.
This is exactly what was also discussed yesterday on irc - if we can
find a simple way to map time-aligned text formats to HTML, it will be
easy to deal with in HTML5.

Regards,
Silvia.


On Thu, Dec 11, 2008 at 9:57 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> And now we have a first demo of the proposed syntax in action. Michael
> Dale implemented SRT support like this:
>
> <video src="sample_fish.ogg" poster="sample_fish.jpg" duration="26">
>        <text category="SUB" lang="en" type="text/x-srt" default="true"
>                title="english SRT subtitles" src="sample_fish_text_en.srt">
>        </text>
>        <text category="SUB" lang="es" type="text/x-srt"
>                title="spanish SRT subtitles" src="sample_fish_text_es.srt">
>        </text>
> </video>
>
> Michael writes:
>> the demo: (tested on IE, Firefox, Safari ... with varying degrees of success ;)
>> http://metavid.org/w/extensions/MetavidWiki/skins/mv_embed/example_usage/sample_timed_text.php
> (bottom example)
>>
>> If Firefox exposes timed text tracks in ogg media the script could query
>> them and display them alongside any available markup text tracks (but of
>> course other browsers like IE wont easily expose those muxed text tracks
>> so its likely the least common denominator of text based markup /
>> pointers will be dominate for some time)
>
> You will need to click on the "CC" button on the player and click on
> "select transcripts" to see the different subtitles in English and
> Spanish.
>
> Regards,
> Silvia.
>
>
> On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> I heard some complaints about there not being any implementation of
>> the suggestions I made.
>>
>> So here goes:
>>
>> 1. out-of-band
>> There is an example of using srt with ogg in a out-of-band approach here:
>> http://v2v.cc/~j/jquery.srt/
>> You will need Firefox3.1 to play it.
>> The syntax of what Jan implemented is different to what I proposed,
>> but I wanted to take it forward and make it more generic.
>>
>> 2. in-band
>> There is also a draft implementation of srt inside Ogg through the
>> OggText specification, but I it's not released yet. It is also not as
>> relevant to this group as the out-of-band example.
>>
>> Cheers,
>> Silvia.
>>
>>
>>
>> On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>>> On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>
>>> wrote:
>>>>
>>>> Silvia Pfeiffer wrote:
>>>>>
>>>>> I'm interested to hear people's opinions on these ideas. I agree with
>>>>> Ralph and think having a simple, explicit mechanism at the html level
>>>>> is worthwhile - and very open and explicit to a web author. Having a
>>>>> redirection through a ROE-type file on the server is more opaque, but
>>>>> maybe more consistent with existing similar approaches as taken by
>>>>> RealNetworks in rm files and WindowsMedia files in asx files.
>>>>>
>>>>
>>>> This (having a separate document that references other streams) is what I
>>>> was thinking of. I guess which is more natural depends on who is doing the
>>>> assembling. If it is the HTML author that takes the individual pieces and
>>>> links them together then doing it in the HTML is probably easiest.
>>>
>>>
>>> For what it's worth, loading an intermediate document of some new type which
>>> references other streams to be loaded adds a lot of complexity to the
>>> browser implementation. It creates new states that the decoder can be in,
>>> and introduces new failure modes. It creates new timing issues and possibly
>>> new security issues.
>>>
>>> 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]
>>>
>>
>


From ian at hixie.ch  Fri Dec 12 00:50:01 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 12 Dec 2008 08:50:01 +0000 (UTC)
Subject: [whatwg] When closing the browser
In-Reply-To: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>
Message-ID: <Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>

On Thu, 28 Feb 2008, ddailey wrote:
>
> The user opens a web application as one of many tabs in a web browser. 
> They then, either within the application window, accidentally hit CTRL W 
> (or its Mac equivalent), or from the operating system, issue a close 
> application command. Most apps (as opposed to the more "passive" 
> browsers) detect that new content has been developed and in is jeopardy 
> of being lost and therefore prompt the user to the status of this 
> possible data loss. The browser, unless I'm missing something, seems to 
> have a different status within the OS and just closes without ceremony.

I just went ahead and specced out the 'onbeforeunload' feature that most 
browsers support today that handles this case.

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


From ian at hixie.ch  Fri Dec 12 00:55:08 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 12 Dec 2008 08:55:08 +0000 (UTC)
Subject: [whatwg] salvaging work while navigating away from a web app --
 onunload="confirm('save before quitting?')
In-Reply-To: <492175F1.4010902@gmail.com>
References: <44E7A70044104684A3494142008367C2@disxgdg31szkx7>
	<a9699fd20811170149w4af10ecfu8c06ea435b9a9c7f@mail.gmail.com>
	<492175F1.4010902@gmail.com>
Message-ID: <Pine.LNX.4.62.0812120850490.30225@hixie.dreamhostps.com>

On Sun, 16 Nov 2008, ddailey wrote:
> 
> Here's the sitch: because of an extensive use of CTRL sequences in the 
> interface, the user will sometimes accidentally do something like CTRL R 
> (which the browser thinks is a refresh command). In a regular app, if 
> users stand in jeopardy of losing all their work, the app usually warns 
> them before quitting. The way I found to work around it (that used to 
> work) was to use onunload="confirm('save before quitting?'). Currently, 
> however, IE seems to have removed my ability to intervene before it 
> erases all work. onbeforeunload=function (){ fix(everything)} doesn't 
> seem to help either.
> 
> So the question: how does HTML 5 currently address the issue and do 
> browsers actually implement something along this line these days?

I just went ahead and specced out the 'onbeforeunload' feature that most 
browsers support today that handles this case.

Basically you just need to do

   onbeforeunload="if (dirty) return 'You have unsaved work. Are you sure you want to close this page?'"

...or some such.


On Mon, 17 Nov 2008, Thomas Broyer wrote:
> 
> I'm not sure you can automatically save but what you can do is cancel 
> the unload with a prompt.
> 
> window.onbeforeunload = function() {
>   return "Your unsaved changes will be lost. Are you sure you want to leave?";
> };
> 
> The browser will prompt the user with the returned string. Clicking "no" 
> or "cancel" (depends on the browser) will cancel the "unload". If you 
> don't want the prompt, just return "undefined" (beware, returning null 
> in IE6 is equivalent to returning the string "null").
> 
> window.onbeforeunload = function() {
>  if (unsavedChanges) {
>    return "You have unsaved changes.";
>  }
>  // return nothing, i.e. return undefined
> };

Right.


> HTML5 is almost silent about beforeunload and unload (and many other) 
> events re. their properties (cancelable in this case). unload is defined 
> in DOM3-Events (as non-cancelable) but AFAICT beforeunload is not spec'd 
> anywhere.

Fixed.


On Mon, 17 Nov 2008, Philipp Serafin wrote:
>
> What you can do for an "emergency save" is to fire a *synchronous* XHR during
> the unload event. This will freeze the UI but since the user was about to
> close the page anyway, this shouldn't matter much.

The other alternative is to be always saving state on the server (or in 
a local database, cookie, or equivalent).

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


From bil at corry.biz  Fri Dec 12 06:59:49 2008
From: bil at corry.biz (Bil Corry)
Date: Fri, 12 Dec 2008 08:59:49 -0600
Subject: [whatwg] When closing the browser
In-Reply-To: <Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>
	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>
Message-ID: <49427C65.6020509@corry.biz>

Ian Hickson wrote on 12/12/2008 2:50 AM: 
> On Thu, 28 Feb 2008, ddailey wrote:
>> The user opens a web application as one of many tabs in a web browser. 
>> They then, either within the application window, accidentally hit CTRL W 
>> (or its Mac equivalent), or from the operating system, issue a close 
>> application command. Most apps (as opposed to the more "passive" 
>> browsers) detect that new content has been developed and in is jeopardy 
>> of being lost and therefore prompt the user to the status of this 
>> possible data loss. The browser, unless I'm missing something, seems to 
>> have a different status within the OS and just closes without ceremony.
> 
> I just went ahead and specced out the 'onbeforeunload' feature that most 
> browsers support today that handles this case.


Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site.  E.g.:

	leaves site:
		closes browser
		closes tab
		closes window
		back/forward to different site
		GET/POST to another site
		navigates away using address bar

	returns to site:
		reloads page
		back/forward to same site
		GET/POST to same site


For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security.


- Bil 



From alex.baldacchino at email.it  Fri Dec 12 08:53:14 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 12 Dec 2008 17:53:14 +0100
Subject: [whatwg] When closing the browser
In-Reply-To: <49427C65.6020509@corry.biz>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>
	<49427C65.6020509@corry.biz>
Message-ID: <494296FA.7040801@email.it>

Bil Corry ha scritto:
> Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was a way to distinguish between the user taking an action which leaves the site vs. taking an action that returns to the site.  E.g.:
>
> 	leaves site:
> 		closes browser
> 		closes tab
> 		closes window
> 		back/forward to different site
> 		GET/POST to another site
> 		navigates away using address bar
>
> 	returns to site:
> 		reloads page
> 		back/forward to same site
> 		GET/POST to same site
>
>
> For privacy, it shouldn't reveal which specific action triggered the event, but knowing if the user is leaving the site means webapps can finally auto-logout the user, which in turn greatly improves security.
>
>
> - Bil 
>
>   

That's a nice idea; the before unload event, for instance, might hold a 
boolean attribute telling whether the user is navigating to the same 
domain or not. Anyway, such might fail somehow (or sometimes) if (a 
relevant part of) the webapp were contained in a frame/iframe inside a 
document coming from a different domain.

Actually, I think your proposed behaviour might be worked around with 
short-living persistent cookies (when enabled, of course). For a login 
mechanism fully based on (non-http-only) cookies, setting a short-timed 
expire date (a matter of few seconds) should do the trick: if the user 
action is directed to the same site, the server would recieve the cookie 
before its expiration; when loading a page within the login cookie 
lifetime, the page would change the expiration time accordingly. For a 
more complex (and secure) login mechanism, a short-living persistent 
cookie might hold a 'secondary' session-id with an expiration date set, 
before unloading, so to match a predefined delay: the webapp would issue 
a delayed logout, so that after the choosen delay every session data 
would be invalidated, and the user logged-out; if an attacker grabbed 
such a secondary cookie, he wouldn't get any relevant login information, 
and its suitability for a cross-site attack (e.g. by loading a page from 
the target site before the cookie expiration) would be restricted to an 
arbitrarily short time (such would be a similar strategy to bank token 
generators: imperfect but working).

Otherwise, the user might be prompted for an explicit logout request 
before unloading (as suggested for volatile data). Perhaps a combination 
of three methods (the boolean attribute telling about same-domain 
navigation, a short-living cookie and an explicit choice by the user) 
might improve the overall security.

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 CheBanca! La prima banca che ti d? gli interessi in anticipo.
* Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8435&d=12-12


From ojan at chromium.org  Fri Dec 12 10:49:39 2008
From: ojan at chromium.org (Ojan Vafai)
Date: Fri, 12 Dec 2008 10:49:39 -0800
Subject: [whatwg] salvaging work while navigating away from a web app --
	onunload="confirm('save before quitting?')
In-Reply-To: <Pine.LNX.4.62.0812120850490.30225@hixie.dreamhostps.com>
References: <44E7A70044104684A3494142008367C2@disxgdg31szkx7>
	<a9699fd20811170149w4af10ecfu8c06ea435b9a9c7f@mail.gmail.com>
	<492175F1.4010902@gmail.com>
	<Pine.LNX.4.62.0812120850490.30225@hixie.dreamhostps.com>
Message-ID: <78dc8440812121049k6fe215a5g1a2ff0bb0d6c98f0@mail.gmail.com>

On Fri, Dec 12, 2008 at 12:55 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Sun, 16 Nov 2008, ddailey wrote:
> >
> > Here's the sitch: because of an extensive use of CTRL sequences in the
> > interface, the user will sometimes accidentally do something like CTRL R
> > (which the browser thinks is a refresh command). In a regular app, if
> > users stand in jeopardy of losing all their work, the app usually warns
> > them before quitting. The way I found to work around it (that used to
> > work) was to use onunload="confirm('save before quitting?'). Currently,
> > however, IE seems to have removed my ability to intervene before it
> > erases all work. onbeforeunload=function (){ fix(everything)} doesn't
> > seem to help either.
> >
> > So the question: how does HTML 5 currently address the issue and do
> > browsers actually implement something along this line these days?
>
> I just went ahead and specced out the 'onbeforeunload' feature that most
> browsers support today that handles this case.
>
> Basically you just need to do
>
>   onbeforeunload="if (dirty) return 'You have unsaved work. Are you sure
> you want to close this page?'"
>
> ...or some such.
>

If we're going for matching what browsers do, there's a number of cases
(different in each browser) where the confirm doesn't popup. In Chrome, for
example, if the beforeunload handler takes too long, we kill it and navigate
away. Similarly, in Firefox, if the beforeunload handler hits the limit for
script execution and the user stops the script, the beforeunload handler
never fires.

Not sure what the right language for that is. But developers try to do
things like using beforeunload/unload to release locks, make server
requests, etc. and it's just not a very reliable thing to do in any browser.
It's really just useful for the quick prompt for the user as to things like
unsaved changes.

Ojan

On Mon, 17 Nov 2008, Thomas Broyer wrote:
> >
> > I'm not sure you can automatically save but what you can do is cancel
> > the unload with a prompt.
> >
> > window.onbeforeunload = function() {
> >   return "Your unsaved changes will be lost. Are you sure you want to
> leave?";
> > };
> >
> > The browser will prompt the user with the returned string. Clicking "no"
> > or "cancel" (depends on the browser) will cancel the "unload". If you
> > don't want the prompt, just return "undefined" (beware, returning null
> > in IE6 is equivalent to returning the string "null").
> >
> > window.onbeforeunload = function() {
> >  if (unsavedChanges) {
> >    return "You have unsaved changes.";
> >  }
> >  // return nothing, i.e. return undefined
> > };
>
> Right.
>
>
> > HTML5 is almost silent about beforeunload and unload (and many other)
> > events re. their properties (cancelable in this case). unload is defined
> > in DOM3-Events (as non-cancelable) but AFAICT beforeunload is not spec'd
> > anywhere.
>
> Fixed.
>
>
> On Mon, 17 Nov 2008, Philipp Serafin wrote:
> >
> > What you can do for an "emergency save" is to fire a *synchronous* XHR
> during
> > the unload event. This will freeze the UI but since the user was about to
> > close the page anyway, this shouldn't matter much.
>
> The other alternative is to be always saving state on the server (or in
> a local database, cookie, or equivalent).
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081212/2201c078/attachment.htm>

From bil at corry.biz  Fri Dec 12 11:17:39 2008
From: bil at corry.biz (Bil Corry)
Date: Fri, 12 Dec 2008 13:17:39 -0600
Subject: [whatwg] salvaging work while navigating away from a web app
 --	onunload="confirm('save before quitting?')
In-Reply-To: <78dc8440812121049k6fe215a5g1a2ff0bb0d6c98f0@mail.gmail.com>
References: <44E7A70044104684A3494142008367C2@disxgdg31szkx7>	<a9699fd20811170149w4af10ecfu8c06ea435b9a9c7f@mail.gmail.com>	<492175F1.4010902@gmail.com>	<Pine.LNX.4.62.0812120850490.30225@hixie.dreamhostps.com>
	<78dc8440812121049k6fe215a5g1a2ff0bb0d6c98f0@mail.gmail.com>
Message-ID: <4942B8D3.90907@corry.biz>

Ojan Vafai wrote on 12/12/2008 12:49 PM: 
> If we're going for matching what browsers do, there's a number of cases
> (different in each browser) where the confirm doesn't popup. In Chrome, for
> example, if the beforeunload handler takes too long, we kill it and navigate
> away. Similarly, in Firefox, if the beforeunload handler hits the limit for
> script execution and the user stops the script, the beforeunload handler
> never fires.
> 
> Not sure what the right language for that is. But developers try to do
> things like using beforeunload/unload to release locks, make server
> requests, etc. and it's just not a very reliable thing to do in any browser.
> It's really just useful for the quick prompt for the user as to things like
> unsaved changes.

Here's a fun one, I made this as a demo to show how a website could trap a user forever:

	http://www.corry.biz/neverleave.lasso

I haven't tried it in any browsers lately, but a quick test with IE7 shows it still is effective (for it at least).


- Bil



From alex.baldacchino at email.it  Fri Dec 12 11:36:32 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 12 Dec 2008 20:36:32 +0100
Subject: [whatwg] URL parsing and same-document references [was: Re:
 Citing multiple <blockquote> elements in HTML5]
In-Reply-To: <49387C93.3010004@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>	<4932CC01.9010301@email.it>	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>	<4933547C.2010501@email.it>	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>	<49341055.1030809@email.it>	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>	<49359594.4060502@email.it>	<4935BB01.9000203@googlemail.com>	<49361DB2.1010103@email.it>	<Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>	<4936F3B7.5030908@email.it>
	<49387C93.3010004@email.it>
Message-ID: <4942BD40.3070303@email.it>

Calogero Alex Baldacchino ha scritto:
> Maybe the above needs a further clarification. Let me start from URL 
> parsing (and resolving) rules: after the URL is validated, it's 
> divided into its components, but nothing is stated about normalization 
> and/or %-encoded characters. I think that applying a somewhat 
> normalization may be useful to parse equivalent URLs in a consistent 
> manner, helpful when dealing with the interfaces for URL manipulation, 
> as described in section 2.5.5, and, last but not least, an improvement 
> in relative references matching (especially same-document references). 
> A minimum requirement, for standardization sake, may consist of 
> decoding any %-encoded characters in the <fragment> production, which 
> are part of the <unreserved> production as defined in RFC 3986 with 
> the changes defined in HTML 5 specification for URLs parsing and 
> restricted to the Unicode ranges representing valid characters for an 
> attribute value (those which are not prohibited neither as 'text' nor 
> as 'character references'). This way, a character-for-character 
> comparison between a fragment identifier and an id attribute value, 
> which would have been equivalent but not matching without the 
> normalization, should success most of times, because, as a consequence 
> of the changes applied by HTML 5 current specification to the 
> <unreserved> production, such characters might or might not be 
> %-encoded in a valid URL, while an id value is likely to contain them 
> non-encoded.
>
> After the above <fragment> normalization, a character-for-character 
> comparison would fail if the id value contained any %-encoded triplet 
> representing a decoded character, such as "foo%20bar". Anyway, such 
> may be a weird thing to deal with, since it can be the %-encoded form 
> of "foo bar", but also the decoded form of "foo%2520bar". In other 
> words, if we apply the same normalization to two complete URLs, then 
> we compare them, the result is quite reliable, but if we start from a 
> component (such as a fragment identifier stored in an id attribute 
> value) it's not easy to tell whether any normalization has been 
> applied and which one, so there are always chances for false positives 
> or false negatives to happen. According with RFC 3986, section "4.4. 
> Same-Document Reference", the correct interpretation of a URI as a 
> same-document reference cannot be hold as guaranteed, thus the 
> mismatch between, for instance, the  decoded fragment identifier "foo 
> bar" and the id attribute value "foo%20bar", in front of (as I think) 
> a wide majority of good matches, can be reasonable. Anyway, a kind of 
> double check might be considered, such as:
>
> - comparing the %-unescaped fragment identifier with the ID of each 
> element in the DOM;
> - upon failure, applying a %-unescape algorithm to the ID, then 
> comparing again with the fragment identifier and, if matching, marking 
> the element as a 'possible choice';
> - upon a perfect (exact) match, without unescaping the evaluated 
> element ID, choosing such element as the referenced document part 
> (actually defined as "the indicated part of the document" in the spec) 
> and stopping;
> - without any perfect match in the whole document, choosing the first 
> 'possible choice', if any;
> - without any match at all, the search for the referenced document 
> part fails.
>
> With respect to a "single check" for an exact match, the overall 
> computational time should increase linearly, thus not being a 
> performance issue.
>
> Best regards, Alex.

The above (but the 'double check' I was suggesting) is about the way 
Firefox (2.x and 3.0.4) behaves (both href="#foo%20bar" and, in a 
different page, href="./example.html#foo%20bar" match id="foo bar"), 
while IE7 and Opera 9.x perform an exact comparison, and show, in the 
address bar, an url with eventual blank spaces, thus applying the 
relaxation allowed by URL parsing rules, but not conforming to RFC 3986, 
as a complete URI string. It seems different browsers implement (more or 
less) different normalization/resolution algorithms, leading to 
different matches, thus the specification of a uniform behaviour 
(whatever one) might be reasonable and useful. Actual resolving 
algorithm, while explicitly asking for %-encoding in a path component 
and for conformance with RFC 3986 in general, doesn't talk about 
fragment identifiers; the referred algorithm for relative resolutions 
(section 5.2 of RFC 3986), AIUI, might not require the creation of a 
complete URI string, but instead be accomplished by returning an object 
holding a separated string for each URI part, thus not necessarily 
requiring %-encoding and potentially leaving out to UAs a certain degree 
of freedom. Furthermore, about URL decomposition attributes it is said, 
'On setting, the new value must first be mutated as described by the 
"setter preprocessor" column, then mutated by %-escaping any characters 
in the new value that are not valid in the relevant component as given 
by the "component" column.'; such seems to refer to the stricter RFC3986 
requirements (which in turn might be relaxed, since any part of a 
decomposed URL may contain unescaped characters), however, the 
'component column' points, for each component, to the corresponding 
definition givent for a parsed-URL component, which is not strictly 
required to have escaped characters by actual parsing rules. I'd suggest 
to re-consider the whole mechanism to avoid any free interpretation and 
make each phase/operation (parsing, resolving, attributes setting) more 
consistent both with each other and cross-browser, if possible (I'd also 
consider one or more DOM methods to help an easy comparison between 
URL-strings and/or between component attributes).

Best regards,
Alex.
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Scopri le supernovit? dei games per cellulare! Giocale tutte!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8271&d=12-12


From alex.baldacchino at email.it  Fri Dec 12 11:38:09 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 12 Dec 2008 20:38:09 +0100
Subject: [whatwg] salvaging work while navigating away from a web app
 --	onunload="confirm('save before quitting?')
In-Reply-To: <4942B8D3.90907@corry.biz>
References: <44E7A70044104684A3494142008367C2@disxgdg31szkx7>	<a9699fd20811170149w4af10ecfu8c06ea435b9a9c7f@mail.gmail.com>	<492175F1.4010902@gmail.com>	<Pine.LNX.4.62.0812120850490.30225@hixie.dreamhostps.com>	<78dc8440812121049k6fe215a5g1a2ff0bb0d6c98f0@mail.gmail.com>
	<4942B8D3.90907@corry.biz>
Message-ID: <4942BDA1.8010608@email.it>

Bil Corry ha scritto:
> Ojan Vafai wrote on 12/12/2008 12:49 PM: 
>   
>> If we're going for matching what browsers do, there's a number of cases
>> (different in each browser) where the confirm doesn't popup. In Chrome, for
>> example, if the beforeunload handler takes too long, we kill it and navigate
>> away. Similarly, in Firefox, if the beforeunload handler hits the limit for
>> script execution and the user stops the script, the beforeunload handler
>> never fires.
>>
>> Not sure what the right language for that is. But developers try to do
>> things like using beforeunload/unload to release locks, make server
>> requests, etc. and it's just not a very reliable thing to do in any browser.
>> It's really just useful for the quick prompt for the user as to things like
>> unsaved changes.
>>     
>
> Here's a fun one, I made this as a demo to show how a website could trap a user forever:
>
> 	http://www.corry.biz/neverleave.lasso
>
> I haven't tried it in any browsers lately, but a quick test with IE7 shows it still is effective (for it at least).
>
>
> - Bil
>
>   

I've tested it 'en passant' with FF3: I want my base back!!!!!!! LOL
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Attiva Carta Eureka! Credito fino a 3.000?, rate da 20? e zero costi di attivazione. Conviene!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8429&d=12-12


From mart at degeneration.co.uk  Fri Dec 12 12:01:46 2008
From: mart at degeneration.co.uk (Martin Atkins)
Date: Fri, 12 Dec 2008 12:01:46 -0800
Subject: [whatwg] salvaging work while navigating away from a web app
 --	onunload="confirm('save before quitting?')
In-Reply-To: <4942B8D3.90907@corry.biz>
References: <44E7A70044104684A3494142008367C2@disxgdg31szkx7>	<a9699fd20811170149w4af10ecfu8c06ea435b9a9c7f@mail.gmail.com>	<492175F1.4010902@gmail.com>	<Pine.LNX.4.62.0812120850490.30225@hixie.dreamhostps.com>	<78dc8440812121049k6fe215a5g1a2ff0bb0d6c98f0@mail.gmail.com>
	<4942B8D3.90907@corry.biz>
Message-ID: <4942C32A.9@degeneration.co.uk>

Bil Corry wrote:
> 
> Here's a fun one, I made this as a demo to show how a website could trap a user forever:
> 
> 	http://www.corry.biz/neverleave.lasso
> 
> I haven't tried it in any browsers lately, but a quick test with IE7 shows it still is effective (for it at least).
> 

I think this makes a good case for not allowing any site to create 
browser-modal UI. Could browsers handle confirm() and friends in such a 
way that they only block the contents of the tab, not the whole browser? 
In particular, the "close tab" and "close window" features, ideally 
along with things such as "Back", "Forward" and "Home" should still be 
available.

This does of course create some tricky interactions where onbeforeunload 
is concerned. If I try to close the browser/tab and the page uses 
onbeforeunload to create a confirmation prompt, how does this interact 
with the confirmation prompt only being tab-modal?

Here's a strawman (which I'm sure has some subtleties I've not 
considered): When the user navigates away from the page, fire 
onbeforeunload. However, if the user navigates away from the page WHILE 
THE ONBEFOREUNLOAD EVENT IS BEING HANDLED kill off the onbeforeunload 
handler and do whatever the user asked for.

A browser could potentially display some hard-coded (i.e. not 
site-overridable) UI here letting the user know that there's a page 
that's in the middle of "shutting down" and giving the option to kill it 
much like what happens when an application blocks Shutdown in Microsoft 
Windows. (though ideally without the confusing auto-timeout thing)




From ian at hixie.ch  Fri Dec 12 12:34:44 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 12 Dec 2008 20:34:44 +0000 (UTC)
Subject: [whatwg] When closing the browser
In-Reply-To: <494296FA.7040801@email.it>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>
	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>
	<49427C65.6020509@corry.biz> <494296FA.7040801@email.it>
Message-ID: <Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>

On Fri, 12 Dec 2008, Bil Corry wrote:
> 
> Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if 
> there was a way to distinguish between the user taking an action which 
> leaves the site vs. taking an action that returns to the site.
>
> For privacy, it shouldn't reveal which specific action triggered the 
> event, but knowing if the user is leaving the site means webapps can 
> finally auto-logout the user, which in turn greatly improves security.

If the goal is auto-logout, then what you describe wouldn't help, as it 
would have false-positives (leaving the site when another tab still has 
the site open) and false-negatives (a crash wouldn't log out the user).

Why do session cookies not address this already?

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


From bil at corry.biz  Fri Dec 12 13:56:31 2008
From: bil at corry.biz (Bil Corry)
Date: Fri, 12 Dec 2008 15:56:31 -0600
Subject: [whatwg] When closing the browser
In-Reply-To: <Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>	<49427C65.6020509@corry.biz>
	<494296FA.7040801@email.it>
	<Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
Message-ID: <4942DE0F.5090106@corry.biz>

Ian Hickson wrote on 12/12/2008 2:34 PM: 
> If the goal is auto-logout, then what you describe wouldn't help, as it 
> would have false-positives (leaving the site when another tab still has 
> the site open) and false-negatives (a crash wouldn't log out the user).

Well, more thought needs to go into it.  And maybe it isn't practical, I don't know.

 
> Why do session cookies not address this already?

They do to some extent.  You can choose to make the session life shorter, increasing security but potentially logging the user out before they're ready OR you can choose to make the session life longer, decreasing security but allowing the user more time.

What I see banks do is make the session life short and prompt the user to renew their session before it expires.  It could be that's the ideal way to handle it.  Or maybe it'd be better if non-persistent cookies are removed once the user no longer has an open tab to the site, instead of using a JavaScript-based solution.


- Bil




From ian at hixie.ch  Fri Dec 12 15:11:55 2008
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 12 Dec 2008 23:11:55 +0000 (UTC)
Subject: [whatwg] When closing the browser
In-Reply-To: <4942DE0F.5090106@corry.biz>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>
	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>
	<49427C65.6020509@corry.biz> <494296FA.7040801@email.it>
	<Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
	<4942DE0F.5090106@corry.biz>
Message-ID: <Pine.LNX.4.62.0812122242470.30197@hixie.dreamhostps.com>

On Fri, 12 Dec 2008, Bil Corry wrote:
> >
> > Why do session cookies not address this already?
> 
> They do to some extent.  You can choose to make the session life 
> shorter, increasing security but potentially logging the user out before 
> they're ready OR you can choose to make the session life longer, 
> decreasing security but allowing the user more time.

I don't mean short cookie times, I mean literally session cookies, that 
expire at the end of the session.

sessionStorage (from HTML5) might also help with this; it's limited to 
the lifetime of the tab that it was used in.


> Or maybe it'd be better if non-persistent cookies are removed once the 
> user no longer has an open tab to the site, instead of using a 
> JavaScript-based solution.

This could be done now; I recommend bringing this up with browser vendors 
as a feature request.

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


From bil at corry.biz  Fri Dec 12 15:30:05 2008
From: bil at corry.biz (Bil Corry)
Date: Fri, 12 Dec 2008 17:30:05 -0600
Subject: [whatwg] When closing the browser
In-Reply-To: <Pine.LNX.4.62.0812122242470.30197@hixie.dreamhostps.com>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>	<49427C65.6020509@corry.biz>
	<494296FA.7040801@email.it>	<Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>	<4942DE0F.5090106@corry.biz>
	<Pine.LNX.4.62.0812122242470.30197@hixie.dreamhostps.com>
Message-ID: <4942F3FD.1070704@corry.biz>

Ian Hickson wrote on 12/12/2008 5:11 PM: 
> On Fri, 12 Dec 2008, Bil Corry wrote:
>>> Why do session cookies not address this already?
>> They do to some extent.  You can choose to make the session life 
>> shorter, increasing security but potentially logging the user out before 
>> they're ready OR you can choose to make the session life longer, 
>> decreasing security but allowing the user more time.
> 
> I don't mean short cookie times, I mean literally session cookies, that 
> expire at the end of the session.

But don't they persist until the entire browser is closed?  They'd be perfect if they were removed once all tabs/windows to the site were closed.



> sessionStorage (from HTML5) might also help with this; it's limited to 
> the lifetime of the tab that it was used in.

That could work too.


>> Or maybe it'd be better if non-persistent cookies are removed once the 
>> user no longer has an open tab to the site, instead of using a 
>> JavaScript-based solution.
> 
> This could be done now; I recommend bringing this up with browser vendors 
> as a feature request.

Thanks, it may be something to pursue.


- Bil



From mart at degeneration.co.uk  Fri Dec 12 15:37:29 2008
From: mart at degeneration.co.uk (Martin Atkins)
Date: Fri, 12 Dec 2008 15:37:29 -0800
Subject: [whatwg] When closing the browser
In-Reply-To: <Pine.LNX.4.62.0812122242470.30197@hixie.dreamhostps.com>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>	<49427C65.6020509@corry.biz>
	<494296FA.7040801@email.it>	<Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>	<4942DE0F.5090106@corry.biz>
	<Pine.LNX.4.62.0812122242470.30197@hixie.dreamhostps.com>
Message-ID: <4942F5B9.5060407@degeneration.co.uk>

Ian Hickson wrote:
> On Fri, 12 Dec 2008, Bil Corry wrote:
> 
>> Or maybe it'd be better if non-persistent cookies are removed once the 
>> user no longer has an open tab to the site, instead of using a 
>> JavaScript-based solution.
> 
> This could be done now; I recommend bringing this up with browser vendors 
> as a feature request.
> 

I'm not sure this is as easy as it first appears. For example, consider 
the following case:

* I have a single tab on site1 and I have a session cookie with them.
* I navigate from a page on site1 to site2 and site2 replaces site1 in 
my single tab.
* I navigate from site2 back to site1.

Have I now lost my session cookie?

This scenario is particularly important for technologies that use 
redirects to exchange data between domains, such as OpenID.

Many OpenID implementations (for better or worse) use session cookies to 
retain state while they do the OpenID transaction, which involves 
redirecting the user away from your site to a URL on the provider's 
domain. If implemented exactly as stated, the session cookie would 
presumably be deleted during the OpenID transaction and the original 
site will break.




From ian at hixie.ch  Fri Dec 12 16:09:27 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 13 Dec 2008 00:09:27 +0000 (UTC)
Subject: [whatwg] When closing the browser
In-Reply-To: <4942F5B9.5060407@degeneration.co.uk>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>
	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>
	<49427C65.6020509@corry.biz> <494296FA.7040801@email.it>
	<Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
	<4942DE0F.5090106@corry.biz>
	<Pine.LNX.4.62.0812122242470.30197@hixie.dreamhostps.com>
	<4942F5B9.5060407@degeneration.co.uk>
Message-ID: <Pine.LNX.4.62.0812130008590.30197@hixie.dreamhostps.com>

On Fri, 12 Dec 2008, Martin Atkins wrote:
> Ian Hickson wrote:
> > On Fri, 12 Dec 2008, Bil Corry wrote:
> > 
> > > Or maybe it'd be better if non-persistent cookies are removed once the
> > > user no longer has an open tab to the site, instead of using a
> > > JavaScript-based solution.
> > 
> > This could be done now; I recommend bringing this up with browser vendors as
> > a feature request.
> 
> I'm not sure this is as easy as it first appears. For example, consider the
> following case:
> 
> * I have a single tab on site1 and I have a session cookie with them.
> * I navigate from a page on site1 to site2 and site2 replaces site1 in my
> single tab.
> * I navigate from site2 back to site1.
> 
> Have I now lost my session cookie?
> 
> This scenario is particularly important for technologies that use redirects to
> exchange data between domains, such as OpenID.
> 
> Many OpenID implementations (for better or worse) use session cookies to
> retain state while they do the OpenID transaction, which involves redirecting
> the user away from your site to a URL on the provider's domain. If implemented
> exactly as stated, the session cookie would presumably be deleted during the
> OpenID transaction and the original site will break.

If this was implemented like sessionStorage is specified, then the 
session cookie would only go away once the tab was completely closed, 
IIRC.

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


From jonas at sicking.cc  Fri Dec 12 16:52:15 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 12 Dec 2008 16:52:15 -0800
Subject: [whatwg] Error in Comment start dash state (8.2.4.19)
Message-ID: <63df84f0812121652p7eae626dh27edacb09b44b007@mail.gmail.com>

Currently tokenizing the following string (starting at Data state)
"<!--foo" results in a parse error when hitting the 'f'. It seems like
the error is in the "Comment start dash state" (section 8.2.4.19). It
should switch to 'comment state' when a '-' is consumed, which is not
what it currently does.

/ Jonas


From jonas at sicking.cc  Fri Dec 12 17:01:30 2008
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 12 Dec 2008 17:01:30 -0800
Subject: [whatwg] Error in Comment start dash state (8.2.4.19)
In-Reply-To: <63df84f0812121652p7eae626dh27edacb09b44b007@mail.gmail.com>
References: <63df84f0812121652p7eae626dh27edacb09b44b007@mail.gmail.com>
Message-ID: <63df84f0812121701u6a025f6cn38ff237c785f16d@mail.gmail.com>

On Fri, Dec 12, 2008 at 4:52 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> Currently tokenizing the following string (starting at Data state)
> "<!--foo" results in a parse error when hitting the 'f'. It seems like
> the error is in the "Comment start dash state" (section 8.2.4.19). It
> should switch to 'comment state' when a '-' is consumed, which is not
> what it currently does.

One more thing I forgot to mention. Several of the states regarding
comments refer to outputting 'the comment token' and 'the comment
tokens data'. However there is no mention that I could find for when
the comment token is created. Maybe this isn't an error but a general
pattern?

/ Jonas


From excors+whatwg at gmail.com  Fri Dec 12 17:14:16 2008
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Sat, 13 Dec 2008 01:14:16 +0000
Subject: [whatwg] Error in Comment start dash state (8.2.4.19)
In-Reply-To: <63df84f0812121701u6a025f6cn38ff237c785f16d@mail.gmail.com>
References: <63df84f0812121652p7eae626dh27edacb09b44b007@mail.gmail.com>
	<63df84f0812121701u6a025f6cn38ff237c785f16d@mail.gmail.com>
Message-ID: <ea09c0d10812121714p4eaf1020h310c939dc9bfa39@mail.gmail.com>

On Sat, Dec 13, 2008 at 1:01 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Fri, Dec 12, 2008 at 4:52 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> Currently tokenizing the following string (starting at Data state)
>> "<!--foo" results in a parse error when hitting the 'f'. It seems like
>> the error is in the "Comment start dash state" (section 8.2.4.19). It
>> should switch to 'comment state' when a '-' is consumed, which is not
>> what it currently does.
>
> One more thing I forgot to mention. Several of the states regarding
> comments refer to outputting 'the comment token' and 'the comment
> tokens data'. However there is no mention that I could find for when
> the comment token is created. Maybe this isn't an error but a general
> pattern?

The comment tokens are created in:

  "8.2.4.17 Markup declaration open state
  ...
  If the next two characters are both U+002D HYPHEN-MINUS (-)
characters, consume those two characters, create a comment token whose
data is the empty string, and switch to the comment start state."

I believe that also deals with your first comment: the two dashes are
consumed before switching to the comment start state, and so they're
not going to be seen again in the comment start state or comment start
dash state. (Those states are there to handle <!---> and <!---->.)

-- 
Philip Taylor
excors at gmail.com


From ian at hixie.ch  Fri Dec 12 17:15:16 2008
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 13 Dec 2008 01:15:16 +0000 (UTC)
Subject: [whatwg] Error in Comment start dash state (8.2.4.19)
In-Reply-To: <63df84f0812121652p7eae626dh27edacb09b44b007@mail.gmail.com>
References: <63df84f0812121652p7eae626dh27edacb09b44b007@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0812130108280.30197@hixie.dreamhostps.com>

On Fri, 12 Dec 2008, Jonas Sicking wrote:
>
> Currently tokenizing the following string (starting at Data state) 
> "<!--foo" results in a parse error when hitting the 'f'.

As far as I can tell, it does not.

Assuming we're in a normal state of affairs, here are the states we visit 
and the parse errors we emit as we are consuming the characters:

1. Data state: consume "<" and switch to tag open state.
2. Tag open state: consume "!" and switch to markup declaration open 
   state.
3. Markup declaration open state: see "--" next, consume those characters, 
   and switch to comment start state.
4. Comment start state: consume anything else ("f"), switch to comment 
   state.
5. Comment state: consume anything else ("o"), stay in comment state.
6. Comment state: consume anything else ("o"), stay in comment state.
7. Comment state: parse error, consume EOF, return to data state.
8. Data state: end.

No errors are emitted until the end of the string, as expected.

Am I missing something?


> It seems like the error is in the "Comment start dash state" (section 
> 8.2.4.19). It should switch to 'comment state' when a '-' is consumed, 
> which is not what it currently does.

Given "<!--foo" you should never hit the comment start dash state.


> One more thing I forgot to mention. Several of the states regarding
> comments refer to outputting 'the comment token' and 'the comment
> tokens data'. However there is no mention that I could find for when
> the comment token is created. Maybe this isn't an error but a general
> pattern?

The comment token is created in the first paragraph of the markup 
declaration open state.

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


From nils-dagsson-moskopp at dieweltistgarnichtso.net  Fri Dec 12 19:07:18 2008
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sat, 13 Dec 2008 04:07:18 +0100
Subject: [whatwg] URL parsing and same-document references [was:
	Re:	Citing multiple <blockquote> elements in HTML5]
In-Reply-To: <4942BD40.3070303@email.it>
References: <4126b3450809101013o1c0ee626gef489aa0f0cd9e57@mail.gmail.com>
	<Pine.LNX.4.62.0811300950000.17414@hixie.dreamhostps.com>
	<4932C182.5010905@email.it>	<7D737E03-85D9-401D-828D-F16857CC3105@iki.fi>
	<4932CC01.9010301@email.it>
	<Pine.LNX.4.62.0811302139320.17401@hixie.dreamhostps.com>
	<4933547C.2010501@email.it>
	<dd0fbad0812010620w59105e2h23edf273cc343c50@mail.gmail.com>
	<49341055.1030809@email.it>
	<Pine.LNX.4.62.0812012210270.17401@hixie.dreamhostps.com>
	<49359594.4060502@email.it>	<4935BB01.9000203@googlemail.com>
	<49361DB2.1010103@email.it>
	<Pine.LNX.4.62.0812030556290.17401@hixie.dreamhostps.com>
	<4936F3B7.5030908@email.it> <49387C93.3010004@email.it>
	<4942BD40.3070303@email.it>
Message-ID: <1229137638.4894.15.camel@desudesudesu>

Am Freitag, den 12.12.2008, 20:36 +0100 schrieb Calogero Alex
Baldacchino:
> The above (but the 'double check' I was suggesting) is about the way 
> Firefox (2.x and 3.0.4) behaves (both href="#foo%20bar" and, in a 
> different page, href="./example.html#foo%20bar" match id="foo bar"), 
> while IE7 and Opera 9.x perform an exact comparison, and show, in the 
> address bar, an url with eventual blank spaces, thus applying the 
> relaxation allowed by URL parsing rules, but not conforming to RFC 3986, 
> as a complete URI string.
Whenever I copypaste an URI from the address bar to any other program, I
am severely annoyed by this, especially when spaces (delimiters !) are
part of the fake-URI. A chat or office program, for example, is unable
to highlight the fake-URI anymore, (how could it ?), also pasting it
into source code can create all kind of validation errors. And whenever
I get a bastardized URI via chat or mail, only a part of it is
clickable.

Can someone from the web browser faction please state if there is any
data to support breaking RFC-compatibility ? Because as I see it, its
something that makes it appear nicer, but breaks whenever URIs are to be
transferred / communicated.

Getting to the problem mentioned here, the robustness principle says
that id="foo bar" should be accepted, but nevertheless invalid - because
a fragment with a space can never be part of an URI. So IMHO, any
program should strive to accept broken URIs if they are unambigous
(which they are here, because the address can hold only one URI at a
time), but never output them.


Greetings
-- 
Nils Dagsson Moskopp
<http://dieweltistgarnichtso.net>



From dhtmlkitchen at gmail.com  Fri Dec 12 23:40:42 2008
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Fri, 12 Dec 2008 23:40:42 -0800
Subject: [whatwg] Thoughts on HTML 5
In-Reply-To: <1238778.1005101204223469180.JavaMail.servlet@perfora>
References: <1238778.1005101204223469180.JavaMail.servlet@perfora>
Message-ID: <c9e12660812122340kc54e7abt4a95724f2f18e98c@mail.gmail.com>

On Thu, Feb 28, 2008 at 10:31 AM,  <html at nczonline.net> wrote:



 We then, as developers, could use that attribute as we see fit and
the document would still validate (for people who care about such
things).
> -----------------------------------------

Are people who care about things are the parenthetical afterthought?

Just curious: What are you expecting your invalid html and custom
attributes to do?

Garrett

>
> -Nicholas
>


From phil127 at gmail.com  Sat Dec 13 06:09:40 2008
From: phil127 at gmail.com (Philipp Serafin)
Date: Sat, 13 Dec 2008 15:09:40 +0100
Subject: [whatwg] When closing the browser
In-Reply-To: <Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>	<49427C65.6020509@corry.biz>
	<494296FA.7040801@email.it>
	<Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
Message-ID: <4943C224.3000204@gmail.com>

Ian Hickson schrieb:
> On Fri, 12 Dec 2008, Bil Corry wrote:
>   
>> Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if 
>> there was a way to distinguish between the user taking an action which 
>> leaves the site vs. taking an action that returns to the site.
>>
>> For privacy, it shouldn't reveal which specific action triggered the 
>> event, but knowing if the user is leaving the site means webapps can 
>> finally auto-logout the user, which in turn greatly improves security.
>>     
>
> If the goal is auto-logout, then what you describe wouldn't help, as it 
> would have false-positives (leaving the site when another tab still has 
> the site open) 
You can solve this easily, just use the same algorithm that 
SessionStorange uses to determine if the session is closed. In other 
words, only set this value to true if the user closes the tab/navigates 
to another domain *and* if there are no other open tabs for this domain.
> and false-negatives (a crash wouldn't log out the user).
>   
I think a responsible server implementation would use this *in addition* 
to session timeouts, not instead of them.
> Why do session cookies not address this already?
>   
I think there are still scenarios where it would be valuable for the 
server to know *exactly when* the user logged out. One example would be 
those "XY is online" badges you see in many internet forums today. 
Today, those have a margin of error of about 15 to 20 minutes at best.
With session cookies, if the client doesn't send more requests, the 
server after all has to guess if you logged out or if you're just taking 
your time. So you have to wait for a pretty long timeout period in any 
case. Even if a 15 minute timeout is not so much of a problem from a 
user perspective, it's still a lot of memory a (potentially buisy) has 
to keep around longer than really necessary.
You can't simply "force-logout" the user inside onunload either, because 
of the "false positives" above.

I believe, such an onunload parameter could fill this gap. With it, you 
could simply check, if you're the last open window and if you are issue 
a "logout" XHR.


From alex.baldacchino at email.it  Sat Dec 13 09:31:36 2008
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sat, 13 Dec 2008 18:31:36 +0100
Subject: [whatwg] When closing the browser
In-Reply-To: <Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
References: <000c01c87a47$66ecc9c0$6501a8c0@disxgdg31szkx7>
	<Pine.LNX.4.62.0812120845360.30225@hixie.dreamhostps.com>
	<49427C65.6020509@corry.biz> <494296FA.7040801@email.it>
	<Pine.LNX.4.62.0812122031040.30197@hixie.dreamhostps.com>
Message-ID: <4943F178.4020808@email.it>

Ian Hickson ha scritto:
> On Fri, 12 Dec 2008, Bil Corry wrote:
>   
>> Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if 
>> there was a way to distinguish between the user taking an action which 
>> leaves the site vs. taking an action that returns to the site.
>>
>> For privacy, it shouldn't reveal which specific action triggered the 
>> event, but knowing if the user is leaving the site means webapps can 
>> finally auto-logout the user, which in turn greatly improves security.
>>     
>
> If the goal is auto-logout, then what you describe wouldn't help, as it 
> would have false-positives (leaving the site when another tab still has 
> the site open)

As well as any tab-restricted session data, if not aware of other 
tabs/windows (as Philipp Serafin suggested, whatever is done to make a 
tab aware of other tabs with the same domain, can be done for an 
attribute telling wheter the user is leaving a certain domain).

>  and false-negatives (a crash wouldn't log out the user).
>
>   

Which may affect persistent cookies, but can be a concern for any 
solution, when it comes with cookie theft (that is, some communication 
with the server may be needed, beside the use of cookies or anything 
else, and such may fail because of a crash).

> Why do session cookies not address this already?
>
>   

Both session and persistent cookies may address this (with the concern 
of false negatives, specially for persistent cookies, but not only). 
Both need to be enabled in a browser to work (usually they are, session 
cookies most of times). Both may fail alone (that is, if an immediate 
invalidation of login data is required - this is a side, related issue).

If the goal is auto-logout *as soon as the user leaves the site*, 
whenever the downside of a possible new login request during the same 
session is not a usability concern, a (session) cookie lifetime must be 
shortened, for instance by adding an expiration timing (e.g., for a 
session cookie, something like 'sessionID=asdf1234fdas.exp=<current gmt 
date + 3 seconds>;'), this way if the user reloads the page or navigates 
a tab history the server will likely recieve such modified cookie before 
its 'expiration' and abort  an atuo-logout process (a cached webapp may 
check cookies as well), otherwise, whenever recieving an 'expired' 
cookie, the logout would trigger immediately; if the client-side script 
knew the user is leaving the site, any cookie might be removed.

But such wouldn't solve the server-side logout concern: to invalidate 
any login data, in the above scena