W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2002

RE: Invisible "Skip navigation" link

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 24 Jul 2002 09:10:55 -0400 (EDT)
To: Steve Vosloo <stevenvosloo@yahoo.com>
cc: "'WAI IG'" <w3c-wai-ig@w3.org>
Message-ID: <Pine.LNX.4.30.0207240904010.1808-100000@tux.w3.org>

I think I was uncleaer. What I am saying is that in this case, for this
purpose, it seems safe to include leading and trailing spaces in either HTML
4 or XHTML. As you say, nothing seems likely to break.

This is not true, for example, where you have a class attribute and the value
includes leading space. Tools are permitted by the specification to ignore or
preserve the white space, leading to two or more different strings. A code
example:

  <a href="foo" class="  navi ">sdf</a>

might be interpreted as having class "navi" or "  navi " or "navi ", so may
not match properly in all browsers that implement the specification
correctly.


(You can run all 28000 pages through a program like tidy - if they are
reasonably unambiguous almost-HTML it can convert them all to XHTML
automatically - then you just need to edit them as XHTML not HTML).

Cheers

Charles

On Wed, 24 Jul 2002, Steve Vosloo wrote:

>
>That's a good option, but not necessarily one the owner of the site I'm
>auditing will like. (It has 28000 pages.)
>
>The HTML spec says:
>
>User agents may ignore leading and trailing white space in CDATA
>attribute values (e.g., "   myval   " may be interpreted as "myval").
>Authors should not declare attribute values with leading or trailing
>white space.
>
>By including leading and trailing spaces I don't see how anything will
>break, except that if spaces are chopped off the accessibility effect is
>lost. Even if well punctuated a screen reader may say this about 2
>images:
>
>"Link to home page.About Us."
>
>The dodgy word may sound like "page DOT About".
>
>I'm afraid I'm still not sure what the safest solution is. Enclose all
>CDATA in "[]"?
>
>
>
>
>-----Original Message-----
>From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
>Behalf Of Charles McCathieNevile
>Sent: 24 July 2002 02:14 PM
>To: Steve Vosloo
>Cc: 'WAI IG'
>Subject: RE: Invisible "Skip navigation" link
>
>
>
>Well, one approach is to use XHTML, where it is OK to have
>leading/trailing whitespace that is expected to be significant.
>
>Going against things specified as "should" should not  be done lightly.
>You should ensure that if you do so, you are not breaking anything. That
>seems to be the case here...
>
>Cheers
>
>Chaals
>
>On Wed, 24 Jul 2002, Steve Vosloo wrote:
>
>>
>>It seems there are instances where guidelines clash with best
>>practices/workarounds, like the example here. You're damned if you do
>>and damned if you don't! This whole field is still working itself out
>>and there are bound to be these situations.
>>
>>I reckon you simply have to choose a solution and make it consistent
>>across your site. Given the facts I have so far, I'm happy to put
>>trailing spaces on everything.
>>
>>Steve
>>
>>
>>
>>
>>-----Original Message-----
>>From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
>>Behalf Of Jukka Korpela
>>Sent: 24 July 2002 09:19 AM
>>To: 'WAI IG'
>>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.
>>
>>
>
>

-- 
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 Wednesday, 24 July 2002 09:10:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:05 GMT