RE: [docbook] updated proposal for multimedia support in DocBook 5.x

["Grosso, Paul" <pgrosso@ptc.com>]

> -----Original Message-----
> From: Jirka Kosek [mailto:jirka@kosek.cz]
> Sent: Monday, 2011 November 21 3:35
> To: Grosso, Paul
> Cc: docbook@lists.oasis-open.org
> Subject: Re: [docbook] updated proposal for multimedia support in
> DocBook 5.x
> 
> On 17.11.2011 19:13, Grosso, Paul wrote:
> 
> > Details
> > -------
> > The classid and autostart attributes are added to audiodata
> > and videodata.  While these attributes could just be specified
> > using the generic multimedia parameter markup discussed below,
> > I've found that these values require special handling to get
> > things to work across the majority of browsers, so it's best
> > to provide a better handle on them.  Then the generics can
> > generally just be passed through without special processing.
> 
> I think that DocBook should catch with HTML5 on multimedia. There
> should
> be ability to reflect sensible attributes from audio/video elements
> http://dev.w3.org/html5/spec/the-iframe-element.html#the-video-element
> in DocBook.

I have not done nearly as much with HTML5 given that browser
support is limited, so I am not opposed to suggestions in
this direction.  I designed my proposal to be a minimal set
of additions.

> 
> Just to be consistent, if we add autostart, we should also add at least
> 
> loop
> muted

We could.  I'm happy to let the TC consider those additions.

The reason I made autostart explicit (instead of just leaving
it as "one of the other params") is that, while its values are
often given as 0, 1, yes, no, true, false, it turns out that
if you want it to work across IE, Firefox, Chrome, and Safari,
you have to use only 0 and true (speaking of inconsistencies,
but that's HTML browsers for you), so I felt it was important
to make it explicit so that it would be easier for any styling 
process to pick up its value and convert the value to one that 
will work.

> 
> Also it might make sense to use autoplay instead of autostart to be
> consistent with HTML here.

We could.  I found autostart was what worked with current browsers.
If we call the attribute autoplay, a transform trying to emit HTML4
would have to emit autostart for autoplay, but since the transform
is already handling auto-whatever specially, that would be trivial.

> 
> We also should make processing expectations more precises in TDG in the
> following two aspects:
> 
> If there both imageobject and videoobject are specified, then
> imageobject is used as a content of poster attribute (or we can devote
> special role on imageobject for this).

I'm not sure we'd want to say that any imageobject is the poster.
I could certainly imagine someone wanting to offer either an image
or a video where the image is not the poster.

So I'd either want to say that an imageobject is only the poster
if it has, say, role="poster" or else add a poster attribute to
videoobject (or else just say that someone can use the generic
multimediaparam with name="poster" which means its value is the
URL to the poster for that viedoobject).

> 
> If there are multiple videoobjects then they will be transformed into
> one video element with several source subelements pointing to video in
> different formats. The same for audio.

I'm not sure I understand this, but I am no video expert.
I defer to the group on this.

> 
> > Finally we allow zero or more multimedia parameter elements as
> > children of audioobject and videoobject.  These are to specify
> > all the many param elements that may be needed as children of
> > the HTML object element in the resulting HTML.
> 
> I think that classid and these parameters are purely presentational
> things and should be handled by stylesheets. We shouldn't add markup
> for them.

First, authors may want some control over certain presentational
things especially in the area of media objects.  After all, we
allow authors to specify height, width, scaling, of graphics.
Not all authors want to leave all design decisions up to the
stylesheet.

As far as things like classid, I suppose a smart stylesheet
could take a look at the value of @format (or maybe the file
name extension of the referenced video object) and figure out
that such a format should be played by, say, QuickTime and
and know that for such to occur the classid needs to be
"clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B", but I felt it
made sense to allow a user to specify such things if they
wanted to do so.

> If some users need ability to propagate things like background
> color of player from document to output they can use processing
> instructions.

While I am not a hater of processing instructions, I don't 
believe it is reasonable in this case to force the use of
them rather than allow markup.  HTML allows the generic
<param> concept, and I don't see why we shouldn't parallel
that in DocBook.  Making people use PIs for things that HTML
does with markup is just going to make people think that
DocBook is less full featured than HTML.

> 
> Also in bigger perspective it might be worth to rething whole
> mediaobject little bit, for example allowing several *data elements
> inside one *object element and moving some attributes up to *object
> element.
> 

My original suggestion included a few minor things like moving
attributes from one element to another, but I was asked to make
another proposal that was backward compatible, so I did not
consider rethinking things to this extent.  But we could 
reconsider this in the group.

paul