The alt text has to be property of the image, which means it has to be either an attribute of <image> or a subelement of <image>.
A better model might have been to also have a separate subelement for the image reference(s) as well, but that’s not how it came from IBM and it’s been that way ever since.
<alt> allows <ph> because there’s no justification for constraining that particular content model at the base level and there’s no way in DITA to constrain an element as it occurs in a specific context using normal grammars (although you could, of course, use a Schematron to do it).
Oxygen’s presentation of the alt text in the editor is an appropriate way to do it for authoring—you have to show it somewhere. It’s not how you would normally show it in presentations (where normally the alt text is either not shown or only shown if the image cannot be shown.
There’s no necessary relationship between <image> and <fig>. (Images do not have to be figures and figures don’t necessarily contain images)
E.
From: <dita@lists.oasis-open.org> on behalf of Jang Graat <jang@jang.nl>
Date: Wednesday, December 20, 2017 at 3:21 PM
To: "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
Cc: <dita-lightweight-dita@lists.oasis-open.org>
Subject: Re: [dita] Rationale for <alt> inside <image>
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.
<attribute name=“height”/>
<attribute name=“width”/>
<attribute name=“scale”/>
<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”/>
<attribute name=“source”/>
<attribute name=“controls”/>
<attribute name=“autoplay”/>
<attribute name=“muted”/>
<attribute name=“track”/>
<attribute name=“poster”/>
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
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