OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: HTML5 Audio + Video multiple sources

Peter Fleck <peterfleck@gmail.com> writes:
> <video>
>   <source src="video.ogg" type="video/ogg" /> 
>   <source src="video.mp4" type="video/mp4" />
>   <source src="video.webm" type=" video/webm">
> </video>
> If tried different ways but haven't been able to do it yet, is it possible?

Not really. HTML5 brings significant new functionality to the realm of
audio and video. It's probably time to revisit the markup that DocBook

Historically, neither browsers nor other rendering tools provided any
facility for mutiple representations or fallback. Among the design
goals for the existing mediaobject markup was the ability to provide
for multiple alternatives in the DocBook source with the understanding
that the transformation from DocBook to the output format would pick
the right one.

It was never an elegant design in part because the transformation
tools rarely had any clue what the actual capabilities of the ultimate
viewing tool would be.

It also produced markup that's several layers deep. Those layers are
needed in the case where multiple alternatives must be selected by the
transformation tool, but in the (very common case) that no
alternatives are provided, they're just extra tags.

The situation is muddied further by the fact that, as alternatives,
the videodata element has attributes that appear to be badly factored.

For example, it seems likely that no matter which of two or three
video alternatives you have, you want the content width, content
depth, scaling, alignment and such to be the same.

In defense of the odd factoring, bear in mind that for raster images,
the choices are less clear. If a medium-resolution black and white
image is an alternative for a high-res four color image, then perhaps
you do want the size, scale, and alignment to differ between the two

I'm not sure what the right answer is. If HTML5 is going to represent
the state of the art for the forseable future, an argument can be made
that we should simply copy its model. But we'd lose functionality if
we did that (functionality that in the HTML5 world is pushed off to
random nesting divs with class attributes).

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com>      | Labor, n. One of the processes by
http://www.oasis-open.org/docbook/ | which A acquires property for
Chair, DocBook Technical Committee | B.--Ambrose Bierce

Attachment: signature.asc
Description: PGP signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]