Re: [whatwg] Internal character encoding declaration, Drop UTF-32, and UTF and BOM terminology

[Ian Hickson]

On Sun, 24 Jun 2007, Peter Karlsson wrote:
> >>
> >> I don't think forbidding BOCU-1 is a good idea. If there is ever a 
> >> proper specification written of it, it could be very useful as a 
> >> compression format for documents.
> >
> > BOCU-1 has been used for security attacks. It's on the "no fly" list.
> 
> Do you have any references on that, or are you thinking about SCSU 
> (which suffers from the problem of having several valid compressions for 
> each string)?

Not off-hand. I'm not confusing it with SCSU, which is also disallowed.

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

Re: [whatwg] The issue of interoperability of the element

[Silvia Pfeiffer]

On 6/25/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

Our current plan is to primarily support MPEG-4, including H.264/AVC
video and AAC audio. We may support other codecs as well - it won't
necessarily be the full set of codecs supported by QuickTime. This
has been discussed to death already, but here are our basic reasons:

- MPEG-4 is an ISO open standard (although unfortunately patent-
encumbered).
- Ogg Theora/Vorbis offers a royalty-free license for the few known
patents, but we would assume additional risk of submarine patents if
we supported it.
- H.264 offers considerably better quality at the same bitrate than
Theora/Vorbis.
- H.264 is better for video delivery to limited-capability and low-
power devices that support hardware video decoding. You may have
heard that YouTube will be serving their video content as H.264 to
AppleTV and iPhone.

That's our current plan. We may revise it in light of future events,
but it is unlikely that even a MUST-level requirement in the HTML
spec would have much effect on whether we support Ogg or not.


Thanks Maciej for summarising Apple's position so nicely.

I think it's good that you have spelled it out:
Apple is happy to support MPEG-4, which has known patent encumberance
and unknown submarine patents, while Apple is not happy to support Ogg
Theora/Vorbis which has no known patent encumberance. This has to be
very clear to everybody.

I also agree: H.264 procudes undoubtedly better quality video than
Theora at the same bitrate. And I have no problem with Apple
supporting H.264. In particular when I sign up e.g. for movie delivery
through Apple, I'd be more than happy for H.264 delivery. But the open
Internet/Web should be run on open technology.

Also, on a side note, it is as yet unproven whether Ogg Theora or
H.264 are "better" for video delivery to low-powered devices. In
particular when considering the complexity of H.264 and the comparable
simplicity of Theora - it may well be that an efficient HW
implementation of Theora is better suited to low-powered devices than
H.264. This is a matter of ongoing research & development.

BTW: don't expect the discussion to be gone just because the position
of Apple has been made clear. As long as it doesn't make sense in the
greater scheme of things, it will re-emerge. Even if it might not get
resolved to the satisfaction of everybody.

Regards,
Silvia.

Re: [whatwg] The issue of interoperability of the element

[Maciej Stachowiak]

On Jun 23, 2007, at 10:58 AM, Ivo Emanuel Gonçalves wrote:


Dear WHATWG members,

It has come to my attention that Apple developers behind the WebKit
platform, which powers the web browser Safari, apparently intend to
support the video element of the HTML 5 spec, section 3.14.7.  It's
all fine and well, but not a victory for web interoperability, as they
do not intend to follow the "User agents should support Theora video
and Vorbis audio, as well as the Ogg container format" part.  In their
own words: "should support in a spec does not denote a requirement.
We could have a perfectly suitable implementation of audio and video
as seen in this draft spec without having theora/vorbis codecs
available".[1]

What this means, in my opinion, is that they will push for QuickTime
video, in spite of the effort of the Opera developers to push Theora
forward as the de facto standard for web video.  Even if Mozilla and
the KDE team prepare their web browsers to support Theora, by choosing
to alienate it, Apple is allowing Microsoft to put WMV support alone
in their Internet Explorer, for if Apple, one of the big players,
shuns Theora, so will Microsoft.  Considering the statistics, Internet
Explorer being currently the web browser with bigger market share, it
will force pretty much every web designer/programmer to stick to WMV
only.


Our current plan is to primarily support MPEG-4, including H.264/AVC  
video and AAC audio. We may support other codecs as well - it won't  
necessarily be the full set of codecs supported by QuickTime. This  
has been discussed to death already, but here are our basic reasons:


- MPEG-4 is an ISO open standard (although unfortunately patent- 
encumbered).
- Ogg Theora/Vorbis offers a royalty-free license for the few known  
patents, but we would assume additional risk of submarine patents if  
we supported it.
- H.264 offers considerably better quality at the same bitrate than  
Theora/Vorbis.
- H.264 is better for video delivery to limited-capability and low- 
power devices that support hardware video decoding. You may have  
heard that YouTube will be serving their video content as H.264 to  
AppleTV and iPhone.


That's our current plan. We may revise it in light of future events,  
but it is unlikely that even a MUST-level requirement in the HTML  
spec would have much effect on whether we support Ogg or not.


Regards,
Maciej

Re: [whatwg] The issue of interoperability of the element

[Silvia Pfeiffer]

On 6/25/07, Spartanicus <[EMAIL PROTECTED]> wrote:

Personally I detest Java (resource hog, slow as wading through molasses)
and don't have it installed, so forgive my potential ignorance.


Don't we all hate java? ;-)


Why
create an HTML  element with the express purpose of supporting
video natively in clients if video needs to be coded as a Java applet
with Java handling it?


No need to encode as a java applet - all you need to do is put the
java applet on the server together with your Ogg Theora content. And -
by all means - this is not supposed to be an end solution, but just a
fix to bridge the gap until all Browsers support the baseline codec.
The native support would always be preferential to any other fix.


And didn't MS stop including their "Java" in
recent OSs after they lost the court case with Sun?


I don't know enough about this subject, but I believe that you always
had to install a java VM to get java support in browsers (as you do
with flash). Wasn't the problem with MS and Java rather one of lack of
interoperability and standards conformance?

I am well aware that the Java solution is not perfect and native
support is heaps better. Therefore the need for the  element
and for an interoperable version with a common baseline codec.

Regards,
Silvia.

[whatwg] Usefulness of nested /

[Simon Pieters]

The spec suggests that  and  elements can be nested in  
different ways to represent different things.


   
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-kbd

This was discussed on IRC:

   http://krijnhoetmer.nl/irc-logs/whatwg/20070615#l-294


Summary:

 * UAs can't do anything useful with the information.

 * The reader can understand the intent by the context.

 * A single level of either  or  is enough for common styling
   needs. Even if it isn't, a class on the outermost element is more
   helpful due to lack of parent selectors in CSS.

 * It's extremely verbose. Compare:

 File > Exit

   ...with:

 File > Exit

 * Fiddly markup inevitably causes confusion and is easier to get wrong.

 * People can nest the elements if they like (e.g. for more complex
   styling) without this being required. An example might be a page that
   contains both text to be entered and keys to be pressed, with those
   being styled differently.

 *  is already used in the wild to represent keys to be pressed.

--
Simon Pieters

Re: [whatwg] The issue of interoperability of the element

[Spartanicus]

"Silvia Pfeiffer" <[EMAIL PROTECTED]> wrote:

>> Imo for content providers to choose  over Flash, client support
>> needs to be close to Flash. Requiring IE and Safari users to go and
>> download and install third party software to play content would imo be
>> considered too much of a hindrance when Flash "simply works".
>
>Cortado is a java applet that "simply works" (apart from a few bugs :)
>and provides Ogg Theora support to Web Browsers even now. There is no
>need to install third-party-software, apart from Java.
>
>For Flash video to work, you have to have the Flash plugin installed.
>For Cortado to work, you have to have Java installed. The install-base
>of Flash and Cortado is probably comparable. So, "client support needs
>to be close to Flash" can be fulfilled with a bit of effort.

Personally I detest Java (resource hog, slow as wading through molasses)
and don't have it installed, so forgive my potential ignorance. Why
create an HTML  element with the express purpose of supporting
video natively in clients if video needs to be coded as a Java applet
with Java handling it? And didn't MS stop including their "Java" in
recent OSs after they lost the court case with Sun?

-- 
Spartanicus

Re: [whatwg] Internal character encoding declaration, Drop UTF-32, and UTF and BOM terminology

[Peter Karlsson]

Ian Hickson:

>> I don't think forbidding BOCU-1 is a good idea. If there is ever a
>> proper specification written of it, it could be very useful as a
>> compression format for documents.
> BOCU-1 has been used for security attacks. It's on the "no fly" list.

Do you have any references on that, or are you thinking about SCSU (which
suffers from the problem of having several valid compressions for each
string)?

-- 
\\// Peter, software engineer, Opera Software ASA

Re: [whatwg] The issue of interoperability of the element

[Silvia Pfeiffer]

On 6/24/07, Spartanicus <[EMAIL PROTECTED]> wrote:

Imo for content providers to choose  over Flash, client support
needs to be close to Flash. Requiring IE and Safari users to go and
download and install third party software to play content would imo be
considered too much of a hindrance when Flash "simply works".


Cortado is a java applet that "simply works" (apart from a few bugs :)
and provides Ogg Theora support to Web Browsers even now. There is no
need to install third-party-software, apart from Java.

For Flash video to work, you have to have the Flash plugin installed.
For Cortado to work, you have to have Java installed. The install-base
of Flash and Cortado is probably comparable. So, "client support needs
to be close to Flash" can be fulfilled with a bit of effort.

Regards,
Silvia.

Re: [whatwg] The issue of interoperability of the element

[Spartanicus]

"Silvia Pfeiffer" <[EMAIL PROTECTED]> wrote:

>A  element that is natively part of html and has a standard set
>of API functions will enable applications that are impossible today,
>even with embedded elements such as flash.
>
>Imagine e.g. a mash-up of video extracts from several video hosting
>sites where you take an offset from each and put them together in a
>new video without having to manually edit that content. Only if all
>videos are in the same format and all hosting sites provide the same
>API will such a mashup be possible.
>
>I for one see the  and  elements as one of the main
>novelties that make html5 important.

You get no argument from me against the basic value of native browser
support for video and audio, although imo the example you use is an edge
use case and might not work in practice (with my limited knowledge of
modern video encoding techniques I'm inclined to believe that the key
frame nature of video formats will make it very difficult to splice
encoded videos together).

What I question is the practical value of specifying something that
afaics will end up being useless for web deployment (controlled intranet
usage could be possible).

>If we put a requirement into the spec for a common baseline codec and
>the value of that can be demonstrated through several hosting sites -
>e.g. wikipedia, archive.org - and new applications will be
>demonstrated with the new  element - then I think there is a
>reason to go forward.

I'm uncomfortable with having a baseline codec. Even if IE would support
a baseline codec, they are likely to also include a codec with a
considerably better quality vs bitrate. Given their market share I fear
that could result in a considerable number of content providers choosing
to use the proprietary format. This would result in a schism in the
availability of web content.

I feel passionately that all public web content, be it text, images,
audio, video or any other form should exclusively be made available
using open, rights free encoding formats and transport protocols.

This would result in lower quality encoding formats given the absence of
commercial incentives to develop such formats and protocols, but the
benefits far outweigh this drawback imo.

>In any case: plugins can be written for IE and for Safari that make
>them support Ogg Theora and the  tag, even if neither Microsoft
>nor Apple will be distributing them.

Imo for content providers to choose  over Flash, client support
needs to be close to Flash. Requiring IE and Safari users to go and
download and install third party software to play content would imo be
considered too much of a hindrance when Flash "simply works".

>Where there's a will, there's a way. We have to do what is right, not
>what is politically acceptable.

Frustrated as I am with the current state of affairs, I don't see any
point in taking a principal stance if it will result in being ignored.

-- 
Spartanicus

Re: [whatwg] The issue of interoperability of the element

[Ivo Emanuel Gonçalves]

On 6/24/07, Silvia Pfeiffer <[EMAIL PROTECTED]> wrote:

A  element that is natively part of html and has a standard set
of API functions will enable applications that are impossible today,
even with embedded elements such as flash.

Imagine e.g. a mash-up of video extracts from several video hosting
sites where you take an offset from each and put them together in a
new video without having to manually edit that content. Only if all
videos are in the same format and all hosting sites provide the same
API will such a mashup be possible.

I for one see the  and  elements as one of the main
novelties that make html5 important.

If we put a requirement into the spec for a common baseline codec and
the value of that can be demonstrated through several hosting sites -
e.g. wikipedia, archive.org - and new applications will be
demonstrated with the new  element - then I think there is a
reason to go forward.

In any case: plugins can be written for IE and for Safari that make
them support Ogg Theora and the  tag, even if neither Microsoft
nor Apple will be distributing them. And as a work-around at the
beginning, java applets such as cortado enable Ogg Theora support even
without a need for native support.

Where there's a will, there's a way. We have to do what is right, not
what is politically acceptable.


I could not possibly put it in better words than this.  Thank you, Silvia.

The video and audio elements are one of the best things to have come
out of HTML 5.  If veiled interests from Microsoft and Apple may turn
those elements useless, then something is clearly wrong.  Are one or
two corporations the ones who decide what will work and what will not
work on the web?  If so, then, there's no point to joint-ventures from
the public and browser developers to create something like HTML 5,
because it will never work unless Microsoft and Apple say so.  If you
people believe that, you may as well just forget about it.  HTML 5
will never work.

However, if we do try to get HTML 5 working on every browser, either
by demand, or through programming those features ourselves (in the
case of free software browsers) it's a step in the right direction.
The more browsers supporting HTML 5, the more web
designers/programmers will try to implement its new features on their
work.  We have to go against the tide.  The faster we see some support
of the HTML 5 features on browsers, the faster this process will work.
And you have to keep in mind that video and audio are one of the most
desired features for the general public.  The same way they can show
images, they can also show video and audio files?  That's just a
feature too awesome to let it go to waste!  And the only way to make
it work is for as many browsers as possible to choose a de facto
standard for video and audio over the web.

A consensus was reached in this list during the discussion of the
video and audio elements.  The majority ruled in favor of Theora and
Vorbis.  So should you.  One or two corporations, in spite of their
size, are not the ones running the web: we are.  We can have video and
audio working outside of Flash.  We can have anyone host video or
audio on their web site and make it work without the middle man, being
it YouTube or any other video hosting web site.  And you can only get
this in the real world by having as many vendors supporting the Theora
and Vorbis standards.

Best regards,
Ivo Emanuel Gonçalves

Re: [whatwg] The issue of interoperability of the element

[Silvia Pfeiffer]

On 6/24/07, Spartanicus <[EMAIL PROTECTED]> wrote:

Allan Sandfeld Jensen <[EMAIL PROTECTED]> wrote:

>> Thus, I suggest to change the wording to "User agents must support
>> Theora video and Vorbis audio, as well as the Ogg container format".
>>
>Or a clear sign that the video tag was doomed to failure anyway. I really
>can't imagine Microsoft or even Apple to let a multi-billion industry go, for
>the sake of implementing HTML5.

I've been struggling with the question what purpose the  element
serves if interop isn't going to be achieved, which is the current state
of affairs.

Afaics as it stands the following codec support is likely:

IE: Windows Media and possibly MPEG4
Apple: Quicktime and MPEG4
Opera: uncertain, but not likely to support Quicktime or Windows Media
Mozilla: uncertain, but not likely to support Quicktime or Windows Media

Afaics the currently most used way to serve video is through Flash. From
a content provider's point of view Flash has very good client support,
but the quality vs bitrate ratio isn't great. Flash is likely to improve
on that latter point long before browser support for the  element
will reach a level for content providers to consider using it.

I understand the desire amongst browser manufacturers to support video
content natively regardless of the above, but afaics native browser
support will be irrelevant since content providers are unlikely to start
serving content using the  element and continue using Flash.

>Keeping it, or changing to wording will not
>change the behavior of Microsoft and Apple, but will only ensure that HTML5
>will never become fully supported in the major browsers.

Support for the  element without a common codec may well become
fully supported, but pointless. Consequently and with regret I favour
removing  from the spec.



A  element that is natively part of html and has a standard set
of API functions will enable applications that are impossible today,
even with embedded elements such as flash.

Imagine e.g. a mash-up of video extracts from several video hosting
sites where you take an offset from each and put them together in a
new video without having to manually edit that content. Only if all
videos are in the same format and all hosting sites provide the same
API will such a mashup be possible.

I for one see the  and  elements as one of the main
novelties that make html5 important.

If we put a requirement into the spec for a common baseline codec and
the value of that can be demonstrated through several hosting sites -
e.g. wikipedia, archive.org - and new applications will be
demonstrated with the new  element - then I think there is a
reason to go forward.

In any case: plugins can be written for IE and for Safari that make
them support Ogg Theora and the  tag, even if neither Microsoft
nor Apple will be distributing them. And as a work-around at the
beginning, java applets such as cortado enable Ogg Theora support even
without a need for native support.

Where there's a will, there's a way. We have to do what is right, not
what is politically acceptable.

Regards,
Silvia.

Re: [whatwg] The issue of interoperability of the element

[Spartanicus]

Allan Sandfeld Jensen <[EMAIL PROTECTED]> wrote:

>> Thus, I suggest to change the wording to "User agents must support
>> Theora video and Vorbis audio, as well as the Ogg container format".
>>
>Or a clear sign that the video tag was doomed to failure anyway. I really 
>can't imagine Microsoft or even Apple to let a multi-billion industry go, for 
>the sake of implementing HTML5.

I've been struggling with the question what purpose the  element
serves if interop isn't going to be achieved, which is the current state
of affairs. 

Afaics as it stands the following codec support is likely:

IE: Windows Media and possibly MPEG4
Apple: Quicktime and MPEG4
Opera: uncertain, but not likely to support Quicktime or Windows Media
Mozilla: uncertain, but not likely to support Quicktime or Windows Media

Afaics the currently most used way to serve video is through Flash. From
a content provider's point of view Flash has very good client support,
but the quality vs bitrate ratio isn't great. Flash is likely to improve
on that latter point long before browser support for the  element
will reach a level for content providers to consider using it.

I understand the desire amongst browser manufacturers to support video
content natively regardless of the above, but afaics native browser
support will be irrelevant since content providers are unlikely to start
serving content using the  element and continue using Flash.

>Keeping it, or changing to wording will not 
>change the behavior of Microsoft and Apple, but will only ensure that HTML5 
>will never become fully supported in the major browsers.

Support for the  element without a common codec may well become
fully supported, but pointless. Consequently and with regret I favour
removing  from the spec.

-- 
Spartanicus

Re: [whatwg] Entity parsing

[Anne van Kesteren]

On Sat, 23 Jun 2007 20:12:45 +0200, Sam Ruby <[EMAIL PROTECTED]>  
wrote:

Before, "A &mdash B" == "A — B", now "A &mdash B" == "A &mdash B".

Is that what we really want?  Testing with Firefox, the old behavior
is preferable.


Yeah, it makes sense to follow Internet Explorer 7 for this.


--
Anne van Kesteren

Re: [whatwg] The issue of interoperability of the element

[Allan Sandfeld Jensen]

On Sunday 24 June 2007 01:07, Silvia Pfeiffer wrote:
> Such a development is a clear sign to change the spec to require
> theora/vorbis support instead of just recommending it. A baseline
> codec has to be a requirement.
>
> Thus, I suggest to change the wording to "User agents must support
> Theora video and Vorbis audio, as well as the Ogg container format".
>
Or a clear sign that the video tag was doomed to failure anyway. I really 
can't imagine Microsoft or even Apple to let a multi-billion industry go, for 
the sake of implementing HTML5. Keeping it, or changing to wording will not 
change the behavior of Microsoft and Apple, but will only ensure that HTML5 
will never become fully supported in the major browsers.

`Allan