From mjs at apple.com  Wed Jul  1 00:12:08 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Wed, 01 Jul 2009 00:12:08 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<5068B3E9-E069-425C-89F7-AD09484F23D2@googlemail.com>
	<fbad4e140906071059h447bd282h2699cc5397c74067@mail.gmail.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
Message-ID: <6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>


I'm not sure I have much useful information to add to this discussion,  
but I wanted to address a few points:

On Jun 30, 2009, at 10:54 PM, Gregory Maxwell wrote:

>
> Then please don't characterize it as "it won't work" when the
> situation is "it would work, but would probably have unacceptable
> battery life on the hardware we are shipping".

I don't believe I ever said "it won't work" or made any claim along  
those lines. All I said was that some products use dedicated hardware  
for H.264, and no such hardware is available for Theora. There was an  
implication that this claim was a smokescreen because really it was  
all just programmable hardware; that is not the case.

> The battery life question is a serious and important one, but its
> categorically different one than "can it work at all".  (In particular
> because many people wouldn't consider the battery life implications of
> a rarely used fallback format to be especially relevant to their own
> development).

If Theora is only going to be a rarely used fallback format, then it  
doesn't seem like a great candidate to mandate in external specs.  
Indeed, others have argued that inclusion in the HTML5 spec would  
drive far greater popularity. If it's going to be widely used, it  
needs power-efficient implementations on mobile.

Battery life is a very important consideration to mobile devices. To  
give an example of a concrete data point, the iPhone 3G S can deliver  
10 hours of video playback on a full charge. It's not very persuasive  
to say that availability of hardware implementations is unimportant  
because, even though battery life will be considerably worse, video  
will still more or less function.


On Jun 30, 2009, at 11:03 PM, Silvia Pfeiffer wrote:

> It's a chicken and egg problem then. Once there is volume in Theora
> (speak: uptake), the vendors will adapt their hardware to support it.
> But we will not adopt Theora because we require hardware support. I
> think requiring hardware support is therefore an unfair requirement -
> when H.264 was being standardised, no hardware support (i.e. ASICs)
> were available either.

I believe the wide availability of H.264 hardware is in part because H. 
264 was developed through an open standards process that included the  
relevant stakeholders. In addition, H.264 was included in standards  
such as Blu-Ray, HD-DVD and 3GPP. This created built-in demand for  
hardware implementations. I believe hardware implementations were  
available before H.264 saw significant deployment for Web content.

It's not clear if a similar virtuous cycle would repeat for other  
codecs. Might happen, but it took a lot of industry coordination  
around H.264 to build the ecosystem around it that exists today. So I  
don't think it's reasonable to assume that hardware implementations  
will just appear.


Regards,
Maciej


From ngompa13 at gmail.com  Wed Jul  1 00:37:30 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Wed, 1 Jul 2009 02:37:30 -0500
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
Message-ID: <8278b1b0907010037y29119d0ci48b8d6f5cfb80c3@mail.gmail.com>

On Wed, Jul 1, 2009 at 2:12 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> I'm not sure I have much useful information to add to this discussion, but
> I wanted to address a few points:
>
> On Jun 30, 2009, at 10:54 PM, Gregory Maxwell wrote:
>
>
>> Then please don't characterize it as "it won't work" when the
>> situation is "it would work, but would probably have unacceptable
>> battery life on the hardware we are shipping".
>>
>
> I don't believe I ever said "it won't work" or made any claim along those
> lines. All I said was that some products use dedicated hardware for H.264,
> and no such hardware is available for Theora. There was an implication that
> this claim was a smokescreen because really it was all just programmable
> hardware; that is not the case.
>


There wasn't much for h.264 when it was being standardized. There was
committment, yes, but little actual hardware until after H.264 was
standardized and the big names of the time requested the chips: Creative,
Samsung, etc.



>
>
>  The battery life question is a serious and important one, but its
>> categorically different one than "can it work at all".  (In particular
>> because many people wouldn't consider the battery life implications of
>> a rarely used fallback format to be especially relevant to their own
>> development).
>>
>
> If Theora is only going to be a rarely used fallback format, then it
> doesn't seem like a great candidate to mandate in external specs. Indeed,
> others have argued that inclusion in the HTML5 spec would drive far greater
> popularity. If it's going to be widely used, it needs power-efficient
> implementations on mobile.
>
> Battery life is a very important consideration to mobile devices. To give
> an example of a concrete data point, the iPhone 3G S can deliver 10 hours of
> video playback on a full charge. It's not very persuasive to say that
> availability of hardware implementations is unimportant because, even though
> battery life will be considerably worse, video will still more or less
> function.
>


I believe he means in the context of the current situation that Theora is
rarely used fallback format. I expect that it would change, given time and a
clear push for Theora. That's why I believe the HTML 5 <video> and <audio>
codec situation is so important. If Theora and Vorbis are standardized here,
and all the major browsers (except Internet Explorer, of course) were to
support it, then users who want to have those videos on the personal
portable media players would ask the companies to add support for them.
Things would probably snowball from there.


>
>
> On Jun 30, 2009, at 11:03 PM, Silvia Pfeiffer wrote:
>
>  It's a chicken and egg problem then. Once there is volume in Theora
>> (speak: uptake), the vendors will adapt their hardware to support it.
>> But we will not adopt Theora because we require hardware support. I
>> think requiring hardware support is therefore an unfair requirement -
>> when H.264 was being standardised, no hardware support (i.e. ASICs)
>> were available either.
>>
>
> I believe the wide availability of H.264 hardware is in part because H.264
> was developed through an open standards process that included the relevant
> stakeholders. In addition, H.264 was included in standards such as Blu-Ray,
> HD-DVD and 3GPP. This created built-in demand for hardware implementations.
> I believe hardware implementations were available before H.264 saw
> significant deployment for Web content.
>
> It's not clear if a similar virtuous cycle would repeat for other codecs.
> Might happen, but it took a lot of industry coordination around H.264 to
> build the ecosystem around it that exists today. So I don't think it's
> reasonable to assume that hardware implementations will just appear.
>
>
> Regards,
> Maciej
>
>
I would like to point out that we do have one of the most influential
hardware manufacturers participating in this: Apple. If they asked for
Theora hardware decoders, they would get them. Which annoys me so much..
They would have quite a lot to gain from supporting Theora, and they refuse
to. If they added Theora and Vorbis to the default set of QuickTime codecs,
then everybody would be happy, since Safari uses QuickTime.

As for the hardware thing, Apple's iPod is the most popular portable media
player. So, any hardware decoder chip manufacturer would be salivating to
get a contract with Apple, and if Apple requested a chip for Theora
decoding, then companies would get it done pronto in hopes of winning a
contract bid with Apple. Then other companies needing hardware decoders for
Theora could get them too.

As it is, Apple is stonewalling efforts to convince them to support Theora
and Vorbis. Additionally, the Theora spec was only finalized last November,
you can't expect all the companies around the world to announce hardware
Theora decoders the next day or something? They need a business case and an
opportunity. The opportunity is here. The business case would be the simple
fact people want to be able to watch videos like Dailymotion, Archive.org,
or Wikimedia ones on their portable media devices. From this desire, profit
could be made in making these chips and selling them to portable media
player makers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090701/e9d5ded2/attachment.htm>

From maikmerten at googlemail.com  Wed Jul  1 00:46:29 2009
From: maikmerten at googlemail.com (Maik Merten)
Date: Wed, 01 Jul 2009 09:46:29 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>	<5068B3E9-E069-425C-89F7-AD09484F23D2@googlemail.com>	<fbad4e140906071059h447bd282h2699cc5397c74067@mail.gmail.com>	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
Message-ID: <4A4B1455.60500@googlemail.com>

Maciej Stachowiak wrote:
> So I don't
> think it's reasonable to assume that hardware implementations will just
> appear.

The dire need of ASIC "hardwired-style" implementations for Theora
hasn't been demonstrated either. H.264 has much higher computational
complexity, it may be interesting to consider if using less-rigid DSPs
(or even the already available DSP extensions of widespread mobile
processors) gives "good enough" results for Theora. Given there's less
to compute one may very well live with a lower energy efficiency per
operation.


Maik

From dgerard at gmail.com  Wed Jul  1 01:27:46 2009
From: dgerard at gmail.com (David Gerard)
Date: Wed, 1 Jul 2009 09:27:46 +0100
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <11e306600906301240t5ce9fb9br1f6387ab3f65a36d@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<11e306600906301240t5ce9fb9br1f6387ab3f65a36d@mail.gmail.com>
Message-ID: <fbad4e140907010127g6becd5d8x789683782a8389b@mail.gmail.com>

2009/6/30 Robert O'Callahan <robert at ocallahan.org>:

> If we are going to allow individual vendors to exert veto power, at least
> lets make them accountable. Let's require them to make public statements
> with justifications instead of passing secret notes to Hixie.


+1

Particularly when (e.g. Google's YouTube claim) the reason for the
claim is then firmly proven not to be factually based.


- d.

From l.mastrodomenico at gmail.com  Wed Jul  1 02:24:09 2009
From: l.mastrodomenico at gmail.com (Lino Mastrodomenico)
Date: Wed, 1 Jul 2009 11:24:09 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
Message-ID: <cc93256f0907010224naa2a81an50c25085f1cab141@mail.gmail.com>

[Maciej, sorry for sending this to you twice]

2009/7/1 Maciej Stachowiak <mjs at apple.com>:
> It's not clear if a similar virtuous cycle would repeat for other codecs.
> Might happen, but it took a lot of industry coordination around H.264 to
> build the ecosystem around it that exists today. So I don't think it's
> reasonable to assume that hardware implementations will just appear.

Even without any apparent "industry coordination" around Vorbis, many
portable music players (not the ones produced by Apple, admittedly)
can play Ogg audio files. Note that many of them do *not* say this on
the tin: e.g. my cheap noname "MP4 player" is advertised as being able
to play only MP3 and WMA audio and AMV video files, but it also
supports Ogg/Vorbis just fine.

When Vorbis files reached a small critical mass a few years ago many
hardware manufacturers without much fanfare started supporting it.
Having a free implementation with a very liberal licence may have
helped.

This player is also a good example of how some DSPs can be used for
different tasks: its DSP is exactly the same that has been used only
for MP3 decoding in earlier players, but in these new models it
decodes the video part of AMV (a modified MJPEG). Obviously I'm not
suggesting that this particular model can also decode Theora (the main
CPU is an 8-bit Z80 at 60 MHz max).

Anyway I think that the spec can be made more informative for web
authors by pointing out (in a non-normative section) the fact that
there's one and only one format that can be played by all browser that
support the video element: Ogg/Theora+Vorbis. Safari can play Theora
if the Xiph Quicktime component is installed, while Firefox cannot
play H.264.

-- 
Lino Mastrodomenico

From annevk at opera.com  Wed Jul  1 02:41:27 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 01 Jul 2009 11:41:27 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
Message-ID: <op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>

On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting <pkasting at google.com>  
wrote:
> There is no other reason to put a codec in the spec -- the primary  
> reason to spec a behavior (to document vendor consensus) does not  
> apply.  "Some
> vendors agreed, and some objected violently" is not "consensus".

The "vendor consensus" line of argument seems like a very dangerous  
slippery slope. It would mean that whenever a vendor refuses to implement  
something it has to be taken out of the specification. I.e. giving a  
single vendor veto power over the documentation of the Web Platform. Not  
good at all in my opinion.


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

From ngompa13 at gmail.com  Wed Jul  1 03:58:32 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Wed, 1 Jul 2009 05:58:32 -0500
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
Message-ID: <8278b1b0907010358g29c0b5b7g620f231251dc28e5@mail.gmail.com>

On Wed, Jul 1, 2009 at 4:41 AM, Anne van Kesteren <annevk at opera.com> wrote:

> On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting <pkasting at google.com>
> wrote:
>
>> There is no other reason to put a codec in the spec -- the primary reason
>> to spec a behavior (to document vendor consensus) does not apply.  "Some
>> vendors agreed, and some objected violently" is not "consensus".
>>
>
> The "vendor consensus" line of argument seems like a very dangerous
> slippery slope. It would mean that whenever a vendor refuses to implement
> something it has to be taken out of the specification. I.e. giving a single
> vendor veto power over the documentation of the Web Platform. Not good at
> all in my opinion.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

We had a vendor majority, right? Of the four major vendors of browsers
participating (Mozilla, Google, Opera, Apple), three have committed to
including the codecs in one form or another for usage with the <video> and
<audio> tags (Mozilla, Opera, Google). I agree it would have been better
would a full consensus, but the fact is that all of these companies look
towards their goals.

Mozilla wants to move towards its vision of the Open Web (which I personally
agree with), Opera has said some time back they plan to support it, Google
is fence-sitting by including ffmpeg due to their ideal of being universal
(and doing a good job of it too), and Apple's vision of an Apple-centric
world means they use the MPEG4 stuff, because it fits more with their
current offerings of iPod, iPhone, Macs, and the Apple TV without exerting
more effort to comply.

We would never get everyone to agree. However, Apple didn't shut the Theora
stuff out entirely. They left it open through QuickTime, which is fine. If
we went through and put the Theora and Vorbis recommendation through, and
the browsers implement it, then pressure would eventually make Apple somehow
concede and do something about the situation. At the very least, add the
XiphQT codec pack to the listing of codecs when QuickTime errors out and
opens Safari to a list of codecs.

If we push through it with the codecs, I don't think there will be too much
of a problem at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090701/4a683842/attachment.htm>

From timeless at gmail.com  Wed Jul  1 04:01:02 2009
From: timeless at gmail.com (timeless)
Date: Wed, 1 Jul 2009 14:01:02 +0300
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<fbad4e140906071059h447bd282h2699cc5397c74067@mail.gmail.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
Message-ID: <26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>

On Wed, Jul 1, 2009 at 8:54 AM, Gregory Maxwell<gmaxwell at gmail.com> wrote:
> There are mass market products that do this.  Specifically palm-pre is
> OMAP3, the N810 is OMAP2. These have conventional DSPs with publicly
> available toolchains.

Hrm, I worked on the n810 (nowhere near DSP, thankfully, although I
did get to hear people crying).

The technical existence of a generic DSP does not a useful implementation make.

So, can you please give me the url for a useful DSP codec I can
install on my n810 (it runs Maemo 4.1 "Diablo", and no, asking me to
install your own custom platform just to play video isn't OK) ?

Hypothetically, just getting the stuff the vendor offers working in a
shape which is shippable is depressingly hard.

I really hate the double and triple standards espoused here.

For lack of a better reference, however i trust that you're capable of
finding hundreds (as a google search [battery life claims] did for
me),

http://www.techradar.com/news/computing-components/lawsuits-planned-over-laptop-battery-life-claims-612614

and adding the word 'cell' leads to:
http://reviews.cnet.com/cell-phone-battery-life-charts

I have nothing to do with the 5800 and don't have any idea what it is,
but it was on the first page of results, so:
http://www.wirelessinfo.com/content/Nokia-5800-Cell-Phone-Review/Battery-Life.htm

Summarily, it said that getting 75% of the claimed battery life was
respectable (not stellar). I think it's safe to say that consumers
really do care about battery life (and at least with laptops are
starting to complain violently).

I have no idea about purchasing costs (again, we work on software),
but I think people will accept that the cost for an FPGA is orders of
magnitudes higher than and not commercially viable in contrast to
ASICs.

Let's consider a different position. If you heard that a hardware
vendor had a product which could decode a video format called
QuperVide and they provided an opensource implementation, but they had
a patent on another (better) technique for decoding QuperVide which
they used in their ASIC. Would you support them in their bid to
mandate QuperVide as a Required codec for a Standard (e.g.
HTML5:Video)?

I'd hope that most people would say that it's unfair to mandate such a
standard which gave the QuperVide vendor a sales advantage in its
market (hardware ASICs).

Would you say: "oh, that's ok, we can standardize on this, and then 5
years from now we'll have an open source hardware implementation
that's as good"?

You could do that, but for the intervening years anyone who sells
hardware and wants to support QuperVide will have three choices: 1.
Pay QuperVide's fees for its ASICs and get tolerable battery life. 2.
Pay for an extra DSP or a faster CPU+BUS and pay a penalty in terms of
battery life. 3. Pay engineers to try to develop a competing hardware
ASIC which doesn't run afoul of QuperVide's vendor's patent for its
hardware ASIC.

I also don't like how people enjoy a good run of corporation hunting.

First you go after Microsoft. Then you go after Google. Then you after Apple.

And yes, you've already hunted Nokia, a couple of times, but I can't
remember when in the sequence it was. I guess that it's sort of open
season for corporation hunting and maybe Nokia is currently slightly
out of season. Actually, it sounds like Congress has opened up a
session there, so maybe you're just politely waiting in line.

Mozilla has sketches for adding pluggable support for its video module
too, but seems to be reticent about working on it as doing that would
distract from their open web position.

Sadly, Apple gets no points for being Pluggable on Desktop (QT has an
open API). If I were to complain about Mozilla not being open, they'd
claim "oh, we're open source, anyone can contribute". That isn't true
btw, if I were to write a pluggable module for video, their benevolent
dictator has every right to veto it. And sure, I can maintain my fork,
but just like Linus with Linux, they have every right to change their
APIs regularly to make my life hell.

Note: Microsoft, like Apple has Pluggable APIs, and again, like Apple,
people don't care, and just say "ooh, they're a bad company, they
won't play with us."

Microsoft, like Opera, like Apple, like every other company in the
world is busy working on things. Often quitely (and yes, Mozilla does
things quietly too). Opera has a policy (like Apple, like Microsoft,
like Nokia, ...) of not announcing things until they announce them.
Microsoft presumably has a roadmap and freeze features out at a
certain point in time, most companies do. Sometimes groups have to
rewrite or reorganize large portions of their code, and can't fix
certain things until then. Gecko, View Manager, Table Rewrites, HTML5
parser, lots of these things happen with Mozilla.

Heck, the ACID tests traditionally are such that the first release of
mozilla after the release of an ACID test can't possibly pass the ACID
test, because of the schedule. And while people do beat up Mozilla for
this (and it's unreasonable), the people in this group are willing to
overlook it, but don't seem to think it's ok to overlook the same
behavior in Microsoft (or ...). So Mozilla has a public roadmap, and
Opera commits to certain specs, but Opera doesn't commit to other
specs, and Mozilla e.g. isn't interested in committing to a certain
SQL spec which would force everyone to bug for bug implement
sqlite3.z.y.a.q.t where those numbers would be fairly arbitrary but
fixed forever.

The decisions of each of these groups (except the people who are busy
boiling tar and collecting feathers) are actually quite reasonable if
you look at them alone. But instead, whoever has the axe to grind or
the tar boiled and feathers ready overlooks the rest of the landscape
and just goes off and hunts down their intended victim.

ps: if you aren't familiar with a word or metaphor, please feel free
to look them up or ask me privately, I'm vaguely sorry for piling them
on, but everyone else vents, so this was my turn.

From timeless at gmail.com  Wed Jul  1 04:02:26 2009
From: timeless at gmail.com (timeless)
Date: Wed, 1 Jul 2009 14:02:26 +0300
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <8278b1b0907010358g29c0b5b7g620f231251dc28e5@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
	<8278b1b0907010358g29c0b5b7g620f231251dc28e5@mail.gmail.com>
Message-ID: <26b395e60907010402g5f701b97u21b52f14599b1a6f@mail.gmail.com>

On Wed, Jul 1, 2009 at 1:58 PM, King InuYasha<ngompa13 at gmail.com> wrote:
> We had a vendor majority, right?

Who is we, and which vendor do you represent?

Please don't use royal we.

From sam.kuper at uclmail.net  Wed Jul  1 04:23:25 2009
From: sam.kuper at uclmail.net (Sam Kuper)
Date: Wed, 1 Jul 2009 12:23:25 +0100
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A4B1455.60500@googlemail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
	<4A4B1455.60500@googlemail.com>
Message-ID: <4126b3450907010423u354cad61k96940d7941468c7e@mail.gmail.com>

2009/7/1 Maik Merten <maikmerten at googlemail.com>
> Maciej Stachowiak wrote:
> > So I don't
> > think it's reasonable to assume that hardware implementations will just
> > appear.
>
> The dire need of ASIC "hardwired-style" implementations for Theora
> hasn't been demonstrated either. H.264 has much higher computational
> complexity, it may be interesting to consider if using less-rigid DSPs
> (or even the already available DSP extensions of widespread mobile
> processors) gives "good enough" results for Theora. Given there's less
> to compute one may very well live with a lower energy efficiency per
> operation.

For information only (I haven't investigated these in any depth), note
the references to Theora in the following pages:

http://wiki.openmoko.org/wiki/Snapshot_review#Media_Player
http://wiki.openmoko.org/wiki/Wish_List_-_Hardware:FPGA#AT91CAP9S500A_.28ARM9_.2B_FPGA-port.29

From jeffm at iglou.com  Wed Jul  1 04:35:55 2009
From: jeffm at iglou.com (Jeff McAdams)
Date: Wed, 01 Jul 2009 07:35:55 -0400
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>	<5068B3E9-E069-425C-89F7-AD09484F23D2@googlemail.com>	<fbad4e140906071059h447bd282h2699cc5397c74067@mail.gmail.com>	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<6B183112-D88F-48D8-8DA4-1517E718F3DE@apple.com>
Message-ID: <4A4B4A1B.7050101@iglou.com>

Only one point to touch on here, and perhaps its a bit off-topic, and if 
it is, I apologize.

Maciej Stachowiak wrote:
> I believe the wide availability of H.264 hardware is in part because 
> H.264 was developed through an open standards process that included the 
> relevant stakeholders.


Saying that ITU-T includes "relevant stakeholders", implying that it 
includes *all* "relevant stakeholders" is a joke.  End-users are 
relevant stakeholders in standards development, and ITU-T excludes 
participation from end-users.

-- 
Jeff McAdams
jeffm at iglou.com

From jeffm at iglou.com  Wed Jul  1 04:43:00 2009
From: jeffm at iglou.com (Jeff McAdams)
Date: Wed, 01 Jul 2009 07:43:00 -0400
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>	<fbad4e140906071059h447bd282h2699cc5397c74067@mail.gmail.com>	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
Message-ID: <4A4B4BC4.8060201@iglou.com>

timeless wrote:
> I also don't like how people enjoy a good run of corporation hunting.

> First you go after Microsoft. Then you go after Google. Then you after Apple.

Many (most?) corporations choose to operate under a heavy veil of 
secrecy (*particularly* Apple).  That choice is also a choice to open 
themselves up these criticisms.  These corporations have to take the 
good with the bad.  If they chose to operate with greater transparency, 
then they would almost certainly come into less criticism.

I have exactly zero sympathy for Apple, MS, and Google, for the 
criticisms they have received.  They choose to operate in secrecy, then 
they choose to be the target of these criticisms.

Suck it up.

-- 
Jeff McAdams
jeffm at iglou.com

From l.mastrodomenico at gmail.com  Wed Jul  1 04:45:15 2009
From: l.mastrodomenico at gmail.com (Lino Mastrodomenico)
Date: Wed, 1 Jul 2009 13:45:15 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
Message-ID: <cc93256f0907010445q4173a275r1da986b43d4255d3@mail.gmail.com>

2009/7/1 timeless <timeless at gmail.com>:
> I have no idea about purchasing costs (again, we work on software),
> but I think people will accept that the cost for an FPGA is orders of
> magnitudes higher than and not commercially viable in contrast to
> ASICs.

I think we can all agree that a FPGA is being used only for
development and debugging of a Theora hardware decoder
(<http://www.students.ic.unicamp.br/~ra031198/theora_hardware/>),
while the final design will be burned to an ASIC if/when there's
commercial demand for it.

> Sadly, Apple gets no points for being Pluggable on Desktop (QT has an
> open API). If I were to complain about Mozilla not being open, they'd
> claim "oh, we're open source, anyone can contribute". That isn't true
> btw, if I were to write a pluggable module for video, their benevolent
> dictator has every right to veto it.

I fear that wide support for pluggable codecs for the video element
may end up putting end users in a "codec hell". If there's only one or
at most two supported video formats/codecs, then it's obviously
responsibility of the websites to correctly encode their videos.

But if Firefox starts supporting any codec that happens to be
installed on the system, many small and medium websites will probably
start using videos in a lot of different formats (that "works" on the
computer of the web developer) and the burden of finding and
installing the correct codecs for each site will shift on the end
user.

Not good for interoperability, non-x86 platforms, and a good
opportunity for spreading malware using trojan codecs.

So please browser vendors, don't do this. The only exception is
Safari, since it wouldn't otherwise support Theora.

-- 
Lino Mastrodomenico

From giecrilj at stegny.2a.pl  Wed Jul  1 06:02:56 2009
From: giecrilj at stegny.2a.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=)
Date: Wed, 1 Jul 2009 15:02:56 +0200
Subject: [whatwg] Localised numbers
In-Reply-To: <Pine.LNX.4.62.0907010421010.1060@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
	<63df84f0905141700v792efe48madbd203a1f4ae63b@mail.gmail.com>
	<63df84f0905141710u11d5bfedl91cd9fd60085d9c2@mail.gmail.com>
	<Pine.LNX.4.62.0906090325080.1648@hixie.dreamhostps.com>
	<63df84f0906090215n9e3d816m695b6026fb4a42b0@mail.gmail.com>
	<0D68C54E0A4044AA87844B8CD7EB1AB9@POCZTOWIEC>
	<Pine.LNX.4.62.0907010421010.1060@hixie.dreamhostps.com>
Message-ID: <760A828A53E64D4E8650D917747F13C6@POCZTOWIEC>

The rules for parsing floating point number values [2.4.4.5] apply to the
input element in number state as well.  This is not good.  People who fill
forms tend to input numbers with the keypad --- that is what the keypad is
for --- and the keypad keyboard layout follows the local conventions and not
the HTML specification (of course).  For example, it is not possible to get
a full stop using the keypad, as required by step 12, as the keypad has a
comma instead.
I suggest that a comma should be treated as a decimal point by step?12.
I also suggest that true MINUS SIGN should be treated the same as HYPHEN
MINUS by step?8.  This applies to the rules for parsing integers [2.4.4.2]
also, and the use case is pasting existing content.  Otherwise, existing
content containing negative numbers would have to be worse than it could be
in order that it could be pasted into HTML forms.
Of course, these extensions should apply to input elements [4.10.4.1.13]
only.  Since they are pure extensions, they should not introduce any
incompatibilities with what is already deployed.
Cheers,
Chris



From giecrilj at stegny.2a.pl  Wed Jul  1 06:12:40 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 1 Jul 2009 15:12:40 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <cc93256f0907010445q4173a275r1da986b43d4255d3@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com><Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com><11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com><Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com><2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com><F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com><e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com><1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com><e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com><26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
	<cc93256f0907010445q4173a275r1da986b43d4255d3@mail.gmail.com>
Message-ID: <9D399EDBF1B5452F8BBE6619BD6A416F@POCZTOWIEC>

Regarding the fear of Trojan codecs: it would help if third-party plug-ins
for codecs could be sandboxed so that they cannot have access to anything
they do not have to access in order to do their job, and only via an API
provided by the host.
IMHO,
Chris



From timeless at gmail.com  Wed Jul  1 06:55:22 2009
From: timeless at gmail.com (timeless)
Date: Wed, 1 Jul 2009 16:55:22 +0300
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <9D399EDBF1B5452F8BBE6619BD6A416F@POCZTOWIEC>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
	<cc93256f0907010445q4173a275r1da986b43d4255d3@mail.gmail.com>
	<9D399EDBF1B5452F8BBE6619BD6A416F@POCZTOWIEC>
Message-ID: <26b395e60907010655hebc0173n3921564af7dda759@mail.gmail.com>

On Wed, Jul 1, 2009 at 4:12 PM, Kristof
Zelechovski<giecrilj at stegny.2a.pl> wrote:
> Regarding the fear of Trojan codecs: it would help if third-party plug-ins
> for codecs could be sandboxed so that they cannot have access to anything
> they do not have to access in order to do their job, and only via an API
> provided by the host.

historically people who want to write codec support want to do it in
DSP land on devices, and in DSP land on devices you can kill devices
very dead (among other interesting thing).

Sandboxing that way is basically impossible.

Now if you rule out DSP, you still have all the other problems
(general proliferation of codecs, finding them, keeping them
sandboxed, bandwidth to network/video).

I'm not saying I don't look forward to this, they're just notes.

From brucel at opera.com  Wed Jul  1 07:08:40 2009
From: brucel at opera.com (Bruce Lawson)
Date: Wed, 01 Jul 2009 15:08:40 +0100
Subject: [whatwg] ambiguity in <header> definition
In-Reply-To: <a9699fd20906290654u37e3f1c5u2793a7ec9a673dd0@mail.gmail.com>
References: <op.uwaf04buh8on37@bruce-pc>
	<a9699fd20906290654u37e3f1c5u2793a7ec9a673dd0@mail.gmail.com>
Message-ID: <op.uwd6wqthh8on37@bruce-pc>

On Mon, 29 Jun 2009 14:54:48 +0100, Thomas Broyer <t.broyer at gmail.com>  
wrote:
  perhaps
>> the language should be tightened? ie ""A header element typically  
>> contains
>> the section's heading (an h1?h6 element or an hgroup element), but this  
>> is
>> not mandatory and may contain content such as navigation, a search form  
>> blah
>> blah"
>
> The fact that it is phrased as "typically contains ... but can also
> contain" makes it clear (for me) that it might contain a section's
> heading but this is not enforced (otherwise, it wouldn't say
> "typically")

my beef is with the words "can also contain", which suggest that it can  
contain other stuff in addition to h1..h6, hgroup (which it can) but it's  
ambiguous as to whether it must contain  h1..h6, hgroup as a minimum.  
(We're getting asked this a lot in html5doctor)



-- 
Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From Smylers at stripey.com  Wed Jul  1 07:18:01 2009
From: Smylers at stripey.com (Smylers)
Date: Wed, 1 Jul 2009 15:18:01 +0100
Subject: [whatwg] Localised numbers
In-Reply-To: <760A828A53E64D4E8650D917747F13C6@POCZTOWIEC>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com>
	<63df84f0905141700v792efe48madbd203a1f4ae63b@mail.gmail.com>
	<63df84f0905141710u11d5bfedl91cd9fd60085d9c2@mail.gmail.com>
	<Pine.LNX.4.62.0906090325080.1648@hixie.dreamhostps.com>
	<63df84f0906090215n9e3d816m695b6026fb4a42b0@mail.gmail.com>
	<0D68C54E0A4044AA87844B8CD7EB1AB9@POCZTOWIEC>
	<Pine.LNX.4.62.0907010421010.1060@hixie.dreamhostps.com>
	<760A828A53E64D4E8650D917747F13C6@POCZTOWIEC>
Message-ID: <20090701141801.GA8251@stripey.com>

K?i?tof ?elechovski writes:

> The rules for parsing floating point number values [2.4.4.5] apply to
> the input element in number state as well.

Do those rules actually limit UI?

The say how a user agent must parse a value attribute provided in the
source.  And they constrain what a UA may send back to the server.  But
surely a UA can pick any UI they want for this -- including a text box
where the user types a comma, and a decimal point displays as a comma?

Smylers

From erik at textivism.com  Wed Jul  1 07:55:46 2009
From: erik at textivism.com (Erik Vorhes)
Date: Wed, 1 Jul 2009 09:55:46 -0500
Subject: [whatwg] the cite element
In-Reply-To: <Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
References: <4A299FA9.40507@awhlink.com>
	<Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
Message-ID: <22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>

On Tue, Jun 30, 2009 at 11:19 PM, Ian Hickson<ian at hixie.ch> wrote:
> I don't understand why it would be more useful. Having an element for the
> typographic purpose of marking up titles seems more useful than an element
> for the purpose of indicating what is a citation.

Why is it more useful?

If <cite> is exclusively for titles, it shouldn't be called <cite>. In
addition to the semantic difference between a title and a citation,
limiting <cite> to titles potentially raises confusion between this
element and the cite attribute (for <blockquote> and <q>), as the
latter is limited to URLs. Yes, elements and attributes are different
things. But in one context the concept "cite" is limited only to
titles (and forbids URLs); in another context "cite" is limited only
to URLs (and forbids titles).

While it makes some sense, I suppose, to limit the cite attribute to
URLs, it makes absolutely no sense to limit the <cite> element only to
titles. If it's so pressing for there to be an element allowed in the
<body> to mark up titles, why not create a new element for that
purpose or allow for a <cite>-specific attribute to note that
designation?

I understand HTML5's attempts to provide semantic value to such
elements as <i>, <b>, and <small>. To at the same time remove semantic
value at the same time is completely asinine.


> Note that HTML5 now has a more detailed way of marking up citations, using
> the Bibtex vocabulary. I think this removes the need for using the <cite>
> element in the manner you describe.

Since this is supposed to be the case, why shouldn't HTML5 just ditch
<cite> altogether? (Aside from "backward compatibility," which is
beside the point of the question.)


Erik Vorhes

From michaeln at google.com  Wed Jul  1 08:22:40 2009
From: michaeln at google.com (Michael Nordman)
Date: Wed, 1 Jul 2009 08:22:40 -0700
Subject: [whatwg] AppCache and javascript url question?
In-Reply-To: <Pine.LNX.4.62.0907010428011.1060@hixie.dreamhostps.com>
References: <fa2eab050906041745p1349fe89x4f66bdf16deb04ff@mail.gmail.com>
	<Pine.LNX.4.62.0907010428011.1060@hixie.dreamhostps.com>
Message-ID: <fa2eab050907010822r613c536dm88bcdc39ccb38c4a@mail.gmail.com>

On Tue, Jun 30, 2009 at 9:29 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 4 Jun 2009, Michael Nordman wrote:
> >
> > What appcache (if any) should the resulting iframes be associated with? I
> > think per the spec, the answer is none. Is that the correct answer?
> >
> > <html manifest='myManifestFile'>
> > <body>
> > <script language="JavaScript">
> >   function frameContents1()
> >   {
> >     var doc = frame1.document;
> >     doc.open();
> >     doc.write('<img src=image.png>');
> >     doc.close();
> >     return;
> >   }
> >
> >   function frameContents2()
> >   {
> >     return "hello";
> >   }
> > </script>
> >
> > <iframe name="frame1" src="javascript:parent.frameContents1()">
> > <iframe name="frame2" src="javascript:parent.frameContents2()">
> > </body>
> > </html>
>
> If there's no manifest="", there's no application cache selected, as far
> as I can tell.


Thats what it looks like to me too in the current draft. Wondering if thats
the right behavior though?

Generally when loading a frame, the appcache from which the doc resource was
loaded gets selected (augmented by an explicit manifest attribute that can
make something 'foreign').

In this case, the src is a script embedded in a page that is appcached, so
in a transitory sense the doc resource was loaded from an appcache, but that
cache does not get selected.

Feels like maybe image.png should load from myManifestFile in the sample?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090701/8b6b1a9a/attachment-0001.htm>

From ashannon1000 at gmail.com  Wed Jul  1 08:38:21 2009
From: ashannon1000 at gmail.com (Adam Shannon)
Date: Wed, 1 Jul 2009 10:38:21 -0500
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <9D399EDBF1B5452F8BBE6619BD6A416F@POCZTOWIEC>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com> 
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com> 
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com> 
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com> 
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com> 
	<cc93256f0907010445q4173a275r1da986b43d4255d3@mail.gmail.com> 
	<9D399EDBF1B5452F8BBE6619BD6A416F@POCZTOWIEC>
Message-ID: <3c4f8cda0907010838l32ece570q441dcc0d201d9b79@mail.gmail.com>

That would have to be done by each browser not the spec.  Some vendors would
include their own plugins that were safe so they may not feel the need to
sandbox them (even though they should).

On Wed, Jul 1, 2009 at 8:12 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl>wrote:

> Regarding the fear of Trojan codecs: it would help if third-party plug-ins
> for codecs could be sandboxed so that they cannot have access to anything
> they do not have to access in order to do their job, and only via an API
> provided by the host.
> IMHO,
> Chris
>
>
>


-- 
- Adam Shannon ( http://ashannon.us )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090701/58356294/attachment.htm>

From giecrilj at stegny.2a.pl  Wed Jul  1 09:28:02 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 1 Jul 2009 18:28:02 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <26b395e60907010655hebc0173n3921564af7dda759@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
	<cc93256f0907010445q4173a275r1da986b43d4255d3@mail.gmail.com>
	<9D399EDBF1B5452F8BBE6619BD6A416F@POCZTOWIEC>
	<26b395e60907010655hebc0173n3921564af7dda759@mail.gmail.com>
Message-ID: <4858A79C5AD348B3B31F562CF838EC4B@POCZTOWIEC>

Clearly allowing a third-party codec to reprogram a hardware DSP would be
one of the silliest things to do.  
(If it turns out that I cannot answer to something important from now on,
assume I am banned for using an offensive word.)
Chris



From pkasting at google.com  Wed Jul  1 09:29:17 2009
From: pkasting at google.com (Peter Kasting)
Date: Wed, 1 Jul 2009 09:29:17 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
Message-ID: <d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com>

On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren <annevk at opera.com> wrote:

> On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting <pkasting at google.com>
> wrote:
>
>> There is no other reason to put a codec in the spec -- the primary reason
>> to spec a behavior (to document vendor consensus) does not apply.  "Some
>> vendors agreed, and some objected violently" is not "consensus".
>>
>
> The "vendor consensus" line of argument seems like a very dangerous
> slippery slope. It would mean that whenever a vendor refuses to implement
> something it has to be taken out of the specification. I.e. giving a single
> vendor veto power over the documentation of the Web Platform. Not good at
> all in my opinion.
>

I am merely echoing Hixie; from his original email in this thread:

> > At the end of the day, the browser vendors have a very effective
> > absolute veto on anything in the browser specs,
>
> You mean they have the power to derail a spec?

They have the power to not implement the spec, turning the spec from a
useful description of implementations into a work of fiction.

> That's something I would have considered before the advent of Mozilla
> Firefox.

Mozilla also has the power of veto here. For example, if we required that
the browsers implement H.264, and Mozilla did not, then the spec would be
just as equally fictional as it would be if today we required Theora.


My sole goal was to try and point out that the situation with codecs is not
equivalent to past cases where vendors merely _hadn't implemented_ part of
the spec; in this case vendors have _actively refused_ to implement support
for various codecs (Apple with Theora and Mozilla(/Opera?) with H.264).

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090701/81bcf623/attachment.htm>

From ifette at google.com  Wed Jul  1 09:31:50 2009
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Wed, 1 Jul 2009 09:31:50 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A4B4BC4.8060201@iglou.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
	<4A4B4BC4.8060201@iglou.com>
Message-ID: <bbeaa26f0907010931r749b28dft3bcc009dab95e430@mail.gmail.com>

2009/7/1 Jeff McAdams <jeffm at iglou.com>

> timeless wrote:
>
>> I also don't like how people enjoy a good run of corporation hunting.
>>
>
>  First you go after Microsoft. Then you go after Google. Then you after
>> Apple.
>>
>
> Many (most?) corporations choose to operate under a heavy veil of secrecy
> (*particularly* Apple).  That choice is also a choice to open themselves up
> these criticisms.  These corporations have to take the good with the bad.
>  If they chose to operate with greater transparency, then they would almost
> certainly come into less criticism.
>
> I have exactly zero sympathy for Apple, MS, and Google, for the criticisms
> they have received.  They choose to operate in secrecy, then they choose to
> be the target of these criticisms.
>

I'm not asking for sympathy, but I also don't think the characterization of
Google as operating in secrecy is fair. There's a large number of people
from the Google Chrome team participating on WHATWG and trying to contribute
openly to these discussions. We're operating as an open source project, and
trying to be as open as possible. At the same time, Google is a company
whose purpose (as is any company) is to make money. YouTube is a separate
team and not an open source project, I don't think it's reasonable to expect
all of Google to suddenly release all of its information that has legitimate
business reasons for staying company-internal. We've made what statements we
can make, and I don't honestly think it reasonable to expect more.


>
> Suck it up.
>
>
> --
> Jeff McAdams
> jeffm at iglou.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090701/42f5ffaf/attachment.htm>

From giecrilj at stegny.2a.pl  Wed Jul  1 09:36:34 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 1 Jul 2009 18:36:34 +0200
Subject: [whatwg] the cite element
In-Reply-To: <22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>
References: <4A299FA9.40507@awhlink.com><Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
	<22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>
Message-ID: <C35A3C262C444951B57A68A603495F04@POCZTOWIEC>

The CITE tag does not mean "I am a citation".  It is as confusing for
novices as can be but the specification cannot do anything about it because
it is already established.  It means "Citing what?" and it does not mean
"Citing whom?".  A book title is the obvious answer to this question.  As I
understand it, the CITE element can contain an anchor around the title, so
you can have a URI as well.  In particular, it could be an ISBN URN,
although the browsers would have to support the ISBN namespace instead of
saying "Bad URL" or something.
HTH,
Chris


From brucel at opera.com  Wed Jul  1 09:39:17 2009
From: brucel at opera.com (Bruce Lawson)
Date: Wed, 01 Jul 2009 17:39:17 +0100
Subject: [whatwg] the cite element
In-Reply-To: <C35A3C262C444951B57A68A603495F04@POCZTOWIEC>
References: <4A299FA9.40507@awhlink.com>
	<Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
	<22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>
	<C35A3C262C444951B57A68A603495F04@POCZTOWIEC>
Message-ID: <op.uwedvrzsh8on37@bruce-pc>

On Wed, 01 Jul 2009 17:36:34 +0100, Kristof Zelechovski  
<giecrilj at stegny.2a.pl> wrote:

> The CITE tag does not mean "I am a citation".  It is as confusing for
> novices as can be but the specification cannot do anything about it  
> because
> it is already established.  It means "Citing what?" and it does not mean
> "Citing whom?".

There is no reason at all why it can't be defined as "citing whom".

-- 
Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From giecrilj at stegny.2a.pl  Wed Jul  1 09:49:31 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 1 Jul 2009 18:49:31 +0200
Subject: [whatwg] the cite element
In-Reply-To: <op.uwedvrzsh8on37@bruce-pc>
References: <4A299FA9.40507@awhlink.com>
	<Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
	<22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>
	<C35A3C262C444951B57A68A603495F04@POCZTOWIEC>
	<op.uwedvrzsh8on37@bruce-pc>
Message-ID: <A34933AC1F4543819D146078D733587D@POCZTOWIEC>

I can imagine two reasons the CITE element cannot be defined as "citing
whom":
  1. Existing tools may assume it contains a title.
  2. A title is conventionally typeset in italic because it is an expression
that is a proper name although it does not really look like one, whereas the
author does not pose such problems with interpretation.  Compare:
  2a. This page is about birds. --- That page is about "Birds". (different
meaning)
  2b. This is a play by Shakespeare. --- Shakespeare was born in England.
(the same meaning)
IMHO,
Chris


From dgerard at gmail.com  Wed Jul  1 09:55:24 2009
From: dgerard at gmail.com (David Gerard)
Date: Wed, 1 Jul 2009 17:55:24 +0100
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <bbeaa26f0907010931r749b28dft3bcc009dab95e430@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
	<4A4B4BC4.8060201@iglou.com>
	<bbeaa26f0907010931r749b28dft3bcc009dab95e430@mail.gmail.com>
Message-ID: <fbad4e140907010955y7bcaf164uae40c5510de64915@mail.gmail.com>

2009/7/1 Ian Fette (????????) <ifette at google.com>:

> all of Google to suddenly release all of its information that has legitimate
> business reasons for staying company-internal. We've made what statements we
> can make, and I don't honestly think it reasonable to expect more.


I think it is reasonable to expect Google to address their statements
of reasons being demonstrated false, however. They have notably failed
to do so. Is Chris DiBona still reading? "Oh sorry, I was completely
wrong" or "you're wrong and here's why" would go a long way to restore
any trust in Google on this matter.


- d.

From philipj at opera.com  Wed Jul  1 10:01:02 2009
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Wed, 01 Jul 2009 19:01:02 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
	<d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com>
Message-ID: <op.uweev0rhsr6mfa@nog>

On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting <pkasting at google.com>  
wrote:

> On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>
>> On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting <pkasting at google.com>
>> wrote:
>>
>>> There is no other reason to put a codec in the spec -- the primary  
>>> reason
>>> to spec a behavior (to document vendor consensus) does not apply.   
>>> "Some
>>> vendors agreed, and some objected violently" is not "consensus".
>>>
>>
>> The "vendor consensus" line of argument seems like a very dangerous
>> slippery slope. It would mean that whenever a vendor refuses to  
>> implement
>> something it has to be taken out of the specification. I.e. giving a  
>> single
>> vendor veto power over the documentation of the Web Platform. Not good  
>> at
>> all in my opinion.
>>
>
> I am merely echoing Hixie; from his original email in this thread:
>
>> > At the end of the day, the browser vendors have a very effective
>> > absolute veto on anything in the browser specs,
>>
>> You mean they have the power to derail a spec?
>
> They have the power to not implement the spec, turning the spec from a
> useful description of implementations into a work of fiction.
>
>> That's something I would have considered before the advent of Mozilla
>> Firefox.
>
> Mozilla also has the power of veto here. For example, if we required that
> the browsers implement H.264, and Mozilla did not, then the spec would be
> just as equally fictional as it would be if today we required Theora.
>
>
> My sole goal was to try and point out that the situation with codecs is  
> not
> equivalent to past cases where vendors merely _hadn't implemented_ part  
> of
> the spec; in this case vendors have _actively refused_ to implement  
> support
> for various codecs (Apple with Theora and Mozilla(/Opera?) with H.264).
>
> PK

That is correct, we consider H.264 to be incompatible with the open web  
platform due to its patent licensing. For the time being we will support  
Ogg Vorbis/Theora, which is the best option patent-wise and neck-in-neck  
with the competition in the quality-per-bit section (especially with  
recent encoder improvements). We would love to see it as the baseline for  
HTML5, but in the absense of that hope that the web community will push it  
hard enough so that it becomes the de-facto standard.

-- 
Philip J?genstedt
Core Developer
Opera Software

From erik at textivism.com  Wed Jul  1 10:04:05 2009
From: erik at textivism.com (Erik Vorhes)
Date: Wed, 1 Jul 2009 12:04:05 -0500
Subject: [whatwg] the cite element
In-Reply-To: <A34933AC1F4543819D146078D733587D@POCZTOWIEC>
References: <4A299FA9.40507@awhlink.com>
	<Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com> 
	<22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com> 
	<C35A3C262C444951B57A68A603495F04@POCZTOWIEC>
	<op.uwedvrzsh8on37@bruce-pc> 
	<A34933AC1F4543819D146078D733587D@POCZTOWIEC>
Message-ID: <22d65dda0907011004m523fa1ccna700f2523297ca93@mail.gmail.com>

On Wed, Jul 1, 2009 at 11:49 AM, Kristof
Zelechovski<giecrilj at stegny.2a.pl> wrote:
> I can imagine two reasons the CITE element cannot be defined as "citing
> whom":
> ?1. Existing tools may assume it contains a title.

Existing tools (which I would assume follow the HTML 4.01 spec) would
be mistaken in their implementation of the <cite> element, then:
"CITE: Contains a citation or reference to other sources." (See
<http://www.w3.org/TR/html401/struct/text.html#h-9.2.1>.) Moreover, in
its sample usage, the HTML 4.01 spec uses <cite> for more than titles.

While the HTML 4.01 specification is hardly perfect, I don't see the
value in limiting the semantic potential of the <cite> element in
HTML5.

Erik Vorhes

From jeffm at iglou.com  Wed Jul  1 10:07:30 2009
From: jeffm at iglou.com (Jeff McAdams)
Date: Wed, 01 Jul 2009 13:07:30 -0400
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <bbeaa26f0907010931r749b28dft3bcc009dab95e430@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>	<4A4B4BC4.8060201@iglou.com>
	<bbeaa26f0907010931r749b28dft3bcc009dab95e430@mail.gmail.com>
Message-ID: <4A4B97D2.9080403@iglou.com>

Ian Fette (????????) wrote:
> 2009/7/1 Jeff McAdams <jeffm at iglou.com <mailto:jeffm at iglou.com>>
> 
>     timeless wrote:
>         I also don't like how people enjoy a good run of corporation
>         hunting.


>         First you go after Microsoft. Then you go after Google. Then you
>         after Apple.


>     Many (most?) corporations choose to operate under a heavy veil of
>     secrecy (*particularly* Apple).  That choice is also a choice to
>     open themselves up these criticisms.  These corporations have to
>     take the good with the bad.  If they chose to operate with greater
>     transparency, then they would almost certainly come into less criticism.

>     I have exactly zero sympathy for Apple, MS, and Google, for the
>     criticisms they have received.  They choose to operate in secrecy,
>     then they choose to be the target of these criticisms.


> I'm not asking for sympathy, but I also don't think the characterization 
> of Google as operating in secrecy is fair. There's a large number of 
> people from the Google Chrome team participating on WHATWG and trying to 
> contribute openly to these discussions. We're operating as an open 
> source project, and trying to be as open as possible. At the same time, 
> Google is a company whose purpose (as is any company) is to make money. 
> YouTube is a separate team and not an open source project, I don't think 
> it's reasonable to expect all of Google to suddenly release all of its 
> information that has legitimate business reasons for staying 
> company-internal. We've made what statements we can make, and I don't 
> honestly think it reasonable to expect more.

I don't disagree with you on any of that, really.  I said you (Google, 
and others) have made a choice, corporately, on how open and transparent 
to be.  Certainly Google is less secretive than many other corporations 
as a whole, and seemingly the Chrome team is considerably more open than 
most of the rest of Google, even.

Nonetheless, as a whole, Google is a corporation and they have made a 
business decision to remain secretive on at least certain things.  I do 
think that's a reasonable decision to make, and I might very well make 
the same decision in your shoes.  My point was only to say that part and 
parcel of that decision is actions that tend to lead to criticisms of 
the company as a whole that Mozilla gets less of because they are more 
open.  I won't exactly hold Mozilla up as a paragon of openness and 
transparency, but they are better than Google, just as Google is better 
than MS, and I would even argue that MS is better than Apple.

I understand that you have said what you can say, and that's fantastic, 
and truthfully, I don't really expect more.  That doesn't, however, mean 
that I'm going to cease criticisms of the stated positions


As to the comparison between the Chrome and Youtube groups.  I wish that 
the Youtube portion of the company were more engaged here as they 
clearly are a relevant party to the discussion.  Again, I understand 
that as a business decision they may choose not to, but my understanding 
of that doesn't mean I'm not going to criticize them on it.


-- 
Jeff McAdams
jeffm at iglou.com

From excors+whatwg at gmail.com  Wed Jul  1 10:09:12 2009
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 1 Jul 2009 18:09:12 +0100
Subject: [whatwg] the cite element
In-Reply-To: <22d65dda0907011004m523fa1ccna700f2523297ca93@mail.gmail.com>
References: <4A299FA9.40507@awhlink.com>
	<Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
	<22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>
	<C35A3C262C444951B57A68A603495F04@POCZTOWIEC>
	<op.uwedvrzsh8on37@bruce-pc>
	<A34933AC1F4543819D146078D733587D@POCZTOWIEC>
	<22d65dda0907011004m523fa1ccna700f2523297ca93@mail.gmail.com>
Message-ID: <ea09c0d10907011009p5d9fd340m8926a6d26f108f19@mail.gmail.com>

On Wed, Jul 1, 2009 at 6:04 PM, Erik Vorhes<erik at textivism.com> wrote:
> On Wed, Jul 1, 2009 at 11:49 AM, Kristof
> Zelechovski<giecrilj at stegny.2a.pl> wrote:
>> I can imagine two reasons the CITE element cannot be defined as "citing
>> whom":
>> ?1. Existing tools may assume it contains a title.
>
> Existing tools (which I would assume follow the HTML 4.01 spec) would
> be mistaken in their implementation of the <cite> element, then:
> "CITE: Contains a citation or reference to other sources." (See
> <http://www.w3.org/TR/html401/struct/text.html#h-9.2.1>.) Moreover, in
> its sample usage, the HTML 4.01 spec uses <cite> for more than titles.

In practical usage it seems to be used for more than titles:
<http://philip.html5.org/data/cite.txt>. (But I haven't tried working
out what else it is used for, or how commonly it's used for titles.)

-- 
Philip Taylor
excors at gmail.com

From giecrilj at stegny.2a.pl  Wed Jul  1 10:32:12 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Wed, 1 Jul 2009 19:32:12 +0200
Subject: [whatwg] the cite element
In-Reply-To: <ea09c0d10907011009p5d9fd340m8926a6d26f108f19@mail.gmail.com>
References: <4A299FA9.40507@awhlink.com>
	<Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
	<22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>
	<C35A3C262C444951B57A68A603495F04@POCZTOWIEC>
	<op.uwedvrzsh8on37@bruce-pc>
	<A34933AC1F4543819D146078D733587D@POCZTOWIEC>
	<22d65dda0907011004m523fa1ccna700f2523297ca93@mail.gmail.com>
	<ea09c0d10907011009p5d9fd340m8926a6d26f108f19@mail.gmail.com>
Message-ID: <FE4019F502F74D899A8CE3511763B5B4@POCZTOWIEC>

If "more then titles" means other uses of the CITE tag, as evidenced in [1],
they do not form any pattern.  They look more like random errors.

If "more then titles" means "title and something else", I do not see much
harm in such syntax.

Chris

[1] <http://philip.html5.org/data/cite.txt>.



From pkasting at google.com  Wed Jul  1 12:04:01 2009
From: pkasting at google.com (Peter Kasting)
Date: Wed, 1 Jul 2009 12:04:01 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <fbad4e140907010955y7bcaf164uae40c5510de64915@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<F30E58D6-BEFE-4D58-98B9-D8C9CA341EB6@apple.com>
	<e692861c0906302113u138fdb13p6ee5c8780f8c918e@mail.gmail.com>
	<1F25621C-8C07-481B-A2D0-BB093EA4DF1F@apple.com>
	<e692861c0906302254h7b58d9abr286d687485612ed4@mail.gmail.com>
	<26b395e60907010401o5c0b938dxf235821de9e4e839@mail.gmail.com>
	<4A4B4BC4.8060201@iglou.com>
	<bbeaa26f0907010931r749b28dft3bcc009dab95e430@mail.gmail.com>
	<fbad4e140907010955y7bcaf164uae40c5510de64915@mail.gmail.com>
Message-ID: <d62cf1d10907011204s5ba113f2m7e1c20288bf6f7de@mail.gmail.com>

I don't believe Chris was speaking in any official capacity for YT or Google
any more than I am.  I think it is inappropriate to conflate his opinion of
the matter with Google's.  I have not seen _any_ official statement from
Google regarding codec quality.

As an aside, I think taking the available recent public comparisons as
"definitive proof" that Theora is (or is not!) "comparable" to H.264 is
inappropriate (and goes further than the Theora developers have).  Codec
comparison is tricky and broad, and a definitive comparison (which I have
not performed) would require a large variety of types/quality of input,
compressed with many different option choices, and compared on both
subjective and objective criteria.  It also would include coverage of issues
like how much buffer is needed to ensure continuous play, whether the
quality can be dynamically degraded, storage space and CPU usage required on
th encoding side, device support (current and projected), etc.

Or, to simplify, you're oversimplifying in your declarations that one codec
is as good as another.

PK

On Jul 1, 2009 9:55 AM, "David Gerard" <dgerard at gmail.com> wrote:

2009/7/1 Ian Fette (????????) <ifette at google.com>:

> all of Google to suddenly release all of its information that has
legitimate > business reasons f...
I think it is reasonable to expect Google to address their statements
of reasons being demonstrated false, however. They have notably failed
to do so. Is Chris DiBona still reading? "Oh sorry, I was completely
wrong" or "you're wrong and here's why" would go a long way to restore
any trust in Google on this matter.


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

From annevk at opera.com  Wed Jul  1 12:14:13 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 01 Jul 2009 21:14:13 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
	<d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com>
Message-ID: <op.uwek1zgg64w2qv@anne-van-kesterens-macbook.local>

On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting <pkasting at google.com>  
wrote:
> On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> The "vendor consensus" line of argument seems like a very dangerous
>> slippery slope. It would mean that whenever a vendor refuses to  
>> implement something it has to be taken out of the specification. I.e.  
>> giving a single vendor veto power over the documentation of the Web  
>> Platform. Not good at all in my opinion.
>
> I am merely echoing Hixie; from his original email in this thread:
>
>>> At the end of the day, the browser vendors have a very effective
>>> absolute veto on anything in the browser specs,
>>
>> You mean they have the power to derail a spec?
>
> They have the power to not implement the spec, turning the spec from a
> useful description of implementations into a work of fiction.
>
>> That's something I would have considered before the advent of Mozilla
>> Firefox.
>
> Mozilla also has the power of veto here. For example, if we required that
> the browsers implement H.264, and Mozilla did not, then the spec would be
> just as equally fictional as it would be if today we required Theora.

I disagree with the characterization Ian makes here as I believe being  
royalty free is very important for the formats we actively deploy to the  
Web and as such H.264 is not an option.


> My sole goal was to try and point out that the situation with codecs is  
> not equivalent to past cases where vendors merely _hadn't implemented_  
> part of the spec; in this case vendors have _actively refused_ to  
> implement support for various codecs (Apple with Theora and  
> Mozilla(/Opera?) with H.264).

Somehow I doubt that if e.g. Opera vetoed the <video> element it would  
actually be removed from the specification. And if it that were the case I  
would consider it to be very bad as I mentioned in my initial email in  
this thread.


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

From jonas at sicking.cc  Wed Jul  1 13:06:37 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 1 Jul 2009 13:06:37 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <op.uwek1zgg64w2qv@anne-van-kesterens-macbook.local>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com> 
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com> 
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com> 
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com> 
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com> 
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
	<d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com> 
	<op.uwek1zgg64w2qv@anne-van-kesterens-macbook.local>
Message-ID: <63df84f0907011306k36a7148l9485f5afd4f032f2@mail.gmail.com>

On Wed, Jul 1, 2009 at 12:14 PM, Anne van Kesteren<annevk at opera.com> wrote:
> On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting <pkasting at google.com>
> wrote:
>>
>> On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren <annevk at opera.com>
>> wrote:
>>>
>>> The "vendor consensus" line of argument seems like a very dangerous
>>> slippery slope. It would mean that whenever a vendor refuses to implement
>>> something it has to be taken out of the specification. I.e. giving a single
>>> vendor veto power over the documentation of the Web Platform. Not good at
>>> all in my opinion.
>>
>> I am merely echoing Hixie; from his original email in this thread:
>>
>>>> At the end of the day, the browser vendors have a very effective
>>>> absolute veto on anything in the browser specs,
>>>
>>> You mean they have the power to derail a spec?
>>
>> They have the power to not implement the spec, turning the spec from a
>> useful description of implementations into a work of fiction.
>>
>>> That's something I would have considered before the advent of Mozilla
>>> Firefox.
>>
>> Mozilla also has the power of veto here. For example, if we required that
>> the browsers implement H.264, and Mozilla did not, then the spec would be
>> just as equally fictional as it would be if today we required Theora.
>
> I disagree with the characterization Ian makes here as I believe being
> royalty free is very important for the formats we actively deploy to the Web
> and as such H.264 is not an option.

Agreed. (Has anyone seriously proposed H.264 as a standard for the web?)

The only arguments against Theora has been:
* Too poor quality to be workable.
* Risk of hidden/unknown patents.
* Doesn't have hardware decoders.

I think the first bullet has been demonstrated to be false. The
relative quality between theora and h.264 is still being debated, but
the arguments are over a few percent here or there. Arguments that
theora is simply not good enough seems based on poor or outdated
information at this point.

The second bullet I don't buy. First of all because that argument
applies to absolutely everything we do. While video is particularly
bad, there is simply always a risk of unknown software patents.
Second, two big browser companies, with a third on the way, have at
this point deemed it safe enough to risk implementing, so presumably
they have done some amount of research into existing public patents.
And that's on top of any company that has shipped Theora support in
other contexts than browsers. Submarine patents are of course still a
problem, but no more so for video than for other technologies as far
as I can tell.

The third applies to basically anything other than a very short list
of codecs. As far as I know none of which are interesting for one
reason or another. If that is a requirement then we might pack up and
give up on making video a integral part of the open web. If a codec is
going to have a chance to become popular enough to make hardware
vendors get behind it, we need to take a first step. Hardware vendors
are not going to.

/ Jonas

From gmaxwell at gmail.com  Wed Jul  1 14:45:10 2009
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Wed, 1 Jul 2009 17:45:10 -0400
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <63df84f0907011306k36a7148l9485f5afd4f032f2@mail.gmail.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
	<d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com>
	<op.uwek1zgg64w2qv@anne-van-kesterens-macbook.local>
	<63df84f0907011306k36a7148l9485f5afd4f032f2@mail.gmail.com>
Message-ID: <e692861c0907011445p1d4afef1teb3b9fa499b95187@mail.gmail.com>

On Wed, Jul 1, 2009 at 4:06 PM, Jonas Sicking<jonas at sicking.cc> wrote:
[snip]
> I think the first bullet has been demonstrated to be false. The
> relative quality between theora and h.264 is still being debated, but
> the arguments are over a few percent here or there. Arguments that
> theora is simply not good enough seems based on poor or outdated
> information at this point.

I'm commenting here because I don't my own posts to be a source of
misinformation.

Depending on how and what you compare it's more than a few percent.

It turns out that H.264 as used in many places on web is within
spitting distance of the newer theora encoder due to encode side and
decode side computational complexity and compatibility concerns and
the selection of encoder software. For these same reasons there are
many 'older' formats still in wide use which Theora clearly
outperforms. The reality of what people are using puts the lie to
broad claims that Theora is generally unusable because it
under-performs the best available H.264 encoders in the lab.

Different uses and organizations will have different requirements.
Which is a good reason why HTML5 never required solutions to support
only one codec.

I do not doubt that there are uses which Theora is clearly inferior,
because of the mixture of tolerance for licensing, computational load,
intolerance for bitrate, requirements to operate at bits-per-pixel
levels below the range that theora operates well at, etc.  but it is
an enormous jump to go from "there are some uses" to apply the claim
to the general case, or to go from "it's needs some more bitrate to
achieve equivalent subjective quality" to remarks that the bitrate
inflation would endanger the Internet.  It was this kind of over
generalization that my commentary on Theora quality was targeting.

(And it should be absolutely unsurprising that at the limit Theora
does a somewhat worse off than H.264 in terms of quality/bits? it's an
older less CPU hungry design which is, from 50,000 ft, almost a strict
subset of H.264)

At the same time, we have clearly defined cases where H.264/AAC is
absolutely unacceptable. Not merely inferior, but completely
unworkable due to the licensing issues.

Different uses and organizations will have different requirements.
Different codecs will be superior depending on your requirements.
Which is a good reason why HTML5 never required solutions to support
only one codec.

But what I think is key is that the inclusion of Theora as a baseline
should do nothing to inhibit the parties which are already invested in
H.264, or whom have particular requirements which make it especially
attractive, from continuing to offer and use it.

The advantage of a baseline isn't necessarily that it's the best at
anything in particular, but that it's workable and mostly universal.
If when talking about a baseline you find yourself debating details
over efficiency vs the state of the art you've completely missed the
point.

This is a field which is still undergoing rapid development. Even if
codec-science were to see no improvements we will still see the state
of the art advance tremendously in the next years simply due to
increasing tolerance for CPU hungry techniques invented many years ago
but still under-used. Anything we use today is going to look pretty
weak compared to the options available 10 years from now.

It's important for a codec to be efficient, but the purpose of the
baseline is to be compatible. As such the relevant arguments should be
largely limited to workability, of which efficiency is only one part.

It was suggested here that MJPEG be added as a baseline.  I considered
this as an option for Wikipedia video support some years ago before we
had the Theora in Java playback working. I quickly determined that it
was unworkable for over-the-web use because of the bitrate: we're
talking about on the order of >10x the required bitrate over Theora
before considering the audio (which would also be >10x the bitrate of
Vorbis).

At lest for general public web use I think the hard workability
threshold could be fairly set as "can a typical consumer broadband
connection stream a 'web resolution' (i.e. somewhat sub-standard
definition) in real time with decent quality". Even though thats a
fairly vague criteria it seems clear that Ogg/Theora is well inside
this limit while MJPEG is well outside it.  Obviously different
parties will have different demands.

As far as I'm concerned spec might as well recommend a lossless codec
as MJPEG? at least lossless has advantages for the set of applications
which are completely insensitive to bitrate.

From robert at ocallahan.org  Wed Jul  1 16:37:03 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Thu, 2 Jul 2009 11:37:03 +1200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<fbad4e140906070830h725c2447l3d2a0d14d7f6c720@mail.gmail.com>
	<5068B3E9-E069-425C-89F7-AD09484F23D2@googlemail.com>
	<fbad4e140906071059h447bd282h2699cc5397c74067@mail.gmail.com>
	<Pine.LNX.4.62.0906071912410.16244@hixie.dreamhostps.com>
	<11e306600906071528i2b1b090fs2fdf9d21bbcd8c47@mail.gmail.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
Message-ID: <11e306600907011637u6b17db99lb447648a81f82e9d@mail.gmail.com>

On Tue, Jun 30, 2009 at 4:50 PM, Ian Hickson <ian at hixie.ch> wrote:

>  - has off-the-shelf decoder hardware chips available
>

I don't think this should be a requirement.

As written, this requirement primarily means "need to be able to build
devices today that play back with minimal power consumption". Obviously this
is desirable, but why is it *necessary* for a baseline codec? Why would a
vendor refuse to support a format because of high power consumption? It
seems to me that using up power can't be worse than refusing to play the
content at all. Does Apple block iPhone apps because they max out the CPU
while they're running?

It seems to me that this requirement forces HTML5 to merely document the
codec preferences of device vendors. I think HTML5 could be proactive
without being obnoxious, by recommending that Theora be supported wherever
possible. That would encourage the consumption and production of Theora
content, which would increase pressure on device vendors to support it well,
which would increase the chances us all getting a codec with good universal
support.

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/20090702/d17cd586/attachment.htm>

From jjcogliati-whatwg at yahoo.com  Wed Jul  1 19:32:26 2009
From: jjcogliati-whatwg at yahoo.com (jjcogliati-whatwg at yahoo.com)
Date: Wed, 1 Jul 2009 19:32:26 -0700 (PDT)
Subject: [whatwg] Codecs for <audio> and <video>
Message-ID: <456156.80439.qm@web63205.mail.re1.yahoo.com>




--- On Wed, 7/1/09, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> 
> It was suggested here that MJPEG be added as a
> baseline.? I considered
> this as an option for Wikipedia video support some years
> ago before we
> had the Theora in Java playback working. I quickly
> determined that it
> was unworkable for over-the-web use because of the bitrate:
> we're
> talking about on the order of >10x the required bitrate
> over Theora
> before considering the audio (which would also be >10x
> the bitrate of
> Vorbis).

Mozilla already supports Motion JPEG for the image tag (but not for video tag so far as I know).  Basically, right now if you want a video file that
will play on Quicktime, Media Player and Gstreamer's good set of plugins, the best option is Motion JPEG.  I have mailed CDs with MJPEG video and PCM audio, and you can fit ~15 minutes of this in ~TV quality.  

For ~TV quality video and audio (240 x 320 pixels  30 fps) we are talking something like (If you have better numbers, point them out to me):
5 MBit/s MJPEG video with PCM audio
1-2 MBit/s MPEG-1 
0.5 MBit/s Ogg Vorbis 

My suggestion (and I am not particularly serious) was:
[(H.264 OR Theora) AND Motion JPEG] 
If you care about bandwidth more than licensing fees, you provide both H.264 and Theora.  If you care more about licensing costs, you can provide Theora and Motion JPEG.  I don't think that enshrining this in the spec is a very good idea however since it is a somewhat poor compromise.  

I can envision a future where a year from now Apple still has not added Theora support, but Mozilla has added gstreamer support, and suddenly Motion JPEG is the 'best' baseline codec, and the defacto video support is
[(H.264 OR Theora) AND Motion JPEG] 

> As far as I'm concerned spec might as well recommend a
> lossless codec
> as MJPEG? at least lossless has advantages for the set of
> applications
> which are completely insensitive to bitrate.

What lossless codecs might be available without patent problems?



From ian at hixie.ch  Wed Jul  1 20:52:35 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 2 Jul 2009 03:52:35 +0000 (UTC)
Subject: [whatwg] <code> attributes
In-Reply-To: <63df84f0906090937p40eb44edicdb963ddf387591c@mail.gmail.com>
References: <bd14ac7c0904281216h8cb7872n42a1bb1dc6541190@mail.gmail.com> 
	<op.us4l5ni51ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0906050122340.1648@hixie.dreamhostps.com>
	<63df84f0906090937p40eb44edicdb963ddf387591c@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907020345120.1060@hixie.dreamhostps.com>

On Tue, 9 Jun 2009, Jonas Sicking wrote:
> On Thu, Jun 4, 2009 at 6:24 PM, Ian Hickson<ian at hixie.ch> wrote:
> > On Tue, 28 Apr 2009, Jacob Rask wrote:
> >>
> >> has there ever been any discussion on including an attribute to the 
> >> code element, specify the programming language in the markup? If so, 
> >> what was the conclusion? I didn't find anything in the list archives.
> >
> > On Tue, 28 Apr 2009, Michael A. Puls II wrote:
> >>
> >> For example: <code class="language-python"></code>
> >
> > This has been discussed before, but the basic answer is "use the class 
> > attribute", at least for now. I would recommend, if this is a 
> > common-enough problem, that a group of people get together and define 
> > a common set of class attribute values for the <code> element, in the 
> > style of a Microformat. That way, we can build a common vocabulary 
> > that can then be made more formal in the next version of HTML.
> 
> Is there a reason you encourage class values rather than microdata here? 
> As I understood it, one of the things microdata was trying to avoid was 
> using the class attribute since there was concern that it would collide 
> with user values.

I suppose you could use microdata if you wanted to, but it's not clear to 
me what the benefit would be. The goal here is typically to allow an 
element to be annotated (class attribute), not to allow a set of 
name-value pairs to be included alongside the markup (microdata).

To do this "right" in microdata, you'd have to do something like:

   <pre item="com.example.code"><code itemprop="com.example.text">
    <meta itemprop="com.example.lang" content="python">
    ... my code ...
   </code></pre>

...to end up with an item that has a "com.example.text" property with the 
code in question and a "com.example.lang" property with the language, 
whereas with a class attribute you just need to do something like:

   <pre><code class="com.example.python">
    ... my code ...
   </code></pre>

...and define that the "com.example.python" class automatically implies 
that the content of the element in the code in question.

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

From ian at hixie.ch  Wed Jul  1 21:44:49 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 2 Jul 2009 04:44:49 +0000 (UTC)
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <op.uu3s6rb3ptj49s@aimac.local>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
	<op.utlmgkuuidj3kv@simon-pieterss-macbook.local>
	<dd0fbad0905080742y6afc45e8x51642ef881addc2e@mail.gmail.com>
	<Pine.LNX.4.62.0906060230060.1648@hixie.dreamhostps.com>
	<op.uu3s6rb3ptj49s@aimac.local>
Message-ID: <Pine.LNX.4.62.0907020443090.1060@hixie.dreamhostps.com>

On Sat, 6 Jun 2009, Kornel Lesinski wrote:
> On Sat, 06 Jun 2009 04:00:28 +0100, Ian Hickson <ian at hixie.ch> wrote:
> 
> > I don't think <hgroup> will be used often enough to justify calling it
> > just <h>.
> 
> Ok, but what about <subheader>? (<subtitle>, <tagline>?)
> 
> The purpose of <hgroup> is to imply that <hx> is a subtitle. That's quite an
> indirection. An explicit element would be easier to understand:
> 
> <h1>Dr. Strangelove</h1>
> <subheader>Or: How I Learned to Stop Worrying and Love the Bomb<subheader>
> 
> Also it could accept only phrasing content, so it would be easier for
> validators to catch when authors confuse it with <header>.
> 
> It doesn't require changes to styling of <hx>, and can be given appropriate
> size with "h1 + subheader" CSS selector.

That would have been another option (it wouldn't handle multiple-level 
subheadings well, but that's not a big deal), but I'm not really convinced 
it's enough of an improvement to change the way the spec is written. It 
also has poorer graceful degradation behaviour, IMHO.

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

From ian at hixie.ch  Wed Jul  1 22:16:52 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 2 Jul 2009 05:16:52 +0000 (UTC)
Subject: [whatwg] Two feature-suggestions for HTML5 (forms)
In-Reply-To: <5d06fd730906080545t694cd0ceoe2824ce0ac38ad99@mail.gmail.com>
References: <5d06fd730906080545t694cd0ceoe2824ce0ac38ad99@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907020514580.1060@hixie.dreamhostps.com>


(Trimmed cc list to reduce cross-posting.)

On Mon, 8 Jun 2009, Asser Nilsson wrote:
> 
> There are two things in HTML5-forms that are often made with "Active" 
> Technology like JavaScript, that would be very cool, if HTML5 could do 
> these things without Scripting:
> 
> 1. I've seen this at the online-dictionary dict.leo.org: they made a 
> JavaScript-function, that you can type the word to translate without the 
> text-box marked an the characters get in there. So, you don't have to 
> mark the right textbox before you type, but you can type, no matter to 
> look, if the box is marked. I think it would be a very nice feature for 
> HTML5-forms if this would work without Scripting... E.g. an option for 
> text-fields, that everythins typed on this site is typed into this field 
> (even if it is not highlighted).

This isn't really done on enough sites to warrant built-in support, I 
don't think.


> 2. In search-boxes Javascript often is used for send every written 
> character to the server and the server return search-suggestions 
> "as-you-type". If this is possible without Scripting only with HTML/CSS 
> this would be very cool.

This was possible in a previous incarnation of HTML5, but we removed 
support because it wasn't an especially popular feature, and it turns out 
to have some pretty subtle complications.

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

From ian at hixie.ch  Wed Jul  1 22:28:22 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 2 Jul 2009 05:28:22 +0000 (UTC)
Subject: [whatwg] request for clarification: aside, figure
In-Reply-To: <op.uu8ylox1h8on37@bruce-pc>
References: <op.utpe39xth8on37@bruce-pc> <op.utpfi0rzh8on37@bruce-pc>
	<Pine.LNX.4.62.0906090050230.1648@hixie.dreamhostps.com>
	<op.uu8ylox1h8on37@bruce-pc>
Message-ID: <Pine.LNX.4.62.0907020519150.1060@hixie.dreamhostps.com>

On Tue, 9 Jun 2009, Bruce Lawson wrote:
> On Tue, 09 Jun 2009 01:57:15 +0100, Ian Hickson <ian at hixie.ch> wrote:
> > On Sun, 10 May 2009, Bruce Lawson wrote:
> > > 
> > > I don't think the spec is clear enough defining these two elements 
> > > from an author's perspective. [...]
> > > What is the difference between a <figure> that has no caption and an
> > > <aside>? Both seem to be connected in some way with the main content
> > > around it, but can be considered separate/ may be moved. [...]
> > > So If I have a magazine-style pullquote, is that a figure or an aside
> > > (or neither)?
> > 
> > I have attempted to address this, but actually it turns out HTML5 
> > already has examples of how to do pull quotes in the <aside> section.
> 
> I didn't express myself clearly enough. This isn't a problem per se - 
> it's the symptom of a problem. I note that there is an example of how to 
> do pullquotes, but I can't deduce the logic that makes it obvious why 
> one should use an <aside> rather than <figure>; the definition of each 
> seems to allow either to be used thus.

<aside> is defined as follows:

# The aside element represents a section of a page that consists of 
# content that is tangentially related to the content around the aside 
# element, and which could be considered separate from that content. Such 
# sections are often represented as sidebars in printed typography.
#
# The element can also be used for typographical effects like pull quotes.

<figure> is defined as follows:

# The figure element represents some flow content, optionally with a 
# caption, that is self-contained and is typically referenced as a single 
# unit from the main flow of the document.
#
# The element can thus be used to annotate illustrations, diagrams, 
# photos, code listings, etc, that are referred to from the main content 
# of the document, but that could, without affecting the flow of the 
# document, be moved away from that primary content, e.g. to the side of 
# the page, to dedicated pages, or to an appendix.

I don't really know how to make it clearer.

At the end of the day it doesn't really matter if <figure> is used for 
pull quotes (it's not really that inappropriate, and if it were the only 
thing <aside> were to be used for, I'd have suggested dropping <aside> and 
leaving pull quotes to <figure> anyway). Pull quotes are kind of a middle 
ground which (notwithstanding the explicit statement in the spec saying 
that <aside> is more appropriate for pull quotes) could probably be argued 
either way.


> > > For example, in the middle of a fictional interview about markup, I 
> > > might want to pull out a quote and citation: Do I write
> > > 
> > > <aside>
> > > <blockquote>After a sip of sweet sherry, I turn into Mr Last
> > > Week</blockquote>
> > > <cite>Ian Hickson</cite>
> > > </aside>
> > > 
> > > Or
> > > 
> > > <figure>
> > > <blockquote>After a sip of sweet sherry, I turn into Mr Last
> > > Week</blockquote>
> > > <legend>Ian Hickson</legend>
> > > </figure>
> > 
> > The former shows correct usage of <aside> vs <figure>, though the 
> > <cite> element usage is incorrect; the name should not be marked up.
> 
> Again, I see no spec-derived reason why it should be <aside> rather than 
> <figure>, other than it happens to be given an example of one rather 
> than the other.

Well it says "The element can also be used for typographical effects like 
pull quotes", which is the main reason. :-)

However, at the end of the day, the second markup snippet there isn't 
especially wrong either, it's just not the preferred way (which was more 
or less arbitrarily chosen in this case).


> (Given that marking up a name as a citation is common practice, and 
> validator cannot distinguish between a name and a title of a work, 
> should we widen the definition of <cite> to match the "English language" 
> defintion "1. to quote or refer to (a passage, book, or author)" ? A 
> different discussion, apologies)

<cite> in HTML5 is defined to mean "title of work" based on current usage, 
rather than having anything to do with actual citations.

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

From ian at hixie.ch  Wed Jul  1 22:37:22 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 2 Jul 2009 05:37:22 +0000 (UTC)
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
In-Reply-To: <63df84f0906090215n9e3d816m695b6026fb4a42b0@mail.gmail.com>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com> 
	<63df84f0905141700v792efe48madbd203a1f4ae63b@mail.gmail.com> 
	<63df84f0905141710u11d5bfedl91cd9fd60085d9c2@mail.gmail.com> 
	<Pine.LNX.4.62.0906090325080.1648@hixie.dreamhostps.com>
	<63df84f0906090215n9e3d816m695b6026fb4a42b0@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907020528490.1060@hixie.dreamhostps.com>

On Tue, 9 Jun 2009, Jonas Sicking wrote:
> >>
> >> Some of the improvement suggestions that I have heard that sounds 
> >> interesting, though possibly for the next version of microdata.
> >>
> >> * Support for specifying a machine-readable value, such as for dates, 
> >> colors, numbers, etc.
> >
> > I expect we will add support for these based on demand, the same way 
> > we added <time> in the first place.
> 
> Using dedicated elements for each data type seems like it will 
> eventually bloat the language.

Only if people don't show restraint in extending the language.


> For example what use would a <color> element or a <number> element do?

It would allow conformance checkers to do type checking for the most 
commonly used types, and might allow (for number, anyway) localised 
formatting.


> If instead mashine readable values could be added using a generic 
> method, such as a 'itemvalue' or 'propvalue' attribute, each microdata 
> format can define how to interpret the values, be they numbers, dates, 
> body parts, or chemical formulas.

You can do that now with <meta itemprop=... content=...>.


> >> I even wonder it would allow replacing the <time> element with a 
> >> standardized microformat, such as:
> >>
> >> Christmas is going down on <span item="w3c.time" 
> >> itemvalue="12-25-2009">The 25th day of December<span>!
> >
> > I don't really understand how that would be better than dedicated 
> > elements.
> 
> The idea would be to reduce the size of the language. I.e. if a feature 
> isn't heavily used, it might be better expressed as a microdata format. 

Well, you can do it today as:

   Christmas is going down on <meta itemprop="w3c.time" 
   content="12-25-2009">The 25th day of December!

...which (assuming that in your example you meant "itemprop" and not 
"item", and assuming that you didn't mean the contents of the <span> to 
have any effect on the microdata processing model) would result in exactly 
the same name/value pair being generated into the relevant item.

On the other hand, if you really meant item="", which I guess you might 
have meant... you could do that today as:

   Christmas is going down on <span item="w3c.time"><meta itemprop="value"
   content="12-25-2009">The 25th day of December</span>!

...or some such (it doesn't matter what the textual contents of the <span> 
are in this example). However, this is going to result in much more 
painful structures, and you'd still need to link the item with a parent 
item (assuming there is one), as in:

   <div item="com.example.somethingorother">
    Christmas is going down on <span itemprop="com.example.startdate" 
    item="w3c.time"><meta itemprop="value" content="12-25-2009">The 25th 
    day of December</span>!
   </div>

...which is really getting complicated compared to just:

   <div item="com.example.somethingorother">
    Christmas is going down on <meta itemprop="w3c.time" 
    content="12-25-2009">The 25th day of December!
   </div>

...or (preferred today):

   <div item="com.example.somethingorother">
    Christmas is going down on <time itemprop="w3c.time" 
    datetime="12-25-2009">The 25th day of December</time>!
   </div>


> For example, why didn't you add elements for bibtex or vCard, but 
> instead used microdata?

New elements didn't really fit the use cases as well.


> Another reason is as a test of the microdata feature itself. Microdata 
> is a sort of extension mechanism to HTML 5. In software development, it 
> is common to test your extension system by developing parts of the 
> product using the extension system. This way you can both keep the core 
> code small, and you get a good test bed for your extension system.

Indeed.


> You have already done this with the "predefined vocabularies"

Right.


> and apparently the lack of ability to define a mashine readable value 
> separate from the human readable one was not a problem. However it would 
> seem that the same does not hold true for <time>.

Right, that's why I adapted <time> into the microdata model.


> >> * Support for tabular data.
> >
> > This would be nice if we can find a way to do it that doesn't put 
> > undue burdens on simple implementations. (e.g. I would imagine that 
> > while a microdata implementation today can be a few hundred lines 
> > total, adding support for the table model could easily double that.)
>
> Quite possibly.
> 
> In both these cases I'm perfectly happy to wait with adding more 
> features to microdata for now and see if what we have is successful, 
> before we start over engineering it to cover every imaginable case.

Agreed.

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

From jeremy at adactio.com  Thu Jul  2 04:00:32 2009
From: jeremy at adactio.com (Jeremy Keith)
Date: Thu, 2 Jul 2009 12:00:32 +0100
Subject: [whatwg] the cite element
In-Reply-To: <FE4019F502F74D899A8CE3511763B5B4@POCZTOWIEC>
References: <4A299FA9.40507@awhlink.com>
	<Pine.LNX.4.62.0907010418140.1060@hixie.dreamhostps.com>
	<22d65dda0907010755k6e64a0ccpbd1c41ed0594d6e2@mail.gmail.com>
	<C35A3C262C444951B57A68A603495F04@POCZTOWIEC>
	<op.uwedvrzsh8on37@bruce-pc>
	<A34933AC1F4543819D146078D733587D@POCZTOWIEC>
	<22d65dda0907011004m523fa1ccna700f2523297ca93@mail.gmail.com>
	<ea09c0d10907011009p5d9fd340m8926a6d26f108f19@mail.gmail.com>
	<FE4019F502F74D899A8CE3511763B5B4@POCZTOWIEC>
Message-ID: <6A36FE6C-CC75-4F94-A334-82B93A615E18@adactio.com>

Chris wrote:
> If "more then titles" means other uses of the CITE tag, as evidenced  
> in [1],
> they do not form any pattern.  They look more like random errors.

I've used the CITE element fairly extensively on my blog, *mostly* for  
titles (books, films) but also for people. If it's a proper noun, then  
it could potentially be marked up using CITE, IMHO.

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From derernst at gmx.ch  Thu Jul  2 05:07:07 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 02 Jul 2009 14:07:07 +0200
Subject: [whatwg] do not encourage use of small element for legal text
In-Reply-To: <Pine.LNX.4.62.0907010409170.1060@hixie.dreamhostps.com>
References: <4A2818E3.7060800@awhlink.com>
	<4A28463D.2030501@mit.edu>	<4A2995B6.4020304@awhlink.com>
	<Pine.LNX.4.62.0907010409170.1060@hixie.dreamhostps.com>
Message-ID: <4A4CA2EB.40205@gmx.ch>

Ian Hickson schrieb:
> On Thu, 4 Jun 2009, Andrew W. Hagen wrote:
> 
>> Encouraging use of small print for legalese also encourages this:
>>
>> <h1>
>> <a href="continue.html">
>> Welcome to the BigCo web site. Click to continue.
>> </a>
>> </h1>
>> <small>By clicking above, you agree that BigCo can charge your
>> credit card $10 per visit to the BigCo web site per page clicked.</small>
> 
> Right, that's the case we do want to encourage. It's better than the 
> alternative, which would be:
> 
>  <style>
>   .s { font-size: smaller; }
>  </style>
>  <h1>
>  <a href="continue.html">
>  Welcome to the BigCo web site. Click to continue.
>  </a>
>  </h1>
>  <span class=s>By clicking above, you agree that BigCo can charge your
>  credit card $10 per visit to the BigCo web site per page clicked.</span>
> 
> ...because if they use <small>, you can configure your client to go out of 
> its way to highlight <small> text, whereas you have no way to know to 
> highlight any text based on its font size or class.

Anyway that does not prevent the BigCos from using <span> or <p> or 
<div>, if they really want to style their fraudulent text the way it is 
hard to read. The more user agents will be set to display the <small> 
element big, the less this element will be used by those who are 
actually addressed by this encouragement.

Instead of keeping a purely presentational category such as "small" as 
an HTML element, would it not be more efficient to use some kind of 
<legal> element? User agents then could be configured to ignore small 
text sizes or badly visible colors on <legal> elements. Also, other ways 
to bar people from reading legal text, such as setting it in uppercase 
characters, could be handled - which does not seem appropriate for a 
<small> element.

And countries willing to protect their people from fraud could establish 
a law that any text on a website is only legally binding when it is 
marked up with the <legal> element.

-- 
Markus

From jeremy at adactio.com  Thu Jul  2 05:22:48 2009
From: jeremy at adactio.com (Jeremy Keith)
Date: Thu, 2 Jul 2009 13:22:48 +0100
Subject: [whatwg] Rel and META values
Message-ID: <EB3952B9-1EB8-46C2-80CC-BC4D0A55A557@adactio.com>

I'm a bit confused by the conditions set out at the bottom of the rel  
extensions wiki page:
http://wiki.whatwg.org/wiki/RelExtensions

"For the "Status" section to be changed to "Accepted", the proposed  
keyword must either have been through the Microformats process, and  
been approved by the Microformats community; or must be defined by a  
W3C specification in the Candidate Recommendation or Recommendation  
state. If it fails to go through this process, it is "Rejected"."

1. Should I change all of the values derived from XFN from "proposal"  
to "accepted" as they seem to fit this criteria?

2. I don't think passing the buck to the microformats community is  
necessarily a good idea. There are perfectly  good values listed (e.g.  
rel="accessibility") that would/should probably never become a  
microformat but are still good semantic values. Will they really be  
rejected outright?

Then there's the wiki page for META values:
http://wiki.whatwg.org/wiki/MetaExtensions

"For the "Status" section to be changed to "Accepted", the proposed  
keyword must either have been through the Microformats process and  
been approved by the Microformats community; or must be defined by a  
W3C specification in the Candidate Recommendation or Recommendation  
state. If it fails to go through this process, it is "Unendorsed"."

This is kinda nuts. No META value will *ever* become a microformat;  
the very concept of invisible metadata is anathema to microformats? 
it's impossible for a META keyword value to pass the microformats  
process.

Should everything on the wiki page be marked as "unendorsed" or, more  
realistically, should the conditions for acceptance be altered?

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From philipj at opera.com  Thu Jul  2 07:06:58 2009
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Thu, 02 Jul 2009 16:06:58 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <op.uweev0rhsr6mfa@nog>
References: <693677.27885.qm@web63201.mail.re1.yahoo.com>
	<Pine.LNX.4.62.0906292331380.1648@hixie.dreamhostps.com>
	<2c0e02830906300159t6950f6c3s899254b40edd1562@mail.gmail.com>
	<4126b3450906300217m4351c2c1i34c350cb3184e0f5@mail.gmail.com>
	<d62cf1d10906301203l1f9e7360r633afae3e742b07@mail.gmail.com>
	<d62cf1d10906301207x614390bej5f31c23495378c0f@mail.gmail.com>
	<d62cf1d10906301215ifd92196jfb7f51b99f81320e@mail.gmail.com>
	<4A4A67EF.6010102@iglou.com>
	<d62cf1d10906301239m4e6124abp256609333c93879e@mail.gmail.com>
	<op.uwdujdda64w2qv@anne-van-kesterens-macbook.local>
	<d62cf1d10907010929r315384a7u55ea8ccff532ad2a@mail.gmail.com>
	<op.uweev0rhsr6mfa@nog>
Message-ID: <op.uwf1hwsjsr6mfa@nog>

On Wed, 01 Jul 2009 19:01:02 +0200, Philip J?genstedt <philipj at opera.com>  
wrote:

> On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting <pkasting at google.com>  
> wrote:
>
>> On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren <annevk at opera.com>  
>> wrote:
>>
>>> On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting <pkasting at google.com>
>>> wrote:
>>>
>>>> There is no other reason to put a codec in the spec -- the primary  
>>>> reason
>>>> to spec a behavior (to document vendor consensus) does not apply.   
>>>> "Some
>>>> vendors agreed, and some objected violently" is not "consensus".
>>>>
>>>
>>> The "vendor consensus" line of argument seems like a very dangerous
>>> slippery slope. It would mean that whenever a vendor refuses to  
>>> implement
>>> something it has to be taken out of the specification. I.e. giving a  
>>> single
>>> vendor veto power over the documentation of the Web Platform. Not good  
>>> at
>>> all in my opinion.
>>>
>>
>> I am merely echoing Hixie; from his original email in this thread:
>>
>>> > At the end of the day, the browser vendors have a very effective
>>> > absolute veto on anything in the browser specs,
>>>
>>> You mean they have the power to derail a spec?
>>
>> They have the power to not implement the spec, turning the spec from a
>> useful description of implementations into a work of fiction.
>>
>>> That's something I would have considered before the advent of Mozilla
>>> Firefox.
>>
>> Mozilla also has the power of veto here. For example, if we required  
>> that
>> the browsers implement H.264, and Mozilla did not, then the spec would  
>> be
>> just as equally fictional as it would be if today we required Theora.
>>
>>
>> My sole goal was to try and point out that the situation with codecs is  
>> not
>> equivalent to past cases where vendors merely _hadn't implemented_ part  
>> of
>> the spec; in this case vendors have _actively refused_ to implement  
>> support
>> for various codecs (Apple with Theora and Mozilla(/Opera?) with H.264).
>>
>> PK
>
> That is correct, we consider H.264 to be incompatible with the open web  
> platform due to its patent licensing. For the time being we will support  
> Ogg Vorbis/Theora, which is the best option patent-wise and neck-in-neck  
> with the competition in the quality-per-bit section (especially with  
> recent encoder improvements). We would love to see it as the baseline  
> for HTML5, but in the absense of that hope that the web community will  
> push it hard enough so that it becomes the de-facto standard.
>

A private email has correctly pointed out that "neck-in-neck" is  
exaggerating Theora's quality when compared to a state of the art H.264  
encoder. It's worth pointing out though that in the immediate future  
Theora/Vorbis will also be competing against FLV (H.263/MP3), where it  
compares favorably (especially for audio).

Some relevant reading:

http://web.mit.edu/xiphmont/Public/theora/demo7.html
http://people.xiph.org/~greg/video/ytcompare/comparison.html
http://www-cs-faculty.stanford.edu/~nick/theora-soccer/

Previously, I have watched the video's from Greg's ~499kbit/sec comparison  
of H.264 (as encoded by YouTube) and Theora and it is clear that Theora  
has more block artifacts and noise overall. However, in the H.264 version  
when the bunny hole is zoomed in the bunny "flicks" with a period with  
about 1 sec, similar to the effect of a keyframe in a dark scene (I  
haven't inspected if these were actually keyframes). I'd argue that for  
this clip, which you prefer depends on how you like your artifacts and if  
you're watching in fullscreen or not (block artifacts are more noticeable  
when magnified while a "keyframe flick" is noticeable also at 1:1  
magnification). However, this comparison was only made to counter a claim  
by Chris DiBona and doesn't show that Theora is "neck-in-neck" with H.264  
in the general case. It does however show that it is neck-in-neck with  
what YouTube produces.

I haven't watched the video's of the soccer comparison, but assume that  
the conclusions are roughly correct.

H.264 is a more modern codec than Theora and will outperform it if the  
best encoders from both sides are used, I don't want to imply anything  
else. Still, Theora is certainly good enough at this point that the  
deciding factor is no longer about technical quality, but about finding a  
common baseline that everyone can support.

-- 
Philip J?genstedt
Core Developer
Opera Software

From contact2009 at awhlink.com  Thu Jul  2 12:25:47 2009
From: contact2009 at awhlink.com (Andrew W. Hagen)
Date: Thu, 02 Jul 2009 14:25:47 -0500
Subject: [whatwg] do not encourage use of small element for legal text
In-Reply-To: <4A4CA2EB.40205@gmx.ch>
References: <4A2818E3.7060800@awhlink.com>
	<4A28463D.2030501@mit.edu>	<4A2995B6.4020304@awhlink.com>
	<Pine.LNX.4.62.0907010409170.1060@hixie.dreamhostps.com>
	<4A4CA2EB.40205@gmx.ch>
Message-ID: <4A4D09BB.7080008@awhlink.com>

The text from the current spec is, "Small print is typically
legalese describing disclaimers, caveats, legal
restrictions, or copyrights. Small print is also sometimes
used for attribution."

By suggesting it is typical, that implicitly encourages people
to use small print for legal text.

One of HTML 5's design principles is to take the predominant
practice of what people are doing on the web, and turn that
into the standard that all HTML 5 authors should follow.

Certain sections in the spec are normative or non-normative.
It does not make sense for the HTML 5 spec to make a non-
normative comment in a normative section. Furthermore, it is
fallacious to argue that something is not "encouragement"
but is "normative."

Leaving any suggestion in the HTML 5 spec that legal text
typically is, could be, or should be in small print could do
a disservice to anyone reading the spec.

Take a hypothetical example. Joe is the owner-operator of
SmallCo, a building contractor. Joe decides to create a web
site for his business. Being technically proficient, he
consults the HTML 5 web site. He reads how the <small>
element is typically used for disclaimers, etc. On his one-
page web site, he posts the following notice:

<p>Your 100% satisfaction in the work of SmallCo is
guaranteed. <small>Guarantee applies only to commercial
buildings. </small></p>

Joe gets a new customer from the web site. The customer has
him build a residential house. Joe does the job. The work is
done well, but the customer is not 100% satisfied. The
customer wants various changes that Joe does not consider
necessary. Joe and the customer have a serious dispute. The
customer claims that $45,000 worth of work must be performed
for the customer to be 100% satisfied. Joe claims that his
obligations are already fulfiled, and the 100% satisfaction
guarantee does not apply to the customer's job because his
residential house is not a commercial building. They take
their dispute to court.

In this particular case, the disclaimer Joe posted on his
web site becomes a hotly disputed issue. The judge takes
special note that Joe had his disclaimer in small print. Due
to the law of the particular jurisdiction they are in, Joe
loses. Joe now must perform a great deal of work for no pay,
or pay the customer $45,000 to hire another contractor. The
financial fortunes of SmallCo and of Joe have taken a
terrible turn for the worse. Joe feels like the HTML 5 spec
gave him bad advice.

Whether legal text may properly appear in small print has
been the subject of numerous lawsuits of greatly significant
value, at least in American law. The implicit encouragement
to use small print takes the lexicographical mandate of
"seeing what people are doing on the web and then making
that the standard" too far. It should be impossible for
anyone reading a tech specification to think that they are
getting legal advice. Yet that is not the case in the
current HTML 5 spec.

The current situation in the spec is really bad. As it reads
currently, the spec encourages fraud. This should not be
acceptable considering how much of a benefit HTML 5 will be
otherwise.

Additionally, the word "legalese" has a strongly negative
connotation . Using the term "legalese" as a stand-in for
any legal text implies that all legal text is suspicious or
useless at best. The spec should not sit in judgment on the
law. Espousing a vaguely anarchical political point of view
is OK, but that should not be part of HTML 5.

What should be done is to remove all references to the law,
legalese, and such from the small element section. If people
want to put something legal in a small element, let them
make their own choice. Let them come up with that generally
bad idea on their own, or perhaps in consultation with their
own attorneys who can take responsibility for their error if
the use of the small element causes some problem. What the
law actually says will vary according to your jurisdiction.

The problem with a <legal> element would be that it does not
correspond to any discrete set of text. If a web page
becomes the subject of a court case, the court is likely to
look at any part of the web page it thinks is relevant, not
just the part contained in a <legal> element. Thus, the
rationale for a <legal> element would not carry through to
the real world. For example, the following would not result
in an effective legal defense:

<legal>SmallCo guarantees 100% satisfaction</legal>
<small>except for residential buildings</small>

Furthermore, we should not create a <legal> element in
anticipation that in the future at some undetermined point
it is conceivable that some legislature will somehow connect
the legal status of text on a web page to its appearance in
a <legal> element. It's too speculative. That would prove
unworkable anyway.

To sum up, legal text generally should not be in small print,
because legal text is important and should be easy to read. The exact
legal consequences of legal text in small print will vary
depending on the facts of the case and on the jurisdiction.
The HTML 5 spec should not make assertions, either normative
or non-normative, about legal matters. The HTML 5 spec is
going to be a terrific advance, and removing this thorn from
its side will only improve it.

Andrew Hagen
contact2009 at awhlink.com


From giecrilj at stegny.2a.pl  Thu Jul  2 12:55:07 2009
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Thu, 2 Jul 2009 21:55:07 +0200
Subject: [whatwg] do not encourage use of small element for legal text
In-Reply-To: <4A4D09BB.7080008@awhlink.com>
References: <4A2818E3.7060800@awhlink.com>
	<4A28463D.2030501@mit.edu>	<4A2995B6.4020304@awhlink.com>
	<Pine.LNX.4.62.0907010409170.1060@hixie.dreamhostps.com>
	<4A4CA2EB.40205@gmx.ch> <4A4D09BB.7080008@awhlink.com>
Message-ID: <0619F085320E406A9D7BCA4E9C49F0E6@POCZTOWIEC>

I have addressed all Andrew's points previously.  Please forgive my posting
an outline of the arguments here.
  1. The specification does not encourage using the SMALL element for legal
notices.  It merely allows the SMALL element to contain legal notices.
  2. Legal texts are unreadable on their own; putting them in small text
does not make them any less readable.  This statement does not make me an
anarchist; I can say the same about math :-)
  3. Legal texts are best read copied to Notepad because they do not and
cannot contain any normative markup.  (They are also best displayed in an
inline frame, especially because the editor of the page is usually not
allowed to edit them.)
  4. I concur that warranties should be added to disclaimers in the text to
make it less negatively biased.
IMHO,
Chris


From ian at hixie.ch  Thu Jul  2 13:09:05 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 2 Jul 2009 20:09:05 +0000 (UTC)
Subject: [whatwg] Reminder - there's no need to repeat yourself
In-Reply-To: <0619F085320E406A9D7BCA4E9C49F0E6@POCZTOWIEC>
References: <4A2818E3.7060800@awhlink.com> <4A28463D.2030501@mit.edu>
	<4A2995B6.4020304@awhlink.com>
	<Pine.LNX.4.62.0907010409170.1060@hixie.dreamhostps.com>
	<4A4CA2EB.40205@gmx.ch> <4A4D09BB.7080008@awhlink.com>
	<0619F085320E406A9D7BCA4E9C49F0E6@POCZTOWIEC>
Message-ID: <Pine.LNX.4.62.0907021958260.1053@hixie.dreamhostps.com>

On Thu, 2 Jul 2009, Kristof Zelechovski wrote:
>
> I have addressed all Andrew's points previously.  Please forgive my 
> posting an outline of the arguments here.

Just as a reminder (and this is especially relevant for the video codecs 
discussion!), there is no need to repeat previously stated arguments.

When going through feedback, I read all the e-mails on the relevant 
threads, and consider all the arguments made, even those made just once. 
Repeating arguments doesn't make me give them any more weight. :-)

So please, if you see something you want to say has already been said, 
either by you or someone else, just bite your tongue and trust that I will 
take the original mention into account. Thanks!

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

From Olli.Pettay at helsinki.fi  Thu Jul  2 13:13:49 2009
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 02 Jul 2009 23:13:49 +0300
Subject: [whatwg] Session history
Message-ID: <4A4D14FD.1090401@helsinki.fi>

Hi all,

copy-pasting an IRC conversation about session history.
Seems like HTML5 isn't compatible with any implementation.

[22:58]	<smaug>	Hixie: ping
[22:58]	<Hixie>	hey
[22:59]	<smaug>	Hixie: about HTML5's session history
[22:59]	<Hixie>	yes
[22:59]	<smaug>	I'm trying to understand the "Each browsing context, 
including nested browsing context, has a distinct session history."
[23:00]	<Hixie>	browsing context = frames, iframes, windows, tabs, etc. 
basically i think what mozilla calls a docshell (?)
[23:00]	<smaug>	but in practice if go(-1) is called in a iframe (and it 
hasn't been navigated from the original page), the top level page is 
navigated
[23:00]	<Hixie>	...oh.
[23:00]	<Hixie>	really?
[23:00]	<Hixie>	huh
[23:01]	<smaug>	every browser
[23:01]	<smaug>	don't know about IE
[23:01]	<Hixie>	wow, how did i miss that
[23:01]	<Hixie>	you sure?
[23:01]	<Hixie>	i mean, i'm sure you're sure
[23:01]	<Hixie>	i'm just so surprised
[23:02]	<Hixie>	do you mean that it navigates whichever of the browsing 
contexts was most recently navigated?
[23:02]	<Hixie>	or does it actually move the top one?
[23:02]	<smaug>	Go http://mozilla.pettay.fi/moztests/ then locate 
history_test.html
[23:02]	<smaug>	then press go(-1)
[23:03]	<smaug>	ah
[23:03]	<smaug>	probably whatever was most recently navigated
[23:03]	<smaug>	I need to test some more
[23:03]	<Hixie>	oh that's even more different
[23:03]	<smaug>	but at least the history isn't per browser context
[23:03]	<Hixie>	or at least, .back() and company don't navigate that one
[23:03]	<Hixie>	but some aggregate one
[23:04]	<Hixie>	huh
[23:04]	<Hixie>	that's going to be a huge pain to fix
[23:04]	<smaug>	right
[23:04]	<smaug>	someone was going to start to implement pushState and I 
had to review HTML5's history....
[23:04]	<smaug>	didn't look quite right
[23:05]	<Hixie>	i wonder if i can define a per-top-level-bc history that 
is the union of all the histories of all the bcs that are active
[23:05]	<Hixie>	sorted in the order in which those entries were added
[23:05]	<Hixie>	and then define .go() in terms of that
[23:05]	<Hixie>	and leave everything else alone
[23:05]	<Hixie>	i think that might do it
[23:06]	<Hixie>	i'd have to define the sort order carefully
[23:06]	<Hixie>	and somehow come up with a definition of the "current" 
position
[23:06]	<Hixie>	i'm sure this will be quite exciting
[23:06]	<smaug>	in gecko top level content docshell owns the shistory
[23:06]	<Hixie>	smaug: can i ask you a favour? can you post this irc log 
or something like it to whatwg?
[23:06]	<smaug>	ok, will do
[23:06]	<Hixie>	plus anything else you know about it, like how mozilla 
does it?
[23:07]	<Hixie>	how urgent is it that i fix this?
[23:07]	<smaug>	well, I don't know yet how pushState works with this all
[23:07]	<smaug>	I need to think about that
[23:08]	<Hixie>	k
[23:08]	<Hixie>	i can probably get to this this weekend




-Olli

From chuck at jumis.com  Thu Jul  2 14:46:22 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Thu, 02 Jul 2009 14:46:22 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <4A4D2AAE.1030701@jumis.com>

whatwg-request at lists.whatwg.org wrote:
> Message: 3
> Date: Tue, 30 Jun 2009 04:50:31 +0000 (UTC)
> From: Ian Hickson <ian at hixie.ch>
> Subject: [whatwg] Codecs for <audio> and <video>
> To: WHATWG <whatwg at whatwg.org>
> Message-ID: <Pine.LNX.4.62.0906292331380.1648 at hixie.dreamhostps.com>
>
> After an inordinate amount of discussions, both in public and privately, 
> on the situation regarding codecs for <video> and <audio> in HTML5, I have 
> reluctantly come to the conclusion that there is no suitable codec that 
> all vendors are willing to implement and ship.
>   
There are many considerations when supporting video codecs, licensing, 
hardware, complexity, cost.

Can the standard simply address video containers (OGG, MKV, AVI) ?
Each container is fairly easy to implement and codecs can be identified 
within the container.
Vendors can decide on their own what to do with that information.

I'd appreciate for the container formats to be supported, so I can get a 
nice message saying:
Your codec "####": Vorbis, is not supported by your computer without a 
plugin,
and/or have the ability to right click, hit properties,
and get some data even without supporting the codec.

I've come across a few wav and avi files, where I've needed to download 
the file,
and download a helper application to simply identify what codec I need 
to install.

If the browser had at least [properly] supported the container, it would 
have saved me quite a bit of time and effort.

Better to say: "Codec XXX not installed"
instead of: "I don't know what it is, good luck with that".
I realize the codec="" attribute provides hints, it's a pain for the 
document author.

As far as I know, there are no patent issues for popular container formats.


-Charles

> I have therefore removed the two subsections in the HTML5 spec in which 
> codecs would have been required, and have instead left the matter 
> undefined, as has in the past been done with other features like <img> and 
> image formats, <embed> and plugin APIs, or Web fonts and font formats.


From rniwa at google.com  Thu Jul  2 15:05:09 2009
From: rniwa at google.com (Ryosuke Niwa)
Date: Thu, 2 Jul 2009 15:05:09 -0700
Subject: [whatwg] Nested list
Message-ID: <5a068af50907021505jd494b69n552f7ea68032c344@mail.gmail.com>

Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
nested OL or UL without LI.  See
http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.2  In fact, the
nested list example is marked deprecated. ?But in practice, all major
user agents produce nested list when execCommand("Indent"...) is
executed. ?Is there any chance we can?standardize?nested lists, and in
particular, what UA produce?

For example, all?major?browsers (Firefox, IE, & WebKit)?produce
slightly different?versions of HTML?when?indenting?"item?2"?in the
following HTML (assume it's content-editable):
<ol>
<ol id="u1"><li id="i1">item 1</li></ol>
<li id="i2">item 2</li>
<ol id="u3"><li id="i3">item 3</li></ol>
</ol>

In particular, many UA remove arbitrary id attributes.

Best regards,
Ryosuke Niwa
rniwa at google.com

From ian at hixie.ch  Thu Jul  2 16:26:11 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 2 Jul 2009 23:26:11 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A4D2AAE.1030701@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
Message-ID: <Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>


I understand that people are disappointed that we can't require Theora 
support. I am disappointed in the lack of progress on this issue also.


On Tue, 30 Jun 2009, Silvia Pfeiffer wrote:
> On Tue, Jun 30, 2009 at 2:50 PM, Ian Hickson<ian at hixie.ch> wrote:
> > I considered requiring Ogg Theora support in the spec, since we do 
> > have three implementations that are willing to implement it, but it 
> > wouldn't help get us true interoperabiliy, since the people who are 
> > willing to implement it are willing to do so regardless of the spec, 
> > and the people who aren't are not going to be swayed by what the spec 
> > says.
> 
> Inclusion of a required baseline codec into a standard speaks more 
> loudly than you may think. It provides confidence - confidence that an 
> informed choice has been made as to the best solution in a given 
> situation. Confidence to Web developers, confidence to hosting 
> providers, confidence also (but less so, since they are gatekeepers in 
> this situation) to Browser Vendors.

Words in the spec only provide this confidence because that confidence is 
well-placed. If we start making the spec say things that don't represent 
reality -- like "everyone agrees that you should use Theora" -- then that 
confidence will erode in all parts of the spec.


> In my opinion, including a baseline codec requirement into a W3C 
> specification that is not supported by all Browser Vendors is much 
> preferable over an unclear situation

Having a baseline codec requirement that is not supported by all Browser 
Vendors _is_ an unclear situation. Adding the requirement doesn't stop 
that.


> In fact, it is a tradition of HTML to have specifications that are only 
> supported by a limited set of Browser Vendors and only over time 
> increasingly supported by all - e.g. how long did it take for all 
> Browser vendors to accept css2, and many of the smaller features of 
> html4 such as fixed positioning?

CSS2.1 and HTML5 were reactions to the exact problem you describe in CSS2 
and HTML4.


> I firmly believe that making the decision to give up on baseline codecs 
> is repeating a mistake made and repeatedly cited as a mistake on the 
> lack of specification of a baseline format for images - which is one of 
> the reasons why it took years to have two baseline image codecs 
> available in all browsers. We could try the other route for a change and 
> see if standards can actually make a difference to adoption.

We basically tried the idea of requiring something that browser vendors 
didn't agree with with XHTML2. IMHO that is a far bigger mistake than not 
specifying something that people don't agree to implement.


> > Going forward, I see several (not mutually exclusive) possibilities, all
> > of which will take several years:
> >
> > ?1. Ogg Theora encoders continue to improve. Off-the-shelf hardware Ogg
> > ? ?Theora decoder chips become available. Google ships support for the
> > ? ?codec for long enough without getting sued that Apple's concern
> > ? ?regarding submarine patents is reduced. => Theora becomes the de facto
> > ? ?codec for the Web.
> 
> This to me is a defeat of the standardisation process. Standards are
> not there to wait for the market to come up with a de-facto standard.
> They are there to provide confidence to the larger market about making
> a choice - no certainty of course, but just that much more confidence
> that it matters.

Actually HTML5 is largely built on the idea of speccing the de-facto 
standards, either long after they were implemented, or in tandem with them 
being implemented. Very little of HTML5 has been ahead of implementations.


> > ?2. The remaining H.264 baseline patents owned by companies who are not
> > ? ?willing to license them royalty-free expire, leading to H.264 support
> > ? ?being available without license fees. => H.264 becomes the de facto
> > ? ?codec for the Web.
> 
> That could take many years.

Yup.


> Your main argument against Theora is a recent email stating that YouTube 
> could not be run using Theora.

No; my only argument against Theora is that Apple won't implement it.


> > No, that was just a tactical withdrawal. This e-mail here is the one 
> > that admits defeat. :-)
> 
> First rule of standards: never give up!

My first rule of standards, if I have one, would be "spec reality".


> Including a Theora prescription and having it only partially supported 
> with at least give a large part of the world an interoperable platform 
> and that's all HTML has traditionally been.

The same argument could be made for H.264.


At the end of the day, if the relevant implementors (in this case browser 
vendors) aren't willing to all implement the same codec, then the codecs 
will just have to compete on their own merits.

This isn't HTML5's fight.


On Tue, 30 Jun 2009, Jeff McAdams wrote:
> 
> But "Most people agreed, and one or two vendors objected violently" 
> probably is.  Just because one or two people are really loud, doesn't 
> mean that there isn't concensus.

The WHATWG doesn't work on consensus.


> Also, I find the focus on vendors to the exclusion of other stakeholders 
> a bit concerning.

The relevant implementors (in this case browser vendors) have the ultimate 
control (since they implement the spec) over what happens. It's not that 
other stakeholders are excluded, but that if the browser vendors aren't on 
board, there is no point moving on.


On Tue, 30 Jun 2009, Joshua Brickner wrote:
> 
> IMHO, the fundamental question here is whether or not the spec should be 
> concerned solely about creating a standard that is satisfactory for 
> implementers to follow, or if it should go further and try to make the 
> standard work well for everyone involved including developers and 
> consumers.
> 
> I am certain that most would like to have a standard that best serves 
> the entire community.

It doesn't help the community if it's not implemented.


On Wed, 1 Jul 2009, Anne van Kesteren wrote:
> 
> The "vendor consensus" line of argument seems like a very dangerous 
> slippery slope. It would mean that whenever a vendor refuses to 
> implement something it has to be taken out of the specification. I.e. 
> giving a single vendor veto power over the documentation of the Web 
> Platform. Not good at all in my opinion.

That's exactly what we have. Mozilla won't implement SQL -- SQL is being 
taken out of the Web Storage draft. Apple won't implement Theora -- Theora 
is out of the HTML5 draft.


On Wed, 1 Jul 2009, Anne van Kesteren wrote:
> >
> > My sole goal was to try and point out that the situation with codecs 
> > is not equivalent to past cases where vendors merely _hadn't 
> > implemented_ part of the spec; in this case vendors have _actively 
> > refused_ to implement support for various codecs (Apple with Theora 
> > and Mozilla(/Opera?) with H.264).
> 
> Somehow I doubt that if e.g. Opera vetoed the <video> element it would 
> actually be removed from the specification. And if it that were the case 
> I would consider it to be very bad as I mentioned in my initial email in 
> this thread.

If Opera decided that <video> as a whole is something they would never 
impelment, then it would probably be moved into a separate spec, just like 
SQL is being moved into a separate spec.


On Tue, 30 Jun 2009, Peter Kasting wrote:
>
> * Acid3 was meant to be an illustrative example of a case where the test 
> itself was not intentionally introducing new behavior or attempting to 
> force consensus on unwilling vendors, not a perfect analogy to something

Also, Acid3 wasn't a particularly great example of how to do this. I made 
an number of mistakes in its development. Hopefully we'll do things better 
with Acid4.


On Tue, 30 Jun 2009, Aryeh Gregor wrote:
> 
> *Requiring* Ogg support might be a bit much, I agree, since it implies 
> that nobody would have a legitimate foreseeable reason for not 
> supporting it, and that's ungenerous at best.  But the spec could still 
> *encourage* Ogg support while acknowledging there may be reasons not to 
> have it.  Saying all implementations *should* support Ogg Theora and 
> Vorbis acknowledges that there "may exist valid reasons in particular 
> circumstances to ignore a particular item, but the full implications 
> must be understood and carefully weighed before choosing a different 
> course".  This seems like a perfectly reasonable response to me.

To be honest I don't see much point in a non-normative mention of Theora 
in the spec. It wouldn't have the teeth people want to change reality, and 
it wouldn't help document reality.


On Tue, 30 Jun 2009, Mikko Rantalainen wrote:
> 
> I don't know about Microsoft but Apple has displayed willingness to 
> implement what specifications say (see http://acid3.acidtests.org/ for 
> example). By W3C standards a spec can get REC status if it has at least 
> two implementations and we already have three. The current HTML 5 spec 
> already has stuff not implemented by every vendor, why should <video> be 
> different?

Does HTML5 have anything that any vendor flat-out refuses to implement, 
other than Theora support? If so, that should be removed.


> I'd suggest one of the two choices (I prefer the first one):
> 
> (1) Specify Theora as the baseline codec. Hopefully it will be tested by 
> acid4 test (or by some other popular test) and Apple will either 
> implement it regardless of the assumed patent risks or finds the actual 
> patent owners and acquires the required licenses for Theora to be 
> implemented by Apple. In the future, if Apple implements Theora, then 
> perhaps even Microsoft will do so, too.

Apple have said that they won't do this.


> (2) Specify {Theora or H.264} as the baseline. That way all vendors that 
> have displayed any interest for <video> could implement the spec. 
> Authors would be required to provide the video in both formats to be 
> sure that any spec compliant user agent is able to display the content, 
> but at least there would be some real target set by the spec. However, I 
> think that this just moves the H.264 patent licensing issue from browser 
> vendors to content authors: if you believe that you cannot decode H.264 
> without proper patent license there's no way you could encode H.264 
> content without the very same license. As a result, many authors will 
> not be able to provide H.264 variant -- and as a result the Theora would 
> become de facto standard in the future.

I don't think this would be any difference, in practice, than what we have 
now.



On Tue, 30 Jun 2009, Jeff McAdams wrote:
> 
> Yes, clearly publishing the spec with a baseline codec specified isn't 
> *sufficient* for definitively "get[ting] us true interoperabiliy[sic]", 
> but it certain does *help* get us true interoperability, in two ways 
> that I can think of off the top of my head.
> 
> First, there is some inherent pressure for implementing the spec.

I think you overestimate this pressure. (Just look at XHTML2.)


> Again, some parties have indicated that it is not enough to get them to 
> do so, but that eliminates their ability to claim adherence to this 
> standard when others are doing so.

Given that nobody has ever correctly and fully implemented HTML4, and yet 
people have claimed to have implemented HTML4, I think that's demonstrably 
false.


> Second, it gives us (people like me) an extra tool to go back to vendors and
> say, "Hey, please support HTML5, its important to me, and the <video> tag,
> with the correct baseline codec support, is important to me."

In my experience your requests would actually have more power on Apple if 
they were _not_ backed by the spec. That is, you will have more effect on 
Apple if HTML5 doesn't say which codec to support and you _still_ go to 
Apple and ask for Theora support, than if the spec says Theora and you ask 
for Theora. In the latter case, they are much more likely to dismiss your 
request as "just someone checking that we support the spec", in the former 
case, they are more likely to actually believe you need Theora support.


> You've said a couple of things that I perceive as contradictory, here. 
> You've said that you want to help bring about interoperability, but then 
> you've also said that you're only documenting what it is that the 
> browser makers are implementing.  There is room in the standards bodies 
> world for both goals, and both goals, at times are valid and beneficial.  
> But, if your intent is to help bring about interoperability, *real* 
> interoperability, then I think its pretty clear that the way forward 
> involves specifying a baseline codec.

The way forward involves getting to the point where we can specify a 
baseline codec, yes. But we do that _after_ everyone agrees on a baseline 
codec. While it may appear that I write stuff in the spec and the browser 
vendors then agree to it, in practice it's usually the other way around.


> Leaving such an important point of interoperability completely up to the 
> whims of "people out there" seems unwise here (I look at MS's latest 
> attempt at supporting ODF as a great example of how interoperability can 
> actually be harmed, even by a "complying" implementation, when important 
> parts of guidelines to interoperability are left out...there are plenty 
> more examples).

This seems unaffected by whether the spec requires this or not.


On Tue, 30 Jun 2009, Dr. Markus Walther wrote:
> > 
> > Having removed everything else in these sections, I figured there 
> > wasn't that much value in requiring PCM-in-Wave support. However, I 
> > will continue to work with browser vendors directly and try to get a 
> > common codec at least for audio, even if that is just PCM-in-Wave.
> 
> Please, please do so - I was shocked to read that PCM-in-Wave as the 
> minimal 'consensus' container for audio is under threat of removal, too.

The consensus isn't removed, only the text documenting it.


> Frankly, I don't understand why audio was drawn into this. Is there any 
> patent issue with PCM-in-Wave? If not, then IMHO the decision should be 
> orthogonal to video.

I just don't see much value in calling this one minor codec amongst all 
the other formats and codecs that browsers have to support (CSS, JS, HTTP, 
PNG, GIF, JPEG, SVG, etc).


On Tue, 30 Jun 2009, Manuel Amador (Rudd-O) wrote:
> 
> The objecting vendors could have taken a number of approaches to band 
> together and protect themselves from the supposed "patent threats" 
> against free formats, but they did not.  They could have lobbied against 
> software patents; they didn't.  They could have agreed to countersue -- 
> with their immense patent portfolio -- anyone who sued any of them for 
> patent infringement; they didn't.  Of course, why would the objecting 
> vendors do that? Most of the competitive advantages they have stem from 
> being able to leverage government force against potential competitors, 
> so doing any of the above would have undermined that.

Actually, I can attest from first-hand knowledge that the "objecting 
vendors" did attempt to find solutions to this. Though this was not done 
in public, plenty of efforts have been made, and continue to be made, to 
find other solutions. The vendors involved really do appear to be acting 
in good faith.

On Thu, 2 Jul 2009, Charles Pritchard wrote:
> 
> Can the standard simply address video containers (OGG, MKV, AVI) ?
> Each container is fairly easy to implement and codecs can be identified within
> the container.
> Vendors can decide on their own what to do with that information.

The spec does document how to distinguish containers via MIME type. Beyond 
that I'm not sure what we can do.

<video> does support fallback, so in practice you can just use Theora and 
H.264 and cover all bases.

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

From silviapfeiffer1 at gmail.com  Thu Jul  2 17:04:12 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 3 Jul 2009 10:04:12 +1000
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org> 
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
Message-ID: <2c0e02830907021704k715e7c87n7b6623842ef69b73@mail.gmail.com>

On Fri, Jul 3, 2009 at 9:26 AM, Ian Hickson<ian at hixie.ch> wrote:
>
>> > Going forward, I see several (not mutually exclusive) possibilities, all
>> > of which will take several years:
>> >
>> > ?1. Ogg Theora encoders continue to improve. Off-the-shelf hardware Ogg
>> > ? ?Theora decoder chips become available. Google ships support for the
>> > ? ?codec for long enough without getting sued that Apple's concern
>> > ? ?regarding submarine patents is reduced. => Theora becomes the de facto
>> > ? ?codec for the Web.
>>
>> This to me is a defeat of the standardisation process. Standards are
>> not there to wait for the market to come up with a de-facto standard.
>> They are there to provide confidence to the larger market about making
>> a choice - no certainty of course, but just that much more confidence
>> that it matters.
>
> Actually HTML5 is largely built on the idea of speccing the de-facto
> standards, either long after they were implemented, or in tandem with them
> being implemented. Very little of HTML5 has been ahead of implementations.

What about Internet Explorer, the browser with the largest market
share? Bascially all of HTML5 is ahead of being implemented in IE. I
don't think that argument holds.


> No; my only argument against Theora is that Apple won't implement it.

What about XiphQT? It doesn't matter that Apple doesn't natively
support Theora - the software exists to provide the support.
Therefore, the argument that "Apple doesn't support Theora" doesn't
hold up. It's not Apple that matters, but their browser. Safari and
Webkit have Theora support. There is an implementation.

In fact, I have not heard Apple object violently to an inclusion of
Theora into the specification as baseline codec. I have only heard
them object to a native implementation in Safari for submarine patent
threat reasons.


>> Including a Theora prescription and having it only partially supported
>> with at least give a large part of the world an interoperable platform
>> and that's all HTML has traditionally been.
>
> The same argument could be made for H.264.

Except that H.264 does not qualify any of the royalty-free
requirements that W3C has for standardising technology.


>> You've said a couple of things that I perceive as contradictory, here.
>> You've said that you want to help bring about interoperability, but then
>> you've also said that you're only documenting what it is that the
>> browser makers are implementing. ?There is room in the standards bodies
>> world for both goals, and both goals, at times are valid and beneficial.
>> But, if your intent is to help bring about interoperability, *real*
>> interoperability, then I think its pretty clear that the way forward
>> involves specifying a baseline codec.
>
> The way forward involves getting to the point where we can specify a
> baseline codec, yes. But we do that _after_ everyone agrees on a baseline
> codec. While it may appear that I write stuff in the spec and the browser
> vendors then agree to it, in practice it's usually the other way around.

That I can understand. But in this case, you should leave the
paragraph in the spec that states the need for a baseline codec, since
the situation hasn't changed and we are still striving for a baseline
codec.

Regards,
Silvia.

From ian at hixie.ch  Thu Jul  2 17:19:37 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 3 Jul 2009 00:19:37 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <2c0e02830907021704k715e7c87n7b6623842ef69b73@mail.gmail.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<2c0e02830907021704k715e7c87n7b6623842ef69b73@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907030011430.1053@hixie.dreamhostps.com>

On Fri, 3 Jul 2009, Silvia Pfeiffer wrote:
> >
> > Actually HTML5 is largely built on the idea of speccing the de-facto 
> > standards, either long after they were implemented, or in tandem with 
> > them being implemented. Very little of HTML5 has been ahead of 
> > implementations.
> 
> What about Internet Explorer, the browser with the largest market share? 
> Bascially all of HTML5 is ahead of being implemented in IE. I don't 
> think that argument holds.

Not every part of HTML5 is implemented by everyone at the same time. 
There's always going to be some areas that are ahead of simple 
implementations, as different vendors focus on different things.

Plenty in HTML5 was implemented by IE first, though -- drag and drop, 
contentEditable, XHR (now in a separate spec), etc.


> > No; my only argument against Theora is that Apple won't implement it.
> 
> What about XiphQT? It doesn't matter that Apple doesn't natively support 
> Theora - the software exists to provide the support.

Does XiphQT ship with Safari? If not, then it doesn't count as part of the 
implementation.


> Therefore, the argument that "Apple doesn't support Theora" doesn't hold 
> up. It's not Apple that matters, but their browser. Safari and Webkit 
> have Theora support. There is an implementation.

Safari on my iPod Touch certainly doesn't, even with all the will in the 
world on the behalf of the user to install third-party software.


> In fact, I have not heard Apple object violently to an inclusion of 
> Theora into the specification as baseline codec. I have only heard them 
> object to a native implementation in Safari for submarine patent threat 
> reasons.

Their objection to implementing the requirement if it is put in the spec 
is what is holding up the spec requiring it.


> That I can understand. But in this case, you should leave the paragraph 
> in the spec that states the need for a baseline codec, since the 
> situation hasn't changed and we are still striving for a baseline codec.

I'm not holding up the spec just because we haven't found a codec to use 
with the spec. This working group can override me on this if it is the 
desire of the group, but in the meantime, I'm trying to drive down to Last 
Call by October and part of that is going through open issues and either 
resolving them, or admitting that they can't be resolved by then and 
moving on. The alternative is to deadlock, and that is worse.

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

From silviapfeiffer1 at gmail.com  Thu Jul  2 17:26:28 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 3 Jul 2009 10:26:28 +1000
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907030011430.1053@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org> 
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com> 
	<2c0e02830907021704k715e7c87n7b6623842ef69b73@mail.gmail.com> 
	<Pine.LNX.4.62.0907030011430.1053@hixie.dreamhostps.com>
Message-ID: <2c0e02830907021726w503397f7w57444d7f1d4125bb@mail.gmail.com>

On Fri, Jul 3, 2009 at 10:19 AM, Ian Hickson<ian at hixie.ch> wrote:
> On Fri, 3 Jul 2009, Silvia Pfeiffer wrote:
>> >
>> That I can understand. But in this case, you should leave the paragraph
>> in the spec that states the need for a baseline codec, since the
>> situation hasn't changed and we are still striving for a baseline codec.
>
> I'm not holding up the spec just because we haven't found a codec to use
> with the spec. This working group can override me on this if it is the
> desire of the group, but in the meantime, I'm trying to drive down to Last
> Call by October and part of that is going through open issues and either
> resolving them, or admitting that they can't be resolved by then and
> moving on. The alternative is to deadlock, and that is worse.

OK, that answers my earlier question of "why now".

That action I can understand. But then I would say we should have a
collection of things that we need to work on for a second version of
HTML5, which obviously includes the baseline codec question and also
audio/video a11y, and probably many more things I am not aware of. Is
there such a list somewhere? Since all these things are now being
pulled out of the spec, they need to continue living somewhere else.

Regards,
Silvia.

From ian at hixie.ch  Thu Jul  2 17:36:20 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 3 Jul 2009 00:36:20 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <2c0e02830907021726w503397f7w57444d7f1d4125bb@mail.gmail.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<2c0e02830907021704k715e7c87n7b6623842ef69b73@mail.gmail.com> 
	<Pine.LNX.4.62.0907030011430.1053@hixie.dreamhostps.com>
	<2c0e02830907021726w503397f7w57444d7f1d4125bb@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907030029340.1053@hixie.dreamhostps.com>

On Fri, 3 Jul 2009, Silvia Pfeiffer wrote:
> 
> That action I can understand. But then I would say we should have a 
> collection of things that we need to work on for a second version of 
> HTML5, which obviously includes the baseline codec question and also 
> audio/video a11y, and probably many more things I am not aware of. Is 
> there such a list somewhere? Since all these things are now being pulled 
> out of the spec, they need to continue living somewhere else.

The spec itself documents these in comments in the source. Search for 
"v2" in the spec source.

The codecs issue is being still actively worked on by a number of parties, 
as it has been for over a year now; the removal of the sections from the 
spec doesn't affect this. I still hold high hopes that one day we can find 
a solution to this that all vendors are willing to implement.

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

From silviapfeiffer1 at gmail.com  Thu Jul  2 18:30:17 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 3 Jul 2009 11:30:17 +1000
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907030029340.1053@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org> 
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com> 
	<2c0e02830907021704k715e7c87n7b6623842ef69b73@mail.gmail.com> 
	<Pine.LNX.4.62.0907030011430.1053@hixie.dreamhostps.com>
	<2c0e02830907021726w503397f7w57444d7f1d4125bb@mail.gmail.com> 
	<Pine.LNX.4.62.0907030029340.1053@hixie.dreamhostps.com>
Message-ID: <2c0e02830907021830u10f0494cye03c11c12b842cad@mail.gmail.com>

On Fri, Jul 3, 2009 at 10:36 AM, Ian Hickson<ian at hixie.ch> wrote:
> On Fri, 3 Jul 2009, Silvia Pfeiffer wrote:
>>
>> That action I can understand. But then I would say we should have a
>> collection of things that we need to work on for a second version of
>> HTML5, which obviously includes the baseline codec question and also
>> audio/video a11y, and probably many more things I am not aware of. Is
>> there such a list somewhere? Since all these things are now being pulled
>> out of the spec, they need to continue living somewhere else.
>
> The spec itself documents these in comments in the source. Search for
> "v2" in the spec source.

Ok, cool.

> The codecs issue is being still actively worked on by a number of parties,
> as it has been for over a year now; the removal of the sections from the
> spec doesn't affect this. I still hold high hopes that one day we can find
> a solution to this that all vendors are willing to implement.

The bit that would be important to keep is the list of requirements on
a baseline codec.

Cheers,
Silvia.

From chuck at jumis.com  Thu Jul  2 18:51:01 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Thu, 02 Jul 2009 18:51:01 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
Message-ID: <4A4D6405.6040409@jumis.com>

I'd like to see some progress on these two tags.

I'd like people to consider that Vorbis can be implemented
in virtual machines (Java, Flash) which support raw PCM data.
Theora is no different.

I'd like to see <canvas> support added to the <video> tag (it's as 
natural as <img>).
and enable the <audio> tag to accept raw data lpcm),
just as the <canvas> tag accepts raw data (bitmap).

Then you can support any codec you create, as well as use system codecs.

You can't make the impossible happen (no HD video on an old 300mhz machine),
but you'd have the freedom to do the improbable.

Add raw pcm and sound font support to <audio>,
add raw pixel support to <video> (via CanvasRenderingContext2D).

And add an event handler when subtitles are enabled / disabled.

I have further, more specific comments, below.
and at the end of the e-mail, two additions to the standard.

> Ian Hickson wrote:
> I understand that people are disappointed that we can't require Theora 
> support. I am disappointed in the lack of progress on this issue also.
>
>
> On Tue, 30 Jun 2009, Dr. Markus Walther wrote:
>   
>>> Having removed everything else in these sections, I figured there 
>>> wasn't that much value in requiring PCM-in-Wave support. However, I 
>>> will continue to work with browser vendors directly and try to get a 
>>> common codec at least for audio, even if that is just PCM-in-Wave.
>>>       

I'd think that FLAC would make more sense than PCM-in-Wave,
as a PNG analog.

Consider the <canvas> element. PNG implementations may be broken.
Internally, <canvas> accepts a raw byte array, a 32 bit bitmap, and
allows a string-based export of a compressed bitmap,
as a base64 encoded 32 bit png.

The <audio> element should accept a raw byte array, 32 bit per sample lpcm,
and allow a similar export of base64 encoded file, perhaps using FLAC.

Canvas can currently be used to render unsupported image formats (and 
mediate unsupported image containers),
it's been proven with ActionScript that a virtual machine can also 
support otherwise unsupported audio codecs.

I'd like to see a font analog in audio as well. Canvas supports the font 
attribute,
audio could certainly support sound fonts. Use a generated pitch if your
platform can't or doesn't store sound fonts.


>> Please, please do so - I was shocked to read that PCM-in-Wave as the 
>> minimal 'consensus' container for audio is under threat of removal, too.
>>     
There seems to be some confusion between codecs and containers.
WAV, OGG, AVI and MKV are containers, OSC is another.

Codecs are a completely separate matter.

It's very clear that Apple will not distribute the Vorbis and Theora codecs
with their software packages.

It's likely that Apple would like to use a library they don't have to 
document,
as required by most open source licenses, and they see no current reason 
to invest
money into writing a new one. Apple supports many chipsets, and many content
agreements, it would be costly.

I see no reason why Apple could not support the OGG container.
That said, I see no reason why a list of containers needs to be in the 
HTML 5 spec.

> On Thu, 2 Jul 2009, Charles Pritchard wrote:
>   
>> Can the standard simply address video containers (OGG, MKV, AVI) ?
>> Each container is fairly easy to implement and codecs can be identified within
>> the container.
>> Vendors can decide on their own what to do with that information.
>>     
>
> The spec does document how to distinguish containers via MIME type. Beyond 
> that I'm not sure what we can do.
>
> <video> does support fallback, so in practice you can just use Theora and 
> H.264 and cover all bases.
>   

I'd like to see this added to <audio> and <video>:

"User agents should provide controls to enable the manual selection of 
fallback content."

"User agents should provide an activation behavior, when fallback 
content is required, detailing why the primary content could not be used."

Many non-technical users will want to know why there is a black screen 
(or still image), even though they can hear the audio.


-Charles



From ashannon1000 at gmail.com  Thu Jul  2 21:14:13 2009
From: ashannon1000 at gmail.com (Adam Shannon)
Date: Thu, 2 Jul 2009 23:14:13 -0500
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A4D6405.6040409@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org> 
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com> 
	<4A4D6405.6040409@jumis.com>
Message-ID: <3c4f8cda0907022114y1eefa49mfbec76316e51fc41@mail.gmail.com>

Do you have an idea on how to introduce fall back support for browsers that
don't even support <canvas>, how will they be expected to implement a base64
string when they skip the element's attributes?
Might a <img> tag work with the src="" set to the same string as the base64?
 Or would that contradict the point of allowing <video>, <audio>, and
<canvas> the extra abilities?  Because if people can just use
the <img> tag which is more comfortable to them, why would they feel
the urge to switch?

On Thu, Jul 2, 2009 at 8:51 PM, Charles Pritchard <chuck at jumis.com> wrote:

> I'd like to see some progress on these two tags.
>
> I'd like people to consider that Vorbis can be implemented
> in virtual machines (Java, Flash) which support raw PCM data.
> Theora is no different.
>
> I'd like to see <canvas> support added to the <video> tag (it's as natural
> as <img>).
> and enable the <audio> tag to accept raw data lpcm),
> just as the <canvas> tag accepts raw data (bitmap).
>
> Then you can support any codec you create, as well as use system codecs.
>
> You can't make the impossible happen (no HD video on an old 300mhz
> machine),
> but you'd have the freedom to do the improbable.
>
> Add raw pcm and sound font support to <audio>,
> add raw pixel support to <video> (via CanvasRenderingContext2D).
>
> And add an event handler when subtitles are enabled / disabled.
>
> I have further, more specific comments, below.
> and at the end of the e-mail, two additions to the standard.
>
>  Ian Hickson wrote:
>> I understand that people are disappointed that we can't require Theora
>> support. I am disappointed in the lack of progress on this issue also.
>>
>>
>> On Tue, 30 Jun 2009, Dr. Markus Walther wrote:
>>
>>
>>> Having removed everything else in these sections, I figured there wasn't
>>>> that much value in requiring PCM-in-Wave support. However, I will continue
>>>> to work with browser vendors directly and try to get a common codec at least
>>>> for audio, even if that is just PCM-in-Wave.
>>>>
>>>>
>>>
> I'd think that FLAC would make more sense than PCM-in-Wave,
> as a PNG analog.
>
> Consider the <canvas> element. PNG implementations may be broken.
> Internally, <canvas> accepts a raw byte array, a 32 bit bitmap, and
> allows a string-based export of a compressed bitmap,
> as a base64 encoded 32 bit png.
>
> The <audio> element should accept a raw byte array, 32 bit per sample lpcm,
> and allow a similar export of base64 encoded file, perhaps using FLAC.
>
> Canvas can currently be used to render unsupported image formats (and
> mediate unsupported image containers),
> it's been proven with ActionScript that a virtual machine can also support
> otherwise unsupported audio codecs.
>
> I'd like to see a font analog in audio as well. Canvas supports the font
> attribute,
> audio could certainly support sound fonts. Use a generated pitch if your
> platform can't or doesn't store sound fonts.
>
>
>  Please, please do so - I was shocked to read that PCM-in-Wave as the
>>> minimal 'consensus' container for audio is under threat of removal, too.
>>>
>>>
>> There seems to be some confusion between codecs and containers.
> WAV, OGG, AVI and MKV are containers, OSC is another.
>
> Codecs are a completely separate matter.
>
> It's very clear that Apple will not distribute the Vorbis and Theora codecs
> with their software packages.
>
> It's likely that Apple would like to use a library they don't have to
> document,
> as required by most open source licenses, and they see no current reason to
> invest
> money into writing a new one. Apple supports many chipsets, and many
> content
> agreements, it would be costly.
>
> I see no reason why Apple could not support the OGG container.
> That said, I see no reason why a list of containers needs to be in the HTML
> 5 spec.
>
>  On Thu, 2 Jul 2009, Charles Pritchard wrote:
>>
>>
>>> Can the standard simply address video containers (OGG, MKV, AVI) ?
>>> Each container is fairly easy to implement and codecs can be identified
>>> within
>>> the container.
>>> Vendors can decide on their own what to do with that information.
>>>
>>>
>>
>> The spec does document how to distinguish containers via MIME type. Beyond
>> that I'm not sure what we can do.
>>
>> <video> does support fallback, so in practice you can just use Theora and
>> H.264 and cover all bases.
>>
>>
>
> I'd like to see this added to <audio> and <video>:
>
> "User agents should provide controls to enable the manual selection of
> fallback content."
>
> "User agents should provide an activation behavior, when fallback content
> is required, detailing why the primary content could not be used."
>
> Many non-technical users will want to know why there is a black screen (or
> still image), even though they can hear the audio.
>
>
> -Charles
>
>
>


-- 
- Adam Shannon ( http://ashannon.us )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090702/6b7d4ec9/attachment-0001.htm>

From skissane at gmail.com  Thu Jul  2 22:35:40 2009
From: skissane at gmail.com (SJ Kissane)
Date: Fri, 3 Jul 2009 15:35:40 +1000
Subject: [whatwg] HTML5 Definition of week (section 2.4.5.6)
Message-ID: <82fa66380907022235l983e42bu17bd5108d5cd6748@mail.gmail.com>

Hi

I am concerned by the wording of this section.
There are different systems of week number -- as far as I can work out,
this is the same as ISO 8601 week numbering.
But it nowhere explicitly says that.

I think, the spec should have a normative reference to ISO 8601 for the
definition of week numbering.
Then, if the spec wants to give an informative recap of what ISO 8601 says,
for
the benefit of those who don't have a copy (especially since it isn't free),
that's fine.
But I'm worried, by inserting some complicated definition into the spec,
does it match exactly ISO 8601's definition?
(I'm sure it does, but "are the definitions the same?" is not immediately
obvious from inspection.)

Cheers
Simon Kissane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090703/b93b9dfa/attachment.htm>

From ian at hixie.ch  Thu Jul  2 23:11:25 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 3 Jul 2009 06:11:25 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <2c0e02830907021830u10f0494cye03c11c12b842cad@mail.gmail.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<2c0e02830907021704k715e7c87n7b6623842ef69b73@mail.gmail.com> 
	<Pine.LNX.4.62.0907030011430.1053@hixie.dreamhostps.com>
	<2c0e02830907021726w503397f7w57444d7f1d4125bb@mail.gmail.com> 
	<Pine.LNX.4.62.0907030029340.1053@hixie.dreamhostps.com>
	<2c0e02830907021830u10f0494cye03c11c12b842cad@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907030610110.1053@hixie.dreamhostps.com>

On Fri, 3 Jul 2009, Silvia Pfeiffer wrote:
> > 
> > The codecs issue is being still actively worked on by a number of 
> > parties, as it has been for over a year now; the removal of the 
> > sections from the spec doesn't affect this. I still hold high hopes 
> > that one day we can find a solution to this that all vendors are 
> > willing to implement.
> 
> The bit that would be important to keep is the list of requirements on a 
> baseline codec.

The only real requirement is that all the relevant implementors be willing 
to ship support for the codec. I think pretty much everyone understand the 
requirements that the various parties have for that (though it varies 
from vendor to vendor).

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

From ian at hixie.ch  Thu Jul  2 23:21:05 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 3 Jul 2009 06:21:05 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A4D6405.6040409@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
Message-ID: <Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>

On Thu, 2 Jul 2009, Charles Pritchard wrote:
> 
> I'd like to see <canvas> support added to the <video> tag (it's as 
> natural as <img>).

<video> elements can be painted onto <canvas> elements already; did you 
have something more in mind?


> and enable the <audio> tag to accept raw data lpcm),
> just as the <canvas> tag accepts raw data (bitmap).

This is on the list of things to consider in a future version. At this 
point I don't really want to add new features yet because otherwise we'll 
never get the browser vendors caught up to implementing the same spec. :-)


> add raw pixel support to <video> (via CanvasRenderingContext2D).

Not really sure what this would look like. Can't you just do that with 
<canvas> already?


> And add an event handler when subtitles are enabled / disabled.

This is on the list for the next version. (Generally speaking, control 
over subtitles is one of the very next features that will be added.)


> > On Tue, 30 Jun 2009, Dr. Markus Walther wrote:
> >   
> > > > Having removed everything else in these sections, I figured there 
> > > > wasn't that much value in requiring PCM-in-Wave support. However, 
> > > > I will continue to work with browser vendors directly and try to 
> > > > get a common codec at least for audio, even if that is just 
> > > > PCM-in-Wave.
> 
> I'd think that FLAC would make more sense than PCM-in-Wave, as a PNG 
> analog.

I encourage you to suggest this straight to the relevant vendors. As it 
stands, HTML5 is codec-neutral.


> I'd like to see a font analog in audio as well. Canvas supports the font 
> attribute, audio could certainly support sound fonts. Use a generated 
> pitch if your platform can't or doesn't store sound fonts.

This seems like an issue for the CSS or SVG working groups, who are 
working on font-related technologies.


> "User agents should provide controls to enable the manual selection of 
> fallback content."

There's no reason the UA couldn't provide an override mechanism to select 
an alternative source if the UA vendor so desires.


> "User agents should provide an activation behavior, when fallback 
> content is required, detailing why the primary content could not be 
> used."

There's no reason why UAs can't do that now. The spec doesn't prohibit 
such UI.


> Many non-technical users will want to know why there is a black screen 
> (or still image), even though they can hear the audio.

This kind of situation is of course why we really want to have a common 
codec.

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

From mjs at apple.com  Fri Jul  3 01:07:37 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 03 Jul 2009 01:07:37 -0700
Subject: [whatwg] Some attributes are said to apply to "all elements"
Message-ID: <1832A59E-F9CD-4070-8A0D-FDB32D7A43A6@apple.com>


Some attributes are said to apply to "all elements" when I think "all  
HTML elements" was intended. Specifically this seems to be the case  
for accesskey, draggable, hidden and style, though I may have missed  
some.

  - Maciej


From mike at w3.org  Fri Jul  3 04:00:41 2009
From: mike at w3.org (Michael(tm) Smith)
Date: Fri, 3 Jul 2009 20:00:41 +0900
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <Pine.LNX.4.62.0907020443090.1060@hixie.dreamhostps.com>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
	<op.utlmgkuuidj3kv@simon-pieterss-macbook.local>
	<dd0fbad0905080742y6afc45e8x51642ef881addc2e@mail.gmail.com>
	<Pine.LNX.4.62.0906060230060.1648@hixie.dreamhostps.com>
	<op.uu3s6rb3ptj49s@aimac.local>
	<Pine.LNX.4.62.0907020443090.1060@hixie.dreamhostps.com>
Message-ID: <20090703110040.GF15201@sideshowbarker>

Ian Hickson <ian at hixie.ch>, 2009-07-02 04:44 +0000:

> On Sat, 6 Jun 2009, Kornel Lesinski wrote:
> > The purpose of <hgroup> is to imply that <hx> is a subtitle. That's quite an
> > indirection. An explicit element would be easier to understand:
> > 
> > <h1>Dr. Strangelove</h1>
> > <subheader>Or: How I Learned to Stop Worrying and Love the Bomb<subheader>
> > [...]
> 
> That would have been another option (it wouldn't handle multiple-level 
> subheadings well, but that's not a big deal), but I'm not really convinced 
> it's enough of an improvement to change the way the spec is written. It 
> also has poorer graceful degradation behaviour, IMHO.

FWIW, I can think of at least one precedent for something similar
to <hgroup> in a markup language: the ISO 12083 standard[1], which
has a <titlegrp> element.

  http://xml.coverpages.org/gen-apps.html#iso12083DTDs

I would suspect there are probably a number of other markup
languages out there that have something like it as well.

So while it might be something unusual in the context of HTML as
it is now, it's not so unusual in the context of markup languages
in general.

Whether to use something like <hgroup> or something like an
explicit <subtitle> element is a document-modeling design choice
that needs to be made by weighing whatever the priorities are for
users and implementors (or producers and consumers) of the
language, and by looking at whatever the combination of advantages
and disadvantages the choice brings to the users and implementors
of the language.

In the case of HTML, having more graceful degradation behavior
seems like an important advantage.

And it seems like introducing a new element like <subheading>
would have the disadvantage of complicating the heading hierarchy
and confusing authors about when and where to use <subheading>
versus using <h2> to <h6>, and also requiring that the spec detail
how to deal with cases like, e.g.:

  <h1>
    <h2>
    <subheading>

...or whatever. Yeah, we could spec the document-conformance rules
to disallow weird <h2>-<h6>/<subheading> combinations, but even
then, the spec would have to state what UAs are supposed to do
when authors don't follow the rules and throw in weird,
non-conformant combinations anyway.

So, on balance, <hgroup> seems like it hits the sweet spot pretty
well, as far as providing something that meets the various
requirements (e.g., a means to associate headings with
subheadings, without causing an inordinate amount of confusion to
authors, and without adding an inordinate amount of processing
complexity for implementors).

  --Mike

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

From herenvardo at gmail.com  Fri Jul  3 04:17:50 2009
From: herenvardo at gmail.com (Eduard Pascual)
Date: Fri, 3 Jul 2009 13:17:50 +0200
Subject: [whatwg] do not encourage use of small element for legal text
In-Reply-To: <4A4D09BB.7080008@awhlink.com>
References: <4A2818E3.7060800@awhlink.com> <4A28463D.2030501@mit.edu> 
	<4A2995B6.4020304@awhlink.com>
	<Pine.LNX.4.62.0907010409170.1060@hixie.dreamhostps.com> 
	<4A4CA2EB.40205@gmx.ch> <4A4D09BB.7080008@awhlink.com>
Message-ID: <6ea53250907030417r20736a4fq162b621207675746@mail.gmail.com>

First of all, let me start with a disclaimer: I am NOT a lawyer. Do
not take any of this post as legal advise, it is based only on common
sense and on some years of web authoring experience.

There are a few basic points to keep in mind:

- First: the <small> element has some purpose, and the HTML5 spec
needs to describe it, just like it describes that <p> is for
paragraphs and <img> is for images.
- Second: there are some kinds of legal text that are appropiate to
put within <small>, while there are some that aren't.
- Third: there is a very thin line between telling web authors which
tools are provided by the language to mark up different kinds of text
(such as legal text) and what would be legal advise about how to
include legal text on a website. We need a spec that does the former
but not the latter, and that's a real challenge.

Now, let me go through Andrew's last mail and I'll add my suggestion
based on all of this by the end of this mail.

On Thu, Jul 2, 2009 at 9:25 PM, Andrew W. Hagen<contact2009 at awhlink.com> wrote:
> The text from the current spec is, "Small print is typically
> legalese describing disclaimers, caveats, legal
> restrictions, or copyrights. Small print is also sometimes
> used for attribution."
>
> By suggesting it is typical, that implicitly encourages people
> to use small print for legal text.
Then it may be appropriate to remove the word "typical".

> One of HTML 5's design principles is to take the predominant
> practice of what people are doing on the web, and turn that
> into the standard that all HTML 5 authors should follow.
>
> Certain sections in the spec are normative or non-normative.
> It does not make sense for the HTML 5 spec to make a non-
> normative comment in a normative section. Furthermore, it is
> fallacious to argue that something is not "encouragement"
> but is "normative."
>
> Leaving any suggestion in the HTML 5 spec that legal text
> typically is, could be, or should be in small print could do
> a disservice to anyone reading the spec.
Then we should avoid referring to legal text as a whole, and simply
point out the most obvious cases where <small> is right or wrong,
maybe even encouraging authors to ask for legal advice for the not so
obvious cases.

> Take a hypothetical example. Joe is the owner-operator of
> SmallCo, a building contractor. Joe decides to create a web
> site for his business. Being technically proficient, he
> consults the HTML 5 web site. He reads how the <small>
> element is typically used for disclaimers, etc. On his one-
> page web site, he posts the following notice:
>
> <p>Your 100% satisfaction in the work of SmallCo is
> guaranteed. <small>Guarantee applies only to commercial
> buildings. </small></p>
>
> Joe gets a new customer from the web site. The customer has
> him build a residential house. Joe does the job. The work is
> done well, but the customer is not 100% satisfied. The
> customer wants various changes that Joe does not consider
> necessary. Joe and the customer have a serious dispute. The
> customer claims that $45,000 worth of work must be performed
> for the customer to be 100% satisfied. Joe claims that his
> obligations are already fulfiled, and the 100% satisfaction
> guarantee does not apply to the customer's job because his
> residential house is not a commercial building. They take
> their dispute to court.
>
> In this particular case, the disclaimer Joe posted on his
> web site becomes a hotly disputed issue. The judge takes
> special note that Joe had his disclaimer in small print. Due
> to the law of the particular jurisdiction they are in, Joe
> loses. Joe now must perform a great deal of work for no pay,
> or pay the customer $45,000 to hire another contractor. The
> financial fortunes of SmallCo and of Joe have taken a
> terrible turn for the worse. Joe feels like the HTML 5 spec
> gave him bad advice.
It's clear that, despite the spec would currently encourage this
example's markup, it is not a good choice. IMHO, either of these
should be used instead:
<p>Your 100% satisfaction in the work of SmallCo is guaranteed.
(Guarantee applies only to commercial buildings.)</p>
or
<small>Your 100% satisfaction in the work of SmallCo is guaranteed.
(Guarantee applies only to commercial buildings.)</small>
(In the second case, the disclaimer should be at least as enforceable
as the guarantee itself, because they are both in small print: either
they are both enforceable, or neither is; but again don't take my
words as legal advice).

> Whether legal text may properly appear in small print has
> been the subject of numerous lawsuits of greatly significant
> value, at least in American law. The implicit encouragement
> to use small print takes the lexicographical mandate of
> "seeing what people are doing on the web and then making
> that the standard" too far. It should be impossible for
> anyone reading a tech specification to think that they are
> getting legal advice. Yet that is not the case in the
> current HTML 5 spec.
There are *some* cases where small print can be appropriate. Since the
<small> element formal description says "The small element represents
small print or other side comments.", it should be appropriate for
such cases.
The best example here are copyright notices: since any work is
automatically protected by copyright on most countries, and it can be
registered for further protection without any requirement to include
such notices, the notice itself doesn't need any kind of
enforceability: the reader should already expect pages to be
copyrighted, and the (c) notices just provide a bit of extra detail
(such as year, copyright holder, and sometimes additional licensing
details).

> The current situation in the spec is really bad. As it reads
> currently, the spec encourages fraud. This should not be
> acceptable considering how much of a benefit HTML 5 will be
> otherwise.
Agreed.

> Additionally, the word "legalese" has a strongly negative
> connotation . Using the term "legalese" as a stand-in for
> any legal text implies that all legal text is suspicious or
> useless at best. The spec should not sit in judgment on the
> law. Espousing a vaguely anarchical political point of view
> is OK, but that should not be part of HTML 5.
I'm not sure if the word "legalese" was intended to refer to all kinds
of legal text, or just the "suspicios or useless" ones. In any case, a
more accurate wording would help.

> What should be done is to remove all references to the law,
> legalese, and such from the small element section. If people
> want to put something legal in a small element, let them
> make their own choice. Let them come up with that generally
> bad idea on their own, or perhaps in consultation with their
> own attorneys who can take responsibility for their error if
> the use of the small element causes some problem. What the
> law actually says will vary according to your jurisdiction.
I have to disagree here. There are still some forms of legal text that
would be at home within a <small> element, and the spec somehow needs
to describe that this would be allowed.

> The problem with a <legal> element would be that it does not
> correspond to any discrete set of text. If a web page
> becomes the subject of a court case, the court is likely to
> look at any part of the web page it thinks is relevant, not
> just the part contained in a <legal> element. Thus, the
> rationale for a <legal> element would not carry through to
> the real world. For example, the following would not result
> in an effective legal defense:
>
> <legal>SmallCo guarantees 100% satisfaction</legal>
> <small>except for residential buildings</small>
What about something like this?
<legal>SmallCo guarantees 100% satisfaction
<small>except for residential buildings</small></legal>
(Note that the <small> would still be inside <legal>).
Anyway, this probably depends on the final font size of the text, and
on the jurisdiction where it is evaluated, so <legal> actually solves
nothing.

> Furthermore, we should not create a <legal> element in
> anticipation that in the future at some undetermined point
> it is conceivable that some legislature will somehow connect
> the legal status of text on a web page to its appearance in
> a <legal> element. It's too speculative. That would prove
> unworkable anyway.
A <legal> element would add complexity to the spec without any
immediate benefit. Something like <p class="legal"> or <small
class="legal"> (depending on each case) would be equally descriptive
and works on current browsers.

> To sum up, legal text generally should not be in small print,
> because legal text is important and should be easy to read. The exact
> legal consequences of legal text in small print will vary
> depending on the facts of the case and on the jurisdiction.
> The HTML 5 spec should not make assertions, either normative
> or non-normative, about legal matters. The HTML 5 spec is
> going to be a terrific advance, and removing this thorn from
> its side will only improve it.
It looks like you are generalizing over the set of legal texts, rather
than the set of web documents. For what I have seen, the proportion of
legalese suitable for small print (such as copyright notices) is quite
higher in the web than in other contexts.

With all this, here is my specific suggestion:
First, leave the formal description "The small element represents
small print or other side comments." as is: IMHO it is accurate and
simple, and that's quite enough to ask from a spec.
Next, replace the note that reads "Small print is typically legalese
describing disclaimers, caveats, legal restrictions, or copyrights.
Small print is also sometimes used for attribution." with something
like this: "Small print is often used for *some* forms of legal text
and for attribution. Defining which kinds of legal text should be on
small print, however, is out of the scope of HTML."
This makes clear that HTML (technically) allows using <small> to put
legal text (or anything else) in small print, but it doesn't encourage
any specific usage of small print.

Regards,
Eduard Pascual

From kornel at geekhood.net  Fri Jul  3 04:58:50 2009
From: kornel at geekhood.net (Kornel)
Date: Fri, 3 Jul 2009 12:58:50 +0100
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <20090703110040.GF15201@sideshowbarker>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
	<op.utlmgkuuidj3kv@simon-pieterss-macbook.local>
	<dd0fbad0905080742y6afc45e8x51642ef881addc2e@mail.gmail.com>
	<Pine.LNX.4.62.0906060230060.1648@hixie.dreamhostps.com>
	<op.uu3s6rb3ptj49s@aimac.local>
	<Pine.LNX.4.62.0907020443090.1060@hixie.dreamhostps.com>
	<20090703110040.GF15201@sideshowbarker>
Message-ID: <EF925172-8BF4-481C-9942-EF4F81A31C25@geekhood.net>

On 3 Jul 2009, at 12:00, Michael(tm) Smith wrote:
>
> And it seems like introducing a new element like <subheading>
> would have the disadvantage of complicating the heading hierarchy
> and confusing authors about when and where to use <subheading>
> versus using <h2> to <h6>, and also requiring that the spec detail
> how to deal with cases like, e.g.:
>
>  <h1>
>    <h2>
>    <subheading>
>
> ...or whatever.

The rule could be simple: it doesn't change document outline, applies  
to single <hx> preceding it.

> Yeah, we could spec the document-conformance rules
> to disallow weird <h2>-<h6>/<subheading> combinations, but even
> then, the spec would have to state what UAs are supposed to do
> when authors don't follow the rules and throw in weird,
> non-conformant combinations anyway.

That applies to <hgroup> too. It too needs to handle weird  
combinations and non-conforming uses.

IMHO <hgroup> is more difficult to use and has potential to break  
document outline, so it would need more complicated error recovery  
than <subheading>.

> So, on balance, <hgroup> seems like it hits the sweet spot pretty
> well, as far as providing something that meets the various
> requirements (e.g., a means to associate headings with
> subheadings, without causing an inordinate amount of confusion to
> authors, and without adding an inordinate amount of processing
> complexity for implementors).

I disagree.

The discussion started because <hgroup> was difficult to understand  
and could be confused with <header>.

It increases complexity of document outline algorithm and authoring by  
changing meaning and rank of <hx> in context of <hgroup>.

-- 
regards, Kornel


From jjcogliati-whatwg at yahoo.com  Fri Jul  3 07:25:37 2009
From: jjcogliati-whatwg at yahoo.com (jjcogliati-whatwg at yahoo.com)
Date: Fri, 3 Jul 2009 07:25:37 -0700 (PDT)
Subject: [whatwg] Codecs for <audio> and <video>
Message-ID: <580384.77475.qm@web63202.mail.re1.yahoo.com>




--- On Mon, 6/29/09, Ian Hickson <ian at hixie.ch> wrote:

>  2. The remaining H.264 baseline patents owned by companies
> who are not 
> ? ? willing to license them royalty-free expire,
> leading to H.264 support 
> ? ? being available without license fees. =>
> H.264 becomes the de facto 
> ? ? codec for the Web.

This could be awhile.  I took the US patents listed on at:
http://www.mpegla.com/avc/avc-patentlist.cfm
in
http://www.mpegla.com/avc/avc-att1.pdf
and checked their expiration dates.
The last ones expires in 2028.  There maybe other patents that are not listed, and some that are listed may not actually be essential to the real date for H.264 being royalty free could be different.   

Here is the complete list:

Patent:  7,292,636 
Filed:  02 mar 2004  Granted:  06 nov 2007  Expiration:  02 mar 2024  Summary:  Using order value for processing a video picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,292,636 

Patent:  RE35,093 
Filed:  03 dec 1990  Granted:  09 mar 1993  Expiration:  03 dec 2010  Summary:  Systems and methods for coding even fields of interlaced video sequences  Notes:  Reissue of 05193004 filed 09 dec 1994 granted 21 nov 1995 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE35,093 

Patent:  7,388,916 
Filed:  07 jul 2001  Granted:  17 jun 2008  Expiration:  07 jul 2021  Summary:  Water ring scanning apparatus and method, and apparatus and method for encoding/decoding video sequences using the same  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,388,916 

Patent:  4,796,087 
Filed:  01 jun 1987  Granted:  03 jan 1989  Expiration:  01 jun 2007  Summary:  Process for coding by transformation for the transmission of picture signals  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=4,796,087 

Patent:  6,894,628 
Filed:  17 jul 2003  Granted:  17 may 2005  Expiration:  17 jul 2023  Summary:  Apparatus and methods for entropy-encoding or entropy-decoding using an initialization of context variables  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,894,628 

Patent:  6,900,748 
Filed:  17 jul 2003  Granted:  31 may 2005  Expiration:  17 jul 2023  Summary:  Method and apparatus for binarization and arithmetic coding of a data value  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,900,748 

Patent:  7,088,271 
Filed:  03 may 2005  Granted:  08 aug 2006  Expiration:  03 may 2025  Summary:  Method and apparatus for binarization and arithmetic coding of a data value  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,088,271 

Patent:  6,943,710 
Filed:  04 dec 2003  Granted:  13 sep 2005  Expiration:  04 dec 2023  Summary:  Method and arrangement for arithmetic encoding and decoding binary states and a corresponding computer program and a corresponding computer-readable storage medium  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,943,710 

Patent:  7,286,710 
Filed:  01 oct 2003  Granted:  23 oct 2007  Expiration:  01 oct 2023  Summary:  Coding of a syntax element contained in a pre-coded video signal  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,286,710 

Patent:  7,379,608 
Filed:  04 dec 2003  Granted:  27 may 2008  Expiration:  04 dec 2023  Summary:  Arithmetic coding for transforming video and picture data units  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,379,608 

Patent:  7,496,143 
Filed:  27 dec 2004  Granted:  24 feb 2009  Expiration:  27 dec 2024  Summary:  Method and arrangement for coding transform coefficients in picture and/or video coders and decoders and a corresponding computer program and a corresponding computer-readable storage medium  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,496,143 

Patent:  5,235,618 
Filed:  06 nov 1990  Granted:  10 aug 1993  Expiration:  06 nov 2010  Summary:  Video signal coding apparatus, coding method used in the video signal coding apparatus and video signal coding transmission system having the video signal coding apparatus  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,235,618 

Patent:  4,849,812 
Filed:  24 feb 1988  Granted:  18 jul 1989  Expiration:  24 feb 2008  Summary:  Television system in which digitized picture signals subjected to a transform coding are transmitted from an encoding station to a decoding station  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=4,849,812 

Patent:  5,021,879 
Filed:  24 sep 1990  Granted:  04 jun 1991  Expiration:  24 sep 2010  Summary:  System for transmitting video pictures  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,021,879 

Patent:  5,128,758 
Filed:  02 jun 1989  Granted:  07 jul 1992  Expiration:  02 jun 2009  Summary:  Method and apparatus for digitally processing a high definition television augmentation signal  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,128,758 

Patent:  5,179,442 
Filed:  26 nov 1990  Granted:  12 jan 1993  Expiration:  26 nov 2010  Summary:  Method and apparatus for digitally processing a high definition television augmentation signal  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,179,442 

Patent:  5,606,539 
Filed:  31 aug 1994  Granted:  25 feb 1997  Expiration:  31 aug 2014  Summary:  Method and apparatus for encoding and decoding an audio and/or video signal, and a record carrier for use with such apparatus  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,606,539 

Patent:  5,608,697 
Filed:  18 mar 1996  Granted:  04 mar 1997  Expiration:  18 mar 2016  Summary:  Record carrier containing an audio and/or video signal which has been encoded and includes a decoder delay time parameter indicating a time delay for one or more portions of the signal  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,608,697 

Patent:  5,844,867 
Filed:  09 sep 1996  Granted:  01 dec 1998  Expiration:  09 sep 2016  Summary:  Methods and apparatus for encoding and decoding an audio and/or video signal, and a record carrier used therewith or produced therefrom  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,844,867 

Patent:  5,699,476 
Filed:  09 may 1996  Granted:  16 dec 1997  Expiration:  09 may 2016  Summary:  Method and apparatus for transmitting and/or storing a series of hierarchically encoded digital image data blocks  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,699,476 

Patent:  5,740,310 
Filed:  28 jun 1994  Granted:  14 apr 1998  Expiration:  28 jun 2014  Summary:  Method of maintaining display continuity from a CD with slow-motion or freeze capability  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,740,310 

Patent:  RE40,177 
Filed:  24 aug 1999  Granted:  15 jul 2003  Expiration:  24 aug 2019  Summary:  Method and apparatus for filtering an image  Notes:  Reissue of 06594400 filed 11 apr 2005 granted 25 mar 2008 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE40,177 

Patent:  RE40,178 
Filed:  24 aug 1999  Granted:  15 jul 2003  Expiration:  24 aug 2019  Summary:  Method of filtering an image  Notes:  Reissue of 06594400 filed 11 apr 2005 granted 25 mar 2008 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE40,178 

Patent:  RE40,179 
Filed:  24 aug 1999  Granted:  15 jul 2003  Expiration:  24 aug 2019  Summary:  Method of image filtering based on successive pixels  Notes:  Reissue of 06594400 filed 11 apr 2005 granted 25 mar 2008 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE40,179 

Patent:  RE40,180 
Filed:  24 aug 1999  Granted:  15 jul 2003  Expiration:  24 aug 2019  Summary:  Method of filtering an image based on comparisons  Notes:  Reissue of 06594400 filed 11 apr 2005 granted 25 mar 2008 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE40,180 

Patent:  6,912,351 
Filed:  19 oct 1998  Granted:  28 jun 2005  Expiration:  19 oct 2018  Summary:  Method and device for condensed image recording and reproduction  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,912,351 

Patent:  7,403,663 
Filed:  31 oct 2007  Granted:  22 jul 2008  Expiration:  31 oct 2027  Summary:  Method and device for condensed image recording and reproduction  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,403,663 

Patent:  7,424,159 
Filed:  31 oct 2007  Granted:  09 sep 2008  Expiration:  31 oct 2027  Summary:  Method and device for condensed image recording and reproduction  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,424,159 

Patent:  7,433,525 
Filed:  22 dec 2004  Granted:  07 oct 2008  Expiration:  22 dec 2024  Summary:  Method and device for condensed image recording and reproduction  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,433,525 

Patent:  7,440,627 
Filed:  31 oct 2007  Granted:  21 oct 2008  Expiration:  31 oct 2027  Summary:  Method and device for condensed image recording and reproduction  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,440,627 

Patent:  7,447,367 
Filed:  30 aug 2007  Granted:  04 nov 2008  Expiration:  30 aug 2027  Summary:  Method and device for condensed image recording and reproduction  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,447,367 

Patent:  7,463,776 
Filed:  31 oct 2007  Granted:  09 dec 2008  Expiration:  31 oct 2027  Summary:  Method and device for condensed image recording and reproduction  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,463,776 

Patent:  7,233,621 
Filed:  06 jan 2003  Granted:  19 jun 2007  Expiration:  06 jan 2023  Summary:  Method of determining a motion vector for deriving motion vectors of bi-predictive block  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,233,621 

Patent:  7,262,886 
Filed:  04 jan 2007  Granted:  28 aug 2007  Expiration:  04 jan 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,262,886 

Patent:  7,277,593 
Filed:  04 jan 2007  Granted:  02 oct 2007  Expiration:  04 jan 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,277,593 

Patent:  7,289,682 
Filed:  09 feb 2007  Granted:  30 oct 2007  Expiration:  09 feb 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,289,682 

Patent:  7,359,569 
Filed:  28 jun 2007  Granted:  15 apr 2008  Expiration:  28 jun 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,359,569 

Patent:  7,391,921 
Filed:  28 jun 2007  Granted:  24 jun 2008  Expiration:  28 jun 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,391,921 

Patent:  7,391,922 
Filed:  07 aug 2007  Granted:  24 jun 2008  Expiration:  07 aug 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,391,922 

Patent:  7,394,945 
Filed:  07 aug 2007  Granted:  01 jul 2008  Expiration:  07 aug 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,394,945 

Patent:  7,397,965 
Filed:  19 oct 2007  Granted:  08 jul 2008  Expiration:  19 oct 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,397,965 

Patent:  7,403,667 
Filed:  29 aug 2007  Granted:  22 jul 2008  Expiration:  29 aug 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,403,667 

Patent:  7,437,015 
Filed:  29 aug 2007  Granted:  14 oct 2008  Expiration:  29 aug 2027  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,437,015 

Patent:  7,463,786 
Filed:  18 apr 2008  Granted:  09 dec 2008  Expiration:  18 apr 2028  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,463,786 

Patent:  7,492,959 
Filed:  18 apr 2008  Granted:  17 feb 2009  Expiration:  18 apr 2028  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,492,959 

Patent:  7,492,960 
Filed:  18 apr 2008  Granted:  17 feb 2009  Expiration:  18 apr 2028  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,492,960 

Patent:  7,496,239 
Filed:  18 apr 2008  Granted:  24 feb 2009  Expiration:  18 apr 2028  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,496,239 

Patent:  7,499,598 
Filed:  18 apr 2008  Granted:  03 mar 2009  Expiration:  18 apr 2028  Summary:  Method of reducing a blocking artifact when coding moving picture  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,499,598 

Patent:  6,563,953 
Filed:  30 nov 1998  Granted:  13 may 2003  Expiration:  30 nov 2018  Summary:  Predictive image compression using a single variable length code for both the luminance and chrominance blocks for each macroblock  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,563,953 

Patent:  6,735,345 
Filed:  19 mar 2003  Granted:  11 may 2004  Expiration:  19 mar 2023  Summary:  Efficient macroblock header coding for video compression  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,735,345 

Patent:  7,289,673 
Filed:  27 jul 2006  Granted:  30 oct 2007  Expiration:  27 jul 2026  Summary:  Decoding macroblock type and coded block pattern information  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,289,673 

Patent:  6,882,685 
Filed:  18 sep 2001  Granted:  19 apr 2005  Expiration:  18 sep 2021  Summary:  Block transform and quantization for image and video coding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,882,685 

Patent:  7,106,797 
Filed:  12 apr 2005  Granted:  12 sep 2006  Expiration:  12 apr 2025  Summary:  Block transform and quantization for image and video coding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,106,797 

Patent:  6,912,584 
Filed:  23 dec 2002  Granted:  28 jun 2005  Expiration:  23 dec 2022  Summary:  Media coding for loss recovery with remotely predicted data units  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,912,584 

Patent:  7,116,830 
Filed:  17 dec 2002  Granted:  03 oct 2006  Expiration:  17 dec 2022  Summary:  Spatial extrapolation of pixel values in intraframe video coding and decoding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,116,830 

Patent:  7,120,197 
Filed:  17 dec 2002  Granted:  10 oct 2006  Expiration:  17 dec 2022  Summary:  Motion compensation loop with filtering  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,120,197 

Patent:  7,263,232 
Filed:  01 feb 2006  Granted:  28 aug 2007  Expiration:  01 feb 2026  Summary:  Spatial extrapolation of pixel values in intraframe video coding and decoding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,263,232 

Patent:  7,149,247 
Filed:  22 jan 2003  Granted:  12 dec 2006  Expiration:  22 jan 2023  Summary:  Methods and systems for encoding and decoding video data to enable random access and splicing  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,149,247 

Patent:  7,162,091 
Filed:  31 mar 2003  Granted:  09 jan 2007  Expiration:  31 mar 2023  Summary:  Intra compression of pixel blocks using predicted mean  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,162,091 

Patent:  7,266,149 
Filed:  17 dec 2002  Granted:  04 sep 2007  Expiration:  17 dec 2022  Summary:  Sub-block transform coding of prediction residuals  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,266,149 

Patent:  7,505,485 
Filed:  22 jan 2003  Granted:  17 mar 2009  Expiration:  22 jan 2023  Summary:  Methods and systems for start code emulation prevention and data stuffing  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,505,485 

Patent:  5,926,225 
Filed:  24 nov 1997  Granted:  20 jul 1999  Expiration:  24 nov 2017  Summary:  Image coder which includes both a short-term frame memory and long-term frame memory in the local decoding loop  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,926,225 

Patent:  6,097,759 
Filed:  22 nov 1999  Granted:  01 aug 2000  Expiration:  22 nov 2019  Summary:  Image signal coding system  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,097,759 

Patent:  7,095,344 
Filed:  10 apr 2003  Granted:  22 aug 2006  Expiration:  10 apr 2023  Summary:  Digital signal encoding device, digital signal decoding device, digital signal arithmetic encoding method and digital signal arithmetic decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,095,344 

Patent:  7,388,526 
Filed:  03 may 2007  Granted:  17 jun 2008  Expiration:  03 may 2027  Summary:  Digital signal coding apparatus, digital signal decoding apparatus, digital signal arithmetic coding method and digital signal arithmetic decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,388,526 

Patent:  7,408,488 
Filed:  23 jul 2007  Granted:  05 aug 2008  Expiration:  23 jul 2027  Summary:  Digital signal coding apparatus, digital signal decoding apparatus, digital signal arithmetic coding method and digital signal arithmetic decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,408,488 

Patent:  7,346,216 
Filed:  10 sep 2003  Granted:  18 mar 2008  Expiration:  10 sep 2023  Summary:  Video encoding method, video decoding method, video encoding apparatus, video decoding apparatus, video encoding program, and video decoding program  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,346,216 

Patent:  RE35,910 
Filed:  11 may 1990  Granted:  12 may 1992  Expiration:  11 may 2010  Summary:  Moving image signal encoding apparatus and decoding apparatus  Notes:  Reissue of 05113255 filed 12 may 1994 granted 29 sep 1998 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE35,910 

Patent:  5,223,949 
Filed:  17 apr 1992  Granted:  29 jun 1993  Expiration:  17 apr 2012  Summary:  Coding means for a signal processing system  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,223,949 

Patent:  6,608,939 
Filed:  18 may 2001  Granted:  19 aug 2003  Expiration:  18 may 2021  Summary:  Image encoder  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,608,939 

Patent:  6,658,152 
Filed:  04 dec 2001  Granted:  02 dec 2003  Expiration:  04 dec 2021  Summary:  Image coding apparatus and an image decoding apparatus  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,658,152 

Patent:  6,681,048 
Filed:  20 dec 2001  Granted:  20 jan 2004  Expiration:  20 dec 2021  Summary:  Image coding apparatus and an image decoding apparatus  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,681,048 

Patent:  6,373,856 
Filed:  15 sep 1998  Granted:  16 apr 2002  Expiration:  15 sep 2018  Summary:  Communications system for transmission of multimedia digital data and a method therefor  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,373,856 

Patent:  6,445,739 
Filed:  29 sep 1998  Granted:  03 sep 2002  Expiration:  29 sep 2018  Summary:  Quantization matrix for still and moving picture coding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,445,739 

Patent:  6,501,793 
Filed:  16 may 2001  Granted:  31 dec 2002  Expiration:  16 may 2021  Summary:  Quantization matrix for still and moving picture coding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,501,793 

Patent:  6,954,157 
Filed:  21 apr 2005  Granted:  11 oct 2005  Expiration:  21 apr 2025  Summary:  Variable length coding method and variable length decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,954,157 

Patent:  6,967,600 
Filed:  09 dec 2003  Granted:  22 nov 2005  Expiration:  09 dec 2023  Summary:  Variable length coding method and variable length decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,967,600 

Patent:  7,312,731 
Filed:  06 oct 2006  Granted:  25 dec 2007  Expiration:  06 oct 2026  Summary:  Variable length coding method and variable length decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,312,731 

Patent:  6,992,605 
Filed:  21 apr 2005  Granted:  31 jan 2006  Expiration:  21 apr 2025  Summary:  Variable length coding method and variable length decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,992,605 

Patent:  7,088,269 
Filed:  24 feb 2005  Granted:  08 aug 2006  Expiration:  24 feb 2025  Summary:  Variable-length encoding method, variable-length decoding method, storage medium, variable-length encoding device, variable-length decoding device, and bit stream  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,088,269 

Patent:  7,095,896 
Filed:  27 mar 2003  Granted:  22 aug 2006  Expiration:  27 mar 2023  Summary:  Image encoding method and image decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,095,896 

Patent:  7,305,134 
Filed:  15 jun 2006  Granted:  04 dec 2007  Expiration:  15 jun 2026  Summary:  Picture coding method and picture decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,305,134 

Patent:  7,308,143 
Filed:  15 jun 2006  Granted:  11 dec 2007  Expiration:  15 jun 2026  Summary:  Picture coding method and picture decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,308,143 

Patent:  7,308,144 
Filed:  15 jun 2006  Granted:  11 dec 2007  Expiration:  15 jun 2026  Summary:  Picture coding method and picture decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,308,144 

Patent:  7,308,149 
Filed:  15 jun 2006  Granted:  11 dec 2007  Expiration:  15 jun 2026  Summary:  Picture coding method and picture decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,308,149 

Patent:  7,126,989 
Filed:  11 sep 2002  Granted:  24 oct 2006  Expiration:  11 sep 2022  Summary:  Image coding method and image decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,126,989 

Patent:  7,167,591 
Filed:  10 apr 2003  Granted:  23 jan 2007  Expiration:  10 apr 2023  Summary:  Image encoding method and image decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,167,591 

Patent:  7,218,787 
Filed:  26 oct 2006  Granted:  15 may 2007  Expiration:  26 oct 2026  Summary:  Picture coding method and picture decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,218,787 

Patent:  7,184,598 
Filed:  15 jun 2006  Granted:  27 feb 2007  Expiration:  15 jun 2026  Summary:  Picture coding method and picture decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,184,598 

Patent:  7,206,347 
Filed:  07 jul 2003  Granted:  17 apr 2007  Expiration:  07 jul 2023  Summary:  Image coding method and image decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,206,347 

Patent:  7,209,520 
Filed:  02 oct 2002  Granted:  24 apr 2007  Expiration:  02 oct 2022  Summary:  Moving picture encoding method and moving picture decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,209,520 

Patent:  7,305,035 
Filed:  16 apr 2003  Granted:  04 dec 2007  Expiration:  16 apr 2023  Summary:  Variable length encoding method and variable length decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,305,035 

Patent:  7,327,788 
Filed:  28 apr 2003  Granted:  05 feb 2008  Expiration:  28 apr 2023  Summary:  Motion vector derivation method, dynamic image encoding method, and dynamic image decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,327,788 

Patent:  7,362,807 
Filed:  08 jan 2003  Granted:  22 apr 2008  Expiration:  08 jan 2023  Summary:  Motion vector coding method and motion vector decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,362,807 

Patent:  7,411,526 
Filed:  31 jul 2006  Granted:  12 aug 2008  Expiration:  31 jul 2026  Summary:  Variable length coding method and variable length decoding method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,411,526 

Patent:  5,384,849 
Filed:  18 may 1993  Granted:  24 jan 1995  Expiration:  18 may 2013  Summary:  Apparatus and method for encoding/decoding data including the suppression of blocking artifacts  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,384,849 

Patent:  5,467,086 
Filed:  18 jun 1993  Granted:  14 nov 1995  Expiration:  18 jun 2013  Summary:  Apparatus and method of coding/decoding video data  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,467,086 

Patent:  5,654,706 
Filed:  18 dec 1996  Granted:  05 aug 1997  Expiration:  18 dec 2016  Summary:  System for variable length decoding digital transmission data which has been compressed by selecting a scanning pattern  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,654,706 

Patent:  6,680,975 
Filed:  02 nov 2000  Granted:  20 jan 2004  Expiration:  02 nov 2020  Summary:  Signal encoding and decoding system and method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,680,975 

Patent:  7,292,657 
Filed:  03 jul 2003  Granted:  06 nov 2007  Expiration:  03 jul 2023  Summary:  Signal compressing signal  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,292,657 

Patent:  6,646,578 
Filed:  22 nov 2002  Granted:  11 nov 2003  Expiration:  22 nov 2022  Summary:  Context adaptive variable length decoding system and method  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,646,578 

Patent:  7,050,504 
Filed:  05 dec 2002  Granted:  23 may 2006  Expiration:  05 dec 2022  Summary:  Low-complexity deblocking filter  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,050,504 

Patent:  7,227,901 
Filed:  21 nov 2002  Granted:  05 jun 2007  Expiration:  21 nov 2022  Summary:  Low-complexity deblocking filter  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,227,901 

Patent:  7,400,681 
Filed:  28 nov 2003  Granted:  15 jul 2008  Expiration:  28 nov 2023  Summary:  Low-complexity motion vector prediction for video codec with two lists of reference pictures  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,400,681 

Patent:  6,510,554 
Filed:  27 apr 1998  Granted:  21 jan 2003  Expiration:  27 apr 2018  Summary:  Method for generating information sub-streams for FF/REW applications  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,510,554 

Patent:  7,106,795 
Filed:  30 sep 2002  Granted:  12 sep 2006  Expiration:  30 sep 2022  Summary:  Systems and methods for enabling reduced bit-depth processing and memory reduction in video-related data processing  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,106,795 

Patent:  7,123,655 
Filed:  02 may 2002  Granted:  17 oct 2006  Expiration:  02 may 2022  Summary:  Method for reduced bit-depth quantization  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,123,655 

Patent:  7,130,348 
Filed:  30 sep 2002  Granted:  31 oct 2006  Expiration:  30 sep 2022  Summary:  Systems and methods for reduced bit-depth processing in video-related data  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,130,348 

Patent:  7,170,942 
Filed:  20 dec 2002  Granted:  30 jan 2007  Expiration:  20 dec 2022  Summary:  Systems and methods for efficient video-related data processing  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,170,942 

Patent:  7,340,102 
Filed:  08 dec 2006  Granted:  04 mar 2008  Expiration:  08 dec 2026  Summary:  Decoding apparatus using tool information for constructing a decoding algorithm  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,340,102 

Patent:  7,352,812 
Filed:  29 mar 2002  Granted:  01 apr 2008  Expiration:  29 mar 2022  Summary:  Method and apparatus for controlling loop filtering or post filtering in block based motion compensationed video coding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,352,812 

Patent:  7,386,048 
Filed:  31 mar 2003  Granted:  10 jun 2008  Expiration:  31 mar 2023  Summary:  Methods and systems for image intra-prediction mode organization  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,386,048 

Patent:  5,933,541 
Filed:  16 aug 1996  Granted:  03 aug 1999  Expiration:  16 aug 2016  Summary:  Method for processing decoded picture blocks in a block-based method of picture coding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,933,541 

Patent:  6,115,503 
Filed:  03 jul 1997  Granted:  05 sep 2000  Expiration:  03 jul 2017  Summary:  Method and apparatus for reducing coding artifacts of block-based image encoding and object-based image encoding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,115,503 

Patent:  RE37,222 
Filed:  12 oct 1990  Granted:  21 jul 1992  Expiration:  12 oct 2010  Summary:  Video signal transmitting system  Notes:  Reissue of 05132792 filed 19 jul 1994 granted 12 jun 2001 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE37,222 

Patent:  4,864,393 
Filed:  31 may 1988  Granted:  05 sep 1989  Expiration:  31 may 2008  Summary:  Motion vector estimation in television images  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=4,864,393 

Patent:  5,510,840 
Filed:  15 may 1995  Granted:  23 apr 1996  Expiration:  15 may 2015  Summary:  Methods and devices for encoding and decoding frame signals and recording medium therefor  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,510,840 

Patent:  5,539,466 
Filed:  26 sep 1994  Granted:  23 jul 1996  Expiration:  26 sep 2014  Summary:  Efficient coding apparatus for picture signal and decoding apparatus therefor  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,539,466 

Patent:  6,160,849 
Filed:  30 may 1995  Granted:  12 dec 2000  Expiration:  30 may 2015  Summary:  Selectable field and frame based predictive video coding  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,160,849 

Patent:  5,930,395 
Filed:  25 oct 1996  Granted:  27 jul 1999  Expiration:  25 oct 2016  Summary:  Moving-picture signal coding and/or decoding system resistant to transmission error  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=5,930,395 

Patent:  6,353,681 
Filed:  23 dec 1999  Granted:  05 mar 2002  Expiration:  23 dec 2019  Summary:  Computer system for realizing coding function having improved error resilience  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,353,681 

Patent:  6,408,098 
Filed:  23 dec 1999  Granted:  18 jun 2002  Expiration:  23 dec 2019  Summary:  Moving-picture signal for use in a coding apparatus for transmitting image information  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,408,098 

Patent:  6,571,361 
Filed:  16 sep 1998  Granted:  27 may 2003  Expiration:  16 sep 2018  Summary:  Encoder and decoder  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,571,361 

Patent:  7,321,995 
Filed:  09 apr 2003  Granted:  22 jan 2008  Expiration:  09 apr 2023  Summary:  Coding system and decoding system  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,321,995 

Patent:  6,621,931 
Filed:  29 jan 2002  Granted:  16 sep 2003  Expiration:  29 jan 2022  Summary:  Moving-picture signal coding and/or decoding system resistant to transmission error  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,621,931 

Patent:  RE34,965 
Filed:  18 jan 1990  Granted:  15 jan 1991  Expiration:  18 jan 2010  Summary:  Inter-frame predictive encoding system with encoded and transmitted prediction error  Notes:  Reissue of 04985768 filed 14 jan 1993 granted 13 jun 1995 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE34,965 

Patent:  RE35,158 
Filed:  26 apr 1990  Granted:  01 jan 1991  Expiration:  26 apr 2010  Summary:  Apparatus for adaptive inter-frame predictive encoding of video signal  Notes:  Reissue of 04982285 filed 28 dec 1992 granted 20 feb 1996 http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=RE35,158 

Patent:  7,020,200 
Filed:  13 aug 2002  Granted:  28 mar 2006  Expiration:  13 aug 2022  Summary:  System and method for direct motion vector prediction in bi-predictive video frames and fields  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=7,020,200 

Patent:  6,862,043 
Filed:  02 feb 1999  Granted:  01 mar 2005  Expiration:  02 feb 2019  Summary:  Device for converting video format  Notes:   http://patft1.uspto.gov/netacgi/nph-Parser?patentnumber=6,862,043 

Josh Cogliati
http://jjc.freeshell.org/

From agl at chromium.org  Fri Jul  3 09:54:12 2009
From: agl at chromium.org (Adam Langley)
Date: Fri, 3 Jul 2009 09:54:12 -0700
Subject: [whatwg] MathML in non-XML documents
Message-ID: <a84d7bc60907030954y7535c72atac6fafb5b8ec73ac@mail.gmail.com>

>From my reading of the spec, it appears that MathML embedded in HTML
documents (not just XHTML) is intended to work?
(http://www.whatwg.org/specs/web-apps/current-work/#mathml)

I.e. something like the following snippet should render as math?

<body>
  <math>
    <msup>
      <mi>x</mi>
      <mn>2</mn>
    </msup>
  </math>
</body>

Is my interpretation correct? (Note, I'm not questioning browser
support for the above, which I believe is non-existent).


Cheers

AGL

From narendra.sisodiya at gmail.com  Fri Jul  3 10:11:51 2009
From: narendra.sisodiya at gmail.com (narendra sisodiya)
Date: Fri, 3 Jul 2009 22:41:51 +0530
Subject: [whatwg] Open Slide Format
Message-ID: <e3fb97f30907031011x39f8eed5tb2aa5281a944a719@mail.gmail.com>

Dear All,
   I am looking for open slide format or a format which is can be standard
for slides on web. I am working on a project where i am creating on
slideshows and editor. I am currently i am mainly looking into s5 type of
format which use id , class and other attribute to send slide information.
Moreover there are some  more issues like uniform display of slides, because
html is just rendered depends on browser.
What is your opinion on this. If you want to checkout the complete project
specification you can click here -- http://eduvid.techfandu.org/

-- 
???????????????????????????
?    Narendra Sisodiya ( ???????? ???????? )
?    R&D Engineer
?    Web : http://narendra.techfandu.org
?    Twitter : http://tinyurl.com/dz7e4a
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090703/20ae2dab/attachment.htm>

From jackalmage at gmail.com  Fri Jul  3 10:19:28 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 3 Jul 2009 12:19:28 -0500
Subject: [whatwg] MathML in non-XML documents
In-Reply-To: <a84d7bc60907030954y7535c72atac6fafb5b8ec73ac@mail.gmail.com>
References: <a84d7bc60907030954y7535c72atac6fafb5b8ec73ac@mail.gmail.com>
Message-ID: <dd0fbad0907031019j1616687ah1e225682c221f20a@mail.gmail.com>

On Fri, Jul 3, 2009 at 11:54 AM, Adam Langley<agl at chromium.org> wrote:
> >From my reading of the spec, it appears that MathML embedded in HTML
> documents (not just XHTML) is intended to work?
> (http://www.whatwg.org/specs/web-apps/current-work/#mathml)
>
> I.e. something like the following snippet should render as math?
>
> <body>
> ?<math>
> ? ?<msup>
> ? ? ?<mi>x</mi>
> ? ? ?<mn>2</mn>
> ? ?</msup>
> ?</math>
> </body>
>
> Is my interpretation correct? (Note, I'm not questioning browser
> support for the above, which I believe is non-existent).

Yup, MathML (and SVG, for that matter) are intended to be usable in
HTML documents, not just XHTML.  That's why we have implicit
namespacing and such.

~TJ

From bzbarsky at MIT.EDU  Fri Jul  3 10:38:05 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 03 Jul 2009 10:38:05 -0700
Subject: [whatwg] MathML in non-XML documents
In-Reply-To: <a84d7bc60907030954y7535c72atac6fafb5b8ec73ac@mail.gmail.com>
References: <a84d7bc60907030954y7535c72atac6fafb5b8ec73ac@mail.gmail.com>
Message-ID: <4A4E41FD.3020406@mit.edu>

Adam Langley wrote:
>>From my reading of the spec, it appears that MathML embedded in HTML
> documents (not just XHTML) is intended to work?
> (http://www.whatwg.org/specs/web-apps/current-work/#mathml)
> 
> I.e. something like the following snippet should render as math?
> 
> <body>
>   <math>
>     <msup>
>       <mi>x</mi>
>       <mn>2</mn>
>     </msup>
>   </math>
> </body>
> 
> Is my interpretation correct?

I believe so, yes.

> (Note, I'm not questioning browser support for the above, which I believe is non-existent).

The above is actually supported in current nightly builds of Firefox if 
you set the "html5.enable" preference to true so that you're using the 
new parser.  I can provide screenshots on request if desired.  ;)

-Boris


From ian at hixie.ch  Fri Jul  3 12:18:15 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 3 Jul 2009 19:18:15 +0000 (UTC)
Subject: [whatwg] Question on (new) header and hgroup
In-Reply-To: <EF925172-8BF4-481C-9942-EF4F81A31C25@geekhood.net>
References: <op.utkfcvf1h8on37@bruce-pc> <4A02FF7D.5070301@opera.com>
	<op.utk0rj2bidj3kv@simon-pieterss-macbook.local>
	<op.utlmgkuuidj3kv@simon-pieterss-macbook.local>
	<dd0fbad0905080742y6afc45e8x51642ef881addc2e@mail.gmail.com>
	<Pine.LNX.4.62.0906060230060.1648@hixie.dreamhostps.com>
	<op.uu3s6rb3ptj49s@aimac.local>
	<Pine.LNX.4.62.0907020443090.1060@hixie.dreamhostps.com>
	<20090703110040.GF15201@sideshowbarker>
	<EF925172-8BF4-481C-9942-EF4F81A31C25@geekhood.net>
Message-ID: <Pine.LNX.4.62.0907031914390.1053@hixie.dreamhostps.com>

On Fri, 3 Jul 2009, Kornel wrote:
> On 2 Jul 2009, at 05:44, Ian Hickson wrote:
> > That would have been another option (it wouldn't handle multiple-level 
> > subheadings well, but that's not a big deal), but I'm not really 
> > convinced it's enough of an improvement to change the way the spec is 
> > written. It also has poorer graceful degradation behaviour, IMHO.
> 
> I expect it will be used between <hx> and <p>, both of which are block 
> elements, so it will render fine in HTML 4 browsers. Default styling 
> won't be perfect, but default font size of headers isn't good for 
> subheaders either.

Since HTML5 allows phrasing content in between flow content, I don't think 
we should rely on this. This kind of thing will be common:

   <header>
    <hgroup>
     <h1>My Wonderful Blog</h1>
     <h2>Witty comment goes here</h2>
    </hgroup>
    Last update: <time>2009-01-01</time>
   </header>

...which wouldn't degrade well with <subheading>


> It won't break document outline in older browsers, unlike multiple 
> headers in <hgroup>.

I don't think that's a particularly big concern, since outlines are rarely 
made today.


On Fri, 3 Jul 2009, Kornel wrote:
> 
> IMHO <hgroup> is more difficult to use and has potential to break 
> document outline, so it would need more complicated error recovery than 
> <subheading>.

In practice defining <hgroup> was actually pretty easy. (I don't think 
<subheading> would be particularly hard either.)


> The discussion started because <hgroup> was difficult to understand and 
> could be confused with <header>.
> 
> It increases complexity of document outline algorithm and authoring by 
> changing meaning and rank of <hx> in context of <hgroup>.

Both options have their disadvantages, certainly.

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

From ian at hixie.ch  Fri Jul  3 12:59:39 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 3 Jul 2009 19:59:39 +0000 (UTC)
Subject: [whatwg] Open Slide Format
In-Reply-To: <e3fb97f30907031011x39f8eed5tb2aa5281a944a719@mail.gmail.com>
References: <e3fb97f30907031011x39f8eed5tb2aa5281a944a719@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907031958120.1053@hixie.dreamhostps.com>

On Fri, 3 Jul 2009, narendra sisodiya wrote:
>
>   I am looking for open slide format or a format which is can be 
> standard for slides on web. I am working on a project where i am 
> creating on slideshows and editor. I am currently i am mainly looking 
> into s5 type of format which use id , class and other attribute to send 
> slide information. Moreover there are some more issues like uniform 
> display of slides, because html is just rendered depends on browser. 
> What is your opinion on this. If you want to checkout the complete 
> project specification you can click here -- http://eduvid.techfandu.org/

You can use HTML5 to do this (one <section> per slide), but as you say, it 
might not be the most reliable solution, at least not compared to 
dedicated formats like Keynote or ODF's presentation format. The latter 
may be the better choice.

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

From robert at ocallahan.org  Fri Jul  3 19:21:29 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Sat, 4 Jul 2009 14:21:29 +1200
Subject: [whatwg] MathML in non-XML documents
In-Reply-To: <4A4E41FD.3020406@mit.edu>
References: <a84d7bc60907030954y7535c72atac6fafb5b8ec73ac@mail.gmail.com>
	<4A4E41FD.3020406@mit.edu>
Message-ID: <11e306600907031921x1924fbc5g1142853bec87b57@mail.gmail.com>

On Sat, Jul 4, 2009 at 5:38 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> The above is actually supported in current nightly builds of Firefox if you
> set the "html5.enable" preference to true so that you're using the new
> parser.  I can provide screenshots on request if desired.  ;)
>

Yeah, Adam's example renders correctly using the HTML5 parser (thanks
Henri!).

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/20090704/d6f2ddca/attachment.htm>

From agl at chromium.org  Sat Jul  4 13:33:20 2009
From: agl at chromium.org (Adam Langley)
Date: Sat, 4 Jul 2009 13:33:20 -0700
Subject: [whatwg] MathML in non-XML documents
In-Reply-To: <11e306600907031921x1924fbc5g1142853bec87b57@mail.gmail.com>
References: <a84d7bc60907030954y7535c72atac6fafb5b8ec73ac@mail.gmail.com>
	<4A4E41FD.3020406@mit.edu>
	<11e306600907031921x1924fbc5g1142853bec87b57@mail.gmail.com>
Message-ID: <a84d7bc60907041333t290eb96ay403ffd5a8621bc59@mail.gmail.com>

On Fri, Jul 3, 2009 at 7:21 PM, Robert O'Callahan<robert at ocallahan.org> wrote:
> Yeah, Adam's example renders correctly using the HTML5 parser (thanks
> Henri!).

Thanks for the information all and it's great to know that Firefox
supports this now (modulo a config option).

I'll see what I can do about WebKit support for the same.


Cheers

AGL

From bijumaillist at gmail.com  Sat Jul  4 13:55:32 2009
From: bijumaillist at gmail.com (Biju)
Date: Sat, 4 Jul 2009 16:55:32 -0400
Subject: [whatwg] Need UNIFIED UI for web browser plugin security settings.
Message-ID: <4a27dd80907041355v118ad52fua2ce26095a40c698@mail.gmail.com>

A web browser with plugin is supposed to work as a seamless integrated
single system.
But they are not for security setting UI. Each comes up with their own
UI to confuse users.

Example:-
1. Adobe PDF reader
I have disabled "mailto" URL handler in my firefox setting.
But if click "mailto" URL in an embedded PDF on a webpage viewed using
an Adobe PDF reader plugin, it launches.

2. OpenOffice.org
Firefox by default disabled file:// URL from a internet/intranet webpage.
But a file URL from a link on an embedded OpenOffice document will launch.
OOo will even launch a file:// URL for an EXECUTABLE.
Will it launch remote http:// URL for an executable, I need to check it.

3. Adobe Flash player
Flash player comes with a cute little screen for security control.
So if a child is browsing a site with flash,
it is very tentative for them to change setting if the security control popsup.


4. Sun Java
Java comes with MODAL security settings screen.
Asking "Do you trust?" like the MicroSoft ActiveX
With no indication for what to trust.
And people always press the easy button without reading fully on a MODAL screen.

So in browsers, we need a UNIFIED UI for plugin security settings.
1. Plugin makers should use browser UI, and not their own.
2. It should not be cute.
3. It should not be MODAL
4. It must be specific.
5. It should explain what site is can/about to do.

Here is sample of possible options
1. Do you want to allow www.example.com to read local files
   [ ] No
   [ ] Just c:\file\path\filename.ext
   [ ] Any file under folder c:\file\  <change folder>
          [ ] remember settings

2. Do you want to allow www.example.com to write on local drive
   [ ] No
   [ ] Just c:\file\path\filename.ext
   [ ] Any file under folder c:\file\  <change folder>
          [ ] remember settings

3. Do you want to allow www.example.com to access camera
   [ ] No
   [ ] Still picture
   [ ] take Video

   Which cameras
      [ ] camera 1
      [ ] camera 2
      [ ] camera 3

          [ ] remember settings


4. Do you want to allow www.example.com to access Microphone
   [ ] No
   [ ] Yes
          [ ] remember settings


5. Do you want to allow application from www.example.com to access
other sites, including intranet
   [ ] No
   [ ] Yes
          [ ] remember settings


6. Do you want to allow application from www.example.com to run on
your system like a server, ie by accessing the system TCP/IP port
   [ ] No
   [ ] Yes
          [ ] remember settings

From ian at hixie.ch  Sun Jul  5 13:51:11 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 5 Jul 2009 20:51:11 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>

On Sun, 5 Jul 2009, Eric Flores wrote:
> 
> I agree with 80% of your reponses to the Codecs for <audio> and <video> 
> conversation. However, I think that you are underestimating the 
> influencing power of the spec with regarding to available hardware 
> support. Hardcoding a spec in hardware is a very expensive and time 
> consuming proposition. Chipmakers do not see an incentive to add a spec 
> to their chips if they do not have guidance that provides them a 
> roadmap. Even if some of the browsers choose not to follow the spec, it 
> is good for everybody to have clarity on what is the recommended roadmap 
> (whatever roadmap is decided).

The point is that there is no decided roadmap.


> On the other side, I'm firmly convinced that some vested interest could
> lobby and even pay the chipmakers for having them not adding support to Ogg.
> This is a free market, isn't it?

As you say, it's a free market. If people want Theora chips, then it's 
likely that they will become available. For that to happen there has to be 
some demand for Theora support, though, which the spec's can't generate.


> Definitively not as important as the above, I also have some 
> reservations whenever you talk about alignment of 'all the players'. Are 
> you really expecting agreements from ALL the players? Or just the big 
> ones? I assume that you are disregarding the smallish browsers, aren't 
> you?

I'm talking primarily about the browser vendors who take part in this 
mailing list's discussions and have stated an opinion, regardless of size.


> Finally, it looks like Dirac looks worth discussing. I hope that their 
> proponents do not drop the ball.

Agreed.

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

From sam.kuper at uclmail.net  Sun Jul  5 14:27:09 2009
From: sam.kuper at uclmail.net (Sam Kuper)
Date: Sun, 5 Jul 2009 22:27:09 +0100
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
Message-ID: <4126b3450907051427t40d2e8c9rdb417816500efd0@mail.gmail.com>

2009/7/5 Ian Hickson <ian at hixie.ch>
> On Sun, 5 Jul 2009, Eric Flores wrote:
> [...]
> > On the other side, I'm firmly convinced that some vested interest could
> > lobby and even pay the chipmakers for having them not adding support to Ogg.
> > This is a free market, isn't it?
>
> As you say, it's a free market. If people want Theora chips, then it's
> likely that they will become available. For that to happen there has to be
> some demand for Theora support, though, which the spec's can't generate.

I think that if Theora support is recommended in HTML5, this *will*
generate demand, since content producers and (most) browser vendors
alike will take advantage of it. Chips may well, in that scenario,
become available.

Sam

From ian at hixie.ch  Sun Jul  5 14:31:27 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 5 Jul 2009 21:31:27 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <4126b3450907051427t40d2e8c9rdb417816500efd0@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<4126b3450907051427t40d2e8c9rdb417816500efd0@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907052130480.1053@hixie.dreamhostps.com>

On Sun, 5 Jul 2009, Sam Kuper wrote:
> 2009/7/5 Ian Hickson <ian at hixie.ch>
> > On Sun, 5 Jul 2009, Eric Flores wrote:
> > [...]
> > > On the other side, I'm firmly convinced that some vested interest could
> > > lobby and even pay the chipmakers for having them not adding support to Ogg.
> > > This is a free market, isn't it?
> >
> > As you say, it's a free market. If people want Theora chips, then it's
> > likely that they will become available. For that to happen there has to be
> > some demand for Theora support, though, which the spec's can't generate.
> 
> I think that if Theora support is recommended in HTML5, this *will* 
> generate demand, since content producers and (most) browser vendors 
> alike will take advantage of it. Chips may well, in that scenario, 
> become available.

Most browser vendors are already implementing Theora, and content 
producers will use whatever the browser vendors support, regardless of 
whether it's in the spec or not.

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

From robert at ocallahan.org  Sun Jul  5 15:41:45 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 6 Jul 2009 10:41:45 +1200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
Message-ID: <11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>

On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson <ian at hixie.ch> wrote:

> For that to happen there has to be
> some demand for Theora support, though, which the spec's can't generate.
>

Specs do generate demand --- by creating author expectation that a feature
will be supported, by adding a well-known brand, and because test suites get
created which vendors then compete on.

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/20090706/3f09660e/attachment.htm>

From mjs at apple.com  Sun Jul  5 16:00:57 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Sun, 05 Jul 2009 16:00:57 -0700
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
Message-ID: <59B9568B-18E5-4BA4-800C-FCC47049EC1D@apple.com>


On Jul 5, 2009, at 3:41 PM, Robert O'Callahan wrote:

> On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson <ian at hixie.ch> wrote:
> For that to happen there has to be
> some demand for Theora support, though, which the spec's can't  
> generate.
>
> Specs do generate demand --- by creating author expectation that a  
> feature will be supported, by adding a well-known brand, and because  
> test suites get created which vendors then compete on.

For H.264, a lot of the demand was created by the initial ISO/ITU  
standard and the follow-on standards for hardware products such as HD  
video disc players, set-to boxes and mobile phones. This was actually  
considerably earlier than H.264 deployment on the Web. For Microsoft's  
WMV to participate in some of the same markets, it had to go through a  
formal standards process, becoming SMPTE VC-1. SMPTE has also  
standardized Dirac Pro (a subset with no interframe compression) as  
VC-2.

A spec for Theora through a formal standards process might more  
effectively focus latent demand than a mention in the HTML spec. It  
would also greatly clarify the patent situation, since many holders of  
wide-ranging patents on video compression participate in these groups.  
I've asked the Xiph folks if they'd be willing to take Theora to an  
organization such as SMPTE.[1]

Regards,
Maciej

[1] http://lists.xiph.org/pipermail/theora/2009-July/002418.html

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

From robert at ocallahan.org  Sun Jul  5 16:21:20 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 6 Jul 2009 11:21:20 +1200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <59B9568B-18E5-4BA4-800C-FCC47049EC1D@apple.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
	<59B9568B-18E5-4BA4-800C-FCC47049EC1D@apple.com>
Message-ID: <11e306600907051621r1b1e82a6u3b6a1afaf8a9e490@mail.gmail.com>

On Mon, Jul 6, 2009 at 11:00 AM, Maciej Stachowiak <mjs at apple.com> wrote:

> A spec for Theora through a formal standards process might more effectively
> focus latent demand than a mention in the HTML spec.
>

You may be right, but that is an orthogonal issue.

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/20090706/38ce293f/attachment.htm>

From robert at ocallahan.org  Sun Jul  5 17:27:25 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 6 Jul 2009 12:27:25 +1200
Subject: [whatwg] autobuffer on "new Audio" objects
Message-ID: <11e306600907051727m2996e6a0sf8831c13e02bd7b9@mail.gmail.com>

When script creates an audio element using the "new Audio" constructor, the
'autobuffer' attribute should be automatically set on that element.
Presumably scripts will only create audio elements that they actually intend
to play.

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/20090706/56bdab4d/attachment.htm>

From sylvain.pasche at gmail.com  Sun Jul  5 17:27:42 2009
From: sylvain.pasche at gmail.com (Sylvain Pasche)
Date: Mon, 06 Jul 2009 02:27:42 +0200
Subject: [whatwg] DOMTokenList feedback
Message-ID: <h2rge3$7g6$1@ger.gmane.org>

Hi,

I'm looking at the Gecko implementation of element.classList. I had a 
few comments about the spec.

1) http://html5.org/tools/web-apps-tracker?from=3253&to=3254 missed 
something. There is still a mention of alphabetical sort order in the 
beginning of section 2.8.3:
"element = tokenlist . item(index)
tokenlist[index]
Returns the token with index index. The tokens are sorted alphabetically."

2) contains/add/remove/toggle should mention what happens if an empty 
string token is passed in the token argument. Looking at the DOM Core 
exceptions, throwing a SYNTAX_ERROR seems to be the best match in this 
case (if we consider an empty string as invalid):
"SYNTAX_ERR, introduced in DOM Level 2.
     If an invalid or illegal string is specified."

3) case sensitivity. Would be nice to address [1].
Note that the definition of uniqueness for .length and .item() will also 
need to be revisited if we want to handle classes in a case-insensitive 
way in quirks mode.


Sylvain

[1] 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020425.html


From ashannon1000 at gmail.com  Sun Jul  5 17:36:09 2009
From: ashannon1000 at gmail.com (Adam Shannon)
Date: Sun, 5 Jul 2009 19:36:09 -0500
Subject: [whatwg] autobuffer on "new Audio" objects
In-Reply-To: <11e306600907051727m2996e6a0sf8831c13e02bd7b9@mail.gmail.com>
References: <11e306600907051727m2996e6a0sf8831c13e02bd7b9@mail.gmail.com>
Message-ID: <3c4f8cda0907051736v2ba8d3dar9822cccb1474c9e6@mail.gmail.com>

What about slower, public, or WIFI connections that can't support 5 people
going to yahoo.com and having audio of interviews load?  Yahoo would think
that everyone would want to listen to at least the first ~15-30 seconds.

On Sun, Jul 5, 2009 at 7:27 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> When script creates an audio element using the "new Audio" constructor, the
> 'autobuffer' attribute should be automatically set on that element.
> Presumably scripts will only create audio elements that they actually intend
> to play.
>
> 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]
>



-- 
- Adam Shannon ( http://ashannon.us )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090705/a9c54e0c/attachment.htm>

From robert at ocallahan.org  Sun Jul  5 17:58:53 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 6 Jul 2009 12:58:53 +1200
Subject: [whatwg] autobuffer on "new Audio" objects
In-Reply-To: <3c4f8cda0907051736v2ba8d3dar9822cccb1474c9e6@mail.gmail.com>
References: <11e306600907051727m2996e6a0sf8831c13e02bd7b9@mail.gmail.com>
	<3c4f8cda0907051736v2ba8d3dar9822cccb1474c9e6@mail.gmail.com>
Message-ID: <11e306600907051758i2cfd52f7ue7e056dd17379b95@mail.gmail.com>

On Mon, Jul 6, 2009 at 12:36 PM, Adam Shannon <ashannon1000 at gmail.com>wrote:

> What about slower, public, or WIFI connections that can't support 5 people
> going to yahoo.com and having audio of interviews load?  Yahoo would think
> that everyone would want to listen to at least the first ~15-30 seconds.
>

What about them? I'm not sure what your point is.

I think we expect "new Audio" to be used for scripted playing of sounds, not
to create in-page audio elements.

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/20090706/9051d5ba/attachment.htm>

From ashannon1000 at gmail.com  Sun Jul  5 18:01:52 2009
From: ashannon1000 at gmail.com (Adam Shannon)
Date: Sun, 5 Jul 2009 20:01:52 -0500
Subject: [whatwg] autobuffer on "new Audio" objects
In-Reply-To: <11e306600907051758i2cfd52f7ue7e056dd17379b95@mail.gmail.com>
References: <11e306600907051727m2996e6a0sf8831c13e02bd7b9@mail.gmail.com> 
	<3c4f8cda0907051736v2ba8d3dar9822cccb1474c9e6@mail.gmail.com> 
	<11e306600907051758i2cfd52f7ue7e056dd17379b95@mail.gmail.com>
Message-ID: <3c4f8cda0907051801w15ceff03x71582cf20a4a43e9@mail.gmail.com>

On Sun, Jul 5, 2009 at 7:58 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Mon, Jul 6, 2009 at 12:36 PM, Adam Shannon <ashannon1000 at gmail.com>wrote:
>
>> What about slower, public, or WIFI connections that can't support 5 people
>> going to yahoo.com and having audio of interviews load?  Yahoo would
>> think that everyone would want to listen to at least the first ~15-30
>> seconds.
>>
>
> What about them? I'm not sure what your point is.
>

There already low bandwidth would be crippled more than it already is. (By
loading audio files.

>
>
> I think we expect "new Audio" to be used for scripted playing of sounds,
> not to create in-page audio elements.
>

If that is the purpose for the <audio> element then it may be missing out,
 I would love support for in-page audio, it could be used for podcasts,
radio, interviews, ect...

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



-- 
- Adam Shannon ( http://ashannon.us )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090705/1a1002c9/attachment.htm>

From jimjjewett at gmail.com  Sun Jul  5 18:02:13 2009
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sun, 5 Jul 2009 21:02:13 -0400
Subject: [whatwg] Codecs for <audio> and <video> -- informative note?
Message-ID: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>

Ian Hickson wrote:
|  <video> does support fallback, so in practice you can just use Theora and
|  H.264 and cover all bases.

Could you replace the codec section with at least an informative note
to this effect?  Something like,

"As of 2009, there is no single efficient codec which works on all
modern browsers.  Content producers are encouraged to supply the video
in both Theora and H.264 formats, as per the following example"

(If there is an older royalty-free format that is universally
supported, then please mention that as well, as it will still be
sufficient for some types of videos, such as crude animations.)

-jJ

From ashannon1000 at gmail.com  Sun Jul  5 18:09:21 2009
From: ashannon1000 at gmail.com (Adam Shannon)
Date: Sun, 5 Jul 2009 20:09:21 -0500
Subject: [whatwg] Codecs for <audio> and <video> -- informative note?
In-Reply-To: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>
References: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>
Message-ID: <3c4f8cda0907051809rd81bc8du6478638aa2f0235f@mail.gmail.com>

On Sun, Jul 5, 2009 at 8:02 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

> Ian Hickson wrote:
> |  <video> does support fallback, so in practice you can just use Theora
> and
> |  H.264 and cover all bases.
>
> Could you replace the codec section with at least an informative note
> to this effect?  Something like,
>
> "As of 2009, there is no single efficient codec which works on all
> modern browsers.  Content producers are encouraged to supply the video
> in both Theora and H.264 formats, as per the following example"
>
> (If there is an older royalty-free format that is universally
> supported, then please mention that as well, as it will still be
> sufficient for some types of videos, such as crude animations.)


The browser vendors were not able to implement the same codec (because of
patent's and copyrights), so no codec was able to be chosen. (
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/ )

>
>
> -jJ
>



-- 
- Adam Shannon ( http://ashannon.us )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090705/09b8b1f7/attachment.htm>

From silviapfeiffer1 at gmail.com  Sun Jul  5 18:32:42 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 6 Jul 2009 11:32:42 +1000
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
Message-ID: <2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com>

On Mon, Jul 6, 2009 at 8:41 AM, Robert O'Callahan<robert at ocallahan.org> wrote:
> On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> For that to happen there has to be
>> some demand for Theora support, though, which the spec's can't generate.
>
> Specs do generate demand --- by creating author expectation that a feature
> will be supported, by adding a well-known brand, and because test suites get
> created which vendors then compete on.

I agree: standards generate demand. It is how h.264 hardware support
originated - by making it a ISO standard, the vendors knew there would
be sufficient market demand for it and created the chips.

Silvia.

From ian at hixie.ch  Sun Jul  5 18:44:02 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 01:44:02 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Robert O'Callahan wrote:
> 
> Specs do generate demand --- by creating author expectation that a 
> feature will be supported, by adding a well-known brand, and because 
> test suites get created which vendors then compete on.

On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
>
> I agree: standards generate demand. It is how h.264 hardware support 
> originated - by making it a ISO standard, the vendors knew there would 
> be sufficient market demand for it and created the chips.

I disagree with both these statements, I don't think they are in fact 
accurate. Demand can be focused around a specification if one exists, but 
a specification cannot create demand, and the lack of a specification is 
not an impediment to deployment. We have seen both facets of this 
repeatedly demonstrated through the lifetime of the Web, not least of 
which by HTML itself. Indeed, cutting features that didn't have demand 
despite being in HTML4 for a decade is one of HTML5's achievements.

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

From ian at hixie.ch  Sun Jul  5 18:46:38 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 01:46:38 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video> -- informative note?
In-Reply-To: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>
References: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907060145190.1053@hixie.dreamhostps.com>

On Sun, 5 Jul 2009, Jim Jewett wrote:
> Ian Hickson wrote:
> |  <video> does support fallback, so in practice you can just use Theora and
> |  H.264 and cover all bases.
> 
> Could you replace the codec section with at least an informative note to 
> this effect?  Something like,
> 
> "As of 2009, there is no single efficient codec which works on all 
> modern browsers.  Content producers are encouraged to supply the video 
> in both Theora and H.264 formats, as per the following example"

I might add some text along these lines once it's clearer what the 
implementations have actually deployed. Right now, <video> implementations 
are still quite young.


> (If there is an older royalty-free format that is universally supported, 
> then please mention that as well, as it will still be sufficient for 
> some types of videos, such as crude animations.)

There isn't, as far as I know.

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

From silviapfeiffer1 at gmail.com  Sun Jul  5 18:51:45 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 6 Jul 2009 11:51:45 +1000
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <59B9568B-18E5-4BA4-800C-FCC47049EC1D@apple.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com> 
	<59B9568B-18E5-4BA4-800C-FCC47049EC1D@apple.com>
Message-ID: <2c0e02830907051851o63f8b0ucd480fddee47506@mail.gmail.com>

On Mon, Jul 6, 2009 at 9:00 AM, Maciej Stachowiak<mjs at apple.com> wrote:
>
> On Jul 5, 2009, at 3:41 PM, Robert O'Callahan wrote:
>
> On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> For that to happen there has to be
>> some demand for Theora support, though, which the spec's can't generate.
>
> Specs do generate demand --- by creating author expectation that a feature
> will be supported, by adding a well-known brand, and because test suites get
> created which vendors then compete on.
>
> For H.264, a lot of the demand was created by the initial ISO/ITU standard
> and the follow-on standards for hardware products such as HD video disc
> players, set-to boxes and mobile phones. This was actually considerably
> earlier than H.264 deployment on the Web. For Microsoft's WMV to participate
> in some of the same markets, it had to go through a formal standards
> process, becoming SMPTE VC-1. SMPTE has also standardized Dirac Pro (a
> subset with no interframe compression) as VC-2.
>
> A spec for Theora through a formal standards process might more effectively
> focus latent demand than a mention in the HTML spec. It would also greatly
> clarify the patent situation, since many holders of wide-ranging patents on
> video compression participate in these groups. I've asked the Xiph folks if
> they'd be willing to take Theora to an organization such as SMPTE.[1]

I don't think putting it through SMPTE will magically create hardware
support. VC-1 and VC-2 didn't magically get hardware support through
being standardised by SMPTE. It is a combination of standardisation
and uptake that will get the confidence for the market. I think the
W3C is in a much better position to achieve this right now than the
SMPTE. Which standards body adopts it doesn't make much of a
difference to the market.

Don't get me wrong though: I don't have anything against putting
Theora through SMPTE - if SMPTE would indeed accept such a submission.
I could imagine SMPTE be interested in it for digital TV type
transmissions, e.g. for picture-in-picture in combination with VC-1 or
VC-2. But the SMPTE process will take a minimum of 2 years and a
dedicated person to travel to meetings, prepare the extensive
paperwork required, and lobby the SMPTE members - an expense that Xiph
is simply not in a position to fund. Also, the documentation required
for a standard is already available: a open specification, an open
reference implementation, test data, and a validation approach. So, it
would be a rather expensive experiment just to get political support
from the TV folks.

The only thing that SMPTE would probably add is a call for patent
holders to come forward now. This is something that the W3C can do,
too. If widely enough publicized, it should bring the risk down.

Please note that this is my personal opinion and not Xiph's official stance.

Regards,
Silvia.

From silviapfeiffer1 at gmail.com  Sun Jul  5 18:56:24 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 6 Jul 2009 11:56:24 +1000
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com> 
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com> 
	<Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
Message-ID: <2c0e02830907051856k6628f078h4d8b2855ce78b5dd@mail.gmail.com>

On Mon, Jul 6, 2009 at 11:44 AM, Ian Hickson<ian at hixie.ch> wrote:
> On Mon, 6 Jul 2009, Robert O'Callahan wrote:
>>
>> Specs do generate demand --- by creating author expectation that a
>> feature will be supported, by adding a well-known brand, and because
>> test suites get created which vendors then compete on.
>
> On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
>>
>> I agree: standards generate demand. It is how h.264 hardware support
>> originated - by making it a ISO standard, the vendors knew there would
>> be sufficient market demand for it and created the chips.
>
> I disagree with both these statements, I don't think they are in fact
> accurate. Demand can be focused around a specification if one exists, but
> a specification cannot create demand, and the lack of a specification is
> not an impediment to deployment. We have seen both facets of this
> repeatedly demonstrated through the lifetime of the Web, not least of
> which by HTML itself. Indeed, cutting features that didn't have demand
> despite being in HTML4 for a decade is one of HTML5's achievements.

It's not the standard alone that makes it happen. The standard is for
the general market neither a necessary nor a sufficient requirement
for uptake. However, for the individual vendor, a standard and the
perception that the market is adopting it will be a sufficient
requirement to make a decision to create a product. Lacking the
standard, just the perception that the market is adopting makes taking
that decision just that much harder.

Regards,
Silvia.

From robert at ocallahan.org  Sun Jul  5 18:56:46 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 6 Jul 2009 13:56:46 +1200
Subject: [whatwg] autobuffer on "new Audio" objects
In-Reply-To: <3c4f8cda0907051801w15ceff03x71582cf20a4a43e9@mail.gmail.com>
References: <11e306600907051727m2996e6a0sf8831c13e02bd7b9@mail.gmail.com>
	<3c4f8cda0907051736v2ba8d3dar9822cccb1474c9e6@mail.gmail.com>
	<11e306600907051758i2cfd52f7ue7e056dd17379b95@mail.gmail.com>
	<3c4f8cda0907051801w15ceff03x71582cf20a4a43e9@mail.gmail.com>
Message-ID: <11e306600907051856o141d8f09s696c9d7143598d4f@mail.gmail.com>

On Mon, Jul 6, 2009 at 1:01 PM, Adam Shannon <ashannon1000 at gmail.com> wrote:

> On Sun, Jul 5, 2009 at 7:58 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> I think we expect "new Audio" to be used for scripted playing of sounds,
>> not to create in-page audio elements.
>>
>
> If that is the purpose for the <audio> element then it may be missing out,
>  I would love support for in-page audio, it could be used for podcasts,
> radio, interviews, ect...
>
>>
For in-page audio, put an <audio> element in the page.

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/20090706/cd537a24/attachment.htm>

From robert at ocallahan.org  Sun Jul  5 19:21:32 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 6 Jul 2009 14:21:32 +1200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com>
	<Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
Message-ID: <11e306600907051921p397263d0tf65089f535ae5984@mail.gmail.com>

On Mon, Jul 6, 2009 at 1:44 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 6 Jul 2009, Robert O'Callahan wrote:
> > Specs do generate demand --- by creating author expectation that a
> > feature will be supported, by adding a well-known brand, and because
> > test suites get created which vendors then compete on.
>
> On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
> >
> > I agree: standards generate demand. It is how h.264 hardware support
> > originated - by making it a ISO standard, the vendors knew there would
> > be sufficient market demand for it and created the chips.
>
> I disagree with both these statements, I don't think they are in fact
> accurate. Demand can be focused around a specification if one exists
>

Specs can't create author demand for features that authors don't actually
want, but if authors want a general feature (say, simple CSS animations)
then having an implementation of that feature creates demand for that
particular incarnation of the feature, and giving it the CSS WG imprimatur
increases demand further.

Some authors want a royalty-free video codec. We have an implementation,
Theora. I believe linking HTML5 to it would increase author demand for it to
be supported in all browsers, and help those authors make a stronger case.
If I didn't think so, I wouldn't be wasting my time here.

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/20090706/31244c81/attachment.htm>

From ian at hixie.ch  Sun Jul  5 20:14:03 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 03:14:03 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <2c0e02830907051856k6628f078h4d8b2855ce78b5dd@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com> 
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com> 
	<Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<2c0e02830907051856k6628f078h4d8b2855ce78b5dd@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907060312590.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
> 
> It's not the standard alone that makes it happen. The standard is for 
> the general market neither a necessary nor a sufficient requirement for 
> uptake. However, for the individual vendor, a standard and the 
> perception that the market is adopting it will be a sufficient 
> requirement to make a decision to create a product. Lacking the 
> standard, just the perception that the market is adopting makes taking 
> that decision just that much harder.

I don't buy it. Nobody bases their business decisions on what specs say, 
they base them on what their customers and potential customers say they 
are going to spend money on. (Or the equivalent in the relevant market.)

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

From ian at hixie.ch  Sun Jul  5 20:19:20 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 03:19:20 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <11e306600907051921p397263d0tf65089f535ae5984@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com> 
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com> 
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com> 
	<Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<11e306600907051921p397263d0tf65089f535ae5984@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907060314530.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Robert O'Callahan wrote:
> 
> Some authors want a royalty-free video codec. We have an implementation, 
> Theora. I believe linking HTML5 to it would increase author demand for 
> it to be supported in all browsers, and help those authors make a 
> stronger case.

Given the volume of support Theora has gotten without it being in the 
spec, I don't see why putting it in HTML5 would have any effect on author 
demand. The demand already exists, and the customer pressure on Apple will 
rise as more and more sites make use of Theora. I don't see that the spec 
saying "must...Theora" would have any effect. If anything, I think it 
would be a negative effect, since it would mean that at least one thing in 
the spec was there despite it being known that one vendor is actively 
refusing to implement it (as opposed to just not having gotten to it yet).


> If I didn't think so, I wouldn't be wasting my time here.

I have no doubt that you are arguing in good faith. :-)

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

From ian at hixie.ch  Sun Jul  5 20:40:23 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 03:40:23 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <9f7b98300907051957y38d0dda9u26660aefe8a5624b@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<9f7b98300907051957y38d0dda9u26660aefe8a5624b@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907060320150.1053@hixie.dreamhostps.com>

On Sun, 5 Jul 2009, Eric Flores wrote:
> >
> > The point is that there is no decided roadmap.
>
> There was one, and has been recently dropped.

Actually there has never been a roadmap on this issue.


> My point is that thinking that the free market will solve the issue by 
> any of the two routes that you stated is even more unrealistic than 
> assuming that Apple will implement Theora just because it is part of the 
> spec.

Apple has said they won't implement Theora regardless of whether it's in 
the spec or not. I agree though that it might be that the two outcomes I 
describe are also unlikely.


> Apple will not change their format even if the rest of the world uses 
> any other thing. On the other side, the silent giant will not support 
> anything other than their WMV and WMA format. Even if Apple and Mozilla 
> reach an agreement, what will we do once Microsoft decides to speak up? 
> Yes, I know the response.

I don't. I wish Microsoft would speak up, as that might help tilt the 
balance one way or the other.


> Having a preferred format tips the balance for the chipmakers to make a 
> decision, and in the case of Theora, helps to stir discussion about the 
> supposed hidden patents.

I agree entirely. It is sad that we can't find one.


> Theora might not be the best. But is the best that we have.

We don't even have Theora right now.

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

From lists.whatwg at stakface.com  Sun Jul  5 20:50:51 2009
From: lists.whatwg at stakface.com (Kartikaya Gupta)
Date: Mon, 06 Jul 2009 03:50:51 +0000
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
Message-ID: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>

On Mon, 6 Jul 2009, Ian Hickson wrote:
>
> On Mon, 6 Jul 2009, Robert O'Callahan wrote: 
> 
> > Specs do generate demand --- by creating author expectation that a 
> > feature will be supported, by adding a well-known brand, and because 
> > test suites get created which vendors then compete on.
> > 
> 
> On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: 
> 
> > I agree: standards generate demand. It is how h.264 hardware support 
> > originated - by making it a ISO standard, the vendors knew there would 
> > be sufficient market demand for it and created the chips.
> > 
> 
> I disagree with both these statements, I don't think they are in fact 
> accurate. Demand can be focused around a specification if one exists, but 
> a specification cannot create demand, and the lack of a specification is 
> not an impediment to deployment. We have seen both facets of this 
> repeatedly demonstrated through the lifetime of the Web, not least of 
> which by HTML itself. Indeed, cutting features that didn't have demand 
> despite being in HTML4 for a decade is one of HTML5's achievements. 

I'm not sure whether specs can create demand, and frankly, I find it somewhat irrelevant to the point at hand. The fact is there is already demand for a single encoding format that will be compatible with as many browsers as possible. The only question is what that format will be. In this case, the spec doesn't need to create demand for anything, it just needs to tell people what that format is.

I believe that if HTML5 specified Theora, that would become a self-fulfilling prophecy, and Theora would become the standard (both specified and actual) of the web. There's already been a huge amount of press (on Slashdot, OSNews, Ars Technica, etc.) about the debate on this list. If a decision were to be made in favor of Theora, that would immediately be broadcast by the same channels and a lot of people (including actual and potential web authors) would be aware of it. A lot of those authors (not major publishers like YouTube, but the long tail that includes everybody else) will not bother to read the details of the decision; they will simply assume that since it is in the standard it will soon be supported by all the major browsers, and they will make their choices and start publishing content with that in mind. Since there is already some browser support for it, those efforts won't just fizzle and die. As there is an increase of Theora-encoded content, support for it will increase (including in terms of hardware) and it will drive a virtuous cycle pushing Theora to be even more widespread.

In a nutshell, what I'm thinking is that putting Theora in the HTML5 spec would not be enough to magically get authors to start generating Theora-encoded content. It is, however, enough to make authors in the process of deciding between H.264 and Theora for their <video> content to pick Theora. It's just a little push, but that little push is enough to make all the difference.

Now, I suppose all of the above may hold for H.264 instead of Theora, but I think it is far less likely given the distribution of vendors and their reasons for being in favor of a particular codec. If you disagree, that's fine. Just replace all instances of Theora with H.264 and read on. I'm also ignoring the Dirac possibility which has been mentioned a few times but doesn't seem to be being actively pursued. If that satifies everybody, so much the better.

So, my questions to you are:

1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy?

2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec?

My view with regards to question (2) above is that one way or another, the web will settle on a single encoding format. This can be done the easy way or the hard way. The hard way is to not specify anything, and let authors and vendors battle it out for years at everybody's expense, leaving a trail of carnage and cruft behind that will then need to supported for decades. The easy way is to specify something and cross your fingers. Even if it doesn't work, at worst it will just prolong an already long and bloody battle. The benefits from the best-case scenario make the risk more than worth it.

kats

From ian at hixie.ch  Sun Jul  5 21:06:25 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 04:06:25 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
Message-ID: <Pine.LNX.4.62.0907060403030.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
>
> 1) Do you agree with my view that specifying Theora for the video 
> element would result in a self-fulfilling prophecy?

No. I don't think it would make any difference to what browsers implement, 
and as far as I can tell, what browsers implement is the only thing that 
affects what authors adopt.


> 2) Do you think that it is better to sit on the fence and not specify 
> anything, thereby forcing authors to either (a) be incompatible with 
> some browsers or (b) re-encode their content in multiple formats?

I don't think it makes any difference whether we specify something or not; 
if the browsers aren't all going to implement the same thing, then that is 
what is going to force authors to either (a) be incompatible with some 
browsers or (b) re-encode their content in multiple formats.


> Or do you think it is better to pick a side that has a good shot at 
> winning, even if it means that some vendors may be non-compliant with 
> the spec?

I think it would be harmful to spec something that is actively different 
than what a browser vendor will implement. This is why HTML5 started -- 
because the W3C wrote specs that were idealistic and did not match 
reality.


> My view with regards to question (2) above is that one way or another, 
> the web will settle on a single encoding format. This can be done the 
> easy way or the hard way. The hard way is to not specify anything, and 
> let authors and vendors battle it out for years at everybody's expense, 
> leaving a trail of carnage and cruft behind that will then need to 
> supported for decades. The easy way is to specify something and cross 
> your fingers. Even if it doesn't work, at worst it will just prolong an 
> already long and bloody battle. The benefits from the best-case scenario 
> make the risk more than worth it.

We already know what Apple will do if we put Theora in the spec. They'll 
ignore it. So it will not make any difference one way or the other as far 
as <video> is concerned. It will, however, mean that HTML5 is less in line 
with what authors can actually rely on.

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

From lists.whatwg at stakface.com  Sun Jul  5 22:06:21 2009
From: lists.whatwg at stakface.com (Kartikaya Gupta)
Date: Mon, 06 Jul 2009 05:06:21 +0000
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907060403030.1053@hixie.dreamhostps.com>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<Pine.LNX.4.62.0907060403030.1053@hixie.dreamhostps.com>
Message-ID: <20090706050622.392888DB0010@zapata.dreamhost.com>

On Mon, 6 Jul 2009 04:06:25 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
> > 
> > Or do you think it is better to pick a side that has a good shot at 
> > winning, even if it means that some vendors may be non-compliant with 
> > the spec?
> 
> I think it would be harmful to spec something that is actively different 
> than what a browser vendor will implement. This is why HTML5 started -- 
> because the W3C wrote specs that were idealistic and did not match 
> reality.
> 

You've expressed something similar in a couple of the other threads as well, and I find it puzzling. It's true that if you spec things that will never be implemented, it harms the integrity of the spec. But on the other hand, if you allow any one vendor to determine what does or does not go into the spec [1], you're are exposing the spec to a much greater risk.

In at least one other thread [2] you've implied that you treat all browser vendors as equal. If you put this together with the veto power it means that any browser vendor, "regardless of size" can get things axed from the spec. Am I missing something? What is stopping me from becoming a browser vendor and stating flat-out that I will not support any of the new additions in HTML5 just to kill off a good chunk of the spec? (Since I am working on a browser currently playing catch-up, this would certainly make my life easier).

It seems to me that you need to either take away this veto power you've given browser vendors, or you need to draw a line between the vendors that do have veto power and the ones that don't. If you have already drawn such a line, I would like to know exactly where it is and what criteria were used to determine which vendors to allow and which ones to disallow.

One of the failings of HTML5, IMHO, is that it is trying to both document existing behavior and spec new features. These two activities should use different processes with regard to vendor consensus, but they are instead getting lumped together, and the new features are getting stifled as a result.

kats

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020722.html, your replies to Anne
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020747.html

From giecrilj at stegny.2a.pl  Sun Jul  5 23:48:16 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 6 Jul 2009 08:48:16 +0200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
References: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
Message-ID: <02D0CC86D9034E91833E2B6EB7B83BBC@POCZTOWIEC>

Small authors are hardly an alternative to YouTube because they use YouTube
(or a similar service) to publish their content.  Neither do YouTube publish
most of the stuff on their own; they only allow the authors to do it using
YT technology.
In short, if you do not have the know-how to serve your video content, you
will just use YouTube and never bother.  And if you do have, you will not
begin with reading the HTML specification either.
IMHO,
Chris


From giecrilj at stegny.2a.pl  Mon Jul  6 00:08:01 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 6 Jul 2009 09:08:01 +0200
Subject: [whatwg] DOMTokenList feedback
In-Reply-To: <h2rge3$7g6$1@ger.gmane.org>
References: <h2rge3$7g6$1@ger.gmane.org>
Message-ID: <1024649203EE4BE9B2EC8BB0C7CD19C8@POCZTOWIEC>

Regarding DOMTokenList, why not:
	contains(""): true
	add,remove,toggle(""): no effect?
Are there situations that would require an exception to be thrown, or else
the page would go out in a blast?
Chris



From giecrilj at stegny.2a.pl  Mon Jul  6 00:30:58 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Mon, 6 Jul 2009 09:30:58 +0200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907060320150.1053@hixie.dreamhostps.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com><9f7b98300907051957y38d0dda9u26660aefe8a5624b@mail.gmail.com>
	<Pine.LNX.4.62.0907060320150.1053@hixie.dreamhostps.com>
Message-ID: <C2B6A9CC031E4F858B0D63C9AF5D42E7@POCZTOWIEC>

For those of you that are concerned whether Microsoft will support web
video: Internet Explorer already does, albeit in the Microsoft WayT:

*	dynsrc Property (IMG, INPUT, INPUT type=image, ...)
<URL:http://msdn.microsoft.com/en-us/library/ms533742(VS.85).aspx>  

:-)


From l.mastrodomenico at gmail.com  Mon Jul  6 00:52:00 2009
From: l.mastrodomenico at gmail.com (Lino Mastrodomenico)
Date: Mon, 6 Jul 2009 09:52:00 +0200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <02D0CC86D9034E91833E2B6EB7B83BBC@POCZTOWIEC>
References: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<02D0CC86D9034E91833E2B6EB7B83BBC@POCZTOWIEC>
Message-ID: <cc93256f0907060052m154fd953x65b251449c735ab8@mail.gmail.com>

2009/7/6 Kristof Zelechovski <giecrilj at stegny.2a.pl>:
> Small authors are hardly an alternative to YouTube because they use YouTube
> (or a similar service) to publish their content.
[snip]
> In short, if you do not have the know-how to serve your video content, you
> will just use YouTube and never bother.

I am a small author and I have basic knowledge about how to encode a
video. it's really not hard using a GUI frontend for ffmpeg2theora;
it's pretty much only a matter of selecting a good compromise between
encoding quality, resolution and bitrate, checking the result and
trying again with different resolution or quality until you get what
you want. You usually get subsequent videos right at the first try.

But in the past I've used YouTube to host my videos because I don't
have the know-how to write a Flash video *player* that works on
different browsers, with workarounds for bugs that may crash old (but
still widely used) versions of the plugin, alternative encodings for
old plugins that don't support H.264, etc.

The problem is not that I don't know how to encode a video, it's that
I don't know how to write a video player that works as well as the
YouTube one. I know that there are free ones around, but in my limited
tests they don't work well with old Flash versions and are more
complicated than a simple video tag.

HTML5 solves this problem because now the player is embedded in the
browser, so I started using <video src="whatever.ogv"> and hiding the
YouTube <object> blurb inside it as a fallback. This should work with
every browser (except maybe Safari without XiphQT???), gives me the
freedom to choose exactly the resolution I want and a bit of
Independence from YT, which is good (think about cases like a troll
flagging my videos: AFAIK YouTube automatically removes videos after a
certain number of flags).

With HTML5 video I can also get better quality because the videos
don't have to go through two lossy encodings and I can also push the
bitrate up a bit, since my website doesn't have a billion visitors
each day.

> ?And if you do have, you will not
> begin with reading the HTML specification either.

I did. And after reading it I decided to use the autoplay and controls
attributes.

Except the missing reference to Ogg/Theora, I found the spec much more
informative and useful than other tutorials found on the interwebs
that suggested using autoplay="false" to disable autoplay (completely
wrong, of course) or presented examples using WMV-encoded videos. Yes
I'm talking about w3schools.

ciao

-- 
Lino Mastrodomenico

From dgerard at gmail.com  Mon Jul  6 01:01:00 2009
From: dgerard at gmail.com (David Gerard)
Date: Mon, 6 Jul 2009 09:01:00 +0100
Subject: [whatwg] Codecs for <audio> and <video> -- informative note?
In-Reply-To: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>
References: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>
Message-ID: <fbad4e140907060101y2ac9454evbc643ae24e6e8273@mail.gmail.com>

2009/7/6 Jim Jewett <jimjjewett at gmail.com>:

> "As of 2009, there is no single efficient codec which works on all
> modern browsers. ?Content producers are encouraged to supply the video
> in both Theora and H.264 formats, as per the following example"


A spec that makes an encumbered format a "SHOULD" is unlikely to be
workable for those content providers, e.g. Wikimedia, who don't have
the money, and won't under principle, to put up stuff in a format
rendered radioactive by known enforced patents. Your wording presumes
a paid Web all the way through.


- d.

From mjs at apple.com  Mon Jul  6 01:04:39 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Mon, 06 Jul 2009 01:04:39 -0700
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <cc93256f0907060052m154fd953x65b251449c735ab8@mail.gmail.com>
References: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<02D0CC86D9034E91833E2B6EB7B83BBC@POCZTOWIEC>
	<cc93256f0907060052m154fd953x65b251449c735ab8@mail.gmail.com>
Message-ID: <6EA4FF96-0398-487A-82CC-776CA238CBA8@apple.com>


On Jul 6, 2009, at 12:52 AM, Lino Mastrodomenico wrote:

>
> HTML5 solves this problem because now the player is embedded in the
> browser, so I started using <video src="whatever.ogv"> and hiding the
> YouTube <object> blurb inside it as a fallback. This should work with
> every browser (except maybe Safari without XiphQT???), gives me the
> freedom to choose exactly the resolution I want and a bit of
> Independence from YT, which is good (think about cases like a troll
> flagging my videos: AFAIK YouTube automatically removes videos after a
> certain number of flags).

Here's an example of some markup that will work on a wide range of  
browsers, if you provide Ogg and MP4 versions of your video: <http://camendesign.com/code/video_for_everybody 
 >. The MP4 version can be played either through <video> in browsers  
that support that, or by Flash or QuickTime or Windows Media Player.  
This actually results in video that works better in more browsers than  
Flash alone.

(Personally I'd recommend putting the H.264 <source> first instead of  
last, so browsers that support both H.264 and Theora will pick the  
higher-quality video.)

If you are willing to ignore IE and older browser versions, you can  
use the simpler markup here that just uses <video> with two <source>s:  
<http://daringfireball.net/2009/07/ffmpeg2theora>

Regards,
Maciej


From dgerard at gmail.com  Mon Jul  6 01:12:39 2009
From: dgerard at gmail.com (David Gerard)
Date: Mon, 6 Jul 2009 09:12:39 +0100
Subject: [whatwg]  Chipset support is a good argument
In-Reply-To: <fbad4e140907060111i10f90788x68b827b4da601235@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com>
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com>
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com>
	<Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<11e306600907051921p397263d0tf65089f535ae5984@mail.gmail.com>
	<Pine.LNX.4.62.0907060314530.1053@hixie.dreamhostps.com>
	<fbad4e140907060111i10f90788x68b827b4da601235@mail.gmail.com>
Message-ID: <fbad4e140907060112g3b1fd9c4ra761f1210e29c4d7@mail.gmail.com>

[to list as well, oops]


---------- Forwarded message ----------
From: David Gerard <dgerard at gmail.com>
Date: 2009/7/6
Subject: Re: [whatwg] Chipset support is a good argument
To: Ian Hickson <ian at hixie.ch>


2009/7/6 Ian Hickson <ian at hixie.ch>:

> Given the volume of support Theora has gotten without it being in the
> spec, I don't see why putting it in HTML5 would have any effect on author
> demand. The demand already exists, and the customer pressure on Apple will
> rise as more and more sites make use of Theora. I don't see that the spec
> saying "must...Theora" would have any effect.


This doesn't address the power of a "should".


> If anything, I think it
> would be a negative effect, since it would mean that at least one thing in
> the spec was there despite it being known that one vendor is actively
> refusing to implement it (as opposed to just not having gotten to it yet).


And then there's IE, of course. But if you were considering them, most
of HTML5 wouldn't exist.


- d.

From ian at hixie.ch  Mon Jul  6 02:02:51 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 09:02:51 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <20090706050622.49FF314DD57@looneymail-mx2.g.dreamhost.com>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<Pine.LNX.4.62.0907060403030.1053@hixie.dreamhostps.com>
	<20090706050622.49FF314DD57@looneymail-mx2.g.dreamhost.com>
Message-ID: <Pine.LNX.4.62.0907060856130.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
> 
> You've expressed something similar in a couple of the other threads as 
> well, and I find it puzzling. It's true that if you spec things that 
> will never be implemented, it harms the integrity of the spec. But on 
> the other hand, if you allow any one vendor to determine what does or 
> does not go into the spec [1], you're are exposing the spec to a much 
> greater risk.

What risk?


> In at least one other thread [2] you've implied that you treat all 
> browser vendors as equal. If you put this together with the veto power 
> it means that any browser vendor, "regardless of size" can get things 
> axed from the spec. Am I missing something? What is stopping me from 
> becoming a browser vendor and stating flat-out that I will not support 
> any of the new additions in HTML5 just to kill off a good chunk of the 
> spec? (Since I am working on a browser currently playing catch-up, this 
> would certainly make my life easier).

Nothing is stopping you from doing that.


> It seems to me that you need to either take away this veto power you've 
> given browser vendors, or you need to draw a line between the vendors 
> that do have veto power and the ones that don't.

I haven't given browser vendors this veto power, they have it regardless. 
If implementors don't implement the spec, then the spec is fiction. 
There's nothing I can do about that.


> If you have already drawn such a line, I would like to know exactly 
> where it is and what criteria were used to determine which vendors to 
> allow and which ones to disallow.

In practice, a browser vendor has to have an installed base of a percent 
or so overall before they can really affect the direction of the Web.

This isn't a decision I have made myself. It's just how the world is.

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

From l.mastrodomenico at gmail.com  Mon Jul  6 03:00:10 2009
From: l.mastrodomenico at gmail.com (Lino Mastrodomenico)
Date: Mon, 6 Jul 2009 12:00:10 +0200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <6EA4FF96-0398-487A-82CC-776CA238CBA8@apple.com>
References: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<02D0CC86D9034E91833E2B6EB7B83BBC@POCZTOWIEC>
	<cc93256f0907060052m154fd953x65b251449c735ab8@mail.gmail.com>
	<6EA4FF96-0398-487A-82CC-776CA238CBA8@apple.com>
Message-ID: <cc93256f0907060300gf975356g16a9a9dda00b813e@mail.gmail.com>

2009/7/6 Maciej Stachowiak <mjs at apple.com>:
> Here's an example of some markup that will work on a wide range of browsers,
> if you provide Ogg and MP4 versions of your video:
> <http://camendesign.com/code/video_for_everybody>. The MP4 version can be
> played either through <video> in browsers that support that, or by Flash or
> QuickTime or Windows Media Player. This actually results in video that works
> better in more browsers than Flash alone.

My first goal is to get as much as possible of my users to watch my
videos, but my secondary goal is to do so in a way that encourages a
sustainable video ecosystem on the web. I don't think that including
an easy and always available fallback to H.264 gives Apple and
Microsoft any incentive to support Theora or other free alternatives.

Moreover, while MP3, MPEG-4 ASP and H.264 are entirely fine and widely
used for pirated music and movies (which is illegal anyway), I prefer
not to put any H.264-encoded file on my website, things like these
scare me:

<http://www.streaminglearningcenter.com/articles/46/1/H264-Royalties-what-you-need-to-know/Page1.html>

and:

<http://www.streamingmedia.com/article.asp?id=11011&page=1&c=7>

Apparently the MPEG LA has not yet decided if and how much they want
me to pay from january 2011.

I'm sorry if this sounds like FUD, but I will not use H.264 until is
available without fees for the websites (guaranteed forever, not in a
we-may-change-our-mind-anytime way) and with an open-source-like
patent licence for encoding and decoding.

I'm not asking to the MPEG LA to kill their business, they can sell a
single patent licence to the open source/free software community for a
ridiculously high price. Insanely high. If it's applicable to derived
works, the community may well pay for it, and if it uses (for patents)
terms similar to the ones that the GNU GPL uses (for copyright) then
the MPEG LA will still be able to make more money by selling
"traditional" lower-priced licences to proprietary software vendors.

I hope they change their mind soon, but until the MPEG LA keeps H.264
"captive", it's simply not an option for me as a web developer.

> (Personally I'd recommend putting the H.264 <source> first instead of last,
> so browsers that support both H.264 and Theora will pick the higher-quality
> video.)

I use a high enough bitrate (roughly 0.2-0.25 bits per pixel, but it
changes a lot depending on the material and the resolution) that most
people can't tell the difference even on side-by-side comparisons. And
if they did I don't want to penalize browsers that chose to support
only Theora, since they IMO did the right thing for a sustainable
future of the video on the web.

Anyway I tried deinstalling XiphQT on my Mac and Safari doesn't play
the YouTube fallback inside <video>, so I'll include a small JS that
detects the situation and completely removes <video> leaving only the
YT <object> (BTW, canPlayType in Safari 4.0 seems buggy: it always
returns "no", even with XiphQT installed).

-- 
Lino Mastrodomenico

From jonas at sicking.cc  Mon Jul  6 03:08:00 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 6 Jul 2009 03:08:00 -0700
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907060312590.1053@hixie.dreamhostps.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com> 
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com> 
	<Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<2c0e02830907051856k6628f078h4d8b2855ce78b5dd@mail.gmail.com> 
	<Pine.LNX.4.62.0907060312590.1053@hixie.dreamhostps.com>
Message-ID: <63df84f0907060308q20e7dfd7w805b99da2f65ae3a@mail.gmail.com>

On Sun, Jul 5, 2009 at 8:14 PM, Ian Hickson<ian at hixie.ch> wrote:
> On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
>>
>> It's not the standard alone that makes it happen. The standard is for
>> the general market neither a necessary nor a sufficient requirement for
>> uptake. However, for the individual vendor, a standard and the
>> perception that the market is adopting it will be a sufficient
>> requirement to make a decision to create a product. Lacking the
>> standard, just the perception that the market is adopting makes taking
>> that decision just that much harder.
>
> I don't buy it. Nobody bases their business decisions on what specs say,
> they base them on what their customers and potential customers say they
> are going to spend money on. (Or the equivalent in the relevant market.)

It's not the spec by itself that affects business decisions. It's the
people that back the spec that does. Having names like W3C, Mozilla,
Opera, Google, and the many other parties participating here
officially get behind a HTML spec that endorses Theora sends a signal
that this isn't just a buzz word, but something that is likely to
stick around. Especially in the context of what the future of the web
is going to look like.

Even better would be if we can get names like Apple and Microsoft to
endorse this too, but I don't think it stands and falls by having
these endorsements right now. Especially since so far I see no reason
that couldn't come later.

/ Jonas

From ian at hixie.ch  Mon Jul  6 03:27:44 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 10:27:44 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <63df84f0907060308q20e7dfd7w805b99da2f65ae3a@mail.gmail.com>
References: <9f7b98300907050912r5d311a8of862c816a6c2842c@mail.gmail.com> 
	<Pine.LNX.4.62.0907052045050.1053@hixie.dreamhostps.com>
	<11e306600907051541o11d15ba0m4220e6ec5e0edcf0@mail.gmail.com> 
	<2c0e02830907051832k326397a2i71042fc1d3efc54e@mail.gmail.com> 
	<Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<2c0e02830907051856k6628f078h4d8b2855ce78b5dd@mail.gmail.com> 
	<Pine.LNX.4.62.0907060312590.1053@hixie.dreamhostps.com>
	<63df84f0907060308q20e7dfd7w805b99da2f65ae3a@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907061025440.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Jonas Sicking wrote:
> On Sun, Jul 5, 2009 at 8:14 PM, Ian Hickson<ian at hixie.ch> wrote:
> > On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
> >>
> >> It's not the standard alone that makes it happen. The standard is for 
> >> the general market neither a necessary nor a sufficient requirement 
> >> for uptake. However, for the individual vendor, a standard and the 
> >> perception that the market is adopting it will be a sufficient 
> >> requirement to make a decision to create a product. Lacking the 
> >> standard, just the perception that the market is adopting makes 
> >> taking that decision just that much harder.
> >
> > I don't buy it. Nobody bases their business decisions on what specs 
> > say, they base them on what their customers and potential customers 
> > say they are going to spend money on. (Or the equivalent in the 
> > relevant market.)
> 
> It's not the spec by itself that affects business decisions. It's the 
> people that back the spec that does. Having names like W3C, Mozilla, 
> Opera, Google, and the many other parties participating here officially 
> get behind a HTML spec that endorses Theora sends a signal that this 
> isn't just a buzz word, but something that is likely to stick around. 
> Especially in the context of what the future of the web is going to look 
> like.
> 
> Even better would be if we can get names like Apple and Microsoft to 
> endorse this too, but I don't think it stands and falls by having these 
> endorsements right now. Especially since so far I see no reason that 
> couldn't come later.

Theora is already being endorsed by Mozilla, Opera, and Google; I don't 
think the incremental benefit of having the W3C spec mention Theora would 
offset the loss of having the spec move away from describing consensus.

(For the same reason, I expect to split out the SQL stuff from Web Storage 
before Web Storage moves on. This seems like the same situation to me.)

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

From conrad at metadecks.org  Mon Jul  6 04:22:26 2009
From: conrad at metadecks.org (Conrad Parker)
Date: Mon, 6 Jul 2009 20:22:26 +0900
Subject: [whatwg] HTML5+Ogg
Message-ID: <dba6c0830907060422w6b2f20ean4d259d2e03b78d45@mail.gmail.com>

Hi,

WHATWG is a public community specifying web technologies, such as HTML5.

Xiph.org is a public community specifying free codecs, such as Ogg Theora.

It's great that many people in the web community are supporting Ogg;
but it seems that specifying Ogg in HTML5 is not practical for WHATWG.
HTML5 and Ogg are just two public technologies that happen to work
really well together. If you are interesting in supporting the
combination of HTML5 and Ogg, here are some proactive steps you can
take:

  * contribute your ideas to http://wiki.xiph.org/HTML5

This page outlines some existing hosting options, useful Javascript
libraries and links to existing installations.

  * develop an HTML5+Ogg site, and tell people about it.

  * help write and translate documentation about combining these technologies.

Repeating the existing arguments on this list will not influence
standardization, but encouraging uptake of your favorite format will
influence future developers' decisions.

cheers,

Conrad.

From lists.whatwg at stakface.com  Mon Jul  6 04:49:31 2009
From: lists.whatwg at stakface.com (Kartikaya Gupta)
Date: Mon, 06 Jul 2009 11:49:31 +0000
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <Pine.LNX.4.62.0907060856130.1053@hixie.dreamhostps.com>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<Pine.LNX.4.62.0907060403030.1053@hixie.dreamhostps.com>
	<20090706050622.49FF314DD57@looneymail-mx2.g.dreamhost.com>
	<Pine.LNX.4.62.0907060856130.1053@hixie.dreamhostps.com>
Message-ID: <20090706114932.612A28DB001D@zapata.dreamhost.com>

On Mon, 6 Jul 2009 09:02:51 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
> > 
> > You've expressed something similar in a couple of the other threads as 
> > well, and I find it puzzling. It's true that if you spec things that 
> > will never be implemented, it harms the integrity of the spec. But on 
> > the other hand, if you allow any one vendor to determine what does or 
> > does not go into the spec [1], you're are exposing the spec to a much 
> > greater risk.
> 
> What risk?
> 

The risk I described below, where any one-man browser vendor can get a good chunk of the spec axed.

> 
> > In at least one other thread [2] you've implied that you treat all 
> > browser vendors as equal. If you put this together with the veto power 
> > it means that any browser vendor, "regardless of size" can get things 
> > axed from the spec. Am I missing something? What is stopping me from 
> > becoming a browser vendor and stating flat-out that I will not support 
> > any of the new additions in HTML5 just to kill off a good chunk of the 
> > spec? (Since I am working on a browser currently playing catch-up, this 
> > would certainly make my life easier).
> 
> Nothing is stopping you from doing that.
> 

Seriously? If I were to declare that I, as a browser vendor, will not support anything in HTML5 that wasn't in HTML4, would you actually remove all the new additions from the HTML5 spec?

> > It seems to me that you need to either take away this veto power you've 
> > given browser vendors, or you need to draw a line between the vendors 
> > that do have veto power and the ones that don't.
> 
> I haven't given browser vendors this veto power, they have it regardless. 

No, the browser vendors don't make changes to the HTML5 spec. You do, since you're the editor. I'm not talking about indirect layers of abstraction where they influence what you write. I'm talking about the person who actually makes the cvs commits because when push comes to shove, that person is the one who is actually making the changes to the spec (or not making any change, as the case may be).

> If implementors don't implement the spec, then the spec is fiction. 
> There's nothing I can do about that.
> 

Ah, but there *is* something you can do, and you're doing it. What you're doing to combat the spec from becoming fiction is saying "if a browser vendor won't implement this, I will take it out of the spec". This works to keep the spec and reality in sync, and prevents the spec from becoming fiction. It also provides browser vendors the veto power I'm talking about.

> > If you have already drawn such a line, I would like to know exactly 
> > where it is and what criteria were used to determine which vendors to 
> > allow and which ones to disallow.
> 
> In practice, a browser vendor has to have an installed base of a percent 
> or so overall before they can really affect the direction of the Web.
> 
> This isn't a decision I have made myself. It's just how the world is.

I'm not talking about the direction of the Web. I'm talking about the text that resides at http://www.whatwg.org/specs/web-apps/current-work/. The two are not the same thing. One is supposed to be a representation of the other, but that doesn't happen magically. You are that missing piece in the middle that is taking the real web and translating into the text at that URL. And as such, in the case of conflicting vendor behavior, you are the one that gets to decide which vendors you will take into account and which ones you will not. So let me re-ask my question: if a browser vendor has an installed base of greater than "a percent or so", and they flat-out state they will not implement, e.g. all the new <input> types in HTML5, will you take them out of the spec?

If the answer is yes, I would like specifics as to where that "percent or so" number comes from. There's lots of different ways people use to measure market share, which one are you using?

kats

From eric.carlson at apple.com  Mon Jul  6 06:29:38 2009
From: eric.carlson at apple.com (Eric Carlson)
Date: Mon, 06 Jul 2009 06:29:38 -0700
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <cc93256f0907060300gf975356g16a9a9dda00b813e@mail.gmail.com>
References: <Pine.LNX.4.62.0907060140230.1053@hixie.dreamhostps.com>
	<20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<02D0CC86D9034E91833E2B6EB7B83BBC@POCZTOWIEC>
	<cc93256f0907060052m154fd953x65b251449c735ab8@mail.gmail.com>
	<6EA4FF96-0398-487A-82CC-776CA238CBA8@apple.com>
	<cc93256f0907060300gf975356g16a9a9dda00b813e@mail.gmail.com>
Message-ID: <75596EA2-3A46-4CCA-A562-D4E838687D0E@apple.com>


On Jul 6, 2009, at 3:00 AM, Lino Mastrodomenico wrote:

>  (BTW, canPlayType in Safari 4.0 seems buggy: it always
> returns "no", even with XiphQT installed).
>
   That was fixed just after Safari 4.0 shipped, it should work in  
WebKit nightly builds. See http://trac.webkit.org/changeset/43972.

eric


From hansschmucker at gmail.com  Mon Jul  6 07:09:02 2009
From: hansschmucker at gmail.com (hansschmucker at gmail.com)
Date: Mon, 06 Jul 2009 14:09:02 +0000
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context
Message-ID: <000e0cd250ca57b1c9046e0a0cb6@google.com>

Hi everybody.

I've recently done some experiments using SVG filters (see  
http://www.tapper-ware.net/stable/web.filter.voxels/index.xhtml ). SVG  
Filters basically offer greater speed for users and easier optimization for  
implementing parties than trying to implement standard image manipulation  
through interpreted or compiled Javascript code. Filter operations can also  
easily be implemented via graphics accelerators, which results in far  
greater speed, which is especially important for mobile devices.

A large share of the typical operations performed by Canvas developers can  
be expressed easier via an SVG Filter like interface. Like contrast,  
brightness, blur and so on. Right now, such operations can sometimes be  
done in a hackish way, by combining the target image with a solid  
black/white picture and then masking it, or using getImageData, which is  
slow.

Mozilla also includes drawWindow, which allows a filtered element to be  
imported back into the Canvas, but there are dozens of security issues if  
you try to do that on the web (which is why it's only allowed for chrome).  
Aside from drawWindow, we are currently unable to build a processing chain  
that does include filters, other than applying a filter to the result  
rendered by the canvas via foreignObject.

SVG Filters are a relatively easy spec, where the most important parts can  
be implemented in a matter of hours. Also, since all browsers that  
currently support Canvas also support SVG, the actual functionality is  
already included in the source, so very little new code would have to be  
written.

I'm willing to write a spec for it if there's any interest, but for now,  
I'll just give you an example of how this could work.

The 2D Context gets a new method "createFilterChain()", that if invoked  
returns a Canvas2DContextFilterChain object.
A Canvas2DContextFilterChain is applied to any drawing much like  
globalAlpha via a globalFilterChain property.
A Canvas2DContextFilterChain is bound to a specific Canvas and can not be  
applied to anything else.
The affected region is by default the rectangle of the operation.
Canvas2DContextFilterChain instances have methods to add  
Canvas2DContextFilterNode elements, one for each type.
Note that there is no feImage equivalent to keep security complexities to a  
minimum.
Data is passed into a filter chain as BackgroundImage/Alpha (containing the  
image data in the target rectangle) and SourceImage/SourceAlpha for the  
data that is supposed to be drawn.
Each Canvas2DContextFilterNode operates in the RGBA32 space, no other color  
space is supported.
By default, each Canvas2DContextFilterNode is applied to a 0%,0% 100%,100%  
rectangle (the -10%,-10% rule of SVG is not applied)
For each Node, the coordinate system can be set to be Canvas relative or  
affected region relative.
Units are either numbers for absolute offsets from the chosen rectangle or  
percentages of the same.
Instead of the string based buffer system of SVG, each  
Canvas2DContextFilterNode has connectOutputImage/Alpha methods.


Am I the only one seeing any benefit for this or does anybody else think  
that would be hope for such a proposal?

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

From Simetrical+w3c at gmail.com  Mon Jul  6 11:18:56 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 6 Jul 2009 14:18:56 -0400
Subject: [whatwg] Codecs for <audio> and <video> -- informative note?
In-Reply-To: <fbad4e140907060101y2ac9454evbc643ae24e6e8273@mail.gmail.com>
References: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com>
	<fbad4e140907060101y2ac9454evbc643ae24e6e8273@mail.gmail.com>
Message-ID: <7c2a12e20907061118r6f4344bby894187cdb19fe062@mail.gmail.com>

On Mon, Jul 6, 2009 at 4:01 AM, David Gerard<dgerard at gmail.com> wrote:
> A spec that makes an encumbered format a "SHOULD" is unlikely to be
> workable for those content providers, e.g. Wikimedia, who don't have
> the money, and won't under principle, to put up stuff in a format
> rendered radioactive by known enforced patents.

That's why "should" is not the same as "must".  Those who have a good
reason not to do it can decline to do it.

From ashannon1000 at gmail.com  Mon Jul  6 11:45:35 2009
From: ashannon1000 at gmail.com (Adam Shannon)
Date: Mon, 6 Jul 2009 13:45:35 -0500
Subject: [whatwg] Codecs for <audio> and <video> -- informative note?
In-Reply-To: <7c2a12e20907061118r6f4344bby894187cdb19fe062@mail.gmail.com>
References: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com> 
	<fbad4e140907060101y2ac9454evbc643ae24e6e8273@mail.gmail.com> 
	<7c2a12e20907061118r6f4344bby894187cdb19fe062@mail.gmail.com>
Message-ID: <3c4f8cda0907061145r69ef2c50t4f2576d514a6be5c@mail.gmail.com>

The spec (at least from what I know) wants to create a unified experience,
we don't want users to have a different experience from browser to browser.
Nor do developers want to implement hacks for every browser.  If no common
ground can be reached then maybe no common ground is better than common
ground, who knows it may spark new ideas that we haven't thought of yet.

On Mon, Jul 6, 2009 at 1:18 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Mon, Jul 6, 2009 at 4:01 AM, David Gerard<dgerard at gmail.com> wrote:
> > A spec that makes an encumbered format a "SHOULD" is unlikely to be
> > workable for those content providers, e.g. Wikimedia, who don't have
> > the money, and won't under principle, to put up stuff in a format
> > rendered radioactive by known enforced patents.
>
> That's why "should" is not the same as "must".  Those who have a good
> reason not to do it can decline to do it.
>



-- 
- Adam Shannon ( http://ashannon.us )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/401d33f3/attachment.htm>

From awhyte at google.com  Mon Jul  6 11:46:57 2009
From: awhyte at google.com (Aaron Whyte)
Date: Mon, 6 Jul 2009 11:46:57 -0700
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains won't load
Message-ID: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>

When a page is loaded from an AppCache, even when online, external resources
such as images will not be loaded at all.
If foo.com has an image <img src="http://bar.com/img.png" />, then according
to the steps in
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
it will fail the load for the resource.
For example, someone with an Offline Gmail client would never be able to see
cross-domain images in emails, even when completely online.

There's no workaround in the current spec.  For user-defined img tags, like
those in webmail apps, the set of external domains is practically infinite.
 The NETWORK namespace, which requires a known domain for the
domain-matching check, won't help.  The FALLBACK namespace has to have a
known domain, that has to be the same as the manifest's domain, so it also
can't help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/168e1b5d/attachment-0001.htm>

From giecrilj at stegny.2a.pl  Mon Jul  6 11:57:09 2009
From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=)
Date: Mon, 6 Jul 2009 20:57:09 +0200
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains won't load
In-Reply-To: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
References: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
Message-ID: <6CAFD530D6D644CB96436479A290AFF9@POCZTOWIEC>

Not loading cross-domain images in e-mail messages is a standard privacy
feature e.g. in Microsoft Outlook.  (Indeed, that means that Microsoft
Outlook does not allow any external images, only attachments).

The workaround, to save as a HTML document and view in browser, should work.
If the images are important and viewing them stand-alone makes sense, the
user can also use the URL from image properties.

Therefore I do not think this particular problem is worth fighting with for
off-line Web applications.

IMHO,

Chris

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

From michaeln at google.com  Mon Jul  6 12:05:09 2009
From: michaeln at google.com (Michael Nordman)
Date: Mon, 6 Jul 2009 12:05:09 -0700
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains 	won't load
In-Reply-To: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
References: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
Message-ID: <fa2eab050907061205ja11f2ddh4f8ce5803785ab51@mail.gmail.com>

Yup... the source of grief is...

6.9.7 Changes to the networking model    5: Fail the resource load.

The intent behind this was "making the testing of offline application
easier". Given the unintended consequence Aaron brought up, we should
probably revisit this.

Maybe only fail to load the resource if its from the same-origin as the
manifest, otherwise load as usual.



On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyte <awhyte at google.com> wrote:

> When a page is loaded from an AppCache, even when online, external
> resources such as images will not be loaded at all.
> If foo.com has an image <img src="http://bar.com/img.png" />, then
> according to the steps in
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
> it will fail the load for the resource.
> For example, someone with an Offline Gmail client would never be able to
> see cross-domain images in emails, even when completely online.
>
> There's no workaround in the current spec.  For user-defined img tags, like
> those in webmail apps, the set of external domains is practically infinite.
>  The NETWORK namespace, which requires a known domain for the
> domain-matching check, won't help.  The FALLBACK namespace has to have a
> known domain, that has to be the same as the manifest's domain, so it also
> can't help.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/bcce2828/attachment.htm>

From Anton.Frattaroli at hc.msu.edu  Mon Jul  6 12:17:09 2009
From: Anton.Frattaroli at hc.msu.edu (Anton Frattaroli)
Date: Mon, 6 Jul 2009 15:17:09 -0400
Subject: [whatwg] HTML5 competing with XML
Message-ID: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>

I just read about how other markup languages (e.g. MathML, SVG) will be
implicitly namespace'd when put into an appropriate tag here:

 

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020740.htm
l

 

Allowing XML namespaces to be "inserted" into HTML5 is a neat feature,
but challenges its definition as a subset of XML.  I don't believe the
XML 1.0 specification allows this.  The XHTML specification would allow
a module to be added on to it (in the form of a DTD fragment), but in
this case it would no longer be its own markup language, but an add-on
to HTML5.

 

Mixing markup languages also makes the DOCTYPE declaration pretty much
null and void.  What's the point of a DTD if you're going to add in
other DTDs?

 

This is really challenging the whole direction the w3c has pointed out
for SGML.

 

-frattaro

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

From t.broyer at gmail.com  Mon Jul  6 12:47:00 2009
From: t.broyer at gmail.com (Thomas Broyer)
Date: Mon, 6 Jul 2009 21:47:00 +0200
Subject: [whatwg] HTML5 competing with XML
In-Reply-To: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>
References: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>
Message-ID: <a9699fd20907061247n2f86255dg123a66cc9bdc286e@mail.gmail.com>

On Mon, Jul 6, 2009 at 9:17 PM, Anton Frattaroli wrote:
> I just read about how other markup languages (e.g. MathML, SVG) will be
> implicitly namespace?d when put into an appropriate tag here:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020740.html
>
> Allowing XML namespaces to be ?inserted? into HTML5 is a neat feature, but
> challenges its definition as a subset of XML.? I don?t believe the XML 1.0
> specification allows this.

Implicit namespaces are a specificity of the text/html serialization;
on the other hand, application/xhtml+xml is XML and you have to play
by the XML rules: declare namespaces and eventually bind them to
prefixes; HTML5 doesn't change those rules.

> Mixing markup languages also makes the DOCTYPE declaration pretty much null
> and void.? What?s the point of a DTD if you?re going to add in other DTDs?

There's no DTD for HTML5, so?

-- 
Thomas Broyer

From jonas at sicking.cc  Mon Jul  6 13:28:20 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Mon, 6 Jul 2009 13:28:20 -0700
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains 	won't load
In-Reply-To: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
References: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
Message-ID: <63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>

On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyte<awhyte at google.com> wrote:
> When a page is loaded from an AppCache, even when online, external resources
> such as images will not be loaded at all.
> If foo.com has an image <img src="http://bar.com/img.png" />, then according
> to the steps in
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
> it will fail the load for the resource.
> For example, someone with an Offline Gmail client would never be able to see
> cross-domain images in emails, even when completely online.
> There's no workaround in the current spec.

The workaround is for the gmail to download the images to gmails
servers and then serve them from a google domain. Not as simple as
simply being able to cache urls from other servers I agree, but doing
multi domain application caches is very complicated from a security
point of view so I think we wanted to stay clear of it for the first
iteration of the spec.

/ Jonas

From jackalmage at gmail.com  Mon Jul  6 13:29:10 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 6 Jul 2009 15:29:10 -0500
Subject: [whatwg] HTML5 competing with XML
In-Reply-To: <a9699fd20907061247n2f86255dg123a66cc9bdc286e@mail.gmail.com>
References: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>
	<a9699fd20907061247n2f86255dg123a66cc9bdc286e@mail.gmail.com>
Message-ID: <dd0fbad0907061329k4a2d7e74sc221f54071cb7427@mail.gmail.com>

On Mon, Jul 6, 2009 at 2:47 PM, Thomas Broyer<t.broyer at gmail.com> wrote:
> On Mon, Jul 6, 2009 at 9:17 PM, Anton Frattaroli wrote:
>> Mixing markup languages also makes the DOCTYPE declaration pretty much null
>> and void.? What?s the point of a DTD if you?re going to add in other DTDs?
>
> There's no DTD for HTML5, so?

To be even more specific, HTML5 isn't an SGML-based language at all.
It merely bears superficial resemblance to SGML-based languages such
as HTML4.

~TJ

From sylvain.pasche at gmail.com  Mon Jul  6 13:30:29 2009
From: sylvain.pasche at gmail.com (Sylvain Pasche)
Date: Mon, 06 Jul 2009 22:30:29 +0200
Subject: [whatwg] DOMTokenList feedback
In-Reply-To: <1024649203EE4BE9B2EC8BB0C7CD19C8@POCZTOWIEC>
References: <h2rge3$7g6$1@ger.gmane.org>
	<1024649203EE4BE9B2EC8BB0C7CD19C8@POCZTOWIEC>
Message-ID: <4A525EE5.9030006@gmail.com>

On 7/6/2009 9:08 AM, Kristof Zelechovski wrote:
> Regarding DOMTokenList, why not:
> 	contains(""): true
> 	add,remove,toggle(""): no effect?

That could be an option. There is already a INVALID_CHARACTER_ERR 
exception thrown if the token contains spaces. So I think it would be 
consistent to throw an exception if the token is empty, following the 
rule "invalid tokens raise exception" (and considering empty tokens as 
invalid).

> Are there situations that would require an exception to be thrown, or else
> the page would go out in a blast?

Hard to say, but calling these functions with empty tokens certainly 
means there is a bug somewhere and throwing an exception in that case 
could help authors identify the issue when it happens.

Sylvain


From robert at ocallahan.org  Mon Jul  6 13:54:08 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 7 Jul 2009 08:54:08 +1200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <000e0cd250ca57b1c9046e0a0cb6@google.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
Message-ID: <11e306600907061354k5130a318kb8d97f1bb44f27ae@mail.gmail.com>

On Tue, Jul 7, 2009 at 2:09 AM, <hansschmucker at gmail.com> wrote:

> SVG Filters are a relatively easy spec, where the most important parts can
> be implemented in a matter of hours.


Speaking as an implementor of SVG filters, I don't believe you :-).

Am I the only one seeing any benefit for this or does anybody else think
> that would be hope for such a proposal?
>

I agree that we need a convenient way to use filters with canvas. But I
would rather not create an entirely new object model.

How about a drawImageWithFilter method that takes the same set of parameters
as drawImage plus a reference to an SVG <filter> element? The image is used
for Source/SourceAlpha and the size of the image establishes the object
bounding box for filter and filter primitive units. Since drawImage can draw
a canvas, this seems completely flexible.

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/20090707/3351b1b9/attachment.htm>

From michaeln at google.com  Mon Jul  6 14:05:13 2009
From: michaeln at google.com (Michael Nordman)
Date: Mon, 6 Jul 2009 14:05:13 -0700
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains 	won't load
In-Reply-To: <63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>
References: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
	<63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>
Message-ID: <fa2eab050907061405h27b65256l18a719bf70e88d71@mail.gmail.com>

Couple of comments...

1) Aaron's comment was not about caching them at all, it was about referring
to them from a cached application and having them load via the network as
usual. "Step 5" gets in the way of that.

2) The spec already allows for cross-origin caching, they can be explicitly
listed in a manifest file.


On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyte<awhyte at google.com> wrote:
> > When a page is loaded from an AppCache, even when online, external
> resources
> > such as images will not be loaded at all.
> > If foo.com has an image <img src="http://bar.com/img.png" />, then
> according
> > to the steps in
> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
> > it will fail the load for the resource.
> > For example, someone with an Offline Gmail client would never be able to
> see
> > cross-domain images in emails, even when completely online.
> > There's no workaround in the current spec.
>
> The workaround is for the gmail to download the images to gmails
> servers and then serve them from a google domain. Not as simple as
> simply being able to cache urls from other servers I agree, but doing
> multi domain application caches is very complicated from a security
> point of view so I think we wanted to stay clear of it for the first
> iteration of the spec.
>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/c19bdefa/attachment-0001.htm>

From hansschmucker at gmail.com  Mon Jul  6 14:21:21 2009
From: hansschmucker at gmail.com (hansschmucker at gmail.com)
Date: Mon, 06 Jul 2009 21:21:21 +0000
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <000e0cd250ca57b1c9046e0a0cb6@google.com>
Message-ID: <000e0cd250ca6cc8a5046e101602@google.com>

On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker at gmail.com> wrote:
> SVG Filters are a relatively easy spec, where the most important parts  
> can be implemented in a matter of hours.
On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
> Speaking as an implementor of SVG filters, I don't believe you :-).

I said most parts (by which I meant the actual image manipulations, which  
are defined pretty well in the SVG spec, not the surrounding issues of when  
to do drawing updates and so on that wouldn't apply to a Canvas  
anyway) :) . OK, I made it sound simpler than it is, but when you get right  
down to it, just the drawing code isn't terribly complicated.

On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker at gmail.com> wrote:
> Am I the only one seeing any benefit for this or does anybody else think  
> that would be hope for such a proposal?
On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
> I agree that we need a convenient way to use filters with canvas. But I  
> would rather not create an entirely new object model.
> How about a drawImageWithFilter method that takes the same set of  
> parameters as drawImage plus a reference to an SVG element? The image is  
> used for Source/SourceAlpha and the size of the image establishes the  
> object bounding box for filter and filter primitive units. Since  
> drawImage can draw a canvas, this seems completely flexible.

I'm fearing that the dependency on SVG would bring a lot of problems if a  
browser vendor wants to include just Canvas, like WebKit on the Palm Pre.  
Also, the SVG model is pretty complex when you include all the ways to  
cross-reference data. What would happen if a filter would want to load an  
image? Canvas can't work asyc, so either the whole call would fail or we'd  
lock up the browser for ages. Security issues would also increase tenfold  
as Canvas has a pretty simple security model. If we'd allow normal SVG  
filters, we'd probably need to flag the Canvas as "dirty", since SVG flters  
allow for loading of data from many sources, including what's currently on  
the screen. Or we forbid only dangerous elements, but that would mean that  
Canvas filters would look like SVG filters, but really function differently.

Including a dedicated filter API for Canvas would keep it simple and  
self-contained, allowing for much easier implementation, wouldn't it?

It would also give us a chance to strip out SVG stuff that doesn't make any  
sense for Canvas or is too complicated for too little benefit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/f7789cd6/attachment.htm>

From awhyte at google.com  Mon Jul  6 14:36:14 2009
From: awhyte at google.com (Aaron Whyte)
Date: Mon, 6 Jul 2009 14:36:14 -0700
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains 	won't load
In-Reply-To: <63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>
References: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
	<63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>
Message-ID: <a8329d140907061436x3543c9e4o903a975e6ad84014@mail.gmail.com>

On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sicking <jonas at sicking.cc> wrote:

>
> The workaround is for the gmail to download the images to gmails
> servers and then serve them from a google domain.


This isn't just an email problem.  It'll also affect RSS readers, document
editors, blogging tools, and other tools where user-defined HTML appears.


> Not as simple as
> simply being able to cache urls from other servers I agree, but doing
> multi domain application caches is very complicated from a security
> point of view so I think we wanted to stay clear of it for the first
> iteration of the spec.


I'd like to stay clear of it too.  I'm not saying that all these external
images should be AppCache-able or otherwise available offline.  I simply
want the option to have them work the way they do in normal, non-AppCached
pages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/0dbd02b4/attachment.htm>

From aa at google.com  Mon Jul  6 14:40:25 2009
From: aa at google.com (Aaron Boodman)
Date: Mon, 6 Jul 2009 14:40:25 -0700
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains 	won't load
In-Reply-To: <63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>
References: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
	<63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>
Message-ID: <278fd46c0907061440r3ceb559bm9bc80c9d34b9a339@mail.gmail.com>

On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sicking<jonas at sicking.cc> wrote:
> On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyte<awhyte at google.com> wrote:
>> When a page is loaded from an AppCache, even when online, external resources
>> such as images will not be loaded at all.
>> If foo.com has an image <img src="http://bar.com/img.png" />, then according
>> to the steps in
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
>> it will fail the load for the resource.
>> For example, someone with an Offline Gmail client would never be able to see
>> cross-domain images in emails, even when completely online.
>> There's no workaround in the current spec.
>
> The workaround is for the gmail to download the images to gmails
> servers and then serve them from a google domain. Not as simple as
> simply being able to cache urls from other servers I agree, but doing
> multi domain application caches is very complicated from a security
> point of view so I think we wanted to stay clear of it for the first
> iteration of the spec.

The spec already provides for loading resources not in the app cache
from the network (across origins or not). It simply defaults to not
allowing it. You have to opt-into the url prefixes you want to load
from the network.

I think we could fix this issue by simply changing the rules to
default to allowing requests, and having the author mark the url
prefixes he wants to blacklist from being loaded from the network.

- a

From robert at ocallahan.org  Mon Jul  6 15:15:46 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 7 Jul 2009 10:15:46 +1200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <000e0cd250ca6cc8a5046e101602@google.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
Message-ID: <11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>

On Tue, Jul 7, 2009 at 9:21 AM, <hansschmucker at gmail.com> wrote:

> On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker at gmail.com> wrote:
> > SVG Filters are a relatively easy spec, where the most important parts
> can be implemented in a matter of hours.
> On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
> > Speaking as an implementor of SVG filters, I don't believe you :-).
>
> I said most parts (by which I meant the actual image manipulations, which
> are defined pretty well in the SVG spec, not the surrounding issues of when
> to do drawing updates and so on that wouldn't apply to a Canvas anyway) :) .
> OK, I made it sound simpler than it is, but when you get right down to it,
> just the drawing code isn't terribly complicated.
>

Some of the filters aren't complicated, but some are. You're also talking
about duplicating the object model. And looking forward, if we do some
JIT-based or GPU-based filter acceleration, duplicating that work would
really suck. I would say the drawing code has to be shared even if the
object model is not.

On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
> > I agree that we need a convenient way to use filters with canvas. But I
> would rather not create an entirely new object model.
> > How about a drawImageWithFilter method that takes the same set of
> parameters as drawImage plus a reference to an SVG element? The image is
> used for Source/SourceAlpha and the size of the image establishes the object
> bounding box for filter and filter primitive units. Since drawImage can draw
> a canvas, this seems completely flexible.
>
> I'm fearing that the dependency on SVG would bring a lot of problems if a
> browser vendor wants to include just Canvas, like WebKit on the Palm Pre.
>

Webkit on iPhone and I think Android, and Fennec too, support SVG. If Palm
decides differently, that's their call and they can take the consequences. I
am deeply averse to duplicating functionality across specs "just in case"
someone implements one but not the other. It punishes authors and vendors of
full-function browsers.

Also, the SVG model is pretty complex when you include all the ways to
> cross-reference data. What would happen if a filter would want to load an
> image? Canvas can't work asyc, so either the whole call would fail or we'd
> lock up the browser for ages.
>

You'd just use whatever image you've got, just like SVG filter drawing does
normally. It's no different from doing drawImage with a partially loaded
image.


> Security issues would also increase tenfold as Canvas has a pretty simple
> security model. If we'd allow normal SVG filters, we'd probably need to flag
> the Canvas as "dirty", since SVG flters allow for loading of data from many
> sources, including what's currently on the screen.
>

You mean BackgroundImage? That makes no sense for canvas usage anyway, we'd
just ignore it. Foreign image usage would taint the canvas, that's easy to
do.

Including a dedicated filter API for Canvas would keep it simple and
> self-contained, allowing for much easier implementation, wouldn't it?
>

No, not really. Duplicating code is evil. Adding layers of abstraction so
that the same code can be used through different interfaces is less evil,
but it's still bad.

It would also give us a chance to strip out SVG stuff that doesn't make any
> sense for Canvas or is too complicated for too little benefit.
>

You see that as a chance. I see it as an opportunity for endless arguments.
And experience suggests that over time both sets of functionality will grow
to meet all users' requirements.

BTW with an HTML5 parser you can write <svg> content directly in HTML, which
makes it really easy to write an SVG filter to use with <canvas>.

One thing I would change is SVG filters should not clip to the filter region
or the filter primitive subregions. That's actually a change that should be
made to SVG (and I think the SVG WG is planning to make it), but for canvas
that should be the default.

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/20090707/27e289a4/attachment-0001.htm>

From ian at hixie.ch  Mon Jul  6 15:24:40 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 22:24:40 +0000 (UTC)
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <20090706114932.564B014DE21@looneymail-mx2.g.dreamhost.com>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<Pine.LNX.4.62.0907060403030.1053@hixie.dreamhostps.com>
	<20090706050622.49FF314DD57@looneymail-mx2.g.dreamhost.com>
	<Pine.LNX.4.62.0907060856130.1053@hixie.dreamhostps.com>
	<20090706114932.564B014DE21@looneymail-mx2.g.dreamhost.com>
Message-ID: <Pine.LNX.4.62.0907062213460.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
> 
> Seriously? If I were to declare that I, as a browser vendor, will not 
> support anything in HTML5 that wasn't in HTML4, would you actually 
> remove all the new additions from the HTML5 spec?

Not immediately, but if you had notable market share and we could not 
convince you to implement these new features, then yes, I'd remove them 
and then work with you (and everyone else) to try to come up with 
solutions that you _would_ agree to.

Even if you did not have notable market share, I would work with you to 
understand your objections, and try to resolve them. (Naturally if your 
goals are substantially different than the WHATWG's goals, then this might 
not go anywhere. For example, if Microsoft said that we should abandon 
HTML in favour of Silverlight, without making Silverlight backwards- 
compatible with HTML, then this would be somewhat of a non-starter, since 
backwards-compatibility is an underpinning of our work.)


> I'm not talking about the direction of the Web. I'm talking about the 
> text that resides at http://www.whatwg.org/specs/web-apps/current-work/. 
> The two are not the same thing.

If they're not one and the same, then I'm not doing my job.


> So let me re-ask my question: if a browser vendor has an installed base 
> of greater than "a percent or so", and they flat-out state they will not 
> implement, e.g. all the new <input> types in HTML5, will you take them 
> out of the spec?

Yes.


> If the answer is yes, I would like specifics as to where that "percent 
> or so" number comes from. There's lots of different ways people use to 
> measure market share, which one are you using?

I haven't needed to exclude a browser vendor before, so this hasn't come 
up. In practice, it's any browser vendor that has enough influence that if 
they fail to implement something, it'll affect broad deployment of the 
feature. Generally speaking, that would be the browsers that are important 
enough for sites like Wikipedia to include in their reports, e.g. on:

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

...but again, so far I've not had to decline the feedback of any browser 
vendor, including a number that were much smaller than those on that page.

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

From ian at hixie.ch  Mon Jul  6 15:33:07 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 22:33:07 +0000 (UTC)
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
 Context
In-Reply-To: <000e0cd250ca57b1c9046e0a0cb6@google.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
Message-ID: <Pine.LNX.4.62.0907062227190.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009 hansschmucker at gmail.com wrote:
> 
> Aside from drawWindow, we are currently unable to build a processing 
> chain that does include filters, other than applying a filter to the 
> result rendered by the canvas via foreignObject.

Doing filters in <canvas> is an interesting idea, but I think that it is 
probably too early to add it. We have dozens of feature requests for the 
next version of <canvas> already.

For what it's worth, you can do filters manually using getImageData() and 
putImageData().

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

From ian at hixie.ch  Mon Jul  6 15:36:23 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 22:36:23 +0000 (UTC)
Subject: [whatwg] HTML5 competing with XML
In-Reply-To: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>
References: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>
Message-ID: <Pine.LNX.4.62.0907062235290.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Anton Frattaroli wrote:
> 
> Allowing XML namespaces to be "inserted" into HTML5 is a neat feature,
> but challenges its definition as a subset of XML.

As others have noted, HTML5 in text/html isn't XML. If you want to use 
HTML5 with XML you have to use XHTML5, which does require you to declare 
your namespaces, as per the XML specification.


> Mixing markup languages also makes the DOCTYPE declaration pretty much 
> null and void.  What's the point of a DTD if you're going to add in 
> other DTDs?

We don't have DTDs in HTML5.


> This is really challenging the whole direction the w3c has pointed out 
> for SGML.

HTML5 doesn't use SGML at all.

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

From agrieve at google.com  Mon Jul  6 15:37:02 2009
From: agrieve at google.com (Andrew Grieve)
Date: Mon, 6 Jul 2009 15:37:02 -0700
Subject: [whatwg] Fragments included in Application Cache master entries
Message-ID: <3128e0550907061537hf48da6bsea9ee373d25d3f94@mail.gmail.com>

The current behavior in Webkit is for URL fragments to be stored in the
URLs for master entries. I believe this to be a bug in Webkit, but cannot
determine from the spec if this is or not.

Example:

1. Navigate to: http://www.thecssninja.com/demo/offline_webapp/#foo
2. Go offline
3. Do a browser refresh and ensure the page refreshes from AppCache.
4. Change the URL hash to #bar
5. Do a browser refresh and notice that it fails to load.

I've filed a bug on webkit.org (
https://bugs.webkit.org/show_bug.cgi?id=26925)
regarding this, but realized that the spec is unclear about what is
expected here. Since fragments are not sent to servers, I can't see
why they would be included in the master entry URLs as they make no
difference in the content that is served.

Anyone know if the spec does in fact address this issue?

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

From hansschmucker at gmail.com  Mon Jul  6 15:52:08 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 00:52:08 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
Message-ID: <f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>

On Tue, Jul 7, 2009 at 12:15 AM, Robert O'Callahan<robert at ocallahan.org> wrote:
> On Tue, Jul 7, 2009 at 9:21 AM, <hansschmucker at gmail.com> wrote:
>>
>> On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker at gmail.com> wrote:
>> > SVG Filters are a relatively easy spec, where the most important parts
>> > can be implemented in a matter of hours.
>> On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
>> > Speaking as an implementor of SVG filters, I don't believe you :-).
>>
>> I said most parts (by which I meant the actual image manipulations, which
>> are defined pretty well in the SVG spec, not the surrounding issues of when
>> to do drawing updates and so on that wouldn't apply to a Canvas anyway) :) .
>> OK, I made it sound simpler than it is, but when you get right down to it,
>> just the drawing code isn't terribly complicated.
>
> Some of the filters aren't complicated, but some are. You're also talking
> about duplicating the object model. And looking forward, if we do some
> JIT-based or GPU-based filter acceleration, duplicating that work would
> really suck. I would say the drawing code has to be shared even if the
> object model is not.
>
>> On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
>> > I agree that we need a convenient way to use filters with canvas. But I
>> > would rather not create an entirely new object model.
>> > How about a drawImageWithFilter method that takes the same set of
>> > parameters as drawImage plus a reference to an SVG element? The image is
>> > used for Source/SourceAlpha and the size of the image establishes the object
>> > bounding box for filter and filter primitive units. Since drawImage can draw
>> > a canvas, this seems completely flexible.
>>
>> I'm fearing that the dependency on SVG would bring a lot of problems if a
>> browser vendor wants to include just Canvas, like WebKit on the Palm Pre.
>
> Webkit on iPhone and I think Android, and Fennec too, support SVG. If Palm
> decides differently, that's their call and they can take the consequences. I
> am deeply averse to duplicating functionality across specs "just in case"
> someone implements one but not the other. It punishes authors and vendors of
> full-function browsers.

It may just be me, but I think that the success of Canvas, which is
way ahead of HTML5 in general, is largely due to the fact that it's
pretty much standalone. You don't have to read through hundreds of
pages of other documentation, you just read the Canvas spec and that's
pretty much it. Same for parties who want to implement it, there's
virtually no big dependency.

Of course, how you actually implement it (i.e. by sharing code with
the SVG filters) is not even something a spec is supposed to dictate,
you can share as much code as you want as long as the result is what
the spec says.

>> Also, the SVG model is pretty complex when you include all the ways to
>> cross-reference data. What would happen if a filter would want to load an
>> image? Canvas can't work asyc, so either the whole call would fail or we'd
>> lock up the browser for ages.
>
> You'd just use whatever image you've got, just like SVG filter drawing does
> normally. It's no different from doing drawImage with a partially loaded
> image.
Is this really useful for Canvas? Partial results are fine when all
you do is filter, but if the filter is part of a larger drawing
routine, then the result could be pretty undesirable. And since
there's no direct way to check for the status of the resource, all the
Canvas user could do would be trying again and again until it works
should we decide that methods should throw an error if a resource
isn't loaded yet.

>> Security issues would also increase tenfold as Canvas has a pretty simple
>> security model. If we'd allow normal SVG filters, we'd probably need to flag
>> the Canvas as "dirty", since SVG flters allow for loading of data from many
>> sources, including what's currently on the screen.
>
> You mean BackgroundImage? That makes no sense for canvas usage anyway, we'd
> just ignore it. Foreign image usage would taint the canvas, that's easy to
> do.
Nope, I meant the filter loading an SVG, loading a HTML via
foreignElement, loading another SVG via iframe, loading an image from
another server. BackgroundImage is of no use for Canvas anyway.

>> Including a dedicated filter API for Canvas would keep it simple and
>> self-contained, allowing for much easier implementation, wouldn't it?
> No, not really. Duplicating code is evil. Adding layers of abstraction so
> that the same code can be used through different interfaces is less evil,
> but it's still bad.
I think that abstraction would provide an OK compromise, but that's up
to the implementing parties.

>> It would also give us a chance to strip out SVG stuff that doesn't make
>> any sense for Canvas or is too complicated for too little benefit.
> You see that as a chance. I see it as an opportunity for endless arguments.
> And experience suggests that over time both sets of functionality will grow
> to meet all users' requirements.
But do you really want to explain to everybody who wants to use it
that the colorspace is not normal RGBA32, but some strange....
something? That the applied rectangle is actually 1.2x the given size
in any dimension? There is simply a lot of stuff in SVG that's meant
for graphics artists, not programmers. The usage would be different in
Canvas from what it is in SVG.

> BTW with an HTML5 parser you can write <svg> content directly in HTML, which
> makes it really easy to write an SVG filter to use with <canvas>.
And suddenly we have another dependency :) But seriously: What good is
a filter that is supplied somewhere in the document body to a dynamic
graphic. Why would I want to meddle with the DOM, when really all I
want to set is a local property? Maybe I could pipe the SVG in via
E4X, but that's just another dependency, that doesn't really do any
good.

> One thing I would change is SVG filters should not clip to the filter region
> or the filter primitive subregions. That's actually a change that should be
> made to SVG (and I think the SVG WG is planning to make it), but for canvas
> that should be the default.
I think I'll have to look that one up :)

--hans

From hansschmucker at gmail.com  Mon Jul  6 16:03:06 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 01:03:06 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <Pine.LNX.4.62.0907062227190.1053@hixie.dreamhostps.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<Pine.LNX.4.62.0907062227190.1053@hixie.dreamhostps.com>
Message-ID: <f7458d480907061603g512aa38fq3e4828929b2f4c94@mail.gmail.com>

> Doing filters in <canvas> is an interesting idea, but I think that it is
> probably too early to add it. We have dozens of feature requests for the
> next version of <canvas> already.
>
> For what it's worth, you can do filters manually using getImageData() and
> putImageData().

But if we begin with a more declarative approach now, we can actually
encourage browser vendors to include the functionality if they want
greater speed. Fallbacks to putImageData would provide basic
functionality anywhere, but if a vendor wants to access greater speed
for say, photo editing or games, he can chose to add filter support
and see an immediate speed increase.

Basically, filters for Canvas would provide new functionality through
speed. Responsiveness would increase dramatically for certain kinds of
applications.

From ian at hixie.ch  Mon Jul  6 16:24:26 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 23:24:26 +0000 (UTC)
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
 Context
In-Reply-To: <f7458d480907061603g512aa38fq3e4828929b2f4c94@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com> 
	<Pine.LNX.4.62.0907062227190.1053@hixie.dreamhostps.com>
	<f7458d480907061603g512aa38fq3e4828929b2f4c94@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907062323230.1053@hixie.dreamhostps.com>

On Tue, 7 Jul 2009, Hans Schmucker wrote:
> >
> > Doing filters in <canvas> is an interesting idea, but I think that it 
> > is probably too early to add it. We have dozens of feature requests 
> > for the next version of <canvas> already.
> >
> > For what it's worth, you can do filters manually using getImageData() 
> > and putImageData().
> 
> But if we begin with a more declarative approach now, we can actually 
> encourage browser vendors to include the functionality if they want 
> greater speed. Fallbacks to putImageData would provide basic 
> functionality anywhere, but if a vendor wants to access greater speed 
> for say, photo editing or games, he can chose to add filter support and 
> see an immediate speed increase.
> 
> Basically, filters for Canvas would provide new functionality through 
> speed. Responsiveness would increase dramatically for certain kinds of 
> applications.

I think in practice if people have declarative filter needs, they'll just 
use SVG. But that said, filters are indeed something we should look at in 
a future version. Right now, though, I'd rather we let the browser vendors 
get interoperable on what exists already in the spec.

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

From Pidgeot18 at verizon.net  Mon Jul  6 16:30:05 2009
From: Pidgeot18 at verizon.net (Joshua Cranmer)
Date: Mon, 06 Jul 2009 19:30:05 -0400
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
Message-ID: <4A5288FD.6090204@verizon.net>

Kartikaya Gupta wrote:
> I'm not sure whether specs can create demand, and frankly, I find it somewhat irrelevant to the point at hand. The fact is there is already demand for a single encoding format that will be compatible with as many browsers as possible. The only question is what that format will be. In this case, the spec doesn't need to create demand for anything, it just needs to tell people what that format is.
>   
The key point I think you've missed is that putting Theora (or H.264) as 
THE format in a specification won't make it so. One or the other codec 
is completely untenable under present circumstances to at least one 
major browser vendor. It is better that the specification reflect 
reality--that there is no such format, and there will not be one in the 
foreseeable future, than that it reflects a mythical utopia.

Perhaps what could break the deadlock would be Apple conceding to 
implementing Theora, or Mozilla conceding to implementing H.264. In 
either case, the decision to implement would most likely be a result of 
market pressure, not some arcane specification. Browser vendors can and 
will ignore specifications if the burden of implementation does not 
match the value of having it.
> A lot of those authors (not major publishers like YouTube, but the long tail that includes everybody else) will not bother to read the details of the decision; they will simply assume that since it is in the standard it will soon be supported by all the major browsers, and they will make their choices and start publishing content with that in mind.
I think you have a misconceived notion of the world here, too. Most of 
the HTML is not manually written by authors, it is automatically 
generated from programs, be it a Wiki-style generator, or a discrete 
utility like Dreamweaver. For the most part, those who write these 
programs--the people who will truly be writing and using the <video> 
tags--will be driven by what works in practice, not a statement in a 
specification that everyone ignores.
> 1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy?
>   
In short, no.
> 2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec?
>   
Well, pursuant to the answer to question 1, the choice is either between 
lying about the reality in claiming something works when it does not or 
admitting that there is no right answer. Since one of the intents of 
HTML 5 is to codify the status quo, I think it would be living up to its 
goal in following the latter steps.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth


From hansschmucker at gmail.com  Mon Jul  6 16:32:33 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 01:32:33 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <Pine.LNX.4.62.0907062323230.1053@hixie.dreamhostps.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<Pine.LNX.4.62.0907062227190.1053@hixie.dreamhostps.com>
	<f7458d480907061603g512aa38fq3e4828929b2f4c94@mail.gmail.com>
	<Pine.LNX.4.62.0907062323230.1053@hixie.dreamhostps.com>
Message-ID: <f7458d480907061632v6c79d918l5abe04b27e4b3672@mail.gmail.com>

> I think in practice if people have declarative filter needs, they'll just
> use SVG. But that said, filters are indeed something we should look at in
> a future version. Right now, though, I'd rather we let the browser vendors
> get interoperable on what exists already in the spec.

Often, you have need for both. Right now it's either fast,
declarative, but limited OR slow, but customizable.

About interoperability: At least for me Canvas support seems very
stable across browsers, which is why I'm comfortable asking for the
next step, as long as including it doesn't change compatibility with
existing JS code and wouldn't require needlessly complicated
fallbacks. Both fallbacks and support would be pretty straight-forward
for this.

From hansschmucker at gmail.com  Mon Jul  6 16:37:08 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 01:37:08 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
Message-ID: <f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>

I should really add one point. The Canvas spec, above all, is
predictable. You pretty much know exactly what you'll get when you
perform certain actions. Relying directly on SVG filters makes things
harder to understand and predict. A flat, stripped-down API on the
other hand could provide the same amount of predictability that we're
used to from Canvas,

If you directly include SVG, a developer who wants to use it has to
understand all of SVG, which is a pretty big spec, with lots of
unexpected behaviour. And as a result, often incorrect behaviour in
implementations.

--hans

From ian at hixie.ch  Mon Jul  6 16:39:58 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 6 Jul 2009 23:39:58 +0000 (UTC)
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
 Context
In-Reply-To: <f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907062338160.1053@hixie.dreamhostps.com>

On Tue, 7 Jul 2009, Hans Schmucker wrote:
> 
> About interoperability: At least for me Canvas support seems very stable 
> across browsers, which is why I'm comfortable asking for the next step, 
> as long as including it doesn't change compatibility with existing JS 
> code and wouldn't require needlessly complicated fallbacks. Both 
> fallbacks and support would be pretty straight-forward for this.

This is about more than just <canvas>; if we add more canvas features now, 
it takes resources away from other features in the spec. (Also, <canvas> 
isn't _that_ well supported yet; there are many edge cases where support 
is somewhat flaky.)

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

From robert at ocallahan.org  Mon Jul  6 16:45:58 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 7 Jul 2009 11:45:58 +1200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
Message-ID: <11e306600907061645u4715a098g93ffcb70a4c326ff@mail.gmail.com>

On Tue, Jul 7, 2009 at 10:52 AM, Hans Schmucker <hansschmucker at gmail.com>wrote:

> It may just be me, but I think that the success of Canvas, which is
> way ahead of HTML5 in general, is largely due to the fact that it's
> pretty much standalone. You don't have to read through hundreds of
> pages of other documentation, you just read the Canvas spec and that's
> pretty much it. Same for parties who want to implement it, there's
> virtually no big dependency.


That's not going to change, unless you want this relatively narrow extra
functionality. For those who do, someone can write an SVG-filters-for-canvas
tutorial that can ignore most of the SVG spec.

If we duplicate the feature, then someone who's already familiar with SVG or
canvas filters and wants to use the other will need to read twice as much
documentation, and try to keep two separate syntaxes for the same feature
straight in their head. I think you know that in Firefox we support SVG
filters for HTML content, and it's very useful, so it's quite likely that
advanced Web authors will be learning about SVG filters independent of
canvas.

Of course, how you actually implement it (i.e. by sharing code with
> the SVG filters) is not even something a spec is supposed to dictate,
> you can share as much code as you want as long as the result is what
> the spec says.


Yes, but the specs can make code sharing painful or even infeasible if they
diverge, even accidentally.

On Tue, Jul 7, 2009 at 12:15 AM, Robert O'Callahan<robert at ocallahan.org>
> wrote:
> > On Tue, Jul 7, 2009 at 9:21 AM, <hansschmucker at gmail.com> wrote:
> >> Also, the SVG model is pretty complex when you include all the ways to
> >> cross-reference data. What would happen if a filter would want to load
> an
> >> image? Canvas can't work asyc, so either the whole call would fail or
> we'd
> >> lock up the browser for ages.
> >
> > You'd just use whatever image you've got, just like SVG filter drawing
> does
> > normally. It's no different from doing drawImage with a partially loaded
> > image.
> Is this really useful for Canvas? Partial results are fine when all
> you do is filter, but if the filter is part of a larger drawing
> routine, then the result could be pretty undesirable. And since
> there's no direct way to check for the status of the resource, all the
> Canvas user could do would be trying again and again until it works
> should we decide that methods should throw an error if a resource
> isn't loaded yet.


In Gecko at least, the feImage element fires 'load' and 'error' events like
other image elements, and also blocks the document load event while it's
loading, so waiting for it to fully load is easy.

Nope, I meant the filter loading an SVG, loading a HTML via
> foreignElement, loading another SVG via iframe, loading an image from
> another server. BackgroundImage is of no use for Canvas anyway.


We already have to solve that problem when we support SVG images with
drawImage, which is already in the spec (implicitly).

But do you really want to explain to everybody who wants to use it
> that the colorspace is not normal RGBA32, but some strange....
> something?


I think we should change the SVG spec so that the default value of
color-interpolation-filters is sRGB.


> That the applied rectangle is actually 1.2x the given size
> in any dimension?


As I said in my previous email, the SVG working group is already receptive
to the idea of changing SVG filters so we don't clip to the filter region,
in which case the filter region (and its -10%,-10%,120%,120% default) can be
ignored in most cases.

There is simply a lot of stuff in SVG that's meant
> for graphics artists, not programmers. The usage would be different in
> Canvas from what it is in SVG.


There's a lot of stuff in SVG that's meant for programmers too. Some of it's
just not very well done, and will have to be fixed. I think it's pretty
clear programmers are a more suitable audience for SVG filters than graphic
artists...

> BTW with an HTML5 parser you can write <svg> content directly in HTML,
> which
> > makes it really easy to write an SVG filter to use with <canvas>.
> And suddenly we have another dependency :)


Not a dependency, just a convenience.


> But seriously: What good is
> a filter that is supplied somewhere in the document body to a dynamic
> graphic. Why would I want to meddle with the DOM, when really all I
> want to set is a local property?


In many cases it's easier to write markup and refer to it than to write
code. The goal here is to support declarative filters, after all.

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/20090707/560bd7e4/attachment.htm>

From robert at ocallahan.org  Mon Jul  6 16:47:56 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 7 Jul 2009 11:47:56 +1200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
Message-ID: <11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>

On Tue, Jul 7, 2009 at 11:37 AM, Hans Schmucker <hansschmucker at gmail.com>wrote:

> I should really add one point. The Canvas spec, above all, is
> predictable. You pretty much know exactly what you'll get when you
> perform certain actions.


Like arcTo?


> Relying directly on SVG filters makes things
> harder to understand and predict. A flat, stripped-down API


APIs don't remain stripped-down for long.

If you directly include SVG, a developer who wants to use it has to
> understand all of SVG,


That is completely untrue.


> which is a pretty big spec, with lots of
> unexpected behaviour. And as a result, often incorrect behaviour in
> implementations.
>

Yet you're asking us to duplicate code, which inevitably leads to even more
bugs.

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/20090707/98e79675/attachment-0001.htm>

From Simetrical+w3c at gmail.com  Mon Jul  6 17:05:54 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 6 Jul 2009 20:05:54 -0400
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <4A5288FD.6090204@verizon.net>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com>
	<4A5288FD.6090204@verizon.net>
Message-ID: <7c2a12e20907061705i6c5f496ct63e41e19dc0aa165@mail.gmail.com>

On Mon, Jul 6, 2009 at 7:30 PM, Joshua Cranmer<Pidgeot18 at verizon.net> wrote:
> Perhaps what could break the deadlock would be Apple conceding to
> implementing Theora, or Mozilla conceding to implementing H.264. In either
> case, the decision to implement would most likely be a result of market
> pressure, not some arcane specification.

Given that Apple's only stated reason for not implementing Theora
support alongside H.264 is the patent risk, and given that a company
nearly as large as Apple (Google) has taken the risk and not gotten
sued yet, I'm personally hoping that market pressure won't be
necessary to get Apple to change its mind.  Every other good argument
I've heard advanced against Theora argues against supporting it as the
only standard, but not against supporting it as a baseline minimal
standard.

> I think you have a misconceived notion of the world here, too. Most of the
> HTML is not manually written by authors, it is automatically generated from
> programs, be it a Wiki-style generator, or a discrete utility like
> Dreamweaver. For the most part, those who write these programs--the people
> who will truly be writing and using the <video> tags--will be driven by what
> works in practice, not a statement in a specification that everyone ignores.

As someone who does write one of those programs, I have to say it's
remarkable how many people actually do want to pointlessly follow
meaningless requirements of specifications.  How many respectable web
app packages *don't* slavishly include things like type="text/css" so
that the W3C validator will magically bestow conformance upon them?
(Until the validator gets updated and they have to scramble to fix the
new pointless things it covers.)  How many have gone out of their way
to eliminate table-based markup, because they heard it was bad
practice -- and replaced it with divs and spans with presentational
classes?

I once did some quick manual hacking and determined that a MediaWiki
page could have the size of its HTML source cut by 5% or so if you
took out all the pointless stuff that XHTML 1 requires but HTML 5
permits you to omit.  And that's comparing the *gzipped* files.
Seriously.  Keep in mind that all browsers simply ignore this garbage.
 The pages were totally identical after parsing (unless I messed up).

That said, the above admittedly only applies if the specification does
actually work in practice.  But don't underestimate web app authors'
desire to conform to standards, even ones that make no sense or that
they don't understand.

From hansschmucker at gmail.com  Mon Jul  6 17:10:39 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 02:10:39 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
	<11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>
Message-ID: <f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com>

On Tue, Jul 7, 2009 at 1:47 AM, Robert O'Callahan<robert at ocallahan.org> wrote:
> On Tue, Jul 7, 2009 at 11:37 AM, Hans Schmucker <hansschmucker at gmail.com>
> wrote:
>>
>> I should really add one point. The Canvas spec, above all, is
>> predictable. You pretty much know exactly what you'll get when you
>> perform certain actions.
>
> Like arcTo?

OK, there may be some border cases. But in general Canvas is a whole
lot more predictable than anything else you'll find in a browser.

>
>>
>> Relying directly on SVG filters makes things
>> harder to understand and predict. A flat, stripped-down API
>
> APIs don't remain stripped-down for long.

They can, if the individual modules are specific enough. Future
versions may add more filters, but the basic API would stay the same.
When you use SVG filters, there are lots of question marks in the
equation. Like, how will it render dynamic content loaded from inside
the current document, how an animation from an outside document, how
will it deal with foreignContent, how with form data inside it? All
this is largely irrelevant for Canvas, but it would still have to be
considered. A simple API could get rid of such cases straight away.


>
>> If you directly include SVG, a developer who wants to use it has to
>> understand all of SVG,
>
> That is completely untrue.

That was a bit over-dramatic. But try to learn SVG filters without an
in-depth knowledge of SVG first. There are many points that you can
trip over. Stuff that your garden-variety HTML/JS developer would just
understand differently (color spaces, units, rectangles, ...).

>> which is a pretty big spec, with lots of
>> unexpected behaviour. And as a result, often incorrect behaviour in
>> implementations.
>
> Yet you're asking us to duplicate code, which inevitably leads to even more
> bugs.

Again, you can share as much drawing code as you like, but after all,
how the filter is applied to Canvas would have to be written from
scratch anyway,

From ian at hixie.ch  Mon Jul  6 17:30:40 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 00:30:40 +0000 (UTC)
Subject: [whatwg] Session history
In-Reply-To: <4A4D14FD.1090401@helsinki.fi>
References: <4A4D14FD.1090401@helsinki.fi>
Message-ID: <Pine.LNX.4.62.0907060437470.1060@hixie.dreamhostps.com>

On Thu, 2 Jul 2009, Olli Pettay wrote:
> 
> [22:59]	<smaug>	I'm trying to understand the "Each browsing context, including
> nested browsing context, has a distinct session history."
> [23:00]	<smaug>	but in practice if go(-1) is called in a iframe (and it hasn't
> been navigated from the original page), the top level page is navigated

I've now fixed the spec to match IE's behaviour when it comes to 
history.go(), history.length, and history.back().

This doesn't quite match what Gecko, Webkit, or Opera do, but then they 
all each do their own slightly different thing, so I had to pick one, and 
IE seemed like the obvious choice.

I have some tests here:
   http://www.hixie.ch/tests/adhoc/dom/level0/history/

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

From hansschmucker at gmail.com  Mon Jul  6 17:38:00 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 02:38:00 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
	<11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>
	<f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com>
Message-ID: <f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com>

*sigh* I hate it when I start sounding whiny and I probably did in the
previous posts.

I'll try to sum it up again without the whining sound.

I simply think that when using SVG filters, we are much more likely to
add a lot of these "border-cases" where browsers behave subtly
different. We already have that problem with SVG in general and it's
really holding SVG back. If at all possible, I'd like to avoid that
with Canvas filters. A lot of functionality offered by SVG filters is
either already included elsewhere in the Canvas spec or simply not
relevant. I think if we strip the filter API of these cases we can
make using it a lot more stable, predictable and attractive to
developers.

From ian at hixie.ch  Mon Jul  6 17:44:09 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 00:44:09 +0000 (UTC)
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
 Context
In-Reply-To: <f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
	<11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>
	<f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com>
	<f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907070043540.1053@hixie.dreamhostps.com>

On Tue, 7 Jul 2009, Hans Schmucker wrote:
> 
> I simply think that when using SVG filters, we are much more likely to 
> add a lot of these "border-cases" where browsers behave subtly 
> different. We already have that problem with SVG in general and it's 
> really holding SVG back. If at all possible, I'd like to avoid that with 
> Canvas filters. A lot of functionality offered by SVG filters is either 
> already included elsewhere in the Canvas spec or simply not relevant. I 
> think if we strip the filter API of these cases we can make using it a 
> lot more stable, predictable and attractive to developers.

If we add filters to <canvas>, I would expect to be defined in a way that 
doesn't leave edge cases undefined.

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

From hansschmucker at gmail.com  Mon Jul  6 17:47:55 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 02:47:55 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <Pine.LNX.4.62.0907070043540.1053@hixie.dreamhostps.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
	<11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>
	<f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com>
	<f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com>
	<Pine.LNX.4.62.0907070043540.1053@hixie.dreamhostps.com>
Message-ID: <f7458d480907061747j3b68096cv265d626100f0f151@mail.gmail.com>

> If we add filters to <canvas>, I would expect to be defined in a way that
> doesn't leave edge cases undefined.
But for all practical purposes, that would be what we'd do if we just
said "just use your usual SVG filter system",

From robert at ocallahan.org  Mon Jul  6 18:01:23 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 7 Jul 2009 13:01:23 +1200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
	<11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>
	<f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com>
	<f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com>
Message-ID: <11e306600907061801j6fa00ac7x87b248360408ea46@mail.gmail.com>

On Tue, Jul 7, 2009 at 12:38 PM, Hans Schmucker <hansschmucker at gmail.com>wrote:

> I simply think that when using SVG filters, we are much more likely to
> add a lot of these "border-cases" where browsers behave subtly
> different. We already have that problem with SVG in general and it's
> really holding SVG back.


Whatever those issues are that you're referring to, they need to be fixed in
SVG already. Creating a new set of "well-defined" behaviours in <canvas> can
only add more work. If the new "well-defined" behaviours fail to match the
behaviour SVG requires, then the situation will be even worse.

(I'd actually like to know what all these SVG filter "border-cases" are.
I've discovered a few spec issues and reported them to the SVG list, but not
too many. There are certainly browser bugs in some cases, but any new
proposal will have browser bugs too.)

A lot of functionality offered by SVG filters is
> either already included elsewhere in the Canvas spec or simply not
> relevant.


Like what?

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/20090707/b38a3d5c/attachment.htm>

From chuck at jumis.com  Mon Jul  6 18:03:47 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Mon, 06 Jul 2009 18:03:47 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
Message-ID: <4A529EF3.6010702@jumis.com>

Ian Hickson wrote:
> On Thu, 2 Jul 2009, Charles Pritchard wrote:
>   
>> I'd like to see <canvas> support added to the <video> tag (it's as 
>> natural as <img>).
>>     
>
> <video> elements can be painted onto <canvas> elements already; did you 
> have something more in mind?
>   
This is sufficient. <video> can be used with the drawImage tag,
and original video element can be hidden.

>> and enable the <audio> tag to accept raw data lpcm),
>> just as the <canvas> tag accepts raw data (bitmap).
>>     
>
> This is on the list of things to consider in a future version. At this 
> point I don't really want to add new features yet because otherwise we'll 
> never get the browser vendors caught up to implementing the same spec. :-)
>   
Consider a programmable <audio> element as a priority.

Apple has said they will not carry the Vorbis codec in their distributions.
I don't see any objection in them carrying a programmable <audio> element.

With a raw data api, Vorbis enthusiasts may share their codec.
Otherwise, HTML 5 is codec naive.

Programmable audio has support in Flash and Java, and their wide audience.
WebIDL is described in ECMAScript and Java.

I believe this is an achievable compromise.

It's already available in ActionScript and Java,
and their associated VMs installed on well over 90% of web browsers,
with open source development tools and compilers.

>> And add an event handler when subtitles are enabled / disabled.
>>     
>
> This is on the list for the next version. (Generally speaking, control 
> over subtitles is one of the very next features that will be added.)
>
>   
Meanwhile, using a <canvas> tag, drawImage(HTMLVideoElement) and fillText
are sufficient.

>> I'd think that FLAC would make more sense than PCM-in-Wave, as a PNG 
>> analog.
>>     
>
> I encourage you to suggest this straight to the relevant vendors. As it 
> stands, HTML5 is codec-neutral.
>   
Perhaps it's not necessary.

There's no need to standardize on an audio codec.
It can be handled in a device independent manner,
provided the player for that codec can be expressed in
ECMAScript+Java (see: WebIDL).


>> I'd like to see a font analog in audio as well. Canvas supports the font 
>> attribute, audio could certainly support sound fonts. Use a generated 
>> pitch if your platform can't or doesn't store sound fonts.
>>     
>
> This seems like an issue for the CSS or SVG working groups, who are 
> working on font-related technologies.
>   
Should it gather any momentum, this would be an attribute which 
HTMLMediaElement tags should
be aware of. For example: <audio style="-ext-audio-font: 
tone|url(arbitrary.url)" />.

Should the audio source be a container format, such as midi, it would 
interpret the css property.


>> "User agents should provide controls to enable the manual selection of 
>> fallback content."
>>     
>
> There's no reason the UA couldn't provide an override mechanism to select 
> an alternative source if the UA vendor so desires.
>   
I was considering the current dead-lock about the situation of h.264 and 
theora codecs.
An explicit statement encourages UA-developers to adopt good practices.
>> Many non-technical users will want to know why there is a black screen 
>> (or still image), even though they can hear the audio.
>>     
This section works well:

"User agents that cannot render the video may instead make the element 
represent a link to an external video playback utility or to the video 
data itself."


From ian at hixie.ch  Mon Jul  6 18:04:57 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 01:04:57 +0000 (UTC)
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
 Context
In-Reply-To: <f7458d480907061747j3b68096cv265d626100f0f151@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com> 
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com> 
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com> 
	<11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com> 
	<f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com> 
	<f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com> 
	<Pine.LNX.4.62.0907070043540.1053@hixie.dreamhostps.com>
	<f7458d480907061747j3b68096cv265d626100f0f151@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907070104080.1053@hixie.dreamhostps.com>

On Tue, 7 Jul 2009, Hans Schmucker wrote:
> >
> > If we add filters to <canvas>, I would expect to be defined in a way 
> > that doesn't leave edge cases undefined.
>
> But for all practical purposes, that would be what we'd do if we just 
> said "just use your usual SVG filter system",

That's possible, I haven't looked into it. As I mentioned, I think we're 
better off waiting some time before adding this feature anyway.

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

From ian at hixie.ch  Mon Jul  6 18:08:02 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 01:08:02 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A529EF3.6010702@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
Message-ID: <Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Charles Pritchard wrote:
> > 
> > This is on the list of things to consider in a future version. At this 
> > point I don't really want to add new features yet because otherwise 
> > we'll never get the browser vendors caught up to implementing the same 
> > spec. :-)
>
> Consider a programmable <audio> element as a priority.

Could you elaborate on what your use cases are? Is it just the ability to 
manually decode audio tracks?


> > > I'd like to see a font analog in audio as well. Canvas supports the 
> > > font attribute, audio could certainly support sound fonts. Use a 
> > > generated pitch if your platform can't or doesn't store sound fonts.
> > 
> > This seems like an issue for the CSS or SVG working groups, who are 
> > working on font-related technologies.
>
> Should it gather any momentum, this would be an attribute which 
> HTMLMediaElement tags should be aware of. For example: <audio 
> style="-ext-audio-font: tone|url(arbitrary.url)" />.
> 
> Should the audio source be a container format, such as midi, it would 
> interpret the css property.

If the CSS working group go down this road, I shall make sure HTML5 is 
compatible with what the CSS working group define.


> > > "User agents should provide controls to enable the manual selection 
> > > of fallback content."
> > 
> > There's no reason the UA couldn't provide an override mechanism to 
> > select an alternative source if the UA vendor so desires.
>
> I was considering the current dead-lock about the situation of h.264 and
> theora codecs.
> An explicit statement encourages UA-developers to adopt good practices.

I encourage you to contact the user agents directly. I generally try to 
avoid specifying UI in the specification.

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

From hansschmucker at gmail.com  Mon Jul  6 18:08:57 2009
From: hansschmucker at gmail.com (Hans Schmucker)
Date: Tue, 7 Jul 2009 03:08:57 +0200
Subject: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
	Context
In-Reply-To: <11e306600907061801j6fa00ac7x87b248360408ea46@mail.gmail.com>
References: <000e0cd250ca57b1c9046e0a0cb6@google.com>
	<000e0cd250ca6cc8a5046e101602@google.com>
	<11e306600907061515hda85768u844af0fff80cbde9@mail.gmail.com>
	<f7458d480907061552i14a135edyb79bdcf9debaebb6@mail.gmail.com>
	<f7458d480907061637r7f8cad8ch42998801e638cbf7@mail.gmail.com>
	<11e306600907061647j2d6d115ft618f6e2acc9e65cb@mail.gmail.com>
	<f7458d480907061710l7e027b8ak33e60f546a1cc7e5@mail.gmail.com>
	<f7458d480907061738k26eca225j4d4583cf71d1d14f@mail.gmail.com>
	<11e306600907061801j6fa00ac7x87b248360408ea46@mail.gmail.com>
Message-ID: <f7458d480907061808p684da06cob65a99b725cfef22@mail.gmail.com>

> Whatever those issues are that you're referring to, they need to be fixed in
> SVG already. Creating a new set of "well-defined" behaviours in <canvas> can
> only add more work. If the new "well-defined" behaviours fail to match the
> behaviour SVG requires, then the situation will be even worse.

feImage is my problem case #1. There's some other odd stuff, but
feImage is really my top concern.
Anything else will have to wait till tomorrow: I'm off to bed.

From michaeln at google.com  Mon Jul  6 18:17:09 2009
From: michaeln at google.com (Michael Nordman)
Date: Mon, 6 Jul 2009 18:17:09 -0700
Subject: [whatwg] In AppCache web apps,
	images from unpredictable domains 	won't load
In-Reply-To: <278fd46c0907061440r3ceb559bm9bc80c9d34b9a339@mail.gmail.com>
References: <a8329d140907061146o20af3ae6n1f5f55d3670675ca@mail.gmail.com>
	<63df84f0907061328y557c0399y164d610252390620@mail.gmail.com>
	<278fd46c0907061440r3ceb559bm9bc80c9d34b9a339@mail.gmail.com>
Message-ID: <fa2eab050907061817w3c9e8146i5c74fc322853793f@mail.gmail.com>

On Mon, Jul 6, 2009 at 2:40 PM, Aaron Boodman <aa at google.com> wrote:

> On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sicking<jonas at sicking.cc> wrote:
> > On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyte<awhyte at google.com> wrote:
> >> When a page is loaded from an AppCache, even when online, external
> resources
> >> such as images will not be loaded at all.
> >> If foo.com has an image <img src="http://bar.com/img.png" />, then
> according
> >> to the steps in
> >>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
> >> it will fail the load for the resource.
> >> For example, someone with an Offline Gmail client would never be able to
> see
> >> cross-domain images in emails, even when completely online.
> >> There's no workaround in the current spec.
> >
> > The workaround is for the gmail to download the images to gmails
> > servers and then serve them from a google domain. Not as simple as
> > simply being able to cache urls from other servers I agree, but doing
> > multi domain application caches is very complicated from a security
> > point of view so I think we wanted to stay clear of it for the first
> > iteration of the spec.
>
> The spec already provides for loading resources not in the app cache
> from the network (across origins or not). It simply defaults to not
> allowing it. You have to opt-into the url prefixes you want to load
> from the network.
>
> I think we could fix this issue by simply changing the rules to
> default to allowing requests, and having the author mark the url
> prefixes he wants to blacklist from being loaded from the network.


That would work too. We'd have to introduce a new kind of 'namespace' in the
manifest file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/e88a1ff8/attachment.htm>

From chuck at jumis.com  Mon Jul  6 18:24:12 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Mon, 06 Jul 2009 18:24:12 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
Message-ID: <4A52A3BC.2010608@jumis.com>

Ian Hickson wrote:
> On Mon, 6 Jul 2009, Charles Pritchard wrote:
>   
>>> This is on the list of things to consider in a future version. At this 
>>> point I don't really want to add new features yet because otherwise 
>>> we'll never get the browser vendors caught up to implementing the same 
>>> spec. :-)
>>>       
>> Consider a programmable <audio> element as a priority.
>>     
>
> Could you elaborate on what your use cases are? Is it just the ability to 
> manually decode audio tracks?
>   
Some users could manually decode a Vorbis audio stream.

I'm interested in altering pitch and pre-mixing channels.
I believe some of these things are explored in CSS already.

There are accessibility cases, for the visually impaired,
and I think that they will be better explored.

-Charles

From ian at hixie.ch  Mon Jul  6 18:28:47 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 01:28:47 +0000 (UTC)
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A52A3BC.2010608@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
	<4A52A3BC.2010608@jumis.com>
Message-ID: <Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Charles Pritchard wrote:
> Ian Hickson wrote:
> > On Mon, 6 Jul 2009, Charles Pritchard wrote:
> > > > This is on the list of things to consider in a future version. At 
> > > > this point I don't really want to add new features yet because 
> > > > otherwise we'll never get the browser vendors caught up to 
> > > > implementing the same spec. :-)
> > >
> > > Consider a programmable <audio> element as a priority.
> > 
> > Could you elaborate on what your use cases are? Is it just the ability 
> > to manually decode audio tracks?
>
> Some users could manually decode a Vorbis audio stream.
> 
> I'm interested in altering pitch and pre-mixing channels. I believe some 
> of these things are explored in CSS already.
> 
> There are accessibility cases, for the visually impaired, and I think 
> that they will be better explored.

If you could elaborate on these use cases that would be really useful. How 
do you envisage using these features on Web pages?

(There has been some discussion of suppoting an "audio canvas" before, but 
a lack of compelling use cases has really been the main blocker. Without a 
good understanding of the use cases, it's hard to design an API.)

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

From chuck at jumis.com  Mon Jul  6 18:44:25 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Mon, 06 Jul 2009 18:44:25 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
	<4A52A3BC.2010608@jumis.com>
	<Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
Message-ID: <4A52A879.50403@jumis.com>

Ian Hickson wrote:
> On Mon, 6 Jul 2009, Charles Pritchard wrote:
>   
>> Ian Hickson wrote:
>>     
>>> On Mon, 6 Jul 2009, Charles Pritchard wrote:
>>>       
>>>>> This is on the list of things to consider in a future version. At 
>>>>> this point I don't really want to add new features yet because 
>>>>> otherwise we'll never get the browser vendors caught up to 
>>>>> implementing the same spec. :-)
>>>>>           
>>>> Consider a programmable <audio> element as a priority.
>>>>         
>>> Could you elaborate on what your use cases are? Is it just the ability 
>>> to manually decode audio tracks?
>>>       
>> Some users could manually decode a Vorbis audio stream.
>>
>> I'm interested in altering pitch and pre-mixing channels. I believe some 
>> of these things are explored in CSS already.
>>
>> There are accessibility cases, for the visually impaired, and I think 
>> that they will be better explored.
>>     
>
> If you could elaborate on these use cases that would be really useful. How 
> do you envisage using these features on Web pages?
>   
Use a sound of varying pitch to hint to a user the location of their mouse
(is it hovering over a button, is it x/y pixels away from the edge of 
the screen, how close is it to the center).

Alter the pitch of a sound to make a very cheap midi instrument.

Pre-mix a few generated sounds, because the client processor is slow.

Alter the pitch of an actual audio recording, and pre-mix it,
to give different sounding voices to pre-recorded readings of a single text.
As has been tried for "male" "female" sound fonts.

Support very simple audio codecs, and programmable synthesizers.

The API must support a playback buffer.

putAudioBuffer(in AudioData) [ Error if audiodata properties are not 
supported ]
createAudioData( in sample hz, bits per sample, length ) [ Error if 
properties are not supported. ]
AudioData ( sampleHz, bitsPerSample, length, AudioDataArray )
AudioDataArray ( length, IndexGetter, IndexSetter ) 8 bits per property.

I think that's about it.

> (There has been some discussion of suppoting an "audio canvas" before, but 
> a lack of compelling use cases has really been the main blocker. Without a 
> good understanding of the use cases, it's hard to design an API.)
>
>   


From oliver at apple.com  Mon Jul  6 18:57:44 2009
From: oliver at apple.com (Oliver Hunt)
Date: Mon, 6 Jul 2009 18:57:44 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
Message-ID: <7BDABBC0-3442-4A62-AAD5-CB83BD45B3ED@apple.com>


On Jul 6, 2009, at 6:08 PM, Ian Hickson wrote:

> On Mon, 6 Jul 2009, Charles Pritchard wrote:
>>>
>>> This is on the list of things to consider in a future version. At  
>>> this
>>> point I don't really want to add new features yet because otherwise
>>> we'll never get the browser vendors caught up to implementing the  
>>> same
>>> spec. :-)
>>
>> Consider a programmable <audio> element as a priority.
>
> Could you elaborate on what your use cases are? Is it just the  
> ability to
> manually decode audio tracks?

I actually have thought about this.  Having an ability to post- 
process, mix, or generate audio content manually is useful for certain  
classes of games and applications.

--Oliver
  

From maria.khomenko at gmail.com  Mon Jul  6 19:13:00 2009
From: maria.khomenko at gmail.com (Maria Khomenko)
Date: Mon, 6 Jul 2009 19:13:00 -0700
Subject: [whatwg] Fragments included in Application Cache master entries
In-Reply-To: <3128e0550907061537hf48da6bsea9ee373d25d3f94@mail.gmail.com>
References: <3128e0550907061537hf48da6bsea9ee373d25d3f94@mail.gmail.com>
Message-ID: <4bc348310907061913k392c7b15l5cae909fb0eddcf6@mail.gmail.com>

Actually, I believe the spec does address the question in the following
passage (this is in the manifest parsing algorithm):


> If mode is "explicit"

Resolve the first item in tokens, relative to base URL; ignore the rest.


> If this fails, then jump back to the step labeled "start of line".


> If the resulting absolute URL has a different <scheme> component than the
> manifest's URL (compared in an ASCII case-insensitive manner), then jump
> back to the step labeled "start of line".


> *Drop the <fragment> component of the resulting absolute URL, if it has
> one.*


> Add the resulting absolute URL to the explicit URLs.


So it must be an implementation issue.

Cheers,
Maria

On Mon, Jul 6, 2009 at 3:37 PM, Andrew Grieve <agrieve at google.com> wrote:
>
> The current behavior in Webkit is for URL fragments to be stored in the
> URLs for master entries. I believe this to be a bug in Webkit, but cannot
> determine from the spec if this is or not.
>
> Example:
>
> 1. Navigate to: http://www.thecssninja.com/demo/offline_webapp/#foo
> 2. Go offline
> 3. Do a browser refresh and ensure the page refreshes from AppCache.
> 4. Change the URL hash to #bar
> 5. Do a browser refresh and notice that it fails to load.
>
> I've filed a bug on webkit.org (
https://bugs.webkit.org/show_bug.cgi?id=26925)
> regarding this, but realized that the spec is unclear about what is
> expected here. Since fragments are not sent to servers, I can't see
> why they would be included in the master entry URLs as they make no
> difference in the content that is served.
>
> Anyone know if the spec does in fact address this issue?
>
> Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/62800e5c/attachment.htm>

From chris.double at double.co.nz  Mon Jul  6 19:24:33 2009
From: chris.double at double.co.nz (Chris Double)
Date: Tue, 7 Jul 2009 14:24:33 +1200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <7BDABBC0-3442-4A62-AAD5-CB83BD45B3ED@apple.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
	<7BDABBC0-3442-4A62-AAD5-CB83BD45B3ED@apple.com>
Message-ID: <c2e346f90907061924s2850c4fexf132532f1d6308b8@mail.gmail.com>

> > Could you elaborate on what your use cases are? Is it just the ability to
> > manually decode audio tracks?
> >
>
>  I actually have thought about this.  Having an ability to post-process,
> mix, or generate audio content manually is useful for certain classes of
> games and applications.
>  >

There's been some discussion about this type of functionality in this
Mozilla bug too:

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

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

From ian at hixie.ch  Mon Jul  6 21:30:18 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 04:30:18 +0000 (UTC)
Subject: [whatwg] Issues with Web Sockets API
In-Reply-To: <5A8E44FD455C42FF80951A18E6332C72@POCZTOWIEC>
References: <ad1a0c1e0906260918m4401d334vd14fc7d530874195@mail.gmail.com>
	<f965ae410906260946x4ba99dear742a828d0b266342@mail.gmail.com>
	<bd8f24d20906260952la72aefeu9b0d907b6a105131@mail.gmail.com>
	<f965ae410906261034m47f3d117k7f430aaed4ae398f@mail.gmail.com>
	<932a5d5f0906261314x94a70xd2d78edb743dcf28@mail.gmail.com>
	<5A8E44FD455C42FF80951A18E6332C72@POCZTOWIEC>
Message-ID: <Pine.LNX.4.62.0907070326030.1060@hixie.dreamhostps.com>

On Fri, 26 Jun 2009, James Robinson wrote:
> 
> 0) postMessage() looks as if it is intended to mimic 
> MessagePort.postMessage(), but the arguments and error conditions are 
> different.  While it would be conceptually nice to treat a web socket in 
> the same way as a message port, it's not possible to treat the two 
> postMessage() functions in the same way.  I'd recommend the WebSocket 
> version be renamed to something like "send()" to avoid confusion and 
> false expectations.

Fair enough. Done.



> There's similar oddness with receiving events that satisfy the MessageEvent
> interface - since all fields except 'data' will necessarily be invalid I
> don't see the value in receiving something more complex.

I would like to avoid introducing four different event types for the four 
different types of 'message' events being introduced, which is why I 
overloaded the same interface for all four. I don't think it's a problem.


> 1) The 'readyState' attribute can never actually be used by an application
> and is redundant.
> 
> Initially, the 'readyState' attribute is set to CONNECTING, but while 
> the object is in this state the user is not permitted to interact with 
> the WebSocket in any way.  The only useful thing that a user could do is 
> set event handlers and wait for the 'open' event to fire.  When the 
> WebSocket becomes connected, the readyState becomes 1 and the 'open' 
> event is fired. Once the WebSocket is open, the spec states that 
> whenever the connection is closed the readyState changes to CLOSED and a 
> 'close' event is enqueued. However, users can't usefully check the 
> readyState to see if the WebSocket is still open because there are not 
> and cannot be any synchronization guarantees about when the WebSocket 
> may close.  A user will have to wrap all calls to postMessage() (or 
> send() if the function is renamed) in a try/catch block in order to 
> handle INVALID_STATE_ERRs.  Once the 'close' event has been received the 
> readyState attribute is useless since the state of the WebSocket is 
> known and can never change.
>
> I think 'readyState' should just go away since an application will have 
> to keep track of state updates through the fired events and use 
> try/catch blocks around all API calls anyway.

The attribute is mostly present for debugging purposes. I wouldn't expect 
anyone to actually use it for production work.


On Fri, 26 Jun 2009, Drew Wilson wrote:
>
> Yes, but the "closed" state of a given WebSocket doesn't have to exactly 
> match the state of the underlying TCP connection, in the same way that 
> document.cookies doesn't exactly match the current set of cookies that 
> the network stack may be tracking (they can differ when HTTP responses 
> are received in the background while JS is executing).
> 
> So if the remote server closes the TCP connection, it generates a 
> "close" event which marks the WebSocket as closed. It means that you 
> could have a situation where you post messages to a WebSocket which 
> aren't received by the server because the connection is closed, but 
> that's true regardless due to the asynchronous nature of the networking 
> protocol.

I've changed the spec to not throw an exception on send() if the 
connection is closed.


On Fri, 26 Jun 2009, Kelly Norton wrote:
>
> One thing about postMessage that I'm curious about. Since it has to 
> report failure synchronously by throwing an INVALID_STATE_ERR, that 
> seems to imply that all data must be written to a socket before 
> returning and cannot be asynchronously delivered to an I/O thread 
> without adding some risk of silently dropping messages. Seems like the 
> right choice would be to allow outbound messages to drop, which would 
> mean that developers would be forced to do their own handshaking.

send() doesn't report I/O errors, it only throws an exception if the 
connection isn't open yet (and previously, if the connection had died 
prior to it being called, though that is no longer the case), or if the 
input is invalid.


> I'm also not sure there is good coverage of error conditions in the 
> spec. The only methods of error notification are exceptions in 
> postMessage and onclose.

In fact, only onclose actually reports an error; the exception from send() 
now only reports a misuse of the API, not a network error.


> I had assumed that a WebSocket that fails to connect would invoke 
> onclose asynchronously, but I didn't see that in the spec.

It's there, though subtle. :-)

The constructor in the API spec invokes the "Establish a Web Socket 
connection" algorithm from the protocol spec. That algorithm then invokes 
the "fail the Web Socket connection" algorithm upon failure, and that 
algorithm says to invoke the "close the Web Socket connection" algorithm, 
and that algorithm says that this means that "Web Socket connection is 
closed", and the API spec says "When the Web Socket connection is closed, 
the readyState attribute's value must be changed to CLOSED (2), and the 
user agent must queue a task to fire a simple event called close at the 
WebSocket object".

I've added a note that says this.


> Without that you don't even have the ability to know if a 
> socket failed to establish a connection (short of readyState polling). 
> The spec also doesn't indicate that the readyState should transition to 
> CLOSED on connection failure.

This is part of the same sequence of events as described above.


On Fri, 26 Jun 2009, Kelly Norton wrote:
>
> Doesn't it seem strange that disconnect() causes an onclose event to be 
> dispatched? Should the method not be close() to be consistent with 
> open(), onopen, onclose?

I've renamed disconnect() to close() in both EventSource and WebSocket.


On Fri, 26 Jun 2009, Michael Nordman wrote:
>
> Does disconnect() attempt to flush pending messages or drop them? There 
> isn't a way to determine if the WebSocket is successfully sending the 
> postMessage data? For all the caller knows, its just backing up and not 
> going anywhere.
> 
> Something that might add value is an onmessagesent event that fires 
> after a postMessage has put the bits on the wire.

If you want acknowledgements, implement app-level acks -- in practice, 
there's not much difference between hitting the network or not, if the 
other side hasn't yet received the packets.


> postMessage() may want another exception condition... 'too much data 
> pending exception'... consider calling postMessage in a while(true) 
> loop... at some point the system is going to have to give up queing the 
> data if its not actually making its way out on the wire.

The spec doesn't specify how UAs are to handle hitting hardware 
limitations or system limitations, because it's often difficult to truly 
control how those cases are handled.


On Fri, 26 Jun 2009, James Robinson wrote:
>
> Not changing variables out from under executing JavaScript makes a lot 
> of sense, but if that was the case then it's not clear when the 
> readyState could be updated.  The spec states "When the *Web Socket 
> connection is closed*, the readyState attribute's value must be changed 
> to CLOSED (2), and the user agent must queue a task to fire a simple 
> event called close at the WebSocket object." If the browser cannot 
> mutate the readyState until JavaScript stops running then it would 
> either have to either enqueue a second task to change readyState at some 
> point in the future or set the readyState right before dispatching the 
> 'close' event.  The latter would be much nicer to implement - but then 
> it does make the readyState completely useless as it would always be 
> exactly equivalent to the last event that was fired on a given 
> WebSocket.

I've left it as is (the attribute changes on the fly), which is possibly 
risky, but more consistent with how such attributes are handled in 
general.


> I think a better way to do error handling is to have an asynchronous 
> onerror callback or event when the browser notes that a message did not 
> make it to the other side.

The client can't really always know this anyway. I think it's better to do 
app-level acking if you care enough.


On Fri, 26 Jun 2009, James Robinson wrote:
> 
> The concept of a port being in a closed state is not very well defined - 
> if the state means only the readyState status, then when can the state 
> legally be updated?  If it has some meaning closer to the state of the 
> underlying connection, then it can't be queried synchronously without 
> very expensive synching to the I/O thread or process.
> 
> Forcing applications to build their own send/ack functionality would be 
> pretty tragic considering that WebSockets are built on top of TCP.

If we had access to the underlying TCP packets, I guess we could return a 
number with each send() and have some way to query the number of the 
mesage that the most recent packet that got all the way to other side 
contained, but in practice I don't think that implementations are always 
going to have access to that, and also it's not just that the other stack 
got the message that matters, but that the remote server actually got the 
messages and processed it.


On Fri, 26 Jun 2009, Michael Nordman wrote:
>
> If you're uploading a large data set incrementally across many distinct 
> postMessage calls (perhaps to leave room for other control messages 
> interspersed amoungst them, or to present progress info), how do you 
> know when to queue more data to be sent.

I think when we add support for file upload, we'll make it so that it 
automagically supports this case. That is, you'll say "upload this file in 
small bits" and then if you later say "send this text message", the text 
message will be sent before any pending file bits. We can use a separate 
type of packet in the WebSocket stream to do this.

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

From ian at hixie.ch  Mon Jul  6 21:31:53 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 04:31:53 +0000 (UTC)
Subject: [whatwg] on bibtex-in-html5
In-Reply-To: <4A2F8714.30303@gmx.de>
References: <9ABBA478-E05D-41F0-A9BB-0C007D75689E@simifilm.ch>
	<Pine.LNX.4.62.0905232130530.7824@hixie.dreamhostps.com>
	<fbb7c5df0905240717h6c8dddc4od0f38be34b111fe8@mail.gmail.com>
	<fbb7c5df0906020828n64141eb8m92f3da5a19254a90@mail.gmail.com>
	<4A254DC8.6020105@opera.com>
	<Pine.LNX.4.62.0906100857240.1648@hixie.dreamhostps.com>
	<4A2F8714.30303@gmx.de>
Message-ID: <Pine.LNX.4.62.0907070431040.1060@hixie.dreamhostps.com>

On Wed, 10 Jun 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> >
> > So far based on my experience with the Workers, Storage, Web Sockets, 
> > and Server-sent Events sections, I'm not convinced that the advantage 
> > of getting more review is real. Those sections in particular got more 
> > review while in the HTML5 spec proper than they have since.
> 
> So you are putting stuff you're personally interested in into the HTML5 
> spec, so that people read it?

No; but I don't think taking things out of the HTML5 spec gets them more 
review, so if someone did want to reorganise the specs to get more review, 
I don't think that would be the way to do it.

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

From bzbarsky at MIT.EDU  Mon Jul  6 22:03:27 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 06 Jul 2009 22:03:27 -0700
Subject: [whatwg] Session history
In-Reply-To: <Pine.LNX.4.62.0907060437470.1060@hixie.dreamhostps.com>
References: <4A4D14FD.1090401@helsinki.fi>
	<Pine.LNX.4.62.0907060437470.1060@hixie.dreamhostps.com>
Message-ID: <4A52D71F.90107@mit.edu>

Ian Hickson wrote:
> On Thu, 2 Jul 2009, Olli Pettay wrote:
>> [22:59]	<smaug>	I'm trying to understand the "Each browsing context, including
>> nested browsing context, has a distinct session history."
>> [23:00]	<smaug>	but in practice if go(-1) is called in a iframe (and it hasn't
>> been navigated from the original page), the top level page is navigated
> 
> I've now fixed the spec to match IE's behaviour when it comes to 
> history.go(), history.length, and history.back().
> 
> This doesn't quite match what Gecko, Webkit, or Opera do, but then they 
> all each do their own slightly different thing, so I had to pick one, and 
> IE seemed like the obvious choice.

Can you possibly summarize the differences you encountered?  Or at least 
point to the specific tests on which the behaviors differed, assuming 
you put them all up?

-Boris

From agrieve at google.com  Mon Jul  6 22:17:45 2009
From: agrieve at google.com (Andrew Grieve)
Date: Mon, 6 Jul 2009 22:17:45 -0700
Subject: [whatwg] Fragments included in Application Cache master entries
In-Reply-To: <4bc348310907061913k392c7b15l5cae909fb0eddcf6@mail.gmail.com>
References: <3128e0550907061537hf48da6bsea9ee373d25d3f94@mail.gmail.com>
	<4bc348310907061913k392c7b15l5cae909fb0eddcf6@mail.gmail.com>
Message-ID: <3128e0550907062217p252624e9vc59d6071282faa4d@mail.gmail.com>

The problem I'm seeing is not with URLs listed in the manifest, but rather
for URLs added to the Application Cache because they were navigated to and
pointed to an existing manifest. I think the following excerpt is the
relevant part of the spec:

 Master entries
> Documents that were added to the cache because a browsing context<http://www.whatwg.org/specs/web-apps/current-work/#browsing-context>was
> navigated <http://www.whatwg.org/specs/web-apps/current-work/#navigate> to
> that document and the document indicated that this was its cache, using the
> manifest<http://www.whatwg.org/specs/web-apps/current-work/#attr-html-manifest>attribute.


Andrew

On Mon, Jul 6, 2009 at 7:13 PM, Maria Khomenko <maria.khomenko at gmail.com>wrote:

> Actually, I believe the spec does address the question in the following
> passage (this is in the manifest parsing algorithm):
>
>
>> If mode is "explicit"
>
> Resolve the first item in tokens, relative to base URL; ignore the rest.
>
>
>> If this fails, then jump back to the step labeled "start of line".
>
>
>> If the resulting absolute URL has a different <scheme> component than the
>> manifest's URL (compared in an ASCII case-insensitive manner), then jump
>> back to the step labeled "start of line".
>
>
>> *Drop the <fragment> component of the resulting absolute URL, if it has
>> one.*
>
>
>> Add the resulting absolute URL to the explicit URLs.
>
>
> So it must be an implementation issue.
>
> Cheers,
> Maria
>
> On Mon, Jul 6, 2009 at 3:37 PM, Andrew Grieve <agrieve at google.com> wrote:
> >
> > The current behavior in Webkit is for URL fragments to be stored in the
> > URLs for master entries. I believe this to be a bug in Webkit, but cannot
> > determine from the spec if this is or not.
> >
> > Example:
> >
> > 1. Navigate to: http://www.thecssninja.com/demo/offline_webapp/#foo
> > 2. Go offline
> > 3. Do a browser refresh and ensure the page refreshes from AppCache.
> > 4. Change the URL hash to #bar
> > 5. Do a browser refresh and notice that it fails to load.
> >
> > I've filed a bug on webkit.org (
> https://bugs.webkit.org/show_bug.cgi?id=26925)
> > regarding this, but realized that the spec is unclear about what is
> > expected here. Since fragments are not sent to servers, I can't see
> > why they would be included in the master entry URLs as they make no
> > difference in the content that is served.
> >
> > Anyone know if the spec does in fact address this issue?
> >
> > Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/8ccd3a96/attachment-0001.htm>

From ian at hixie.ch  Mon Jul  6 22:40:47 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 05:40:47 +0000 (UTC)
Subject: [whatwg] Session history
In-Reply-To: <4A52D71F.90107@mit.edu>
References: <4A4D14FD.1090401@helsinki.fi>
	<Pine.LNX.4.62.0907060437470.1060@hixie.dreamhostps.com>
	<4A52D71F.90107@mit.edu>
Message-ID: <Pine.LNX.4.62.0907070538500.1053@hixie.dreamhostps.com>

On Mon, 6 Jul 2009, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > On Thu, 2 Jul 2009, Olli Pettay wrote:
> > > [22:59]	<smaug>	I'm trying to understand the "Each browsing context,
> > > including
> > > nested browsing context, has a distinct session history."
> > > [23:00]	<smaug>	but in practice if go(-1) is called in a iframe (and
> > > it hasn't
> > > been navigated from the original page), the top level page is navigated
> > 
> > I've now fixed the spec to match IE's behaviour when it comes to
> > history.go(), history.length, and history.back().
> > 
> > This doesn't quite match what Gecko, Webkit, or Opera do, but then they all
> > each do their own slightly different thing, so I had to pick one, and IE
> > seemed like the obvious choice.
> 
> Can you possibly summarize the differences you encountered?  Or at least 
> point to the specific tests on which the behaviors differed, assuming 
> you put them all up?

I didn't work out what the algorithms for the other browsers were, because 
IE's was actually sane for once (shockingly).

However, in Gecko, for instance, the following tests act differently than 
in IE:

   http://www.hixie.ch/tests/adhoc/dom/level0/history/002.html
   http://www.hixie.ch/tests/adhoc/dom/level0/history/003.html
   http://www.hixie.ch/tests/adhoc/dom/level0/history/004.html

Off-hand I can't really work out what Gecko is doing.

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

From giecrilj at stegny.2a.pl  Mon Jul  6 22:43:49 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 7 Jul 2009 07:43:49 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A52A879.50403@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org><4A4D2AAE.1030701@jumis.com><Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com><4A4D6405.6040409@jumis.com><Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com><4A529EF3.6010702@jumis.com><Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com><4A52A3BC.2010608@jumis.com><Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
	<4A52A879.50403@jumis.com>
Message-ID: <3BAB9F2095E5488A99FAB11ABB8C1457@POCZTOWIEC>

Audible mouse feedback is an OS thing, not an HTML thing.
I would rather have programmatic access to the MIDI synthesizer rather than
be able to simulate it with a beep.
How do you detect that the client mixer is too slow?
Why can't you just get the premixed jingles from the server?
Isn't the reading voice a CSS thing?  
Isn't sound transformation hard enough to deserve a complete API?  I think
allowing playing with binary audio data is not going to help most
programmers who do not have the slightest idea of how to deal with it.
Imagine a Canvas interface with PutPixel only.
IMHO,
Chris 


From giecrilj at stegny.2a.pl  Mon Jul  6 23:06:20 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 7 Jul 2009 08:06:20 +0200
Subject: [whatwg] Chipset support is a good argument
In-Reply-To: <7c2a12e20907061705i6c5f496ct63e41e19dc0aa165@mail.gmail.com>
References: <20090706035052.0AC5D8DB0010@zapata.dreamhost.com><4A5288FD.6090204@verizon.net>
	<7c2a12e20907061705i6c5f496ct63e41e19dc0aa165@mail.gmail.com>
Message-ID: <9EF24FC7472444F99F10B21ED3B55229@POCZTOWIEC>

As the Eolas or RIM cases show, patent trolls can wait for a very long time
until they are sure that their victim has no way out.  It does not prove
that Theora is clean that Google has not been sued yet.
IMHO,
Chris


From giecrilj at stegny.2a.pl  Mon Jul  6 23:57:27 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Tue, 7 Jul 2009 08:57:27 +0200
Subject: [whatwg] HTML5 competing with XML
In-Reply-To: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>
References: <E02F007573AE8543AABE2995D7D05D3703AC2CBA@TEAM-EXCHANGE1.hc.msu.edu>
Message-ID: <A491340E7330458A9132E55807AEB068@POCZTOWIEC>

A clean way to insert extraneous elements into SGML is to use NOTATION
entities.  This does not work for HTML and it has never worked, although TBL
did have such an idea for images at the very beginning.  It cannot be done
because it is extremely inconvenient for the author/publisher and very
insecure on the WWW.

Otherwise, you can think of MATH and SVG in HTML5 as an analogue of SCRIPT,
which is of course very weak - but you cannot verify the validity of
JavaScript code with a DTD either.  And you can have a DTD for XHTML5 with
MathML and SVG using XML modularization (although the WHATWG does not
provide you with one).  The DTD in question would of course be an upper
approximation of what is allowed.

HTH,

Chris

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

From jonas at sicking.cc  Tue Jul  7 00:20:56 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 7 Jul 2009 00:20:56 -0700
Subject: [whatwg] scripts, defer, document.write and DOMContentLoaded
Message-ID: <63df84f0907070020p59739086pde4e35bf0efa95a8@mail.gmail.com>

Hi all!

I wanted to share some experiences with implementing the defer
attribute on scripts.

After the initial implementation[1] one of the problems that we
quickly ran in to was pages going blank [2][3][4] due to pages
containing markup like

<script defer>
  document.write("something");
</script>

In IE this will in some circumstances (more below) not replace the
current page, but instead just append the written markup to the end of
the page. There was even one large site that had markup like

<script defer>
  if (navigator.platform == "MacIntel") {
    document.write("something");
  }
</script>

even though as far as I know there is no browser running on mac that
supports defer (maybe Opera?).

What's tricky is that a document.write inside a deferred script in IE
will in some circumstances clear the current document, in other cases
append to it. Specifically it seems that if the page has ever set
.innerHTML on any node then document.write in the deferred script will
append to the current page. If .innerHTML has never been set, then it
will replace the current page.

In order to fix this in Gecko we decided [2] to let the "insertion
point" be set to the end of the document while executing all deferred
scripts. Additionally we hold off firing DOMContentLoaded until all
deferred scripts have loaded and executed. This was in part due to
implementation specific problems (a lot of internal mozilla code
relies DOMContentLoaded), but also to allow pages to more easily defer
scripts across browsers [5]. Additionally always firing
DOMContentLoaded before all, or after all, deferred elements increases
consistency and reduces the risk of race conditions in pages.

Also, in an effort to reduce the amount of possible race conditions in
pages, if there are any scripts that were inserted using the DOM, we
wait for all those to finish loading and executing before firing
DOMContentLoaded. This was mostly because in gecko the concept of
"insertion points" works differently and so document.write never
clears the current document before DOMContentLoaded has fired, making
races with DOMContentLoaded particularly noticeable.

Another thing where it appears that the spec differ from Geckos
behavior is nodes that are not async and not deferred. Gecko always
executes these in the order they are inserted into the main Document.
So if two <script> nodes are created, one with a src attribute set,
and another with just inline script, and then inserted into the
Document, they are always executed in insertion order no matter of the
src-script or the inline-script is inserted first.

All of the above is how things work in Firefox 3.5.

In addition to this we in the next version of firefox where
document.readyState is supported, hold off setting document.readyState
to "interactive" until all deferred scripts have executed. It appears
that the spec changes readyState before executing deferred scripts
which I think would be fine to change our implementation to do.

So all in all, I'd like to see the following changes to the spec:

* Don't fire DOMContentLoaded until all deferred scripts have executed.
* While executing deferred scripts, let the "insertion point" be at
the end of the document.
* Always execute elements in the order they are inserted into the
Document, with exception of async and deferred scripts.
* Possibly hold off firing DOMContentLoaded until any outstanding
scripts have finished loading and executing.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=28293
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=461555
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=461724
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=469751
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=474392

/ Jonas

From philipj at opera.com  Tue Jul  7 00:38:18 2009
From: philipj at opera.com (Philip Jagenstedt)
Date: Tue, 07 Jul 2009 09:38:18 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A52A879.50403@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
	<4A52A3BC.2010608@jumis.com>
	<Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
	<4A52A879.50403@jumis.com>
Message-ID: <op.uwost4qd88ivhk@sisko.linkoping.osa>

On Tue, 07 Jul 2009 03:44:25 +0200, Charles Pritchard <chuck at jumis.com>  
wrote:

> Ian Hickson wrote:
>> On Mon, 6 Jul 2009, Charles Pritchard wrote:
>>
>>> Ian Hickson wrote:
>>>
>>>> On Mon, 6 Jul 2009, Charles Pritchard wrote:
>>>>
>>>>>> This is on the list of things to consider in a future version. At  
>>>>>> this point I don't really want to add new features yet because  
>>>>>> otherwise we'll never get the browser vendors caught up to  
>>>>>> implementing the same spec. :-)
>>>>>>
>>>>> Consider a programmable <audio> element as a priority.
>>>>>
>>>> Could you elaborate on what your use cases are? Is it just the  
>>>> ability to manually decode audio tracks?
>>>>
>>> Some users could manually decode a Vorbis audio stream.
>>>
>>> I'm interested in altering pitch and pre-mixing channels. I believe  
>>> some of these things are explored in CSS already.
>>>
>>> There are accessibility cases, for the visually impaired, and I think  
>>> that they will be better explored.
>>>
>>
>> If you could elaborate on these use cases that would be really useful.  
>> How do you envisage using these features on Web pages?
>>
> Use a sound of varying pitch to hint to a user the location of their  
> mouse
> (is it hovering over a button, is it x/y pixels away from the edge of  
> the screen, how close is it to the center).
>
> Alter the pitch of a sound to make a very cheap midi instrument.
>
> Pre-mix a few generated sounds, because the client processor is slow.
>
> Alter the pitch of an actual audio recording, and pre-mix it,
> to give different sounding voices to pre-recorded readings of a single  
> text.
> As has been tried for "male" "female" sound fonts.
>
> Support very simple audio codecs, and programmable synthesizers.
>
> The API must support a playback buffer.
>
> putAudioBuffer(in AudioData) [ Error if audiodata properties are not  
> supported ]
> createAudioData( in sample hz, bits per sample, length ) [ Error if  
> properties are not supported. ]
> AudioData ( sampleHz, bitsPerSample, length, AudioDataArray )
> AudioDataArray ( length, IndexGetter, IndexSetter ) 8 bits per property.
>
> I think that's about it.
>
>> (There has been some discussion of suppoting an "audio canvas" before,  
>> but a lack of compelling use cases has really been the main blocker.  
>> Without a good understanding of the use cases, it's hard to design an  
>> API.)
>>
>>

For all of the simpler use cases you can already generate sounds yourself  
with a data uri. For example, with is 2 samples of silence:  
"data:audio/wav;base64,UklGRigAAABXQVZFZm10IBAAAAABAAEARKwAAIhYAQACABAAZGF0YQQAAAAAAAAA".

It might be worthwhile implementing the API you want as a JavaScript  
library and see if you can actually do useful things with it. If the use  
cases are compelling and require native browser support to be performant  
enough, perhaps it could go into a future version of HTML.

-- 
Philip J?genstedt
Core Developer
Opera Software

From benno at benno.id.au  Tue Jul  7 00:39:45 2009
From: benno at benno.id.au (Ben Leslie)
Date: Tue, 7 Jul 2009 17:39:45 +1000
Subject: [whatwg] Typo in 3.4.1.5 Phrasing Content
Message-ID: <17b28da20907070039h2cc5de05hbd267e296afae086@mail.gmail.com>

Hi,

In section "3.4.1.5  Phrasing Content", the text reads:

"a (if it contains only phrasing content), abbr (if it is a descendant
of a map element), area, audio,..."

I believe it should read:

"a (if it contains only phrasing content), abbr, area (if it is a
descendant of a map element), audio,..."

Thanks,

Benno

From ian at hixie.ch  Tue Jul  7 01:25:58 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 08:25:58 +0000 (UTC)
Subject: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control
 range]
In-Reply-To: <D69F4CBC-FE2C-4970-99F2-B7AB6AAFA16D@coq.no>
References: <4B419876-1551-447D-8C77-1B702724EDC8@coq.no>
	<Pine.LNX.4.62.0906032200160.1648@hixie.dreamhostps.com>
	<6E531C99-3CEF-446A-9BE3-1FF79CDA839B@coq.no>
	<op.uvat4muq64w2qv@annevk-t60>
	<D69F4CBC-FE2C-4970-99F2-B7AB6AAFA16D@coq.no>
Message-ID: <Pine.LNX.4.62.0907070755380.1060@hixie.dreamhostps.com>

On Tue, 9 Jun 2009, Anne van Kesteren wrote:
> On Tue, 09 Jun 2009 01:42:57 +0200, ??istein E. Andersen <liszt at coq.no> wrote:
> > Le 5 juin 09, Anne van Kesteren ??crivit :
> >>
> >> Is the implication here that Shift_JIS and Shift-JIS are distinct 
> >> [...]?
> >
> > No, Shift-JIS and Windows-932 are commonly used names/labels for the 
> > encodings that are registered as Shift_JIS and Windows-31J 
> > (respectively) in the IANA charset registry. Sorry for the confusion 
> > caused.
> 
> So should HTML5 mention that Windows-932 maps to Windows-31J? (It does 
> not appear in the IANA registry.)

I've added this mapping too, just in case.


On Tue, 9 Jun 2009, ?istein E. Andersen wrote:
> 
> That is an interesting question. My (apparently wrong) understanding was 
> that the table was merely supposed to provide mappings between 
> encodings, since such mappings are inappropriate in non-HTML contexts 
> and cannot be added to the IANA registry. It might be to useful to 
> include a set of MIME charset strings which cannot be or have not yet 
> been registered (e.g., x-x-big5, x-sjis, windows-932) as well as 
> information on how CJK character sets are implemented in practice, both 
> of which seem to be necessary for compatibility.
> 
> Such information does not fit comfortably in the current table, though.

Added x-sjis. What are the other mappings that would be good?


On Tue, 9 Jun 2009, ?istein E. Andersen wrote:
> > 
> > I believe you misunderstand the purpose of this table. The idea is to 
> > give a mapping of _labels_ to encodings, not encodings to encodings. 
> > I've clarified the text to this effect.
> 
> You seem to have added "specified by a label" to the phrase which now 
> reads "an encoding specified by a label given in the first column of the 
> following table" without changing the column heading ("Input encoding") 
> and without defining what a "label" actually is. The reference to 
> "encoding aliasing" is also intact, which seems misleading if the table 
> is not supposed to map between encodings.

I've split the table in two to avoid this issue.


Earlier, you wrote:
>
> GB2312 and GB_2312-80 technically refer to the *character set* GB 
> 2312-80, [...]. GBK, on the other hand, is an encoding.

As far as I can tell, GB2312 and GB_2312-80 are two different encodings 
according to IANA.


On Wed, 10 Jun 2009, Anne van Kesteren wrote:
> 
> I would prefer them being added to the IANA registry.

I've noted that I should do that.

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

From ian at hixie.ch  Tue Jul  7 02:04:10 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 09:04:10 +0000 (UTC)
Subject: [whatwg] Annotating structured data that HTML has no semantics
 for
In-Reply-To: <4A2E5588.5060908@depagecms.net>
References: <Pine.LNX.4.62.0905090731350.18851@hixie.dreamhostps.com> 
	<63df84f0905141700v792efe48madbd203a1f4ae63b@mail.gmail.com>
	<63df84f0905141710u11d5bfedl91cd9fd60085d9c2@mail.gmail.com>
	<Pine.LNX.4.62.0906090325080.1648@hixie.dreamhostps.com>
	<4A2E5588.5060908@depagecms.net>
Message-ID: <Pine.LNX.4.62.0907070853470.1060@hixie.dreamhostps.com>

On Tue, 9 Jun 2009, Frank Hellenkamp wrote:
> >
> > I agree entirely. I actually tried to find a workable solution to 
> > address this but unfortunately the only general solutions I could come 
> > up with that would allow this were selector-based, and in practice 
> > authors are still having trouble understanding how to use Selectors 
> > even with CSS.
> 
> At least simple selectors are well understood and a well established 
> technique on the web.

Sure, but with tables, you can't use simple selectors. Simple selectors 
(e.g. a class attribute on each cell) wouldn't be any better than 
repeating itemprop="" everywhere.


> There is widespread use for it in CSS (so it is very simple to test, if 
> your selector works for the correct set of elements).

It'd actually be quite hard to test a selector layer for microdata, 
relative at least to the testing that (say) CSS gets. The thing is, with 
CSS, if there's a mistake then the worst that will happen is that the rule 
will be ignored, or will apply in some way you didn't realise, but with 
the end result being what you want.

With microdata, if you get the rules wrong, you won't really know, until 
someone tries to apply the data in some way you didn't expect, and then 
it'll fail in ways you won't know about.


> And with a selector-based aproach it is far easier to add 
> metadata-information to existing content, than with the 
> metadata-proposal. So for authors it would be much easier, I think.
> 
> It would work like a dezentralized microformats-approach (btw. it would 
> be easy to map the existing microformats to such a css-based 
> metadata-format), with the benefit that you can simply map your own 
> classes and ids to global ones like foaf, dc or hcard.
> 
> And you could easily use such profiles from other pages, e.g.: Someone 
> could markup the songs on his page in a way last.fm does and then simply 
> use a copy of their meta-data profile (basically in the same way we use 
> microformats now).

A selectors-based approach would be similar to GRDDL in this respect.

I don't think this really needs support within HTML; I would encourage you 
to work on this as a stand-alone technology.


> > There's also the problem with separating the data from the rules that 
> > say how to interpret the data, which would likely lead to more 
> > problems than the typos one would get from repeating the itemprop=""s.
> 
> The only real problem I see is the unfortunate fact, that it is harder 
> for browser-implementors to write a good copy & paste code which 
> preserves all metadata from one source to another.

That's one symptom of the above, yes.

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

From kornel at geekhood.net  Tue Jul  7 02:50:17 2009
From: kornel at geekhood.net (Kornel)
Date: Tue, 7 Jul 2009 10:50:17 +0100
Subject: [whatwg] Codecs for <video> and <audio>
In-Reply-To: <Pine.LNX.4.62.0907070040220.1053@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0906300444010.1648@hixie.dreamhostps.com>
	<63df84f0907021536g4f064a3fid73ebe8e8d8d48e3@mail.gmail.com>
	<p06240810c673bd96a891@10.228.248.1>
	<63df84f0907060439j51ee7c97j242f50a804c89990@mail.gmail.com>
	<19025.62732.637959.845740@opera.com>
	<Pine.LNX.4.62.0907062209270.1053@hixie.dreamhostps.com>
	<63df84f0907061540q1ed221f4ua44a82d4de21112b@mail.gmail.com>
	<Pine.LNX.4.62.0907062255100.1053@hixie.dreamhostps.com>
	<63df84f0907061704g156fcacdse39885006a2fbc5d@mail.gmail.com>
	<Pine.LNX.4.62.0907070006030.1053@hixie.dreamhostps.com>
	<63df84f0907061726u452698d0u21c1e6723490cccc@mail.gmail.com>
	<Pine.LNX.4.62.0907070040220.1053@hixie.dreamhostps.com>
Message-ID: <7D9B480F-CD65-48E0-A0F0-819E89D02D3E@geekhood.net>

> I'm arguing that it does matter what's in the spec, insofar that it  
> should
> match what implementations do.

Can we agree to disagree?

We've narrowed codecs down to two. The spec could say that UA which  
supports <video> MUST implement at least one of Theora or H.264. All  
vendors can comply with that, and that's better than not specifying  
any codecs at all (e.g. doesn't allow browsers to support WMV only).

Similarly, authors publishing <video> MUST put at least one source in  
Theora or H.264, SHOULD publish both. That's probably what authors  
will have to do to achieve interoperability in current situation.

These requirements won't ensure full interoperability - that is not  
possible with the impasse we have - but will match implementations,  
make situation clearer for authors and disallow even less  
interoperable implementations.

-- 
regards, Kornel


From silviapfeiffer1 at gmail.com  Tue Jul  7 03:00:59 2009
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 7 Jul 2009 20:00:59 +1000
Subject: [whatwg] Codecs for <audio> and <video> -- informative note?
In-Reply-To: <fbad4e140907060101y2ac9454evbc643ae24e6e8273@mail.gmail.com>
References: <fb6fbf560907051802l36d4fb13l802af7f4b0abc8c1@mail.gmail.com> 
	<fbad4e140907060101y2ac9454evbc643ae24e6e8273@mail.gmail.com>
Message-ID: <2c0e02830907070300q1cbe76cu9c72169dabb7c46c@mail.gmail.com>

On Mon, Jul 6, 2009 at 6:01 PM, David Gerard<dgerard at gmail.com> wrote:
> 2009/7/6 Jim Jewett <jimjjewett at gmail.com>:
>
>> "As of 2009, there is no single efficient codec which works on all
>> modern browsers. ?Content producers are encouraged to supply the video
>> in both Theora and H.264 formats, as per the following example"
>
>
> A spec that makes an encumbered format a "SHOULD" is unlikely to be
> workable for those content providers, e.g. Wikimedia, who don't have
> the money, and won't under principle, to put up stuff in a format
> rendered radioactive by known enforced patents. Your wording presumes
> a paid Web all the way through.


According to http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing,
the "W3C will not approve a Recommendation if it is aware that
Essential Claims exist which are not available on Royalty-Free terms".
So, until the time that H.264 is available royalty-free, I do not see
how it can be included - in particular since there is a royalty-free
alternative.

Regards,
Silvia.

From jeremy at adactio.com  Tue Jul  7 03:32:17 2009
From: jeremy at adactio.com (Jeremy Keith)
Date: Tue, 7 Jul 2009 11:32:17 +0100
Subject: [whatwg] Rel and META values
In-Reply-To: <EB3952B9-1EB8-46C2-80CC-BC4D0A55A557@adactio.com>
References: <EB3952B9-1EB8-46C2-80CC-BC4D0A55A557@adactio.com>
Message-ID: <8E4F1786-93B2-4DAC-B9ED-33324A971283@adactio.com>

Five days ago I wrote:
> No META value will *ever* become a microformat; the very concept of  
> invisible metadata is anathema to microformats?it's impossible for a  
> META keyword value to pass the microformats process.
>
> Should everything on the wiki page be marked as "unendorsed" or,  
> more realistically, should the conditions for acceptance be altered?

I've updated the wiki page for META values, removing the reference to  
the microformats process.
http://wiki.whatwg.org/wiki/MetaExtensions#Process

Meanwhile, back on the Rel values wiki page...
http://wiki.whatwg.org/wiki/RelExtensions

Can anyone help with either of my questions:

> 1. Should I change all of the values derived from XFN from  
> "proposal" to "accepted" as they seem to fit this criteria?
>
> 2. I don't think passing the buck to the microformats community is  
> necessarily a good idea. There are perfectly  good values listed  
> (e.g. rel="accessibility") that would/should probably never become a  
> microformat but are still good semantic values. Will they really be  
> rejected outright?

Thanks in advance,

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/



From Simetrical+w3c at gmail.com  Tue Jul  7 06:52:54 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Tue, 7 Jul 2009 09:52:54 -0400
Subject: [whatwg] Codecs for <video> and <audio>
In-Reply-To: <7D9B480F-CD65-48E0-A0F0-819E89D02D3E@geekhood.net>
References: <Pine.LNX.4.62.0906300444010.1648@hixie.dreamhostps.com>
	<19025.62732.637959.845740@opera.com>
	<Pine.LNX.4.62.0907062209270.1053@hixie.dreamhostps.com>
	<63df84f0907061540q1ed221f4ua44a82d4de21112b@mail.gmail.com>
	<Pine.LNX.4.62.0907062255100.1053@hixie.dreamhostps.com>
	<63df84f0907061704g156fcacdse39885006a2fbc5d@mail.gmail.com>
	<Pine.LNX.4.62.0907070006030.1053@hixie.dreamhostps.com>
	<63df84f0907061726u452698d0u21c1e6723490cccc@mail.gmail.com>
	<Pine.LNX.4.62.0907070040220.1053@hixie.dreamhostps.com>
	<7D9B480F-CD65-48E0-A0F0-819E89D02D3E@geekhood.net>
Message-ID: <7c2a12e20907070652t5c5bdfc8s8bd8e6746d0a988@mail.gmail.com>

On Tue, Jul 7, 2009 at 5:50 AM, Kornel<kornel at geekhood.net> wrote:
> Similarly, authors publishing <video> MUST put at least one source in Theora
> or H.264

This isn't future-proof.  It's also not reasonable if you happen to
know that all of your clients' browsers support some third format
(e.g. on an intranet), or if you don't care about those who don't for
some reason.  I don't think it adds anything.

> SHOULD publish both.

HTML 5 should not recommend that all sites SHOULD use a
patent-encumbered format, any more than it should recommend that they
SHOULD use Flash for fallback (which is what's really needed for
compatibility in practice).

From chuck at jumis.com  Tue Jul  7 08:39:56 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Tue, 07 Jul 2009 08:39:56 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <3BAB9F2095E5488A99FAB11ABB8C1457@POCZTOWIEC>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org><4A4D2AAE.1030701@jumis.com><Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com><4A4D6405.6040409@jumis.com><Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com><4A529EF3.6010702@jumis.com><Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com><4A52A3BC.2010608@jumis.com><Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
	<4A52A879.50403@jumis.com>
	<3BAB9F2095E5488A99FAB11ABB8C1457@POCZTOWIEC>
Message-ID: <4A536C4C.7060402@jumis.com>

Kristof Zelechovski wrote:
> Audible mouse feedback is an OS thing, not an HTML thing.
>   
While users will certainly have applications and os-level accessibility 
tools,
web designers may have their own unique methods of presenting feedback,
and I believe, given enough easy-access, innovative interfaces will come 
from it.
> I would rather have programmatic access to the MIDI synthesizer rather than
> be able to simulate it with a beep.
>   
There is no guarantee that a host system will have a MIDI synthesizer,
and MIDI itself can quite simply be implemented with a series of audio 
clips, a sound font.
Given a very constrained environment (think old cell phone ring tones), 
you can still
"simulate it, with a beep", to provide some form of fall back.

> How do you detect that the client mixer is too slow?
>   
How do you detect that the client player is too slow with the current 
audio tag?
> Why can't you just get the premixed jingles from the server?
>   
You can get pre-mixed jingles from the server, but that may mean high 
bandwidth
in an otherwise resource constrained environment.
> Isn't the reading voice a CSS thing?  
>   
Yes. So?
> Isn't sound transformation hard enough to deserve a complete API?  I think
> allowing playing with binary audio data is not going to help most
> programmers who do not have the slightest idea of how to deal with it.
>   
Sound transformation does not need a "complete" API, but there are
certainly a few common filters which would make things easier on 
end-developers.
Given any amount of support, you'll soon see programmers developing
their own libraries.
> Imagine a Canvas interface with PutPixel only.
>   

I've imagined Canvas with putPixel (and setPixel) and that's enough to 
support
arbitrary drawing, and arbitrary image formats, and that's better than 
nothing.

Most programmers will be able to use a Javascript library, just as 
they've done in the past.

If you have particulars you'd like to see in an initial API, do share.

I could think of FFT/inverse FFT as a particular function which might 
make sense in an initial API,
as they're very particular functions, they're resource intensive, and 
they're in common use.

> IMHO,
> Chris 
>
>   


From chuck at jumis.com  Tue Jul  7 08:52:29 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Tue, 07 Jul 2009 08:52:29 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <op.uwost4qd88ivhk@sisko.linkoping.osa>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
	<4A52A3BC.2010608@jumis.com>
	<Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
	<4A52A879.50403@jumis.com> <op.uwost4qd88ivhk@sisko.linkoping.osa>
Message-ID: <4A536F3D.7060605@jumis.com>

Philip Jagenstedt wrote:
> For all of the simpler use cases you can already generate sounds 
> yourself with a data uri. For example, with is 2 samples of silence: 
> "data:audio/wav;base64,UklGRigAAABXQVZFZm10IBAAAAABAAEARKwAAIhYAQACABAAZGF0YQQAAAAAAAAA". 
>
Yes you can use this method, and with the current audio tag and 
autobuffer, it may work to some degree.

We've used the data:audio/midi technique, and we've experimented with 
audio/wav,
using the data: injection work-around, does not currently work all that 
well.

It does not produce smooth transitions. We can use raw encoding instead 
of base64 to save on
cpu cycles, but it's still quite "hackish".
>
> It might be worthwhile implementing the API you want as a JavaScript 
> library and see if you can actually do useful things with it. If the 
> use cases are compelling and require native browser support to be 
> performant enough, perhaps it could go into a future version of HTML.
>
Overall, we can not make near-real-time effects, nor jitter-free 
compositions.

We've used wav and midi in a JavaScript library, using the data: url 
technique.
The data: injection technique is inefficient, it's not workable.

Opera has been championing Xiph codecs on this list, There are 
ActionScript and Java Vorbis-players developed using the most basic of APIs.
Isn't that use-case compelling enough?


-Charles

From abaqueiro at gmail.com  Tue Jul  7 09:37:10 2009
From: abaqueiro at gmail.com (SA Alfonso Baqueiro)
Date: Tue, 7 Jul 2009 11:37:10 -0500
Subject: [whatwg] About the video codec supported in HTML5
Message-ID: <62942160907070937g7d849f13y27755e2761bc3070@mail.gmail.com>

In the lack of agreement.

Instead of removing the video section from the spec, we should be
DEMOCRATIC, the codec that more vendors support should get in the spec, like
the goverments are elected.

In this case Ogg Theora will be suported by 3 vendors except Safari, so 3 vs
1, it should get in. The case of H.264 has no majority to be supported.

The whatwg has power, if the standard says something the vendors will have
to implement it to stay on the edge
they have no reason to not do it, more when the the codec of ogg is open and
the source code implementation is out there.

OPEN IS KING.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090707/a12d6383/attachment-0001.htm>

From jackalmage at gmail.com  Tue Jul  7 09:41:51 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 7 Jul 2009 11:41:51 -0500
Subject: [whatwg] About the video codec supported in HTML5
In-Reply-To: <62942160907070937g7d849f13y27755e2761bc3070@mail.gmail.com>
References: <62942160907070937g7d849f13y27755e2761bc3070@mail.gmail.com>
Message-ID: <dd0fbad0907070941x34cc7786o2404be94b7c3909e@mail.gmail.com>

On Tue, Jul 7, 2009 at 11:37 AM, SA Alfonso Baqueiro<abaqueiro at gmail.com> wrote:
> In the lack of agreement.
>
> Instead of removing the video section from the spec, we should be
> DEMOCRATIC, the codec that more vendors support should get in the spec, like
> the goverments are elected.

Unfortunately, browsers don't get coded through the magical power of voting.

> In this case Ogg Theora will be suported by 3 vendors except Safari, so 3 vs
> 1, it should get in. The case of H.264 has no majority to be supported.

Majority doesn't matter, unless Moz and Opera team up to send
mercenaries to Apple headquarters and make the Webkit team implement
Theora support at gunpoint.

> The whatwg has power, if the standard says something the vendors will have
> to implement it to stay on the edge
> they have no reason to not do it, more when the the codec of ogg is open and
> the source code implementation is out there.

Not really.  The WHATWG has the power to *suggest* cool things that
the browser vendors can all do together, but that's about it.  Social
pressure (from other implementors, not from the spec) can provide some
coercion, but that's not working on the codec issue so far.

> OPEN IS KING.

Actually, reality is king.

~tJ

From jorlow at chromium.org  Tue Jul  7 09:43:03 2009
From: jorlow at chromium.org (Jeremy Orlow)
Date: Tue, 7 Jul 2009 09:43:03 -0700
Subject: [whatwg] About the video codec supported in HTML5
In-Reply-To: <62942160907070937g7d849f13y27755e2761bc3070@mail.gmail.com>
References: <62942160907070937g7d849f13y27755e2761bc3070@mail.gmail.com>
Message-ID: <5dd9e5c50907070943i1883ca92r763efd22808a721d@mail.gmail.com>

On Tue, Jul 7, 2009 at 9:37 AM, SA Alfonso Baqueiro <abaqueiro at gmail.com>wrote:

> In the lack of agreement.
>
> Instead of removing the video section from the spec, we should be
> DEMOCRATIC, the codec that more vendors support should get in the spec, like
> the goverments are elected.
>
> In this case Ogg Theora will be suported by 3 vendors except Safari, so 3
> vs 1, it should get in. The case of H.264 has no majority to be supported.
>
> The whatwg has power, if the standard says something the vendors will have
> to implement it to stay on the edge
> they have no reason to not do it, more when the the codec of ogg is open
> and the source code implementation is out there.
>
> OPEN IS KING.
>

This has been discussed to death.  Your exact point has already been made
and responded to several times.  Please read the archives.

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

From brucel at opera.com  Tue Jul  7 09:45:00 2009
From: brucel at opera.com (Bruce Lawson)
Date: Tue, 07 Jul 2009 17:45:00 +0100
Subject: [whatwg] About the video codec supported in HTML5
In-Reply-To: <dd0fbad0907070941x34cc7786o2404be94b7c3909e@mail.gmail.com>
References: <62942160907070937g7d849f13y27755e2761bc3070@mail.gmail.com>
	<dd0fbad0907070941x34cc7786o2404be94b7c3909e@mail.gmail.com>
Message-ID: <op.uwph5aq6h8on37@bruce-pc>

On Tue, 07 Jul 2009 17:41:51 +0100, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:


> Majority doesn't matter, unless Moz and Opera team up to send
> mercenaries to Apple headquarters and make the Webkit team implement
> Theora support at gunpoint.

Apparently, it's illegal, so we've sent themj all back home


Hang loose and stay groovy,

Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)

From philipj at opera.com  Tue Jul  7 13:10:54 2009
From: philipj at opera.com (Philip Jagenstedt)
Date: Tue, 07 Jul 2009 22:10:54 +0200
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <4A536F3D.7060605@jumis.com>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
	<4A52A3BC.2010608@jumis.com>
	<Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
	<4A52A879.50403@jumis.com> <op.uwost4qd88ivhk@sisko.linkoping.osa>
	<4A536F3D.7060605@jumis.com>
Message-ID: <op.uwprogfk88ivhk@sisko.linkoping.osa>

On Tue, 07 Jul 2009 17:52:29 +0200, Charles Pritchard <chuck at jumis.com>  
wrote:

> Philip Jagenstedt wrote:
>> For all of the simpler use cases you can already generate sounds  
>> yourself with a data uri. For example, with is 2 samples of silence:  
>> "data:audio/wav;base64,UklGRigAAABXQVZFZm10IBAAAAABAAEARKwAAIhYAQACABAAZGF0YQQAAAAAAAAA".
> Yes you can use this method, and with the current audio tag and  
> autobuffer, it may work to some degree.
>
> We've used the data:audio/midi technique, and we've experimented with  
> audio/wav,
> using the data: injection work-around, does not currently work all that  
> well.
>
> It does not produce smooth transitions. We can use raw encoding instead  
> of base64 to save on
> cpu cycles, but it's still quite "hackish".
>>
>> It might be worthwhile implementing the API you want as a JavaScript  
>> library and see if you can actually do useful things with it. If the  
>> use cases are compelling and require native browser support to be  
>> performant enough, perhaps it could go into a future version of HTML.
>>
> Overall, we can not make near-real-time effects, nor jitter-free  
> compositions.
>
> We've used wav and midi in a JavaScript library, using the data: url  
> technique.
> The data: injection technique is inefficient, it's not workable.
>
> Opera has been championing Xiph codecs on this list, There are  
> ActionScript and Java Vorbis-players developed using the most basic of  
> APIs.
> Isn't that use-case compelling enough?

If the idea is to write a Vorbis decoder in JavaScript that would be quite  
cool in a way, but for vendors already implementing Vorbis it wouldn't  
really add anything. A pure JS-implementation of any modern audio codec  
would probably be a ridiculous amount of code and slow, so I doubt it  
would be that useful in practice.

For some use cases you could use 2 audio elements in tandem, mixing new  
sound to a new data URI when the first is nearing the end (although sync  
can't be guaranteed with the current API). But yes, there are things which  
can only be done by a streaming API integrating into the underlying media  
framework.

Here's the list of propsed features right out of a comment block in the  
spec:

     * frame forward / backwards / step(n) while paused
     * hasAudio, hasVideo, hasCaptions, etc
     * per-frame control: get current frame; set current frame
     * queue of content
       - pause current stream and insert content at front of queue to play  
immediately
       - pre-download another stream
       - add stream(s) to play at end of current stream
       - pause playback upon reaching a certain time
       - playlists, with the ability to get metadata out of them (e.g. xspf)
     * control over closed captions:
       - enable, disable, select language
       - event that sends caption text to script
     * in-band metadata and cue points to allow:
       - Chapter markers that synchronize to playback (without having to  
poll
         the playhead position)
       - Annotations on video content (i.e., pop-up video)
       - General custom metadata store (ratings, etc.)
     * notification of chapter labels changing on the fly:
       - onchapterlabelupdate, which has a time and a label
     * cue points that trigger at fixed intervals, so that
       e.g. animation can be synced with the video
     * general meta data, implemented as getters (don't expose the whole  
thing)
       - getMetadata(key: string, language: string) => HTMLImageElement or  
string
       - onmetadatachanged (no context info)
     * external captions support (request from John Foliot)
     * video: applying CSS filters
     * an event to notify people of when the video size changes
       (e.g. for chained Ogg streams of multiple independent videos)
     * balance and 3D position audio
     * audio filters
     * audio synthesis
     * feedback to the script on how well the video is playing
        - frames per second?
        - skipped frames per second?
        - an event that reports playback difficulties?
        - an arbitrary quality metric?
     * bufferingRate/bufferingThrottled (see v3BUF)
     * events for when the user agent's controls get shown or hidden
       so that the author's controls can get away of the UA's

Your use cases probably fall under audio filters and synthesis. I expect  
that attention will turn to gradually more complex use cases when the  
basic API we have now is implemented and stable cross-browser and  
cross-platform.

-- 
Philip J?genstedt
Core Developer
Opera Software

From chuck at jumis.com  Tue Jul  7 13:45:41 2009
From: chuck at jumis.com (Charles Pritchard)
Date: Tue, 07 Jul 2009 13:45:41 -0700
Subject: [whatwg] Codecs for <audio> and <video>
In-Reply-To: <op.uwprogfk88ivhk@sisko.linkoping.osa>
References: <mailman.3290.1246337434.8076.whatwg-whatwg.org@lists.whatwg.org>
	<4A4D2AAE.1030701@jumis.com>
	<Pine.LNX.4.62.0907022244470.1060@hixie.dreamhostps.com>
	<4A4D6405.6040409@jumis.com>
	<Pine.LNX.4.62.0907030611490.1053@hixie.dreamhostps.com>
	<4A529EF3.6010702@jumis.com>
	<Pine.LNX.4.62.0907070105370.1053@hixie.dreamhostps.com>
	<4A52A3BC.2010608@jumis.com>
	<Pine.LNX.4.62.0907070127390.1053@hixie.dreamhostps.com>
	<4A52A879.50403@jumis.com> <op.uwost4qd88ivhk@sisko.linkoping.osa>
	<4A536F3D.7060605@jumis.com>
	<op.uwprogfk88ivhk@sisko.linkoping.osa>
Message-ID: <4A53B3F4.8090709@jumis.com>

On 7/7/09 1:10 PM, Philip Jagenstedt wrote:
> On Tue, 07 Jul 2009 17:52:29 +0200, Charles Pritchard 
> <chuck at jumis.com> wrote:
>
>> Philip Jagenstedt wrote:
>>> For all of the simpler use cases you can already generate sounds 
>>> yourself with a data uri. For example, with is 2 samples of silence: 
>>> "data:audio/wav;base64,UklGRigAAABXQVZFZm10IBAAAAABAAEARKwAAIhYAQACABAAZGF0YQQAAAAAAAAA". 
>>>
>> Yes you can use this method, and with the current audio tag and 
>> autobuffer, it may work to some degree.
>>
>> It does not produce smooth transitions. 
At some point, a Blob / Stream API could make things like this easier.
> If the idea is to write a Vorbis decoder in JavaScript that would be 
> quite cool in a way, but for vendors already implementing Vorbis it 
> wouldn't really add anything. A pure JS-implementation of any modern 
> audio codec would probably be a ridiculous amount of code and slow, so 
> I doubt it would be that useful in practice.
>
Well I'd like to disagree, and reiterate my prior arguments.  Vorbis 
decoders have been written in ActionScript and in Java.
They are not ridiculous, in size, nor in CPU usage. They can play audio 
streams, smoothly, and the file size is completely
tolerable. And the idea is codec neutrality, a Vorbis decoder is just 
one example.

> For some use cases you could use 2 audio elements in tandem, mixing 
> new sound to a new data URI when the first is nearing the end 
> (although sync can't be guaranteed with the current API). But yes, 
> there are things which can only be done by a streaming API integrating 
> into the underlying media framework.
Yes, the current API is inadequate. data: encoding is insufficient.
> Here's the list of propsed features right out of a comment block in 
> the spec:
This list of features can be written without a spec, using <canvas>,
using a raw data buffer, and using ECMAScript.

A few of these features may need hardware level support, or a fast computer.
The <audio> tag would be invisible, and the <canvas> tag would
provide the user interface.
> Your use cases probably fall under audio filters and synthesis. I 
> expect that attention will turn to gradually more complex use cases 
> when the basic API we have now is implemented and stable cross-browser 
> and cross-platform.
Yes, some of these use cases qualify as filters, some qualify as synthesis.
I'm proposing that simple filters and synthesis can be accomplished with 
modern
ECMAScript virtual machines and a raw data buffer. My use cases are 
qualified to current capabilities.

Apart from those use cases, I'm proposing that a raw data buffer will 
allow for
codec neutrality.

There are dozens of minor audio codecs, some simpler than others, some 
low bitrate,
that could be programmed in ECMAScript and would run just fine with 
modern ECMAScript VMs.

Transcoding lossy data is a sub-optimal solution. Allowing for arbitrary 
<audio>
codecs is a worthwhile endeavor. ECMAScript can detect if playback is 
too slow.

Additionally, in some cases, the programmer could work-around broken 
codec implementations.
It's forward-looking, it allows real backward compatibility and 
interoperability across browsers.

<canvas> allows for arbitrary, programmable video, <audio> should allow
for programmable audio. Then, we can be codec neutral in our media elements.





From michaeln at google.com  Tue Jul  7 13:48:03 2009
From: michaeln at google.com (Michael Nordman)
Date: Tue, 7 Jul 2009 13:48:03 -0700
Subject: [whatwg] Issues with Web Sockets API
In-Reply-To: <Pine.LNX.4.62.0907070326030.1060@hixie.dreamhostps.com>
References: <ad1a0c1e0906260918m4401d334vd14fc7d530874195@mail.gmail.com>
	<f965ae410906260946x4ba99dear742a828d0b266342@mail.gmail.com>
	<bd8f24d20906260952la72aefeu9b0d907b6a105131@mail.gmail.com>
	<f965ae410906261034m47f3d117k7f430aaed4ae398f@mail.gmail.com>
	<932a5d5f0906261314x94a70xd2d78edb743dcf28@mail.gmail.com>
	<5A8E44FD455C42FF80951A18E6332C72@POCZTOWIEC>
	<Pine.LNX.4.62.0907070326030.1060@hixie.dreamhostps.com>
Message-ID: <fa2eab050907071348s4d61dbedof7640928ed0150d4@mail.gmail.com>

On Mon, Jul 6, 2009 at 9:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 26 Jun 2009, James Robinson wrote:
> >
> > 0) postMessage() looks as if it is intended to mimic
> > MessagePort.postMessage(), but the arguments and error conditions are
> > different.  While it would be conceptually nice to treat a web socket in
> > the same way as a message port, it's not possible to treat the two
> > postMessage() functions in the same way.  I'd recommend the WebSocket
> > version be renamed to something like "send()" to avoid confusion and
> > false expectations.
>
> Fair enough. Done.
>
>
>
> > There's similar oddness with receiving events that satisfy the
> MessageEvent
> > interface - since all fields except 'data' will necessarily be invalid I
> > don't see the value in receiving something more complex.
>
> I would like to avoid introducing four different event types for the four
> different types of 'message' events being introduced, which is why I
> overloaded the same interface for all four. I don't think it's a problem.
>
>
> > 1) The 'readyState' attribute can never actually be used by an
> application
> > and is redundant.
> >
> > Initially, the 'readyState' attribute is set to CONNECTING, but while
> > the object is in this state the user is not permitted to interact with
> > the WebSocket in any way.  The only useful thing that a user could do is
> > set event handlers and wait for the 'open' event to fire.  When the
> > WebSocket becomes connected, the readyState becomes 1 and the 'open'
> > event is fired. Once the WebSocket is open, the spec states that
> > whenever the connection is closed the readyState changes to CLOSED and a
> > 'close' event is enqueued. However, users can't usefully check the
> > readyState to see if the WebSocket is still open because there are not
> > and cannot be any synchronization guarantees about when the WebSocket
> > may close.  A user will have to wrap all calls to postMessage() (or
> > send() if the function is renamed) in a try/catch block in order to
> > handle INVALID_STATE_ERRs.  Once the 'close' event has been received the
> > readyState attribute is useless since the state of the WebSocket is
> > known and can never change.
> >
> > I think 'readyState' should just go away since an application will have
> > to keep track of state updates through the fired events and use
> > try/catch blocks around all API calls anyway.
>
> The attribute is mostly present for debugging purposes. I wouldn't expect
> anyone to actually use it for production work.
>
>
> On Fri, 26 Jun 2009, Drew Wilson wrote:
> >
> > Yes, but the "closed" state of a given WebSocket doesn't have to exactly
> > match the state of the underlying TCP connection, in the same way that
> > document.cookies doesn't exactly match the current set of cookies that
> > the network stack may be tracking (they can differ when HTTP responses
> > are received in the background while JS is executing).
> >
> > So if the remote server closes the TCP connection, it generates a
> > "close" event which marks the WebSocket as closed. It means that you
> > could have a situation where you post messages to a WebSocket which
> > aren't received by the server because the connection is closed, but
> > that's true regardless due to the asynchronous nature of the networking
> > protocol.
>
> I've changed the spec to not throw an exception on send() if the
> connection is closed.
>
>
> On Fri, 26 Jun 2009, Kelly Norton wrote:
> >
> > One thing about postMessage that I'm curious about. Since it has to
> > report failure synchronously by throwing an INVALID_STATE_ERR, that
> > seems to imply that all data must be written to a socket before
> > returning and cannot be asynchronously delivered to an I/O thread
> > without adding some risk of silently dropping messages. Seems like the
> > right choice would be to allow outbound messages to drop, which would
> > mean that developers would be forced to do their own handshaking.
>
> send() doesn't report I/O errors, it only throws an exception if the
> connection isn't open yet (and previously, if the connection had died
> prior to it being called, though that is no longer the case), or if the
> input is invalid.
>
>
> > I'm also not sure there is good coverage of error conditions in the
> > spec. The only methods of error notification are exceptions in
> > postMessage and onclose.
>
> In fact, only onclose actually reports an error; the exception from send()
> now only reports a misuse of the API, not a network error.
>
>
> > I had assumed that a WebSocket that fails to connect would invoke
> > onclose asynchronously, but I didn't see that in the spec.
>
> It's there, though subtle. :-)
>
> The constructor in the API spec invokes the "Establish a Web Socket
> connection" algorithm from the protocol spec. That algorithm then invokes
> the "fail the Web Socket connection" algorithm upon failure, and that
> algorithm says to invoke the "close the Web Socket connection" algorithm,
> and that algorithm says that this means that "Web Socket connection is
> closed", and the API spec says "When the Web Socket connection is closed,
> the readyState attribute's value must be changed to CLOSED (2), and the
> user agent must queue a task to fire a simple event called close at the
> WebSocket object".
>
> I've added a note that says this.
>
>
> > Without that you don't even have the ability to know if a
> > socket failed to establish a connection (short of readyState polling).
> > The spec also doesn't indicate that the readyState should transition to
> > CLOSED on connection failure.
>
> This is part of the same sequence of events as described above.
>
>
> On Fri, 26 Jun 2009, Kelly Norton wrote:
> >
> > Doesn't it seem strange that disconnect() causes an onclose event to be
> > dispatched? Should the method not be close() to be consistent with
> > open(), onopen, onclose?
>
> I've renamed disconnect() to close() in both EventSource and WebSocket.
>
>
> On Fri, 26 Jun 2009, Michael Nordman wrote:
> >
> > Does disconnect() attempt to flush pending messages or drop them? There
> > isn't a way to determine if the WebSocket is successfully sending the
> > postMessage data? For all the caller knows, its just backing up and not
> > going anywhere.
> >
> > Something that might add value is an onmessagesent event that fires
> > after a postMessage has put the bits on the wire.
>
> If you want acknowledgements, implement app-level acks -- in practice,
> there's not much difference between hitting the network or not, if the
> other side hasn't yet received the packets.
>
>
> > postMessage() may want another exception condition... 'too much data
> > pending exception'... consider calling postMessage in a while(true)
> > loop... at some point the system is going to have to give up queing the
> > data if its not actually making its way out on the wire.
>
> The spec doesn't specify how UAs are to handle hitting hardware
> limitations or system limitations, because it's often difficult to truly
> control how those cases are handled.
>
>
> On Fri, 26 Jun 2009, James Robinson wrote:
> >
> > Not changing variables out from under executing JavaScript makes a lot
> > of sense, but if that was the case then it's not clear when the
> > readyState could be updated.  The spec states "When the *Web Socket
> > connection is closed*, the readyState attribute's value must be changed
> > to CLOSED (2), and the user agent must queue a task to fire a simple
> > event called close at the WebSocket object." If the browser cannot
> > mutate the readyState until JavaScript stops running then it would
> > either have to either enqueue a second task to change readyState at some
> > point in the future or set the readyState right before dispatching the
> > 'close' event.  The latter would be much nicer to implement - but then
> > it does make the readyState completely useless as it would always be
> > exactly equivalent to the last event that was fired on a given
> > WebSocket.
>
> I've left it as is (the attribute changes on the fly), which is possibly
> risky, but more consistent with how such attributes are handled in
> general.
>
>
> > I think a better way to do error handling is to have an asynchronous
> > onerror callback or event when the browser notes that a message did not
> > make it to the other side.
>
> The client can't really always know this anyway. I think it's better to do
> app-level acking if you care enough.
>
>
> On Fri, 26 Jun 2009, James Robinson wrote:
> >
> > The concept of a port being in a closed state is not very well defined -
> > if the state means only the readyState status, then when can the state
> > legally be updated?  If it has some meaning closer to the state of the
> > underlying connection, then it can't be queried synchronously without
> > very expensive synching to the I/O thread or process.
> >
> > Forcing applications to build their own send/ack functionality would be
> > pretty tragic considering that WebSockets are built on top of TCP.
>
> If we had access to the underlying TCP packets, I guess we could return a
> number with each send() and have some way to query the number of the
> mesage that the most recent packet that got all the way to other side
> contained, but in practice I don't think that implementations are always
> going to have access to that, and also it's not just that the other stack
> got the message that matters, but that the remote server actually got the
> messages and processed it.
>
>
> On Fri, 26 Jun 2009, Michael Nordman wrote:
> >
> > If you're uploading a large data set incrementally across many distinct
> > postMessage calls (perhaps to leave room for other control messages
> > interspersed amoungst them, or to present progress info), how do you
> > know when to queue more data to be sent.
>
> I think when we add support for file upload, we'll make it so that it
> automagically supports this case. That is, you'll say "upload this file in
> small bits" and then if you later say "send this text message", the text
> message will be sent before any pending file bits. We can use a separate
> type of packet in the WebSocket stream to do this.


Sounds like that would require a protocol change. Is the message framing
spec'd in such a way that a new 'packet type' can be introduced in a
backward compatible fashion?


>
>
> --
> 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/20090707/28a4fe64/attachment-0001.htm>

From ian at hixie.ch  Tue Jul  7 14:09:37 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 21:09:37 +0000 (UTC)
Subject: [whatwg] Codecs for <video> and <audio>
In-Reply-To: <dd0fbad0907070941x34cc7786o2404be94b7c3909e@mail.gmail.com>
References: <62942160907070937g7d849f13y27755e2761bc3070@mail.gmail.com>
	<dd0fbad0907070941x34cc7786o2404be94b7c3909e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907072052590.1060@hixie.dreamhostps.com>

On Tue, 7 Jul 2009, Kornel wrote:
> >
> > I'm arguing that it does matter what's in the spec, insofar that it 
> > should match what implementations do.
> 
> Can we agree to disagree?

I'm not trying to convince you; I'm just explaining why the spec doesn't 
require Theora support right now.


> We've narrowed codecs down to two. The spec could say that UA which 
> supports <video> MUST implement at least one of Theora or H.264. All 
> vendors can comply with that, and that's better than not specifying any 
> codecs at all (e.g. doesn't allow browsers to support WMV only).

That may be where we end up if we really can't resolve this, yes. That 
would be unfortunate, thouh.


> Similarly, authors publishing <video> MUST put at least one source in 
> Theora or H.264, SHOULD publish both. That's probably what authors will 
> have to do to achieve interoperability in current situation.

We can't really require publishers to publish H.264 given that that will 
require license payments soon.


On Tue, 7 Jul 2009, SA Alfonso Baqueiro wrote:
> 
> Instead of removing the video section from the spec, we should be 
> DEMOCRATIC, the codec that more vendors support should get in the spec, 
> like the goverments are elected.

The WHATWG is not a democracy.

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

From ian at hixie.ch  Tue Jul  7 14:10:34 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 21:10:34 +0000 (UTC)
Subject: [whatwg] Issues with Web Sockets API
In-Reply-To: <fa2eab050907071348s4d61dbedof7640928ed0150d4@mail.gmail.com>
References: <ad1a0c1e0906260918m4401d334vd14fc7d530874195@mail.gmail.com> 
	<f965ae410906260946x4ba99dear742a828d0b266342@mail.gmail.com> 
	<bd8f24d20906260952la72aefeu9b0d907b6a105131@mail.gmail.com> 
	<f965ae410906261034m47f3d117k7f430aaed4ae398f@mail.gmail.com> 
	<932a5d5f0906261314x94a70xd2d78edb743dcf28@mail.gmail.com> 
	<5A8E44FD455C42FF80951A18E6332C72@POCZTOWIEC> 
	<Pine.LNX.4.62.0907070326030.1060@hixie.dreamhostps.com>
	<fa2eab050907071348s4d61dbedof7640928ed0150d4@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907072110070.1053@hixie.dreamhostps.com>

On Tue, 7 Jul 2009, Michael Nordman wrote:
> >
> > I think when we add support for file upload, we'll make it so that it 
> > automagically supports this case. That is, you'll say "upload this 
> > file in small bits" and then if you later say "send this text 
> > message", the text message will be sent before any pending file bits. 
> > We can use a separate type of packet in the WebSocket stream to do 
> > this.
> 
> Sounds like that would require a protocol change. Is the message framing 
> spec'd in such a way that a new 'packet type' can be introduced in a 
> backward compatible fashion?

Yes.

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

From ian at hixie.ch  Tue Jul  7 14:43:31 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 21:43:31 +0000 (UTC)
Subject: [whatwg] (no subject)
In-Reply-To: <17494.1244565239@cyclomedia.co.uk>
References: <17494.1244565239@cyclomedia.co.uk>
Message-ID: <Pine.LNX.4.62.0907072141230.1060@hixie.dreamhostps.com>

On Tue, 9 Jun 2009, Ric Hardacre wrote:
>
> Essentially the proposal is for a static DOM object which has read only 
> settings exposed to javascript (ultimately one day sendable via HTTP to 
> the web server to superceed UserAgent sniffing), the browser would be 
> left with the task of presenting the various options to the user 
> (global, per domain, etc.). Javascript has allowed web sites and 
> applications increased levels of functionality but at the same time 
> allowed for more possibilities of special effects and multimedia, these 
> are two seperate sides of the javascript coin and it would be useful to 
> have the former without being required to witness the latter.

I encourage you to approach some browser vendors and see if they are 
interested in implementing this idea. That is one of the steps towards 
standardisation:

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

In general I would expect this idea to be specified independently; it 
doesn't need to be part of HTML5.

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

From ian at hixie.ch  Tue Jul  7 16:20:46 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 23:20:46 +0000 (UTC)
Subject: [whatwg] Helping people seaching for content filtered by license
In-Reply-To: <dd0fbad0906100751l3dc9d42by5cd24eeea0794b7b@mail.gmail.com>
References: <Pine.LNX.4.62.0905072258380.18851@hixie.dreamhostps.com> 
	<6ea53250906100146g108d67a3w81fe6db54767e50e@mail.gmail.com> 
	<dd0fbad0906100619o7506ad4apde3ed02acd41151f@mail.gmail.com> 
	<fbb7c5df0906100645q273d1f88v5b1eba705af67345@mail.gmail.com> 
	<dd0fbad0906100705of8c45cfg66b429e758b47775@mail.gmail.com> 
	<fbb7c5df0906100737m7a63dad9l5cd911b7fc75fc0c@mail.gmail.com>
	<dd0fbad0906100751l3dc9d42by5cd24eeea0794b7b@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907072155040.1060@hixie.dreamhostps.com>

On Tue, 9 Jun 2009, Jeff Walden wrote:
> On 8.6.09 17:33, Ian Hickson wrote:
> > >
> > > - Search engines shouldn't be the gatekeeper when it comes to "valid"
> > >   and "invalid" licenses. New licenses shouldn't be discouraged as
> > >   they're vital to keep up with ever changing laws around the world. I
> > >   don't want to wait around for search engines to decide that supporting
> > >   a particular license is in their best interest.
> > 
> > New licenses absolutely need to be discouraged. License proliferation is a
> > huge problem. Any solution we come up with here must absolutely be
> > designed in such a way as to make introducing a new license have a high
> > cost, because each new license causes further fragmentation of the
> > creative world.
> 
> Notwithstanding that I agree that the world has a surfeit of licenses and
> generally gains little from new ones:
> 
> What core principles for the technical design of HTML and the web dictate that
> license proliferation is a problem?

The "Do the right thing" principle. :-)


> Are there reasons to think that HTML5's implicit encouragement or 
> discouragement of recognizing (or having the capability to recognize) 
> many licenses would be effective at discouraging license creation, or 
> more effective than more targeted actions in a separate venue to combat 
> creation of new licenses?

I don't think it would be more effective than more targeted actions, but I 
do think that if we make HTML5 make it easy to introduce new licenses, 
that this will encourage new licenses to exist.


> Maybe I'm the only person who thinks it (I'd like to hope I'm merely the 
> only person to say it, unless I've missed its mention in the past), but 
> this feels like mission creep to me.

I don't think it's mission creep, it's just a help in figuring out what 
our design for a feature should be.


On Wed, 10 Jun 2009, Eduard Pascual wrote:
> On Fri, May 8, 2009 at 9:57 PM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > This has some implications:
> >
> > - Each unit of content (recipe in this case) must have its own
> >   independent page at a distinct URL. This is actually good practice
> >   anyway today for making content discoverable from search engines, 
> >   and it is compatible with what people already do, so this seems 
> >   fine.
> 
> This is, on a wide range of cases, entirely impossible: while it might 
> work, and maybe it's even good practice, for contents that can be 
> represented on the web as a HTML document, it is not achievable for many 
> other formats.

Fair enough. Let's look at the use case again then:

   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019668.html

...but adding two requirements; first the one from you:

 * It should be possible to find works that do not have their own pages, 
   e.g. images in a library, or software.

...and next a requirement that falls out of this, which isn't needed when 
resources have their own page, but is needed when multiple resources 
share a page:

 * Each resource needs to have the following information:
    - The URL to the resource, for identification purposes
    - The identifier of the license that applies to the resource
    - The name of the resource, for display in search results

We might also want to expose other data; the name of the author for 
instance would likely be useful.

Let's look at some ideas for how to address this. In the following markup 
snippets, I've used the following shortcuts:

  S = url to resources
  L = url to license
  B = license-required boilerplate text (typically name of license)
  T = name of resource
  A = name of author

Here are some ideas, along with brief commentary:

 * Idea 1: New attributes

    <img alt="" src="S" author="A" title="T" license="L">
    B

    - doesn't extend very well
    - lots of hidden metadata


 * Idea 2: Extending <figure>

    <figure>
     <img alt="" src="S">
     <legend>
      <cite>T</cite>
      <credit>A</credit>
      <small><a href="L" rel="fig-license">B</a></small>
     </legend>
    </figure>

    - doesn't extend very well
    - very likely to be ambiguous (e.g. legend could use <cite> to refer to other works)


 * Idea 3: RDFa and ccREL

    <div about="S" xmlns:http="http:">
     <img alt="" src="S">
     <span property="http://purl.org/dc/elements/1.1/title">T</span>
     <span property="http://creativecommons.org/ns#attributionName">A</span>
     <a rel="http://www.w3.org/1999/xhtml/vocab#license" href="L">B</a>
    </div>

    - brittle: duplicates the "S" URL
    - a bit verbose


    <div typeof="" xmlns:http="http:">
     <span rel="http://www.w3.org/2002/07/owl#sameAs"><img alt="" src="S"></span>
     <!-- (this "works" though it relies on owl:sameAs inferencing) -->
     <span property="http://purl.org/dc/elements/1.1/title">T</span>
     <span property="http://creativecommons.org/ns#attributionName">A</span>
     <a rel="http://www.w3.org/1999/xhtml/vocab#license" href="L">B</a>
    </div>

    - relies on advanced RDF features, likely to be misimplemented or confused
    - a bit verbose


    <object data="S" xmlns:http="http:" alt="">
     <span property="http://purl.org/dc/elements/1.1/title">T</span>
     <span property="http://creativecommons.org/ns#attributionName">A</span>
     <a rel="http://www.w3.org/1999/xhtml/vocab#license" href="L">B</a>
    </object>

    - the contents of <object> are supposed to be fallback
    - a bit verbose


 * Idea 4: Microdata and ccREL

    <div item>
     <img itemprop="about" alt="" src="S">
     <cite itemprop="http://purl.org/dc/elements/1.1/title">T</cite>
     <span itemprop="http://creativecommons.org/ns#attributionName">A</span>
     <a itemprop="http://www.w3.org/1999/xhtml/vocab#license" href="L">B</a>
    </div>

    - a bit verbose


 * Idea 5: Microdata with new vocabulary

    <div item="work">
     <img itemprop="about" alt="" src="S">
     <cite itemprop="title">T</cite>
     <span itemprop="author">A</span>
     <a itemprop="license" href="L">B</a>
    </div>

    <figure item="work">
     <img itemprop="about" alt="" src="S">
     <legend>
      <cite itemprop="title">T</cite>
      <span itemprop="author">A</span>
      <small><a itemprop="license" href="L">B</a></small>
     </legend>
    </figure>

    - This could be defined as mapping to the previous one in the RDF
      conversion, so we could maintain the ccREL compatibility even
      with this.


 * Idea 6: EXIF

    - Requires editing the resource


Of these, the simplest is to just extend <img> (and <video>, and 
<article>), but it suffers from the hidden metadata problem.

The next simplest seems to be the microdata vocabulary, with a defined 
mapping to ccREL.

Let's see how it handles the scenarios and requirements:

   SCENARIOS:

     * If a user is looking for recipes of pies to reproduce on his
       blog, he might want to exclude from his results any recipes
       that are not available under a license allowing non-commercial
       reproduction.

A search engine with knowledge of which licenses allow non-commercial 
reproduction can restrict results to only matching resources.


     * Lucy wants to publish her papers online. She includes an
       abstract of each one in a page, but because they are under
       different copyright rules, she needs to clarify what the rules
       are. A harvester such as the Open Access project can actually
       collect and index some of them with no problem, but may not be
       allowed to index others. Meanwhile, a human finds it more
       useful to see the abstracts on a page than have to guess from a
       bunch of titles whether to look at each abstract.

This is now possible without new pages, if the harvester knows which 
licenses allow collection.


     * There are mapping organisations and data producers and people
       who take photos, and each may place different policies. Being
       able to keep that policy information helps people with further
       mashups avoiding violating a policy. For example, if
       GreatMaps.com has a public domain policy on their maps,
       CoolFotos.org has a policy that you can use data other than
       images for non-commercial purposes, and Johan Ichikawa has a
       photo there of my brother's cafe, which he has licensed as
       "must pay money", then it would be reasonable for me to copy
       the map and put it in a brochure for the cafe, but not to copy
       the data and photo from CoolFotos. On the other hand, if I am
       producing a non-commercial guide to cafes in Melbourne, I can
       add the map and the location of the cafe photo, but not the
       photo itself.

This isn't affected; it's a legal issue, not a technological one. So long 
as the licenses are clearly stated, as they presumably must be (for 
example, the MIT license requires the copyright text to follow the text 
even as it is copied, the Creative Commons licenses require the license or 
its URL to be published with any reproductions, etc), there is no need for 
any markup.


     * Tara runs a video sharing web site for people who want
       licensing information to be included with their videos. When
       Paul wants to blog about a video, he can paste a fragment of
       HTML provided by Tara directly into his blog. The video is then
       available inline in his blog, along with any licensing
       information about the video.

This is now possible in a straight-forward manner.


     * Fred's browser can tell him what license a particular video on
       a site he is reading has been released under, and advise him on
       what the associated permissions and restrictions are (can he
       redistribute this work for commercial purposes, can he
       distribute a modified version of this work, how should he
       assign credit to the original author, what jurisdiction the
       license assumes, whether the license allows the work to be
       embedded into a work that uses content under various other
       licenses, etc).

This is now possible, assuming that the browser knows the license.


     * Flickr has images that are CC-licensed, but the pages
       themselves are not.

This is already handled by the rules for rel=license, but the license of 
the image itself can be even more clearly given with the microdata.


     * Blogs may wish to reuse CC-licensed images without licensing
       the whole blog as CC, but while still including attribution and
       license information (which may be required by the licenses in
       question).

This is also possible.


Let's look at the requirements:

   REQUIREMENTS:

     * Content on a page might be covered by a different license than
       other content on the same page.

Same as the scenario above.


     * When licensing a subpart of the page, existing implementations
       must not just assume that the license applies to the whole page
       rather than just part of it.

Existing implementations will see nothing, so that is handled easily. 
ccREL implementations will immediately support the new vocabulary once the 
mapping of HTML to RDF described in the spec is implemented (less than 
24 hours' work, apparently).


     * License proliferation should be discouraged.

License proliferation is not really _discouraged_, but it isn't 
encouraged, since new licenses wouldn't be known by the various tools.


     * License information should be able to survive from one site to
       another as the data is transfered.

This is now possible, assuming the microdata is also transfered.


     * Expressing copyright licensing terms should be easy for content
       creators, publishers, and redistributors to provide.

It's as easy as writing a license has always been, I guess.


     * It should be more convenient for the users (and tools) to find
       and evaluate copyright statements and licenses than it is
       today.

I guess it's easier than rel=license, insofar as rel=license required new 
pages, and this doesn't. I don't know if that's what was meant, though. 
The actual processing model is more complex now.


     * Shouldn't require the consumer to write XSLT or server-side
       code to process the license information.

Some code is necessary to make a search engine index license microdata, 
but that seems inevitable and, in practice, is a small amount of code 
relative to the rest of the code involved in an indexing project.


     * Machine-readable licensing information shouldn't be on a
       separate page than human-readable licensing information.

It's on the same page.


     * There should not be ambiguous legal implications.

There are, as far as I can tell, no legal implications at all.


     * Parsing rules should be unambiguous.

Microdata parsing rules are unambgious.


     * Should not require changes to HTML5 parsing rules.

HTML5 parsing isn't affected.


     * It should be possible to find works that do not have their own
       pages, e.g. images in a library, or software.

This is now handled.


     * Each resource needs to have the following information:
        - The URL to the resource, for identification purposes
        - The identifier of the license that applies to the resource
        - The name of the resource, for display in search results

This is now handled.



I've added this vocabulary to the spec.



On Wed, 10 Jun 2009, Tab Atkins Jr. wrote:
> 
> I think it's fundamentally rare to have a bunch of resources that (a) 
> *only* exist grouped together on a single page, and (b) need different 
> licenses.

Apparently you and I are the only ones who believe this. :-(

(In addition to some of the e-mails on-list about this, I've also received 
a lot of off-list feedback to the same effect as Eduard's feedback.)

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

From ian at hixie.ch  Tue Jul  7 16:59:48 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 7 Jul 2009 23:59:48 +0000 (UTC)
Subject: [whatwg] Limit on number of parallel Workers.
In-Reply-To: <fa2eab050906101411p694945fercba14316f96812da@mail.gmail.com>
References: <28040fc60906091813h7c301019h9c15e9fe7e26e167@mail.gmail.com>
	<63df84f0906091829w3b3f9b6cs6f3d828fc217c669@mail.gmail.com>
	<fa2eab050906091907r7cd5bcfdka513d14555a05d63@mail.gmail.com>
	<63df84f0906101346s6c163d51ka004480a09754d07@mail.gmail.com>
	<fa2eab050906101411p694945fercba14316f96812da@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0907072347480.1060@hixie.dreamhostps.com>


I include below, for the record, a set of e-mails on the topic of settings 
limits on Workers to avoid DOS attacks.

As with other such topics, the HTML5 spec allows more or less any 
arbitrary behaviour in the face of hardware limitations. There are a 
variety of different implementations strategies, and these will vary 
based on the target hardware. How to handle a million new workers will be 
different on a system with a million cores and little memory than a system 
with one core but terabytes of memory, or a system with 100 slow cores vs 
a system with 10 fast cores.

I have therefore not added any text to the spec on the matter. Please let 
me know if you think there should really be something in the spec on this.


On Tue, 9 Jun 2009, Dmitry Titov wrote:
> 
> In Chromium, workers are going to have their separate processes, at 
> least for now. So we quickly found that "while(true) foo = new 
> Worker(...)" quickly consumes the OS resources :-) In fact, this will 
> kill other browsers too, and on some systems the unbounded number of 
> threads will effectively "freeze" the system beyond the browser.
> 
> We think about how to reasonably place limits on the resources consumed 
> by 'sea of workers'. Obviously, one could just limit a maxumum number of 
> parallel workers available to page or domain or browser. But what do you 
> do when a limit is reached? The Worker() constructor could return null 
> or throw exception. However, that seems to go against the spirit of the 
> spec since it usually does not deal with resource constraints. So it 
> makes sense to look for the most sensible implementation that tries best 
> to behave.
> 
> Current idea is to let create as many Worker objects as requested, but 
> not necessarily start them right away. So the resources are not 
> allocated except the thin JS wrapper. As long as workers terminate and 
> the number of them decreases below the limit, more workers from the 
> "ready queue" could be started. This allows to support implementation 
> limits w/o exposing them.
> 
> This is similar to how a 'sea of XHRs' would behave. The test page 
> here<http://www.figushki.com/test/xhr/xhr10000.html> creates 10,000 
> async XHR requests to distinct URLs and then waits for all of them to 
> complete. While it's obviosuly impossible to have 10K http connections 
> in parallel, all XHRs will be completed, given time.
> 
> Does it sound like a good way to avoid the resource crunch due to high 
> number of workers?

On Tue, 9 Jun 2009, Oliver Hunt wrote:
>
> I believe that this will be difficult to have such a limit as sites may 
> rely on GC to collect Workers that are no longer running (so number of 
> running threads is non-deterministic), and in the context of mix source 
> content ("mash-ups") it will be difficult for any content source to be 
> sure it isn't going to contribute to that limit.  Obviously a UA 
> shouldn't crash, but i believe that it is up to the UA to determine how 
> to achieve this -- eg. having a limit to allow a