[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Review of "Add a multimedia domain #27"
Keith, Apologies for the long delay on this. Things were a bit crazy before I went on vacation last week and this fell through the cracks. Re: the decision to add nested elements with true/false values. In DITA 1.3 and lightweight DITA, we’re not allowed to add arbitrary attributes to specific elements; specializations of @base are global and can’t be targeted without extensive
constraints. Since one of the drivers for this domain is consistency between DITA 1.3, DITA 2.0, and LwDITA, we have to use the ‘least common denominator’ approach here, which means using nested <data> specializations. Also, of course, it’s impossible to have
an attribute without a value in XML. That’s the main reasoning behind this design. Note that the @value attributes on the nested elements are all #IMPLIED. My thinking here – though I now realize I never made it explicit in the proposal – was that if the @value attribute is missing, “true” should be assumed. Thus, the
mere presence of one of these elements will be sufficient to turn that option “on”. For example: <video data=""> <media-controls/> </video> The notes about the examples are well taken and I’ll address those in the Stage 3 proposal. Chris From: <dita@lists.oasis-open.org> on behalf of Keith Schengili-Roberts <keith.roberts@ixiasoft.com> The following was originally meant as a stage 2 critique, but I understand from Chris that the following should prove useful
for his work on stage 3. --Original message -- The proposal looks great, and I checked everything against the latest spec for HTML5 and everything stands up, ditto the arguments
for the attributes that are deliberately being excluded. A question regarding the associated elements: your
DTD and example code suggests that media-controls, media-autoplay and media-loop (for example) should be value="true|false", but I note that the equivalent in HTML5 is more like <audio controls="controls"> or <audio loop="loop"> or <audio controls loop> (all
equivalents for "true"). While I'm not advocating the W3C's "loopy" approach to this, am wondering if it might be worthwhile to be more explicit as to why we are taking this approach. My only other quibbles are with the examples. In the first instance, you reference an audio file ("An audio element with a
single source") but the example uses the video element rather than audio. From a technical perspective I think this is possible, but I think the
intention was to show an example using the audio element. Also, from a best practices perspective, isn't it always a good idea to throw in fallback? That would make a revised audio example look like this: <!-- An audio element with a single source --> <audio data="">
<fallback="Audio playback is unavailable" /> The other examples are fine, I would just like to see more of them. Suggested code for audio with multiple sources/audio types: <!-- An audio element with the same audio content in three different formats --> Suggested code for audio with audio controls explicitly turned on, and automatic looping disabled: <!-- An audio element with controls turned on, and looping turned off --> <audio data="">
<fallback="Audio playback is unavailable" /> Cheers! - Keith Schengili-Roberts Market Researcher and DITA Evangelist IXIASOFT 825 Querbes,
Suite 200, Montréal, Québec, Canada, H2V 3X1 tel +
1 514 279-4942 / toll free +
1 877 279-4942 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]