W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: using an attribute to categorize the @alt state [was Baby Steps or Backwards Steps?]

From: Robert Burns <rob@robburns.com>
Date: Fri, 17 Aug 2007 03:55:52 -0500
Message-Id: <EA2BC2EC-539B-4377-893A-3AD66A0B597C@robburns.com>
Cc: public-html@w3.org
To: Smylers <Smylers@stripey.com>

HI Smylers,

On Aug 17, 2007, at 3:30 AM, Smylers wrote:

> Jon Barnett writes:
>> On 8/16/07, Robert Burns <rob@robburns.com> wrote:
>>> I can't think of a good name for this attribute, but consider
>>> something like @embedrel (required) for now (name suggestions
>>> welcome). The value of this attribute would reflect the scenarios
>>> identified in the recent changes to the draft. missing, icon,
>>> decorative, seecontext, seefallback. The value 'missing' would be
>>> the default value, unless '@a't had a string (or perhaps some other
>>> contingencies for content backwards compatibility )  so not setting
>>> either @alt or @embedrel would be considered 'missing'.
>> I am by no means opposed to a new attribute for indicating that an
>> image intentionally has no @alt text, i.e. a new attribute to do what
>> omitting @alt does now.  The suggestion was @noalt, Maciej has
>> mentioned it in a recent message.  If it can be proven that either  
>> (a)
>> enough UAs treat missing @alt the same as alt="" or (b) enough  
>> authors
>> omit alt when they really mean alt="", then I'd be in favor of that
>> attribute.
> We'd also need to define what user-agents should do if:
> * an img has both noalt and alt=""
> * an img has both noalt and a non-empty alt
> By using two separate attributes we introduce the scope for
> self-contradictory documents.  An advantage of using 'not having an  
> alt
> attribute' to mean 'noalt' is that it's impossible to simultaneously
> both omit the alt attribute and include it.

The proposal is not for a noalt boolean attribute. Its for a keyword  
value attribute that deals with many of the issues raised.

I actually did specify how UAs should interpret that in this message:


I think I may have gotten some of that wrong. There I said:

@alt (required in some contexts)
@embedrel (required) with keywords:
     missing (whether @alt is there or not its value has no meaning)
     decorative (whether @alt is there or not its value has no meaning)
     icon (whether @alt is there or not its value has no meaning)
     seecontext (whether @alt is there or not its value has no meaning)
    * seefallback (@alt is required or for other elements the elements
contents must contain non-<source> and non-<parameter> content
providing a textual equivalent for the embedded resource.

But I think I may have gotten the icon scenario wrong there. It  
should probably be

     icon (@alt is optional; if specified it provides the alternate  
text for this resource)

There may be other tweaks that would help.

I understand your concern about these being out of sync. However,  
looking down the list, I think its not that big of a concern. Most of  
that concern is tied up with simply a mis-specified value for  
@embedrel. And that's a concern for any attribute.

I think the other benefit to this approach is that even if @alt is  
specified and the @embedrel keyword is mis-specified, AT and other  
UAsj could provide users with the option to delve deeper to see if  
there's any @alts where there shouldn't be. Much of my motivation  
here is trying to cover the use-case where a user is trying to  
comprehend a page, but something seems to be missing. If an entire  
page appeared to have incorrect @embedrel values a user could even  
turn off UA processing of that attribute for the entire page or the  
entire site. The approach provides a lot of flexibility I think.

Take care,
Received on Friday, 17 August 2007 08:56:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC