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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[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:

> 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:

> > 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.
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.


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