Re: Ideas for the ACSS module of CSS3

> > No: it is a "head" element. You could anchor it using XLink and frag
> > IDs, but that would be *very* messy.
>
> What I meant was that the entire idea of a navigation bar should be in
> the HEAD using LINK elements. Or alternatively, using out-of-band
> XLinks, but that is a new idea, whereas LINK was defined 7 years ago.
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.

> >> . Something like:
> >>    body { play: normal; }
> >>    .navbar { play: optional; }
> >> ...or something?
> > Yes. Good idea, but maybe add a little bit more depth:
> >
> > .navbar { play: optional uri(#intro); skip: true; }
> Again, that implies a knowledge of the DOM, which is bad.
Forget the URI suggestion then! Skip: true is O.K.

> However, you don't need to know that -- an element, inherently, has a
> start and an end. So just define the entire element to be 'optional'
> as it were.
Yes, good point. But the very existence of "content: uri()" implies that CSS
enables some DOM interaction:
h1 { content: uri(h1.gif); }
That isn't a classical style. It is a modern style! And so is my/our
proposal...

> What we are really looking at here is a way of persisting document
> fragment states between document instances. It could be argued that
> that is outside the scope of CSS.
It would be a pretty pointless arguement.
Your:
body { play: normal; }
.navbar { play: optional; }
idea is good enough for now, and we may need to tweak it in future.

> 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. What I really mean by it is a "grouped set of links",
whatever their purpose. 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."
Am eans of alternative content negotiation that is inherent in the attached
style (CSS) of a document. Rather than give a navbar the style "don't play",
we could instead/also give it "provide optional alternative (to skip the
content)".

> This still doesn't define how we establish that two documents have
> equivalent elements that should be considered the same and skipped as
> appropriate.
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 (?)

> Maybe out of band links really would be a better way...?
Coming from an XML/XHTML/XLink background, I would say "NO" ;-)

> >> Specifically picking the URI to jump to is Bad (tm), since it
> >> requires knowledge of the actual document. Stylesheets should be
> >> authorable with only knowledge of the document writing guidelines
> >> (e.g., the HTML spec).
> >
> > Ah, excellent point. However, you use classes and IDs in CSS, so
> > they could be used, in theory.
>
> Just because they can be used in theory does not make them ideal to
> use for an accessibility feature.
I agree, but we can restrict ourselves to marking it up (sorry, styling it)
as "skippable".


> As currently defined, aural and visual media are independent and so
> this situation wouldn't occur. The two 'views' of a document occur in
> different spaces, for example. (The canvas and the aural space.)
>
> Hence my explicit mention of "same medium/UA combination".
Agreed, for now...

> > Yes, that is a good proposal. Howver, what I proposed gies a bit
> > more extension to the situation: it gives CSS a more human readable
> > element to its design.
> That is debatable. 'content' is a full English word, 'alt' is not.
I suggest they re-write the dictionary.

> > Auto implies computer.
> 'auto' is what is used in the rest of the specification. It could be
> whatever, it is just a value that represents the 'automatic result'.
Fair enough.

> > Bet it still takes years to see real life W3C implementations though...
> You mean "to see real life implementation of W3C Specifications" ?
> Yes. Not the fault of the W3C particularly though...
No, but that as well. I mean: chances of " p { play: optional; skip:
true; }" being valid in CSS3: 1000:1.

> Cat Lover                                      /. `- '  (  `--'
So am I!

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

Received on Friday, 13 October 2000 10:07:40 UTC