W3C home > Mailing lists > Public > www-style@w3.org > October 2000

Re: Wrapping up the ACSS Module Ideas

From: Sean Palmer <wapdesign@wapdesign.org.uk>
Date: Wed, 18 Oct 2000 10:56:43 +0100
Message-ID: <003c01c038e9$c9ca7d00$c8d893c3@z5n9x1>
To: "Ian Hickson" <ianh@netscape.com>
Cc: <www-style@w3.org>
> Sean Palmer wrote:
> > [...snip interesting proposals...]
>
> As I understand it, the problem is that a document contains a navigation
> bar, and the WAI guidelines say that this navigation bar should be made
> easy to skip so as not to bore aural browser users.
>
> Is this correct?
Yes, although the guidelines actually specify "grouped links", which I
redefine as "optional content". Also, "aural users" should probably be "any
streamed media (or time dependant)", to accomodate the future.


> 1. In the content, include a "skip" link that points to just after the
>    navigation bar. Then, in the CSS stylesheet, hide that link for visual
>    browsers.
This would appear to be the *only* ideal solution. And although it works
fine in 99% of the cases, imagine, for example, this:-
<a href=... class="optional" >a</a>
<a href=... >b</a>
<a href=... class="optional" >c</a>
<a href=... class="optional" >d</a>
<a href=... class="optional" >e</a>
It's not a perfect suggestion, because it is hardwired, not a style.

> 2. Aural browsers could implement a feature whereby saying "skip"
>    automatically jumps to the end of the current (deepest) element, or
>    jump to the end of the element that contains the end of the current
>    sentence, or some such.
That wouldn't work because the DOM is often messy.
<div>
<map id="..."...>
<p etc><a href <a href (NAVBAR) <a href ...</p>
</map>
Other content
</div>
As the guideline implementation notes advise.
Would you skip to the end of p, map, div, or what??? Once again: what if you
missed a bit of content that isn't skippable:
<a href=... class="optional" >a</a>
<a href=... >b</a>
<a href=... class="optional" >c</a>
<a href=... class="optional" >d</a>
<a href=... class="optional" >e</a>

> 3. The content could be transformed using XSLT to include a skip link if
>    the media is aural.
But for that you would have to use CC/PP or some kind of scripting (ASP),
which is not at all viable at this stage.

> 4. The navigation bar could be given using elements explicitly designed
>    for this (<link> in HTML) so that the UA will be able to automatically
>    handle the skipping of the navigation bar.
No, what you are suggesting simply isn't used. For example, would you put a
TOC in the head using Link elements? No-one would be able to use it because
browsers don't support it! The W3C doesn't expect you to use this and
accepts the fact that navigation bars are here to stay.

> 5. The navigation bar could be given using out-of-band data such as HTTP
>    "Link" headers or an XLink file, and again handled specially by the UA.
XLink? You would have to use XPointer as well. That would be soo messy as to
be unreal.
I might actually prepare an example of that just to show you how big a task
that is. And is is fairly DOM rooted. If you change the DOM just one little
bit, the whole system could backfire.

> Given that there are already at least five solutions to this problem,
At least five? I count one...
Summary:
1) Good idea (99% of the time!)
- - -
2) No: DOM dependant, so what if the DOM is not as expected?
3) Not implementable (for years to come?)
4) Very bad idea (sorry).
5) DOM dependant and messy (and complicated)

> some
> of which have been defined since the early 90s, some of which have only
> recently entered Candidate Recommendation stage, is there any reason to
> introduce a sixth solution at the draft stage?
Yes: this "solution" is pretty simple: for whatever content you want to
skip, label it as class="optional" and then in your stylesheet, write
.optional { skip: etc....

It's so much easier than any of the above solutions (XLink???), and it'll
work, all of the time, every time - 100% (somebody prove me wrong!). The
easier it is, the more people use it. The more people use it, the more
useful it is...

Once again, I hope this clears up some of the problems here, but it feels
like you are starting to believe that proprietary solutions are going to
work better than this idea, when they simply aren't.

Kindest Regards,
Sean B. Palmer
WAP Tech Info - http://www.waptechinfo.com/
Received on Wednesday, 18 October 2000 05:57:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:06 GMT