Re: BLINK repair mechanisms (calling all CSS gurus!)

aloha, again!

i have since extended my mini test suite of blinking text to 3 files:

1) http://www.hicom.net/~oedipus/temp/blink.html
which uses the straight Netscapism to cause a blinking affect (when i used
Netscape Navigator 4.08 to access the page, the content was continuously
repeated by my screen-reader, which is the stereotypical response of a screen
reader to blinking text)

2) http://www.hicom.net/~oedipus/temp/blink2.html
which uses only the text-decoration style declaration to cause a blinking
effect -- as far as i can tell from aural output alone -- when this page is
rendered by Netscape Navigator 4.08, Opera 3.6, or IE5, only 2 lines of text
are spoken -- i assume that this means that the rendered text is static

3) http://www.hicom.net/~oedipus/temp/blink3.html
which uses the straight Netscapism (BLINK) to attempt to cause a blinking
effect on the first line of text, and a text-decoration style declaration to
attempt to cause a blinking effect on the second line...  as far as i can tell
from aural output alone, only the Netscapism is spoken -- and then continuously
repeated -- when this page is rendered by Netscape Navigator 4.08 -- aural
evidence also suggests that Opera 3.6 and IE5 simply rendered 2 static lines of
text...

of the 3 files, only blink2.html validates as HTML 4.0 Transitional [1] --
unless you count validating to "Netscape HTML" [2] valid!

valid, i suppose, in the strictest sense of the word, but definitely not the
type of validity that is oft-touted as the first step towards accessibility --
the first step towards accessibility, then, i suppose, is validation to a W3C
document type that's been given the once over by PF -- or to a DTD of a markup
language for which accessible authoring practices and accessibility mechanisms
have been defined...

References
[1]
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.hicom.net%2F%7Eoedipus%2F
temp%2Fblink2.html&ss=&outline=&sp=&noatt=
[2]
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.hicom.net%2F%7Eoedipus%2F
temp%2Fblink.html&ss=&outline=&sp=&noatt=

a while ago, i wrote:
>whilst cleaning up the minutes from this morning's telecon, i came across the
>following:
>
>-- begin quote from 19 October telecon minutes
>(note: DD stands for Daniel Dardailler, CR for Chris Ridpath, HB for Harvey
>Bingham, and GJR Gregory Rosmaita)
>
>Topic 4: ERT 7.2.A (BLINK)
>DD: is there only one technique, or are there more?  can make things blink
>using CSS, I think, or by using a script -- need to address; evaluation: look
>for BLINK, is that the only suggested language?  not that they are not
>standard/valid HTML or that they cause problems for adaptive equipment and for
>some PWDs?
>
>CR: trying to get away from bringing everything back to PWDs -- want a general
>usability tool
>
>HB: telecon running overtime
>
>DD: technique: remove BLINK; should we point to CSS if really want BLINK
>mechanism that can be user over-ridden? 
>
>GJR: that could be an "advanced" option -- we should have an intermediary
step:
>if user chooses "No" when asked if wants to remove BLINK, pop up explanation
of
>interoperability, accessibility, and usability problems posed by BLINK, noting
>that it is a bloody stupid thing to use, but if author chooses "use BLINK
>anyway" then prompt user to use CSS to achieve BLINK
>
>DD: replace BLINK with STRONG or EM or use a SPAN should be first step
>
>Resolved: Repair strategy will consist of the following steps:
>1) remove BLINK or replace with STRONG or EM
>2) if author chooses "No" when prompted to replace BLINK, issue a dialog
>containing an explanation of accessibility and usability problems posed by
>BLINK
>3) if author chooses "Use BLINK Anyway", prompt the user (or automatically)
use
>CSS to achieve blinking effect so that end user has control over presentation
>
>-- end quote from 19 October telecon minutes
>
>i scoured the CSS2 spec [1] in an attempt to turn up a reference to which to
>point to illustrate how one could obtain a blinking effect using stylesheets
>but the only thing that i could find that was even remotely close to a "valid"
>stylesheet equivalent for the proprietary element BLINK was the following [2]
>
>begin quote from CSS2 
>16.3 Decoration
>
>16.3.1 Underlining, overlining, striking, and blinking: the 'text-decoration'
>property
>
>'text-decoration' 
>Value:  none | [ underline || overline || line-through || blink ] | inherit 
>Initial:                none 
>Applies to:     all elements 
>Inherited:      no (see prose) 
>Percentages:    N/A 
>Media:  visual 
>
>This property describes decorations that are added to the text of an element.
>If the property is specified for a block-level element, it affects all
>inline-level descendants of the element. If it is specified for (or affects)
an
>inline-level element, it affects all boxes generated by the element. If the
>element has no content or no text content (e.g., the IMG element in HTML),
user
>agents must ignore this property. 
>
>Values have the following meanings:
>none 
>        Produces no text decoration. 
>underline 
>        Each line of text is underlined. 
>overline 
>        Each line of text has a line above it. 
>line-through 
>        Each line of text has a line through the middle 
>blink 
>        Text blinks (alternates between visible and invisible). 
>        Conforming user agents are not required to support 
>        this value. 
>
>The color(s) required for the text decoration should be derived from the
>'color' property value. 
>This property is not inherited, but descendant boxes of a block box should be
>formatted with the same decoration (e.g., they should all be underlined). The
>color of decorations should remain the same even if descendant elements have
>different 'color' values. 
>unquote
>
>the term "conforming user agents" is a hyperlink that points to:
><http://www.w3.org/TR/REC-CSS2/conform.html#conformance>
>which reads:
>
>quote
>3.2 Conformance
>This section defines conformance with the CSS2 specification only. There may
be
>other levels of CSS in the future that may require a user agent to implement a
>different set of features in order to conform. 
>
>In general, the following points must be observed by a user agent claiming
>conformance to this specification:
>
>1. It must support one or more of the CSS2 media types. 
>2. For each source document, it must attempt to retrieve all associated style
>sheets that are appropriate for the supported media types. If it cannot
>retrieve all associated style sheets (for instance, because of network
errors),
>it must display the document using those it can retrieve. 
>3. It must parse the style sheets according to this specification. In
>particular, it must recognize all at-rules, blocks, declarations, and
selectors
>(see the grammar of CSS2). If a user agent encounters a property that applies
>for a supported media type, the user agent must parse the value according to
>the property definition. This means that the user agent must accept all valid
>values and must ignore declarations with invalid values. User agents must
>ignore rules that apply to unsupported media types. 
>4. For each element in a document tree, it must assign a value for every
>applicable property according to the property's definition and the rules of
>cascading and inheritance. 
>5. If the source document comes with alternate style sheets (such as with the
>"alternate" keyword in HTML 4.0 [HTML40]), the UA must allow the user to
select
>one from among these style sheets and apply the selected one. 
>
>Not every user agent must observe every point, however:
>
>* A user agent that inputs style sheets must respect points 1 - 3. 
>* An authoring tool is only required to output valid style sheets 
>* A user agent that renders a document with associated style sheets must
>respect points 1 - 5 and render the document according to the media-specific
>requirements set forth in this specification. Values may be approximated when
>required by the user agent. 
>
>The inability of a user agent to implement part of this specification due to
>the limitations of a particular device (e.g., a user agent cannot render
colors
>on a monochrome monitor or page) does not imply non-conformance. 
>
>This specification recommends that a user agent allow the user to specify user
>style sheets. 
>unquote
>
>so, am i correct in concluding that there is no "approved" CSS equiv for BLINK
>(and if there ain't, that ain't no skin off my back!), or am i overlooking
>something?  was text-decoration : blink added merely to provide a
>backwards-looking user-control mechanism to support (or squelch, depending
upon
>your point of view) the proprietary BLINK?
>
>if "text-decoration : blink;" isn't exactly kosher (and doesn't have a very
>good chance of being implemented), should we be advising authors to employ it?
>
>philosophically and realistically, i'd say we shouldn't, but if
>text-decoration: blink doesn't have a chance of being rendered and the author
>persists in insisting that the text blink, my cynical side says to let him or
>her use a style that won't actually be rendered
>
>by the way, when I ran a test page
>        <http://www.hicom.net/~oedipus/temp/blink.html>
>through Bobby, the suggested solutions were:
>
>-- begin Bobby BLINK error message [3] 
>Some screen readers for the blind are unable to read blinking text. It is
>suggested that blinking text created by the Netscape BLINK tag be replaced by
>one of the following options
>1. Emphasized text, i.e. <EM>this is important</EM> 
>2. An animated GIF image whose ALT text corresponds to the blinking text. 
>3. A Java applet with alternative text that corresponds to the blinking text. 
>-- end Bobby BLINK error message
>
>gregory
>
>References
>[1] http://www.w3.org/TR/REC-CSS2/
>[2] http://www.w3.org/TR/REC-CSS2/text.html#propdef-text-decoration
>[3] http://www.cast.org/bobby/html/gls/g4.html


-------------------------------------------------------------------
ACCOUNTABILITY, n.  The mother of caution.
                        -- Ambrose Bierce, _The Devil's Dictionary_
-------------------------------------------------------------------
Gregory J. Rosmaita      <unagi69@concentric.net>
Camera Obscura           <http://www.hicom.net/~oedipus/index.html>
VICUG NYC                <http://www.hicom.net/~oedipus/vicug/>
Read 'Em & Speak         <http://www.hicom.net/~oedipus/books/>
-------------------------------------------------------------------

Received on Wednesday, 20 October 1999 03:41:15 UTC