BLINK repair mechanisms (calling all CSS gurus!)

aloha, all!

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
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Wednesday, 20 October 1999 01:22:31 UTC