[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook] Re: markup for mediaobject parameters
> -----Original Message----- > From: Norman Walsh [mailto:ndw@nwalsh.com] > Sent: Friday, 2011 August 26 16:00 > To: docbook@lists.oasis-open.org > Subject: [docbook] Re: markup for mediaobject parameters > > "Grosso, Paul" <pgrosso@ptc.com> writes: > > The problem with just embedding html:object is that you have > > to structure your <object> code differently for every browser. > > I've been experimenting with IE7, Firefox 4, and Chrome 10. > > Just for example, here's some notes I have: > > Aha! You've worked out what actually has to be generated in each case. > You were clearly better motivated than I :-) I'm only at the beginning of the research. And as browser versions continue to be deployed, the solution is probably a continually moving target. > [...] > > Height and width we've already got covered. > > Are @data and the 'src' param just copies of the fileref? Pretty much. > > What's classid? I cryptic string identifying a particular piece of software, e.g., "clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95" for (at least some versions of) Windows Media Player. It is an HTML attribute on object: http://www.w3.org/TR/html401/struct/objects.html#adef-classid > > What's the "type" that Firefox can't have set sometimes and > can it have it set sometimes? The media type, such as audio/mpeg or video/x-ms-wmv. It is also an HTML attribute on object: http://www.w3.org/TR/html401/struct/objects.html#adef-type-OBJECT > > > So the only choices I see are to tell them that there is no > > support for doing this in DocBook or to suggest they use > > something like the keywordset solution. > > I suggest a third option: that we extend the markup in DocBook to > support this case better. I've wanted to more than once but never been > motivated to work out the details as you have. > > What I can't tell is if the best way to do that would be to add new > attributes: @type, @autostart, @classid or to add a more general > <param name="key" value="value"/> mechanism. I suggest the more general (though I might suggest using elements instead of attributes, as that is more flexible). Not only does that build somewhat on the HTML knowledge base, but there are LOTS of parameters--many of them proprietary--and probably more every day. See http://www.w3schools.com/media/media_playerref.asp for just some examples on Windows Media Player. Also see http://www.w3.org/TR/html401/struct/objects.html#h-13.3 for the various attributes on the HTML object tag. If we have a general mechanism, we can use that to handle things like @codetype without having to add that attribute to videoobject, etc. > > (I suppose we could allow html:param inside audiodata and > videodata...) Aside from the fact that I'd just as soon avoid mixing namespaces unnecessarily, semantically, it might not be quite right in all cases. Consider codetype which in HTML is an attribute on object, but which we could indicate using a general "param" type mechanism. It wouldn't really be expected in an html:param, but there is no reason we couldn't say in DocBook you indicate the codetype via DocBook's param, and DocBook-to-HTML transformations are expected to do the right thing with it. By using html:param, I would think the expectation is that a transformation can just pass it through to the HTML, and that is not always going to be the right thing to do. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]