Feature Proposal: Add an alt parameter to ICON

Motivation

You can use %ICON to display an icon for a filename e.g. %ICON{"flurble.jpg"}% displays as flurble.jpg

By default if the filename doesn't reduce to a known icon you get the full filename thrown back at you e.g. %ICON{"flurble.nuts"}% displays as flurble.nuts

This is a bad. You should be able to specify an alternate image.

Description and Documentation

%ICON{ "filename or icon name" [ default="filename or icon name" ] [ alt="alt text to be added to the HTML img tag" ] }%

If the main parameter refers to a non-existent icon, and default is not given, or also refers to a non-existent icon, then the else icon (else) will be used. The HTML alt attribute for the image will be taken from the alt parameter. If alt is not given, the main parameter will be used.

A knock-on change is that this would allow us to eliminate some poorly documented code that basically does this internally for the attachments table (where the icons are generated by the equivalent of %ICON{"$filename" default="else"}%)

Implementation

Uinintentionally checked in to trunk last night, under Tasks.Item2511

-- Contributors: CrawfordCurrie - 18 Dec 2009

Discussion

Good feature. No compatibility issues related to it. It has my support.

-- KennethLavrsen - 19 Dec 2009

the 14 day acceptance period is over.

-- WillNorris - 02 Jan 2010

Just noticed this - I guess it's too late, but in HTML alt= is used to provide text when an image cannot be displayed. It this alt= pointing to an alternate image going to be in conflict with the alt= html "Alternate Text" parameter? Providing alternate text is important for accessibility for the visually disabled.

-- GeorgeClark - 03 Jan 2010

Actually that's a very good point. I've wanted to provide alt text with %ICON{}% in the past. The parameter should be renamed alternate or missing. Other ideas I dismissed included other, fallback, else, and default.

I understand that the process means this has been accepted, but I set this back to UnderInvestigation to help it get noticed by CrawfordCurrie; hopefully it's not too late to change the parameter name (we haven't released with this yet).

-- PaulHarvey - 03 Jan 2010

I deliberately used "alt" because of the relationship to the HTML alt parameter, which provides an alternate if the image can't be found. In %ICON, that alternate can either be interpreted as an image, or as text if no such image exists. The 'alt' parameter in the HTML IMG tag is generated using the text from either the _DEFAULT param to the %ICON macro, or the alt, depending on which was finally used, and as such does not conflict.

Set back to "merged", as I can't see any real problem here.

-- CrawfordCurrie - 06 Jan 2010

I assume then that any issues with accessibility would be with usage of the alt= parameter and not implementation? If alt= is used to provide an alternate image, how does a user get the text version of the image. In order to pass Section 508 validation, the text form of alt= would be required, and not an alternate image. Is this recursive, so that Foswiki would pick up alt text somehow from the alternate image? Foswiki.org and Foswiki in general does not pass validation for the visually impaired: A. 508 Standards, Section 1194.22, (a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). At least in the US this can be an issue for organizations that are required to comply with these standards.

-- GeorgeClark - 06 Jan 2010

I have to agree with GeorgeClark. We need a way to provide a text alt. Maybe %ICON{"mansion" alt="house" title="Go home"}%?

-- PaulHarvey - 07 Jan 2010

http://www.htmlhelp.com/reference/html40/special/img.html states:
The required ALT attribute provides alternate text for those not loading images. Effective ALT text should generally give the function of the image rather than a description of the image. For example, ALT="Welcome to XYZ Corp." would be more appropriate than ALT="XYZ Corp. Logo" for a company's logo on its welcome page. Good ALT text is crucial to the document's accessibility for users who do not load images; see Use of ALT texts in IMGs for a thorough discussion.
Some pseudo-code of the current implementation, to scare you:
If =alt= is defined, then
   Let alt = =alt=
else
   Let alt = =_DEFAULT=

If =_DEFAULT= is a file name, then
   Let icon = the extension in =_DEFAULT= e.g. 'gif'
else if =_DEFAULT= is defined and is not empty
   Let icon = =_DEFAULT_=
else
   Let icon = "else"

If the icon map contains icon, then
   Generate <img src="icon url" with alt=" =_DEFAULT= "
else if alt is defined and is not the empty string, then
   Generate <img src="alt url" with alt=" =alt= "

I did it this way to maintain compatibility with the existing code, which has always implicitly defined alt="else". However I find this rather counter-intuitive, especially given the remarks above. I think the following would be clearer:
%ICON{ "filename or icon name" [ default="filename or icon name" ] [ alt="alt text to be added to the HTML img tag" ] }%

If the main parameter refers to a non-existent icon, and default is not given, or also refers to a non-existent icon, then the else icon (else) will be used.

Given the change in the proposal, I changed status to "Under Investigation"

-- CrawfordCurrie - 07 Jan 2010

Thanks Crawford! I think the %ICON{"icon" default="alticon" alt="Useful icon text"}% syntax is good.

-- PaulHarvey - 07 Jan 2010

I put my name in concern.

And only concern is that the spec is changed from original proposal.

Crawford can you put the updated spec at the top?

From the reactions it seems the altered spec will result in concensus. If we get the final spec clear and no protests within a few days I will declare it accepted by consensus.

-- KennethLavrsen - 21 Jan 2010

The spec was updated shortly after Kenneth asked; so I'm going to assume his concern is removed and go ahead with this under the 14 day rule.

-- CrawfordCurrie - 17 Feb 2010
Topic revision: r15 - 06 Dec 2010, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy