- From: Al Gilman <asgilman@iamdigex.net>
- Date: Fri, 25 Jun 1999 10:18:36 -0400
- To: w3c-wai-er-ig@w3.org
At 05:26 PM 6/24/99 -0400, Leonard R. Kasday wrote: >At 04:22 PM 6/24/99 -0400, Nir Dagan wrote: ND:: >>Generally null is not white space but the specs say that leading and >>trailing white space in CDATA attribute values can be egnored by user >>agents. E.g., "myval" may be treated as " myval " AG:: I believe that the word used is "may," not "can." I believe that what the editors of the HTML specification were trying to get across was how to work around a fact of current implementation. Something like: "Although a strict SGML interpretation of the CDATA type would indicate that ' myval ' and 'myval' are distinguished values, users of HTML should be aware that implementations may treat ' myval ' as if it were 'myval'. Note that this situation is not symmetrical. Implementations will likely strip, but not likely add, leading or trailing whitespace in extracting attribute values. LK:: > >In addition, http://www.w3.org/TR/REC-html40/types.html#h-6.2 states that > >"Authors should not declare attribute values with leading or trailing white >space. " > >Seems to me that rules out " " or am I reading this wrong? It looks like " >" has both leading and trailing white space in fact. AG:: I think you have to distinguish "leading whitespace" from "initial whitespace" to parse this situation correctly. In other words, leading whitespace is whitespace preceding the first non-whitespace character, and trailing whitespace is whitespace occurring after that last non-whitespace character. Neither are present in " ", although it meets the criteria both for initial and final whitespace. > >Len Al > >At 04:22 PM 6/24/99 -0400, Nir Dagan wrote: >>Generally null is not white space but the specs say that leading and >>trailing white space in CDATA attribute values can be egnored by user >>agents. E.g., "myval" may be treated as " myval " >>Regards, >> >>Nir Dagan >> >>http://www.nirdagan.com >>mailto:nir@nirdagan.com >> >>"There is nothing quite so practical as a good theory." >>-- A. Einstein >> >>On Thu, 24 Jun 1999, Al Gilman wrote: >> >>> At 11:56 AM 6/24/99 +0300, Nir Dagan wrote: >>> >I realy do not understand the idea behind: >>> > >>> >Not allowed - NULL ALT value (ALT="") >>> >Allowed - ALT value of 1 or more spaces (ALT=" ") >>> > >>> >Both from a semantic/logical point of view and HTML specification >>> >these are quite the same thing. >>> >>> Not quite. You are ignoring the way logic depends on lexical analysis or >>> the recognition of word boundaries. "Lay out" is a verb while "layout" is >>> a noun. The logic depends on the lexing. Whitespace is not guaranteed to >>> be logically without effect. Null is not whitespace, space is. There are >>> enough situations where this introduces a semantic difference. >>> >>> In the HTML specification it merely warns that some user agents may ignore >>> whitespace in certain circumstances. I do not believe that you will find >>> this carried forward in either the work on XML normalisation nor in the >>> Internet-Draft from DRUMS updating RFC 822. What I am saying is that the >>> best thinking on this issue is that a null string and linear whitespace are >>> logically different, a distinction that must be preserved. >>> >>> Al >>> >>> > >>> >My major reservation with this guideline is that there may be out there >>> >many people who took the effort to write accessible pages with alt="" >>> >where appropriate, and now we tell them to revise their pages, without >>> >any reason whatsoever. >>> > >>> >Regards, >>> >Nir Dagan >>> > >>> >http://www.nirdagan.com >>> >mailto:nir@nirdagan.com >>> >tel:+972-2-588-3143 >>> > >>> >"There is nothing quite so practical as a good theory." >>> >-- A. Einstein >>> > >>> >> >> >> >------- >Leonard R. Kasday, Ph.D. >Universal Design Engineer, Institute on Disabilities/UAP, and >Adjunct Professor, Electrical Engineering >Temple University > >Ritter Hall Annex, Room 423, Philadelphia, PA 19122 >kasday@acm.org >(215} 204-2247 (voice) >(800) 750-7428 (TTY) >
Received on Friday, 25 June 1999 10:12:54 UTC