RE: Invisible Skip navigation link

(you mean as three example fragments, not as one single fragment, I assume)

No, I can't see any problem with this technique.

Cheers

Chaals

On Thu, 25 Jul 2002, John Foliot - bytown internet wrote:

>
>What about:
>	<a href="#content" title="Skip Navigation. Access key = 2.&nbsp;">
>	<img src="hello.gif" alt="Hello world.&nbsp;">
>	<frame src="banner.html" title="Frame banner.&nbsp;">
>
>I know this validates, but does it create any problems? (I can't think of
>any, but...)
>
>JF
>
>
>> -----Original Message-----
>> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
>> Behalf Of poehlman1@comcast.net
>> Sent: July 25, 2002 1:40 PM
>> To: jukka.korpela@tieke.fi; w3c-wai-ig@w3.org
>> Subject: RE: Invisible Skip navigation link
>>
>>
>>
>> It might be possible then to delimit the words in some other way such as
>> vertical bar or - or slash but vertical bar might be the best choice.
>>
>>
>> Original Message:
>> -----------------
>> From: Jukka Korpela jukka.korpela@tieke.fi
>> Date: Wed, 24 Jul 2002 10:19:27 +0300
>> To: w3c-wai-ig@w3.org
>> Subject: RE: Invisible "Skip navigation" link
>>
>>
>>
>> Steve Vosloo wrote:
>>
>> > To cover all bases it seems a good idea to always put a space after a
>> > text description, and usually after some sort of punctuation:
>> >
>> > <a href="#content" title="Skip Navigation. Access key = 2. ">
>> > <img src="hello.gif" alt="Hello world. ">
>> > <frame src="banner.html" title="Frame banner. ">
>>
>> In practice, I tend to agree, at least in situations where alt texts would
>> otherwise "run together".
>>
>> But we have a problem here. The HTML 4 specification says that user agents
>> may ignore leading and trailing spaces in attributes (e.g., treat
>> alt="foo "
>> as equivalent to alt="foo") for "CDATA attributes" (such as
>> title, alt, and
>> many others). This is specified in section 6.2 "SGML basic types" (so you
>> may easily miss it when using the specification as a reference):
>> http://www.w3.org/TR/html4/types.html#h-6.2
>> And it even says in this context: "Authors should not declare attribute
>> values with leading or trailing white space." (Someone might
>> interpret this
>> "only" as a strong way of saying that authors should not _rely_ on such
>> space being preserved.)
>>
>> XHTML is a different beast:
>> "Whitespace in attribute values is processed according to [XML]."
>>   http://www.w3.org/TR/html/#uaconf
>> And this means strict (and fairly complicated) normalization rules:
>>   http://www.w3.org/TR/REC-xml#AVNormalize
>> But those rules do not make stripping leading and trailing spaces
>> mandatory
>> for CDATA attributes - though they _do_ require such stripping for other
>> attributes! (And they require compression of multiple spaces, so that
>> alt="foo  " is normalized to alt="foo ".)
>>
>> It's difficult to say whether XHTML is intended to _allow_ stripping of
>> leading and trailing spaces in CDATA attributes (as HTML 4 does).
>>
>> Note that if such stripping is allowed, alt=" " can be treated as
>> identical
>> to alt="", which would not be nice at all if e.g. the image is a separator
>> between adjacent words.
>>
>> --
>> Jukka Korpela, senior adviser
>> TIEKE Finnish Information Society Development Centre
>> http://www.tieke.fi
>> Phone: +358 9 4763 0397 Fax: +358 9 4763 0399
>>
>>
>> --------------------------------------------------------------------
>> mail2web - Check your email from the web at
>> http://mail2web.com/ .
>>
>>
>

-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI  fax: +33 4 92 38 78 22
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Friday, 26 July 2002 08:02:44 UTC