Re: Ideas for the ACSS module of CSS3

> > No, you could never have a navigation bar etc. that is anything but
> > proper document content. I.e. why link to a navigation bar. Kind of
> > defies the point really.
>
> I find it hard to understand how the whole point of <link> defies the
> whole point of <link>.
>
> I am referring to something like:
>
>    <head>
>      <title>The construction of Widgets</title>
>      <link rel="contents" href="./">
>      <link rel="next" href="production.html" title="Production of
Widgets">
>      <link rel="previous" href="design.html" title="Design of Widgets">
>      <link rel="search" href="../search/" title="Search the Site">
>    </head>
>
> This is how navigation bars were _supposed_ to be done in HTML. Doing
> it this way neatly sidesteps the entire issue.
Yes, but browsers find it very hard to implement the link attributes such as
above structurally. If you relied on links rather than navbars, no-one would
be able to find ther way around your site - that's just the way it is. HTML
implementations of "grouped links" are out of date now, and further HTML
solutions, especially hard to implement ones are not a good idea. Hence a
proposal in CSS. CSS allows us to simply style the navbar so that we can
render/treat it differently (see below).

> No. CSS cannot affect the DOM (by definition). The 'content' property
> would merely take the place of the H1's real contents in the rendering
> tree (not the document tree).
Exactly. So an alt attibute can specify an alternate means of rendering! It
has been suggested that more things than the simple img element should have
alternatives: ASCII art for example. The WAI are quite keen to see that more
alternatives are given in HTML/CSS.


> > Your:
> > body { play: normal; }
> > .navbar { play: optional; }
> > idea is good enough for now, and we may need to tweak it in future.
> Ok, the future is now, let's tweak it. What is subideal about it?

What, so it's been implemented in CSS2? *laugh*
O.K.: see my previous email & further note of:
Proposal: .navbar { play: optional; skip: true; }
With <map title="Navigation Bar" class="navbar"...>.
Or maybe:.navbar { play: optional; allow-skip: true; alt: (#intro); }or:
.navbar { play: optional; provide-skip: true; }
or you could just set the provide-skip as a token in play:
.navbar { play: optional provide-skip; }
I think any of the options discussed above would be suitable, but as a final
say, I would propose: .navbar { play: optional; skip: provide, allow; alt:
(#intro); }
Which would give any element with the navbar class, a style that
denotes the playing of which is optional, the skipping of which
should be provided by the UA, or at the very least, allowed by the
UA, and with an alternative ID frag reference of Intro, overriding
the default of the next element.
"Provide" means provide a skipping link, or alternative, or whatever, based
on the UA.


> >> I'm not sure what the 'skip' property defines, isn't the whole
> >> point that it will be skipped only if the UA thinks that the
> >> equivalent part of the document has already been shown?
> > The problem lies in the definition of a navbar, which I am ont
> > possibley going to define here.
> Well that blocks discussion then, if the problem is with something
> that cannot be brought to the discussion... Could you give us a
> reference to this definition you allude to?
Well, I was preparing a document about navigation bars and grouped links,
but I abandoned it. I suggest we define it as something like "a set of
grouped links imperative to the central navigation of a site".

> > What I really mean by it is a "grouped set of links", whatever their
> > purpose.
> How about the company catchphrase that appears on every page? That is
> not a link but it could very well want to be made optional on
> subsequent reads.
O.K., I don't mind if you use this solution as an interim method for solving
other accessibility problems: in fact kudos to you for finding tht example!
That is a vey good suggestion, and shows a wider application for the
proposal(s) that we are discussing.

> > Allowing "skipping" as well as "not playing" involves two different
> > states: not playing is ignoring altogether. skipping was probably a
> > bad choice of word, but it involves waht I said earlier: "The
> > reasoning behind it is that a User Agent specific link (or similar),
> > like 'Do you want to hear this damn navigation bar again?' could be
> > placed before the damn annoying navigation bar."
> Well, surely that is something that could be applied to _any_ part of
> the document, and is therefore a UA-specific feature: Just like "Page
> Down" works with every visual browser, you'd expect "SKIP!" to jump
> the playback point to the next element or end of that element, or some
> such. Thus this is not so much a CSS request as a UA feature request.
But it's a good idea to give a style to it to tell the UA that it should be
allowed to do so. You could write a browser that allows you to change font
properties, and all other aspects of CSS, so you could argue that CSS is
better as a UA feature request!

> > Interim use of the map element, or div for grouping. That is up to
> > the developer. Frag Id's classes, XLink. There are many ways to do
> > it: all beyond the scope of this discussion (?)
>
> It's very much within the scope of this discussion. You cannot define
> a property to 'skip the element if it has been played in another
> document during the current session' if you don't define how the UA
> should be able to tell. I don't see a clean way, myself.
No, it provides a style which says: "give the option of skipping". It's a
CSS answer to a structural dilemma.

> >> Maybe out of band links really would be a better way...?
> > Coming from an XML/XHTML/XLink background, I would say "NO" ;-)
>
> Whyever not? Out of band links would be ideal for a site-wide
> navigation bar -- instead of having to embed navigation aids into
> every page, you just link to a single file from every page. Just like
> you can have a single CSS file apply to an entire 57,000 page site,
> you could have a single XLink file apply to an entire 57,000 page
> site. A maintenance dream!

XLink isn't as widely supported as CSS yet. And I am talking about an
accessibility style for a docuemnt, that DOES NOT rely on hard structural
wiring throughout a site, even if it is XLink. Style is all about proving a
choice.


> >> That is debatable. 'content' is a full English word, 'alt' is not.
> > I suggest they re-write the dictionary.
> Now _that_ is out of scope for this mailing list! ;-)
I'll write to the OED!

> > No, but that as well. I mean: chances of " p { play: optional; skip:
> > true; }" being valid in CSS3: 1000:1.
> Why? I don't follow. If there is a clear need for something to appear
> in the specification, why would it not be introduced?

[Tell that to the HTML WG. There have been numerous excellent proposals and
discussions on www-html (remember the comment attribute?!)]
Hmmmm.....due to past experience with these sort of matters, I have to
remain sceptical. The problem is not many things are tht clear: most are
just *good* ideas. I've seen too many good ideas flamed down for no reason
in HTML. I am suprised that you are so involved in discussing this proposal
with me, and I am truly thankful.
Still a chance of 1000:1 IMO! I like being cynical.

And further still: it's nice to have a good idea, and then have it discussed
thouroughly.

Kindest Regards,
Sean B. Palmer
WAP Tech Info - http://www.waptechinfo.com/

Received on Saturday, 14 October 2000 10:55:58 UTC