Re: smileys vs. ASCII art (editorial FWIW)

Summary:

Just one opinion, but I think that checkpoint 1.6 is OK as in 0316 draft.

There was a remark in the minutes from 0322 to the effect that we need to
clarify to exclude smileys.  I myself don't actually think it is necessary
to spell that out.   My email was responding to the idea in the minutes and
was just a suggestion as to how to clarify this point if it needed to be
clarified.  

I expect most people will not include smileys in what they think this rule
is about, and I hope that in case they apply the rule to smileys they will
ignore the "provide a means to skip over" something as brief as a smiley.

Al

Somewhere in the rationale we could stand to confess that we are not
recommending OBJECT markup here because of the inconsistencies in the
current implementation of OBJECT.

We have claimed we aren't going to discuss implementation browser by
browser, but here what we have done is illogical if one only reads the HTML
spec.  So we might offer a note to the effect that IMG is preferred as an
interim solution until OBJECT is better supported in browsers.

Note to PF: ASCII art can be a test case for "Do we have in XML Fragments a
replacement for OBJECT that works?"

At 09:42 AM 3/23/99 -0500, Ian Jacobs wrote:
>Al Gilman wrote:
>> 
>> >From yesterday's minutes:
>> 
>>       e) ASCII art has to be carefully defined (e.g., to
>>          not include a smiley, which, in certain circles,
>>          is just a accessible as an abbreviation, and in
>>          other circles, just as obscure. This is
>>          arguably different than using characters
>>          to create an image.
>> 
>> Suggestion:
>> 
>> Make the subject of this rule more narrow by qualifying the term "ASCII
>> art."  For example say, "for multiline ASCII art, <what to do>."
>
>Yesterday's minutes [1] talk about breaking the ascii 
>art checkpoint (1.6 in [2]):
>
>    Replace ASCII art with an image or describe the 
>    ASCII art and provide a means (e.g., a link) to skip over it. 
>
>Into three checkpoints, stated briefly as:
>
>a) Use images instead of ascii art.       (Use proper markup)
>b) Provide text equivalents of ascii art. (Equivalent information)
>c) Provide links over ascii art.          (Navigation)
>
>Although breaking down the current checkpoint this way makes
>sense to me, it seems to imply that any time you use ascii art,
>you are not satisfying (a). That's probably why there is
>currently only one checkpoint with an "or" in it. 
>
>Unless someone wants to propose a different formulation
>of checkpoint 1.6, I will leave it as is. 
>
>Al, do you think the existing text of 1.6 should be
>changed/made more precise?
>
> - Ian
>
>[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0486.html
>[2] http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19990316 
>
>
>
>
>
>
> 
>> Smileys and multiline ASCII art share the following characteristics:
>> 
>> a) is constructed on the fly out of the same characters concurrently used
>> to convey natural language which has a sonic equivalent.
>> 
>> b) has no phonetic interpretation.
>> 
>> In other words, it
>> 
>> a) occurs in a context where text-to-speech processing may assume it is
>> articulable as speech, and
>> 
>> b) is not appropriate for text-to-speech transformation by the standard
>> relationships of the enclosing natural language.
>> 
>> If we "define ASCII art" to exclude smileys, I fear we will have numerous
>> readers who fail to retain and apply the local definition.  Since the
>> reader who does not pay close attention to our definitions may still
>> interpret "ASCII art" as applying to smileys, it is the better part of
>> valor to state the guideline in a way which explicitly narrows what we are
>> talking about.
>
>-- 
>Ian Jacobs (jacobs@w3.org) 
>Tel/Fax: (212) 684-1814 
>http://www.w3.org/People/Jacobs
>

Received on Tuesday, 23 March 1999 14:00:54 UTC