Re: [whatwg] on codecs in a 'video' tag.

[Dave Singer]

At 19:28  +0200 27/03/07, Christian F.K. Schaller wrote:


That is a matter of perception. Flash player which is the de-facto
standard at this point provides support on at least linux, windows and
Mac. We do risk that if this element is provided it could replace
Flash video with something that only supports Windows/Mac like Quicktime
or Windows only like Windows Media. So this could turn out to be a step
backward for interoperability. And I do prefer Adobe as a neutral broker
to be our 'evil overlords' if that is the choice given than someone like
Microsoft or Apple which has a their operating system platforms to push
and thus has an inherent interest to make life hard for Linux and
Solaris users.


I have a hard time believing what I am reading here.  A new video tag 
cannot 'replace' flash support unless Adobe wishes it.  Apple has 
neither power or desire to stop people implementing the video tag on 
any platform, and indeed the whole point in helping develop open 
standards is tyhat we want there to be broad support and 
interoperability.  In many places, we openly encourage companies to 
implement standards, or we open-source software to make it easy 
(webkit, Darwin Streaming Server, to name but two).  Our interest in 
multi-vendor multimedia standards is deep and long-lasting, 
interoperable, and very open.


Really, conspiracy theories are out of place here, please.



But I think this codec discussion isn't a reason to block on the
discussion of how this element should work.


I am glad we agree on that!


I think there are many
common sense decisions that can be made there which are irrelevant to
whether there are a baseline set of codecs and container format defined
in the spec.


Agreed as well.


If the end result is a specification contains requirements
for Vorbis and Theora and Apple choose to not be spec compliant with
Safari or Apple gets support for not including any mention of specific
codecs in the spec is in some ways irrelevant to the discussion of how
these elements should work.


Yes.  I re-iterate;  we have nothing aganist the Ogg or Theora 
codecs;  we just don't have a commercial reason to implement them, 
and we'd rather not have the HTML spec. try to force the issue.  It 
just gets ugly (like the 3G exception).

--
David Singer
Apple Computer/QuickTime

Re: [whatwg] Canvas - globalCompositeOperation

[ddailey]

I suspect you already are aware of this but in addition to the references 
you provide

the SVG 1.1 reco gives examples of the Porter-Duff composites
http://www.w3.org/TR/SVG11/filters.html

It appears that Opera is not handling them properly in SVG either:
http://srufaculty.sru.edu/david.dailey/svg/newstuff/filterComposite2.svg

fwiw
David Dailey
- Original Message - 
From: "Philip Taylor" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, March 27, 2007 7:30 PM
Subject: [whatwg] Canvas - globalCompositeOperation



It has been mentioned before [1] that globalCompositeOperation is
poorly defined - the spec has a note saying "The source-* descriptions
below don't define what should happen with semi-transparent regions"
and is vague about non-transparent colours too - and it is not
implemented interoperably. I haven't seen any descriptions of what it
ought to do, so this is an attempt to explain and describe what I
believe should be specified.



Most of the operations are defined in the Porter-Duff paper [2], which
does say how semi-transparent regions should be handled. My summary of
it:

A single pixel with 25% alpha is considered to be a large number of
subpixels of which a uniformly-random 25% are totally solid and 75%
are totally transparent - the subpixels only have 1-bit alpha. When
you combine that 25% alpha pixel 'A' with a 50% alpha pixel 'B', you
expect 25%*50% of the subpixels to overlap, while (1-25%)*(1-50%) of
subpixels are covered by neither pixel, and similar for the subpixels
that are covered by only 'A' or only 'B'.

The composite operators define how you choose which of the inputs (0,
A, B) is used as the output of the subpixel, for each of the four
possible coverage cases (!A & !B, !A & B, A & !B, A & B). Then you
just (conceptually) average all the subpixels, to get the actual pixel
output.


The P-D paper assumes colours are represented with pre-multiplied
alpha (where nonpremul[r, g, b, a] == premul[r*a, g*a, b*a, a]), e.g.
50%-transparent bright red is premul[0.5, 0, 0, 0.5]. The canvas
(inheriting from CSS) and seemingly much of the rest of the world
(e.g. Cairo, and most humans) use non-pre-multiplied alpha in their
APIs, e.g. 50% transparent red is "rgba(255, 0, 0, 0.5)". But the
compositing equations won't work nicely with non-pre-multiplied alpha,
and implementations appear to use pre-multiplied alpha internally, so
the operation should be specified in the pre-multiplied form. (I'll
use lowercase c for pre-multiplied colour components, uppercase C for
non-pre-multiplied.)


Taking that into account gives the following algorithm for most of the
composite operators:

|  Operator | FA   | FB
|  -+--+--
|  source-over  | 1| 1-aA
|  destination-over | 1-aB | 1
|  source-in|   aB | 0
|  destination-in   | 0|   aA
|  source-out   | 1-aB | 0
|  destination-out  | 0| 1-aA
|  source-atop  |   aB | 1-aA
|  destination-atop | 1-aB |   aA
|  xor  | 1-aB | 1-aA
|  copy | 1| 0
|  lighter  | 1| 1
|
|cO = cA*FA + cB*FB
|aO = aA*FA + aB*FB
|
|  where cX is the pre-multiplied colour component of pixel X, in the 
range
|  [0, 1]; aX is the alpha component of pixel X in the range [0, 1]; A and 
B
|  are the source and destination pixels respectively; O is the output 
pixel.

|
|  The calculation of aO must be clamped to the range [0, 1].

("lighter" can result in aO > 1, hence the need to clamp it.)

Only "darker" cannot fit in this table (given that FA is a function of
aB, and FB is a function of aA).



To compare the main implementations (Firefox trunk 20070326, Opera
9.20, Safari 2.0.4), there is a demonstration at
 http://canvex.lazyilluminati.com/tests/composite/composite.html
and example outputs at
 http://canvex.lazyilluminati.com/tests/composite/firefox3_20070326.png
 http://canvex.lazyilluminati.com/tests/composite/opera920_8762.png
 http://canvex.lazyilluminati.com/tests/composite/safari204.png

"over", "in", "out" and "copy" are all correct (in that they match the
above algorithm).

"xor" is correct in Firefox and Safari, but incorrect in Opera; Opera
appears to be using the pre-multiplied equations on the
non-pre-multiplied colours (i.e. doing CO = CA*FA + CB*FB, where CX is
the non-pre-multiplied colour component).

"atop" and "lighter" are correct in Firefox and Safari, but incorrect
in Opera; I don't know what Opera is doing.

"darker" is messy:

Firefox's "darker" is implemented as:

 Operator  | FA| FB
 --+---+--
 darker [saturate] | min(1, (1-aB)/aA) | 1

It seems this can't easily be hardware-accelerated - the Cairo GL
backend [3] doesn't support CAIRO_OPERATOR_SATURATE, and says

 case CAIRO_OPERATOR_SATURATE:
   /* XXX: This line should never be reached. Glitz backend should
bail out earlier if saturate operator is used. OpenGL can't do
saturate with pre-multiplied colors. Solid colors can still be do

[whatwg] Canvas - globalCompositeOperation

[Philip Taylor]

It has been mentioned before [1] that globalCompositeOperation is
poorly defined - the spec has a note saying "The source-* descriptions
below don't define what should happen with semi-transparent regions"
and is vague about non-transparent colours too - and it is not
implemented interoperably. I haven't seen any descriptions of what it
ought to do, so this is an attempt to explain and describe what I
believe should be specified.



Most of the operations are defined in the Porter-Duff paper [2], which
does say how semi-transparent regions should be handled. My summary of
it:

A single pixel with 25% alpha is considered to be a large number of
subpixels of which a uniformly-random 25% are totally solid and 75%
are totally transparent - the subpixels only have 1-bit alpha. When
you combine that 25% alpha pixel 'A' with a 50% alpha pixel 'B', you
expect 25%*50% of the subpixels to overlap, while (1-25%)*(1-50%) of
subpixels are covered by neither pixel, and similar for the subpixels
that are covered by only 'A' or only 'B'.

The composite operators define how you choose which of the inputs (0,
A, B) is used as the output of the subpixel, for each of the four
possible coverage cases (!A & !B, !A & B, A & !B, A & B). Then you
just (conceptually) average all the subpixels, to get the actual pixel
output.


The P-D paper assumes colours are represented with pre-multiplied
alpha (where nonpremul[r, g, b, a] == premul[r*a, g*a, b*a, a]), e.g.
50%-transparent bright red is premul[0.5, 0, 0, 0.5]. The canvas
(inheriting from CSS) and seemingly much of the rest of the world
(e.g. Cairo, and most humans) use non-pre-multiplied alpha in their
APIs, e.g. 50% transparent red is "rgba(255, 0, 0, 0.5)". But the
compositing equations won't work nicely with non-pre-multiplied alpha,
and implementations appear to use pre-multiplied alpha internally, so
the operation should be specified in the pre-multiplied form. (I'll
use lowercase c for pre-multiplied colour components, uppercase C for
non-pre-multiplied.)


Taking that into account gives the following algorithm for most of the
composite operators:

|  Operator | FA   | FB
|  -+--+--
|  source-over  | 1| 1-aA
|  destination-over | 1-aB | 1
|  source-in|   aB | 0
|  destination-in   | 0|   aA
|  source-out   | 1-aB | 0
|  destination-out  | 0| 1-aA
|  source-atop  |   aB | 1-aA
|  destination-atop | 1-aB |   aA
|  xor  | 1-aB | 1-aA
|  copy | 1| 0
|  lighter  | 1| 1
|
|cO = cA*FA + cB*FB
|aO = aA*FA + aB*FB
|
|  where cX is the pre-multiplied colour component of pixel X, in the range
|  [0, 1]; aX is the alpha component of pixel X in the range [0, 1]; A and B
|  are the source and destination pixels respectively; O is the output pixel.
|
|  The calculation of aO must be clamped to the range [0, 1].

("lighter" can result in aO > 1, hence the need to clamp it.)

Only "darker" cannot fit in this table (given that FA is a function of
aB, and FB is a function of aA).



To compare the main implementations (Firefox trunk 20070326, Opera
9.20, Safari 2.0.4), there is a demonstration at
 http://canvex.lazyilluminati.com/tests/composite/composite.html
and example outputs at
 http://canvex.lazyilluminati.com/tests/composite/firefox3_20070326.png
 http://canvex.lazyilluminati.com/tests/composite/opera920_8762.png
 http://canvex.lazyilluminati.com/tests/composite/safari204.png

"over", "in", "out" and "copy" are all correct (in that they match the
above algorithm).

"xor" is correct in Firefox and Safari, but incorrect in Opera; Opera
appears to be using the pre-multiplied equations on the
non-pre-multiplied colours (i.e. doing CO = CA*FA + CB*FB, where CX is
the non-pre-multiplied colour component).

"atop" and "lighter" are correct in Firefox and Safari, but incorrect
in Opera; I don't know what Opera is doing.

"darker" is messy:

Firefox's "darker" is implemented as:

 Operator  | FA| FB
 --+---+--
 darker [saturate] | min(1, (1-aB)/aA) | 1

It seems this can't easily be hardware-accelerated - the Cairo GL
backend [3] doesn't support CAIRO_OPERATOR_SATURATE, and says

 case CAIRO_OPERATOR_SATURATE:
   /* XXX: This line should never be reached. Glitz backend should
bail out earlier if saturate operator is used. OpenGL can't do
saturate with pre-multiplied colors. Solid colors can still be done as
we can just un-pre-multiply them. However, support for that will have
to be added to glitz. */

Safari gives completely different output, and is very close to
implementing it with non-pre-multiplied colours as:

 CO = 1 - (1-CA)*aA - (1-CB)*aB
 aO = aA + aB

except not quite like that (see the bottom-right box in the example
page), and I don't know what it's really doing. Opera is also quite
like that, except more different.

KHTML [4] doesn't implement either "lighter" or "darker" - it treats
them as "source-ove

Re: [whatwg] on codecs in a 'video' tag.

[Benjamin Hawkes-Lewis]

James Graham wrote:

> Agreed (much as I dislike Flash). Unfortunatley the fact that Flash is 
> effectivley implemented by a single binary plugin and the public 
> specification 
> has a "no implementations" license makes this impossible to include.

Just wanted to note that, strictly speaking, it might be possible to
define a common core of standard functionality based on what Gnash
supports.

--
Benjamin Hawkes-Lewis

Re: [whatwg] on codecs in a 'video' tag.

[Silvia Pfeiffer]

Hi Dave,

On 3/28/07, Dave Singer <[EMAIL PROTECTED]> wrote:

>>  We really feel that the HTML spec. should say no more about video and
>>  audio formats than it does about image formats (which is merely to give
>>  examples), and we should strive independently for audio/video
>>  convergence.  We'd really like to discuss the 'meat' of the proposal --
>>  the tags, the CSS, and so on!
>
>The whole point of the spec is to make sure implementations are
>compatible.  Just discussing the "meat" and ignoring how things work out
>in practice may backfire.

I think the example of SVG (a 'markup' language) having a codec
requirement that 3GPP then had to explicitly write-out is
instructive.  The attempt there didn't work.


I would be curious for the reasons that 3GPP has taken the requirement
of vorbis out of the spec. Was that a decision based on technical
reasons and could you please explain what these technical reasons
were?

Regards,
Silvia.

[whatwg] Apply script.defer to internal scripts

[Kristof Zelechovski]

  3.17.1. The
script element specification says:

  defer (if the
 src attribute is
present) 

  async (if the
 src attribute is
present) 

  

 

I understand that the async attribute must depend on the src attribute
because it is needed and meaningful only when the script element is loaded
from an external source; however, the advantage of using the defer attribute
is not limited to that case. 

Consider the following example:


function ha8validate(p5event) { return true }
document.forms[0].onsubmit = ha8validate


The script embedded here is so short and specific that it makes no sense
relaying it to an external location; however, if the script is not deferred,
the script fails with an exception at run time because the document body is
not constructed yet.  

Therefore, the defer attribute can be meaningful without the src attribute
and the dependency should be removed.

 

Yours sincerely

Christopher Yeleighton

Re: [whatwg] on codecs in a 'video' tag.

[Maik Merten]

Dave Singer schrieb:
> We'd really like to get to a good design on this, as the mess of
> embed/object plug-ins we feel is limiting both functionality and
> interoperability.

Yeah, and the work to get good functionality into the  element
obviously can and should go on without having to worry about codecs at all.

Once the implementation work starts the topic of codecs will inevitably
matter again and I hope this won't lead to a media-format fragmentation
that hinders interoperability.

> It would be tempting to go into a discussion of the IPR concerning the
> baseline of H.264, but it's really off-topic and obviously delicate.

You're right.

>> And to make matters worse you of course need a MPEG audio codec, too,
>> which adds to the overal costs.
> 
> well, you could match an mpeg video codec with an audio codec from
> somewhere else, technically.

Yeah, but that'd mean you'd come up with a "Frankenstein" format that is
neither free nor a standard of any kind. However, you're just pointing
out the technical possibility.

> I think the example of SVG (a 'markup' language) having a codec
> requirement that 3GPP then had to explicitly write-out is instructive. 
> The attempt there didn't work.

Well, if 3GPP chose to write out a required format they obviously wanted
to violate the spec without getting blamed for violating it ;)

In case of WHATWG, which primarily is "just" Apple, Mozilla and Opera I
guess such spec-mangling should be unnecessariy, especially if the spec
only mentions special formats as an optional thing.

Personally I fear that once  is out in the wild without a free
base format getting promoted Microsoft sooner or later will join the
party with a Windows Media only implementation and effectively sabotage
the WHATWG efforts of interoperability without even having to take the
blame for ignoring the base format. That's just a theoretical
possibility, but I think it doesn't harm to "harden" the spec against
such "hacks".

Actually the current  draft requires user agents to support PCM
in a .wav container (that's way stronger than what can be found in the
 section). I guess your points apply there, too?


Maik Merten

Re: [whatwg] on codecs in a 'video' tag.

[Christoph Päper]

Anne van Kesteren:
Also, I think the HTML specification should mandate (as SHOULD- 
level requirement, probably) support for the various supported  
image formats as it gives a clear indication of what authors can  
rely on and what user agents have to implement in order to support  
the web.


Which format would this be for animated true-colour images, lossy or  
lossless? MNG/JNG, APNG, JS+PNG/JPEG, SVG+PNG/JPEG ...? Or is there  
no need to require one? If so why not?


I am still not convinced (X)HTML5 should recommend support for  
anything but itself. Although HTTP, CSS, JS, GIF and JPEG/JFIF might  
seem safe, they all have certain (exotic) features that are not  
implemented (the same / correctly / at all) in current browsers. I  
think informative advise is all there needs to be, but RFC 2119 does  
not have something between 'should' and 'may', like 'ought' and  
'suggested' or 'advocated' perhaps.


--
RFC 2119:
'must'   = 'shall'  = 'required'
'must not'   = 'shall not'
   'should' = 'recommended'
   'should not' = 'not recommended'
'may'='optional'

Terms not defined therein, but sometimes encountered in "Web  
standards" are for example 'forbidden', 'mandatory', 'prescribed',  
'compulsory', 'permissive', 'allowed', deprecated', 'obsolete',  
'will', 'would'.

Re: [whatwg] on codecs in a 'video' tag.

[Christian F.K. Schaller]

On Tue, 2007-03-27 at 09:04 -0700, Dave Singer wrote:
> At 13:26  +0200 27/03/07, Maik Merten wrote:
> >It's good to know that Apple considers interoperability as something
> >important.
> >
> >Of course in case of the iPod the highly proprietary DRM scheme is
> >preventing true interoperability if someone condiders DRM a must for his
> >business needs and Apple's credibility concerning true, termless
> >interoperability sadly is taking some damage there.
> 
> I think we're getting well off topic of HTML here, but a good 
> discussion of the problems here can be found in Steve Jobs' open 
> letter.
> 
> >
> >What matters here in the context of web-video is Apple's commitment to
> >get  working on all platforms and all environments (either
> >proprietary or free software or whatever categories there may be).
> 
> We'd really like to get to a good design on this, as the mess of 
> embed/object plug-ins we feel is limiting both functionality and 
> interoperability.

That is a matter of perception. Flash player which is the de-facto
standard at this point provides support on at least linux, windows and
Mac. We do risk that if this element is provided it could replace 
Flash video with something that only supports Windows/Mac like Quicktime
or Windows only like Windows Media. So this could turn out to be a step
backward for interoperability. And I do prefer Adobe as a neutral broker
to be our 'evil overlords' if that is the choice given than someone like
Microsoft or Apple which has a their operating system platforms to push
and thus has an inherent interest to make life hard for Linux and
Solaris users.

But I think this codec discussion isn't a reason to block on the
discussion of how this element should work. I think there are many
common sense decisions that can be made there which are irrelevant to
whether there are a baseline set of codecs and container format defined
in the spec. If the end result is a specification contains requirements
for Vorbis and Theora and Apple choose to not be spec compliant with
Safari or Apple gets support for not including any mention of specific
codecs in the spec is in some ways irrelevant to the discussion of how
these elements should work.

Christian

Re: [whatwg] on codecs in a 'video' tag.

[Bjoern Hoehrmann]

* James Graham wrote:
>The pain of having things that "everyone knows" are needed to make a useful 
>HTML 
>reading device but are not documented as such. A specification is 
>documentation 
>both of the language and what needs to be done to implement a UA to read it 
>and 
>I see no reason to arbitarily limit the scope to those parts that can be 
>expressed in pure markup.

Documentation would be, for example, "As of 2007, popular image formats
used in conjunction with HTML documents include GIF, JPEG, ICO and PNG";
specifications, that is, the normative parts of it, define what is
necessary and sufficient to conform to the specification. What you, or
Anne for that matter, are proposing is that certain applications that
implement HTML should be non-conforming if they do not support GIF, or
certain other formats.

>In the case of image formats it's probably not overwhelmingly important (only 
>because "everyone knows" what is needed; in the case of audio and video I 
>think 
>it is very important) but I can't see how it's harmful in the way you suggest.

Then I suggest you write the specification text using a sufficiently
narrow conformance class and use MUST instead of SHOULD, complete with
normative references and such, making it sufficiently robust to with-
stand various questions one might ask, like

  * do I have to implement those features of JPEG that are not commonly
implemented in popular open source JPEG libraries?

  * is it sufficient to support display of GIF images by allowing users
to configure an external application that would be launched on re-
quest?

  * where exactly (img, object, video, iframe, favicons, inline SVG) is
such support required?

  * does IE6' implementation of PNG conform to your requirements?

  * when do I have to animate animated GIF images, and what should be
done if I may and do not want to animate them, for example, in the
bookmark list where favicons would be shown?

It is okay, of course, if you make certain things implementation-
defined, you can than judge how close you are to your goal to avoid
having the "everyone knows" bits in your specification. For the first
item you might start with .
Then tell us why you did not write some useful test cases instead.

>In any case this discussion is probably not very useful.

Well, more useful than having the "HTML specification" mandate some
unqualified level of GIF support.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [whatwg] on codecs in a 'video' tag.

[Dave Singer]

At 13:26  +0200 27/03/07, Maik Merten wrote:

It's good to know that Apple considers interoperability as something
important.

Of course in case of the iPod the highly proprietary DRM scheme is
preventing true interoperability if someone condiders DRM a must for his
business needs and Apple's credibility concerning true, termless
interoperability sadly is taking some damage there.


I think we're getting well off topic of HTML here, but a good 
discussion of the problems here can be found in Steve Jobs' open 
letter.




What matters here in the context of web-video is Apple's commitment to
get  working on all platforms and all environments (either
proprietary or free software or whatever categories there may be).


We'd really like to get to a good design on this, as the mess of 
embed/object plug-ins we feel is limiting both functionality and 
interoperability.





 We also have been sometimes openly critical of licensing terms and
 problems around codecs;  we supported the attempt to get a a
 royalty-free baseline for H.264, for example.  We recognize the value of
 research and invention, but we also realize that to realize a value from
 a use of those inventions, the use has to happen and make business
 sense.  It's a balance...


Well, too bad there's no royality-free, termless licensing for a
baseline of H.264. The current terms (
http://www.mpegla.com/avc/AVC_TermsSummary.pdf ) absolutely question the
suitability of H.264 for free browsers (beer and speech).


It would be tempting to go into a discussion of the IPR concerning 
the baseline of H.264, but it's really off-topic and obviously 
delicate.



And to make matters worse you of course need a MPEG audio codec, too,
which adds to the overal costs.


well, you could match an mpeg video codec with an audio codec from 
somewhere else, technically.






 We really feel that the HTML spec. should say no more about video and
 audio formats than it does about image formats (which is merely to give
 examples), and we should strive independently for audio/video
 convergence.  We'd really like to discuss the 'meat' of the proposal --
 the tags, the CSS, and so on!


The whole point of the spec is to make sure implementations are
compatible.  Just discussing the "meat" and ignoring how things work out
in practice may backfire.


I think the example of SVG (a 'markup' language) having a codec 
requirement that 3GPP then had to explicitly write-out is 
instructive.  The attempt there didn't work.


There are, or should be, two levels of specification:  base 
technologies, and integration specifications.  For example, ISMA 
publishes integration specs on continuous media;  if uses MPEG 
codecs, IETF RTSP/RTP, and so on.  3GPP does the same, effectively. 
In 3G terminals, your image support and video support are defined by 
the matching 3GPP specs.


There is, alas, no group publishing an integration specification, or 
even recommendation, on what a 'web browser' on the general internet 
must, or should do.  It's an interesting exercise to ask what such a 
spec. should include or cover.  What's clear is that if done 
thoroughly, it's a lot of work, and does not belong 'inside' the HTML 
specification itself.  The HTML spec. should instead cover what the 
HTML means, and how it must be processed -- including fall-back.

--
David Singer
Apple Computer/QuickTime

Re: [whatwg] on codecs in a 'video' tag.

[James Graham]

Bjoern Hoehrmann wrote:

I have a hard time following you. Could you rephrase what pain it would
solve, and why this is the best solution, if the HTML specification in-
cludes documentation what you need in terms of explicit interaction with
the document layer to produce a functional graphical web browser, except
those things that cannot be included for some reason; and giving vendors
of said applications a well-defined target? I can honestly think of no
pain that would be solved by having the "HTML specification" recommend
that certain types of web browsers implement the GIF image format.


The pain of having things that "everyone knows" are needed to make a useful HTML 
reading device but are not documented as such. A specification is documentation 
both of the language and what needs to be done to implement a UA to read it and 
I see no reason to arbitarily limit the scope to those parts that can be 
expressed in pure markup. As I mentioned there is also the problem of vendors 
punting on supporting parts of formats that everyone else supports. SHOULD 
requirements in HTML provide a little extra leverage when reporting these 
deficiencies as bugs.


In the case of image formats it's probably not overwhelmingly important (only 
because "everyone knows" what is needed; in the case of audio and video I think 
it is very important) but I can't see how it's harmful in the way you suggest.


In any case this discussion is probably not very useful.

--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

[whatwg] innerHTML in HTML documents with multiple namespaces

[Thomas Broyer]

Hi,

As announced on the WHATWG-Implementors list, I've done some
preliminary work on HTML5 serializers for Kid and Genshi templating
engines. I'm basing on the algorithm for getting the innerHTML value


I'm actually wondering what is supposed to be "tag name" for an
element which is not in the HTML namespace (e.g. created with
document.createElementNS). Is it the localName or the tagName
(qualified name, i.e. with prefix)?

In other words, what should document.body.innerHTML end with after this script:
var svg_svg = document.createElementNS("http://www.w3.org/2000/svg";, "svg:svg");
document.body.appendChild(svg_svg);

Should it end with "" or ""? (Firefox
would have "")

Also, should the "tag name" be lowercased before inclusion in the
output or the algorithm is just assuming the "tag name" of HTML
elements have already been lowercased elsewhere? (Firefox keeps
uppercase letters; elements created with document.createElement are
HTMLElements and have their names lowercased at creation time; as
described in the spec)

Same questions with attribute names ;-)

--
Thomas Broyer

Re: [whatwg] on codecs in a 'video' tag.

[Bjoern Hoehrmann]

* James Graham wrote:
>Partly it's for documentation: a statement of what you need to produce a 
>functional web browser. Partly to give vendors a well-defined target; it is 
>only 
>very recently that IE has grown full support for PNG files, for example.

I have a hard time following you. Could you rephrase what pain it would
solve, and why this is the best solution, if the HTML specification in-
cludes documentation what you need in terms of explicit interaction with
the document layer to produce a functional graphical web browser, except
those things that cannot be included for some reason; and giving vendors
of said applications a well-defined target? I can honestly think of no
pain that would be solved by having the "HTML specification" recommend
that certain types of web browsers implement the GIF image format.

Targeting a certain set of web browsers, some of which support 8 bit
alpha channels in PNG images and some of which failing to do that is a
pain, agreed, but that pain is, as you point out, already solved to a
certain extent. Similarily, if such web browsers support disjunct sets
of audio formats that would be a pain that's worth solving. Certainly
it pains me greatly that certain browser vendors harmfully fail to im-
plement core HTTP features like 'gzip' Transfer-Encoding while others
properly implement it. It's also painful to have no good documentation
on what various relevant versions of relevant browsers implement, from
their support of DOM features over HTTP features to CSS features, that
is also a pain worth fixing. However, I do not see how, for most of
these things, the "HTML specification" is a good place to solve them.

If you broaden the scope from "HTML specification" as David was writing
about, to "Everything you need and always wanted to know about HTML-
based content- and application-authoring and implementation of such, but
were afraid to ask (except the bits about Flash and such we don't tell
you, of course!)" specification, that might be a better place, but
making such a specification is not a good idea. You can certainly make
a good argument to have the "HTML specification" recommend or even re-
quire support for a certain audio or video or whatever format, but do
not fall for the inductive fallacies we are approaching here. If you
want documentation, make documentation, not specifications. And if you
want to solve problems, stop solving them once they are solved.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [whatwg] on codecs in a 'video' tag.

[Spartanicus]

Maik Merten <[EMAIL PROTECTED]> wrote:

>Well, too bad there's no royality-free, termless licensing for a
>baseline of H.264. The current terms (
>http://www.mpegla.com/avc/AVC_TermsSummary.pdf ) absolutely question the
>suitability of H.264 for free browsers (beer and speech). The licensing
>costs can pile up to considerable amounts (hundred of thousands of
>dollars) if you ship as many browser packages as e.g. Mozilla does.
>That's most likely an unacceptable money bleed for a zero-revenue
>product.

Even if it wasn't, using a commercial codec as the baseline codec may
require people who wish to author content using that format to pay for
the privilege. This is currently the case for mp3 [1]. Although afaik
this isn't currently the case for non commercial usage, the rights
holders can change that at any given moment.

[1] http://www.mp3licensing.com/help/index.html#4

-- 
Spartanicus

[whatwg] EMBED should not require src if type is specified.

[Shadow2531]

As mentioned offtopic in
,
just like OBJECT, for EMBED, the src attribute is not always needed
and sometimes it must not be present.

The best example for not requiring src is the tcl plug-in.



Also, Java can be loaded via the embed element where src is not needed.


There are other cases with the Windows Media plug-in or with the
RealPlayer plug-in where just loading the plug-in with the type
attribute and doing scripting on the object is desirable.

There's also the neptune plug-in. For example: . In this case, it wants a
param-location param and not a src param.


--
burnout426

Re: [whatwg] on codecs in a 'video' tag.

[James Graham]

Bjoern Hoehrmann wrote:

* James Graham wrote:
I think you are mistaking a requirement for all UAs with one for UAs that 
support the display of images. For UAs that support the display of images, 
authors rely on GIF, JPEG and PNG support being avaliable. The specifcation 
should reflect the reality that any UA with image support that intends to work 
on the web must support these formats.



Why should some of these be called out in
the "HTML specification", and if only some of them, why bother
with that at all?


Some of these are relevent to the document layer of the UA i.e. the part that 
deals with interpreting HTML documents, others are part of some other part.


> Adobe Flash

Agreed (much as I dislike Flash). Unfortunatley the fact that Flash is 
effectivley implemented by a single binary plugin and the public specification 
has a "no implementations" license makes this impossible to include.



XMLHttpRequest


Is included.


SSL, TLS, IDNs, HTTP Basic Auth, a range of URI schemes


Part of the networking layer of the UA. Only explicit interaction with the 
document layer is important.



Cookies


Well the spec points to RFC 2109 and defines how the cookie attribute works on 
HTMLDocument.



a broad range of character
encodings


The spec does have something to say about character encodings and I would very 
much like a list of baseline encodings that a UA should support.



 some subset of CSS


I have no problem with the spec stating that UAs SHOULD support CSS. However 
many people would argue that style is less important than content and, since 
images are part of content, it would follow that CSS support is not as important 
as image support.



XSLT 1.0


Irrelevant for the vast majority of the web.


And what if, say, some consortium of mobile solution provides agree
on additional required features


Then either those won't be widely used on the public web and so are irrelevant 
or they will be widely adopted and should be specified in the HTML specification 
(or the HTTP specification or wherever they fit).


> They [authors] would

not be helped in their decision what they can use. So, who's this
for?


Partly it's for documentation: a statement of what you need to produce a 
functional web browser. Partly to give vendors a well-defined target; it is only 
very recently that IE has grown full support for PNG files, for example.


--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] on codecs in a 'video' tag.

[Maik Merten]

Dave Singer schrieb:
> On the question of whether a video or audio tag should mention the
> codecs:  we're really very supportive of the need for convergence and
> interoperability.  For example, I took a video iPod to an MPEG meeting a
> week or two after its intro, and at the meeting I got five companies,
> using their own H.264 and AAC and file format implementations, to build
> files that would play on it.  We've actively helped 3rd parties be
> compatible with the iPod and iTunes.  We really do believe in this stuff.

It's good to know that Apple considers interoperability as something
important.

Of course in case of the iPod the highly proprietary DRM scheme is
preventing true interoperability if someone condiders DRM a must for his
business needs and Apple's credibility concerning true, termless
interoperability sadly is taking some damage there.

(Personally I think DRM is doing way to much "collateral" damage and
usually leads to a despicable content lock-in much to the dismay of
customers. But that's most likely not the right place for that kind of
discussion.)

What matters here in the context of web-video is Apple's commitment to
get  working on all platforms and all environments (either
proprietary or free software or whatever categories there may be).

> We also have been sometimes openly critical of licensing terms and
> problems around codecs;  we supported the attempt to get a a
> royalty-free baseline for H.264, for example.  We recognize the value of
> research and invention, but we also realize that to realize a value from
> a use of those inventions, the use has to happen and make business
> sense.  It's a balance...

Well, too bad there's no royality-free, termless licensing for a
baseline of H.264. The current terms (
http://www.mpegla.com/avc/AVC_TermsSummary.pdf ) absolutely question the
suitability of H.264 for free browsers (beer and speech). The licensing
costs can pile up to considerable amounts (hundred of thousands of
dollars) if you ship as many browser packages as e.g. Mozilla does.
That's most likely an unacceptable money bleed for a zero-revenue
product. And of course distributions shipping own versions of Mozilla
(it's free (speech) software after all) most likely aren't able to ever
fulfil the licensing terms (how are they supposed to track deployment -
provided they could pay the fees?).

And to make matters worse you of course need a MPEG audio codec, too,
which adds to the overal costs.

In case of physical hardware players that sell for amounts of money that
dwarf the licensing costs the licensing terms seem to be fair. The Web,
however, has other needs if we want to preserve it as free
infrastructure (apart from the traffic costs) - and thankfully the W3C
realized this.

http://www.w3.org/2004/02/05-patentsummary.html

"The license must not charge a fee or royalty;"


> We really feel that the HTML spec. should say no more about video and
> audio formats than it does about image formats (which is merely to give
> examples), and we should strive independently for audio/video
> convergence.  We'd really like to discuss the 'meat' of the proposal --
> the tags, the CSS, and so on!

The whole point of the spec is to make sure implementations are
compatible.  Just discussing the "meat" and ignoring how things work out
in practice may backfire.

HTML already embraces CSS, which is not part of HTML itself. I don't see
how slightly elevating and embracing a free audio/video format without
requiring support for it (and not disallowing other formats) can do any
damage.

Not caring for video formats at all in practice may only work if there's
already a de-facto standard in place that can be freely implemented by
basically all user agent vendors. It may be possible to "let the market
sort things out" - but that'd take time and lead to confusion... and of
course it may lead to a disastrous kind of "bad luck" for free browsers
if a non-free format happens to become a de-facto standard. All of this
can be avoided if the assembled user agent vendors negotiate on a
gentlemen-agreement that is in spirit of the free nature of the Web -
and I think it can't harm if this gentlemen-agreement makes it into the
spec as optional part.


Maik Merten

Re: [whatwg] on codecs in a 'video' tag.

[Bjoern Hoehrmann]

* James Graham wrote:
>I think you are mistaking a requirement for all UAs with one for UAs that 
>support the display of images. For UAs that support the display of images, 
>authors rely on GIF, JPEG and PNG support being avaliable. The specifcation 
>should reflect the reality that any UA with image support that intends to work 
>on the web must support these formats.

Any mass-market user agent that "intends to work on the web" must
support some recent version of Adobe Flash, XMLHttpRequest, SSL,
TLS, IDNs, Cookies, HTTP Basic Auth, a broad range of character
encodings, some subset of CSS, XSLT 1.0, a range of URI schemes,
and many other things. Why should some of these be called out in
the "HTML specification", and if only some of them, why bother
with that at all?

And what if, say, some consortium of mobile solution provides agree
on additional required features, should those also be re-iterated
in the "HTML specification"? Clearly it does not help mass-market
browser vendors at all if you tell them to support GIF images; and
if the specification requires all of, say, GIF, , and some
socket-based network API, how would that help authors? They would
not be helped in their decision what they can use. So, who's this
for?
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [whatwg] on codecs in a 'video' tag.

[James Graham]

Bjoern Hoehrmann wrote:

* Anne van Kesteren wrote:
Also, I think the HTML specification should mandate (as SHOULD-level  
requirement, probably) support for the various supported image formats as  
it gives a clear indication of what authors can rely on and what user  
agents have to implement in order to support the web.


And you think this should be in the "HTML specification" rather than
some dedicated technologies-that-should-be-implemented-by-visual-desk-
top-browsers specification why exactly?


I think you are mistaking a requirement for all UAs with one for UAs that 
support the display of images. For UAs that support the display of images, 
authors rely on GIF, JPEG and PNG support being avaliable. The specifcation 
should reflect the reality that any UA with image support that intends to work 
on the web must support these formats.



Such a "SHOULD" would not apply
to many "HTML implementations" and not easy to specify (you do not want
to require full JPEG support, for example, and an authoring tool might
not support GIF)


I would expect WYSIWYG authoring environments to display a GIF image that I 
wanted to included in a document. I wouldn't expect them to edit that image.



so you have a SHOULD with many exceptions, decreasing
the normative force of all other SHOULD-level requirements.


How does this affect the force of any other SHOULD level requirement? Text like 
(example only, I'm sure you can pick it apart) "Graphical UAs which support 
images SHOULD support display of the following formats: JPEG [JPEG], GIF [GIF] 
and PNG [PNG]" has no effect on any other SHOULD-level text.


Returning to the issue of , I strongly believe that without one baseline 
format on which authors can rely,  is dead in the water. Mandating a 
baseline format in the spec is the only means to encourage the adoption of a 
format free of known IP issues by big players who can affort the extortionate 
licensing fees needed to implement support for some other formats.


--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] on codecs in a 'video' tag.

[Anne van Kesteren]

On Tue, 27 Mar 2007 12:41:28 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>  
wrote:

* Anne van Kesteren wrote:

Also, I think the HTML specification should mandate (as SHOULD-level
requirement, probably) support for the various supported image formats  
as it gives a clear indication of what authors can rely on and what user

agents have to implement in order to support the web.


And you think this should be in the "HTML specification" rather than
some dedicated technologies-that-should-be-implemented-by-visual-desk-
top-browsers specification why exactly? Such a "SHOULD" would not apply
to many "HTML implementations" and not easy to specify (you do not want
to require full JPEG support, for example, and an authoring tool might
not support GIF), so you have a SHOULD with many exceptions, decreasing
the normative force of all other SHOULD-level requirements.


I forgot to mention that I think the requirement should only apply to the  
web browser conformance class. It indeed doesn't make much sense for a lot  
of other user agents.



--
Anne van Kesteren

Re: [whatwg] on codecs in a 'video' tag.

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>Also, I think the HTML specification should mandate (as SHOULD-level  
>requirement, probably) support for the various supported image formats as  
>it gives a clear indication of what authors can rely on and what user  
>agents have to implement in order to support the web.

And you think this should be in the "HTML specification" rather than
some dedicated technologies-that-should-be-implemented-by-visual-desk-
top-browsers specification why exactly? Such a "SHOULD" would not apply
to many "HTML implementations" and not easy to specify (you do not want
to require full JPEG support, for example, and an authoring tool might
not support GIF), so you have a SHOULD with many exceptions, decreasing
the normative force of all other SHOULD-level requirements.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [whatwg] on codecs in a 'video' tag.

[Anne van Kesteren]

On Tue, 27 Mar 2007 03:18:04 +0200, Dave Singer <[EMAIL PROTECTED]> wrote:

We really feel that the HTML spec. should say no more about video and
audio formats than it does about image formats (which is merely to
give examples), and we should strive independently for audio/video
convergence.  We'd really like to discuss the 'meat' of the proposal
-- the tags, the CSS, and so on!


I'm not sure how that's very interesting without a common baseline format  
that all browsers can implement RF.


Also, I think the HTML specification should mandate (as SHOULD-level  
requirement, probably) support for the various supported image formats as  
it gives a clear indication of what authors can rely on and what user  
agents have to implement in order to support the web.



--
Anne van Kesteren

Re: [whatwg] Video proposals

[Alexey Feldgendler]

On Mon, 26 Mar 2007 13:59:14 +0200, Benoit Piette <[EMAIL PROTECTED]> wrote:

> In the same train of thought, a  tag might be useful. I always
> found anoying that for many embeded documents (word or pdf) you would have a
> second user interface that have similar functionnality to the web browser
> (ex: search within a document). Something like  type="application/ms-word" />. Having a consistent API and consistent user
> interface for an embeded document would be certainly useful. Imagine a
> consitent interface (user and API) for an embeded word document, a pdf, or
> even an editable content / controls for a CMS, wiki or a blog... Of course,
> creating an API that can edit both a PDF and a Word document is something
> daunting to say the least... But something that could be useful for simple
> content creation (like in a simple CMS, blog or wiki, something that can
> actualy generate valid HTML!) and general document embedding for viewing
> might be possible.

There is  for this.


-- 
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com