> -----Original Message----- > From: Jirka Kosek [mailto:ji...@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