Re: markup for mediaobject parameters

[Norman Walsh <ndw@nwalsh.com>]

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

> <notes>
[...]
> </notes>
[...]
> So, what a friendly editor like Arbortext has to do is collect
> the info from the markup and then generate HTML that will work
> on as many browsers as possible.  The necessary HTML consists 
> of multiple nested object elements, nested in just the right order,
> with different ones of those object elements having different 
> attributes set and different children param elements.  For example,
> Firefox needs @data set to the referenced URL on object, but IE 
> needs a child param element whose name is "src" and whose value 
> is the URL.

Aha<sup>2</sup>!

> So just allowing html:object would in theory allow a user to
> insert the necessary code, but it would be close to 0 probability
> they would get code in there that would work with all browsers.

Fair enough!

> Using PIs to insert params could in theory be handled in much
> the same way as the keywordset idea in that the styling code
> could pick up the values and then use them to emit the necessary
> HTML code.  But parsing PIs the get the same info one can get
> more easily when it's marked up in keywords does not seem like
> a good tradeoff to me.  Using something like keywordset, one
> could even write some validation code (in Schematron or your
> own favorite command language) to do some validation, whereas 
> that couldn't be done nearly as easily with PIs. 

Yes.

> I've got customers that want to mark up in DocBook and want
> Arbortext's HTML publishing capabilities to have multimedia support.
> If I go and tell them to insert PIs, they are going to come back
> and say that doesn't sound like non-proprietary support.

Height and width we've already got covered.

Are @data and the 'src' param just copies of the fileref?

What's classid?

What's the "type" that Firefox can't have set sometimes and
can it have it set sometimes?

> 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 suppose we could allow html:param inside audiodata and
videodata...)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | There are infinite possibilities
http://www.oasis-open.org/docbook/ | of error, and more cranks take up
Chair, DocBook Technical Committee | unfashionable untruths than
                                   | unfashionable truths.--Bertrand
                                   | Russell

PGP signature