> > Nice idea, and good in a theoretical sense, but in reality screen
> > readers do say "link", so there is no real need for that.
> </snip>
>
> ...which they could do with an internal stylesheet, allowing the author
> to change it this to something else, should they desire, and the user to
> be able to decide which they prefer. It could also be used to add
> additional information to elements for which the assistive technologies
> do not have as good support for example:
>
> q:before,
> blockquote:before { content: "quote " }
> q:after,
> blockquote:after { content " end-quote" }
Of course, but why should you be responsible for that? And even more
questionable, why should you as the designer define what the aural
browser says when the user can have a preference setting that allows
her to navigate perfectly through the page?
I _can_ make links look like normal text with CSS, but it is not a
clever idea, as users expect them to look different. The same applies
here.
Regardless of technology, the question is does the user benefit or do
we assume he does by applying our likes and standards?
> >>2) Graphical replacement of text.
> >
> >
> > Is a "nice to have", but NEVER a "need to have".
>
> ...is the growing trend in the medium. Flash is nice to have, as are
> drop-down menus and hover effects on links. Regardless of whether or not
> a site needs it, designers are going to circumvent the web's inability
> to control fonts and text effects in a meaningful way. The
> presentational method is the most appropriate way, is it not?
Designers also considered 5 minute flash tunnels a must to bring the
brand to the user, and they went the way of the Dodo bird.
Just because it is cool to achieve does not make it a standard.
What works depends on the audience, and examples of uses of the
aforementioned methods were they are not appropriate are legion -
partly because inexperienced designers saw them as a "must"
It also is a question of maintenance. For a weblog, a brochureware
site or a webzine image replacement might make a difference, for a
high traffic, multilanguage web site with a lot of content it will be
a nightmare to maintain - unless you generate the images via PHP or
Flash, but then you run into encoding issues.
> >>a[href^="http://";] { content:url("external.png") }
> >
> >
> > How about using a background image and padding for that? As the image
> > is just of visual use it doesn't need to be an element.
>
> My error, the selector should have been a[href^="http://"]:after. That
> technique does not work in browsers that do not support padding on
> inline elements (such as IE 5/win), making the text unreadable. This
> technique is more appropriate because is does not rely on the
> implementation and interaction of multiple properties in order to
> work--it either does or does not.
That once again raises the question what to alienate? An outdated
browser like IE5 or a - sadly enough - still very much current one
like IE6? A background image works swimmingly in most current
browsers, the ^= selector in just a few of them.
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
