On Thu, 6 Apr 2023 at 01:47, Bob Stayton <b...@sagehill.net> wrote: > > It seems ok to me. The idea of a mediaobject is to contain markup for one or > more versions of the same content. Presenting more than one of those to the > end user would be redundant and annoying. If you consider the whole > rendering system to be the transformation from DocBook to HTML5 *and* the > browser rendering of that HTML5, then your use case does not seem to violate > the description because the consumer of the content sees only one version, > right?
Relies on an odd (rare?) circumstance, despite being logical. Is there any backwards compatibility reason not to adopt Norms logic? regards > > Bob > > On 4/5/2023 9:27 AM, Norm Tovey-Walsh wrote: > > Hello world, > > The description of mediaobject states: > > This element contains a set of alternative “media objects.” Exactly > one object will be selected and rendered. … Under no circumstances > should more than one object in a mediaobject be used or presented at > the same time. > > Bearing in mind that this markup was invented 15 or 20 years ago, long > before any (widely used) web browser offered anything sophisticated in > the way of fallback, we anticipated that markup like this: > > <mediaobject> > <videoobject>…</videoobject> > <imageobject>…</imageobject> > <textobject>…</textobject> > </mediaobject> > > would be intepreted along the following lines: “… a mediaobject might > contain a video, a high-resolution image, a low-resolution image, a long > text description, and a short text description. In a ‘high-end’ online > system, the video is used. For print publishing, the high-resolution > image is used. For other online systems, either the high- or the > low-resolution image is used, possibly including the short text > description as the online alternative. In a text-only environment, > either the long or the short text description is used.” > > <aside>I observe that “possibly including the short text” is, by a very > narrow reading, a violation of the semantics we’ve already > asserted.</aside> > > Starting in V5.1 we allow more than one *data element in a *object > element[1] with the semantics that the downstream processor will pick > one. So now you can do: > > <mediaobject> > <videoobject> > <videodata type="video/mp4" …/> > <videodata type="video/webm" …/> > </videoobject> > <imageobject>…</imageobject> > <textobject>…</textobject> > </mediaobject> > > And let the browser decide whether it wants to render MP4 or WebM. > > Trouble is, you can’t put imagedata in the videoobject wrapper, so > there’s no way to fallback to a still image. We could fix this by > changing videoobject (and audioobject) to allow imageobject, but at that > point, we might as well do away with the various flavors and just have > one wrapper. (That’s probably what we’d do today, if we were starting > over.) > > Rather than make the markup even more complicated, I’m tempted to squint > really hard at the semantics and try to persuade you that selecting > multiple objects from the same mediaobject is not a violation of the > semantics if the rendering system will only render one of them. > > In other words, I want a license to cheat and say that I can render that > example above in HTML5 as a video element containing three sources, two > videos and an image. What say you? > > Be seeing you, > norm > > [1] But the content model of imageobject weirdly forbids you from mixing > SVG and MathML and other formats. What is that about? > > -- > Norm Tovey-Walsh <n...@nwalsh.com> > https://norm.tovey-walsh.com/ > > Advancement is powered by the dynamic interaction of theory and > practice. -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. --------------------------------------------------------------------- To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
