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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: Re: [dita] Rationale for <alt> inside <image>


(copying this to data-lightweight as it also affects that standard)

That may explain why there is an <alt> instead of @alt, not why <alt> is inside <image> and can itself contain a <ph> which can contain an <image> etc. If <alt> would be part of <fig>, there would not have been any problem with any rendering system, just like there is no problem with <title> at the top of the <fig>, where lots of PDF renderings move the <title> to a caption below the image.

To add to the problem, LwDITA is copying the same situation, with <alt> inside <image>. With <image> essentially being an inline element and <alt> a block element, this implies that mixed content makes its way into a standard that tries to do away with it altogether. Also, there is an irrational mismatch between the semantic markup of <image> and its modern multi-media counterparts <video> and <audio>: those elements have separate child elements for setting various parameters (track, controls, source, loop, etc - none of which have translatable content), where <image> has attributes for all such configuration data plus <alt> as a child element.

A consistent semantic markup for multi-media items would use similar items for similar meanings. If <video>, <audio> and <image> are all seen as part of <fig>, they should all have a similar internal structure and markup.

My suggestion would be:

<element name=“fig”>
<optional>
<element name=“title”/>
</optional>
<optional>
<element name=“alt”/>
</optional>
<choice>
<element name=“image”>
<attribute name=“href”/>
<attribute name=“height”/>
<attribute name=“width”/>
<attribute name=“scale”/>
</element>
<element name=“video”>
<attribute name=“source”/>
<attribute name=“height”/>
<attribute name=“width”/>
<attribute name=“scale”/>
<attribute name=“controls”/>
<attribute name=“autoplay”/>
<attribute name=“muted”/>
<attribute name=“track”/>
<attribute name=“poster”/>
</element>
<element name=“audio”>
<attribute name=“source”/>
<attribute name=“controls”/>
<attribute name=“autoplay”/>
<attribute name=“muted”/>
<attribute name=“track”/>
<attribute name=“poster”/>
</element>
</choice>
</element>

To comply with various accessibility standards, the <alt> would be made mandatory and would, obviously be required for video and audio as well.

Jang F.M. Graat
Smart Information Design
Amsterdam, Netherlands

On 20 Dec 2017, at 17:09, Chris Nitchie <chris.nitchie@oberontech.com> wrote:

In addition, there are some HTML5-based UI frameworks that provide rich-text tooltip widgets via _javascript_ that could be fed by this element.

Chris

On 12/20/17, 10:55 AM, "dita@lists.oasis-open.org on behalf of Eliot Kimber" <dita@lists.oasis-open.org on behalf of ekimber@contrext.com> wrote:

   That design comes from the original IBM design, as far as I know.

   As a general principle, any content that is likely to be translated should be in element content, not attributes, which is sufficient to require <alt> rather than @alt.

   Cheers,

   E.
   --
   Eliot Kimber
   http://contrext.com



   On 12/20/17, 3:02 AM, "Mr. Jang Graat" <dita@lists.oasis-open.org on behalf of jang@jang.nl> wrote:

       I am working on a new DITA implementation for FrameMaker and stumble across a number of design issues, which make me wonder about the use cases that prompted the committee to choose this particular design.

       I have not yet found a use case that would warrant the rich semantics on an alternate text for an image that is presented by <alt>. I have yet to come across an editing and rendering system that would do something useful with such rich semantics inside <alt>. AFAIK, HTML merely offers an @alt on an <img>. Would it not have been wiser to have an @alt on <image> and push the richer semantics to a sibling of <image>, as part of a <fig> ?

       I really want to understand the design rationale for this and hear some convincing use cases. If such rationale and use cases are any less than convincing, I would want to propose a redesign for DITA 2.0.

       Jang



   ---------------------------------------------------------------------
   To unsubscribe from this mail list, you must leave the OASIS TC that
   generates this mail.  Follow this link to all your TCs in OASIS at:
   https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php






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