Re: Ideas for the ACSS module of CSS3

> > Exactly. 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. It
> > follows on from the WAI WCAG accessibility guidelines (actually HTML
> > Techniques for...):
> > http://www.w3.org/TR/2000/NOTE-WCAG10-HTML-TECHS-20000920/#group-bypass
> > "13.6 Group related links, identify the group (for user agents), and,
> > until user agents do so, provide a way to bypass the group. [Priority
> > 3] " However, the retaining of IDs sounds interesting.
>
> Ah, I see. So what you really want is a way to specify that an element
> contains a common set of links.
Yes: you can use map for that, but it is just a hack. I'm providing an "alt,
bypassing, specify as navbar", system for CSS.

> (I would personally say that the HTML <link> element would be better
> suited to that, but whatever.)
No: it is a "head" element. You could anchor it using XLink and frag IDs,
but that would be *very* messy.
And only in XHTML 2.0 anyway (when it comes out).

> This is an interesting proposal.
Thank you: I'm glad you think so.

> . Something like:
>    body { play: normal; }
>    .navbar { play: optional; }
> ...or something?

Yes. Good idea, but maybe add a little bit more depth:

.navbar:play { type: optional; alt: uri(#intro); }

That is a slightly illegal use of pseudo elements, but I'm not sure how else
you would define it.
Maybe:
.navbar { play: optional uri(#intro); skip: true; }

> 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.

> >>> An "else" descriptor
> >>> A kind of alternative attribute but for CSS. Allows UAs that don't
> >>> support a specific CSS property to take on an alternative:
> >>> p { color: #803050, else(volume: 120%;); }
> >> p { color: #803050; volume: 120%; }
> >
> > No, more like:
> > p { color: #803050, volume: 120%; }
> > We have alternatives for fonts, so why not everything else?
>
> What I wrote did exactly what you asked for. The 'color' and 'volumne'
> properties will never be supported by the same medium/UA combination
> anyway, so that may not be what you meant...?

Once again, it is my useage of a bad example which is causing the problems.
Some UAs may have a combination of these properties in future. I could write
a program to speak AND display HTML, so you can't say just because it isn't
out there now, that it won't ever be!
The example just used two different media. Try:
h1 { content: uri(h1.gif), "Welcome"; }
CSS2
This means Lynx viewers wont be dissapointed when people miss out ALT
attributes. Yuo could then apply stlye to correct bad markup. hmmmmm.....

>>>> Alternate placement/content etc.
>>>> @media aural {
>>>> h1 { alt: url(heading1.wav) }
>>>> }

>>>
>>> @media aural {
>>>    h1 { content: url(heading1.wav); }
>>> }

> > Possibly as a hack for now, but I'd rather see alt: whatever, because
> > it is specific that it denotes "alternative content", rather than just
> > "content". This is for an ACSS module, don't forget

> I don't understand. What you are asking for is for the H1 element contents
> to be replaced by 'heading1.wav', no?
> At one point in the past I proposed a multiple item version of 'content':
>    h1 { content: url(heading1.wav), auto; }
> ...which would use heading1.wav if possible, otherwise would use the
> element's contents. Would this work in this case?

Yes, that is a good proposal. Did it get anywere? Howver, what I proposed
gies a bit more extension to the situation: it gives CSS a more human
readable element to its design. Auto implies computer. Alt implies thought!
Actually, I would go with your suggestion for now - just to be amiable.

> > (actually, being "Netscape, Standards Compliance QA" it might well be
> > the main thing on your mind!)
> Hmm. "CSS Working Group, Invited Expert" then ;-)

*oh*
It's nice to see that the CSS WG take an interest in the public opinions
(unlike cou"HTML WG"gh).
Bet it still takes years to see real life W3C implementations though...

> >>> Spacer
> >> ? You mean like margin or pause-before?
> > No, a standardization of all of the spacing attributes of CSS: like
> > text-indent, pause-before, margin, but also allowing us to ass
> > horizontal rules, and as many spacers/spacing rules as you can think
> > of. Probably not ACSS.
> I still don't follow. Could you give an example?

(N.B. ass should have been add. s is too close to d on the keyboard. My
greatest fear is one day writing:
Sean B. Palmer
President and Founder: with the a and the n swapped around accidentally.)

As it won't be ACSS, i'll leave this for another day.

> >>> anim:freeze
> >> Wouldn't this be best dealt with at a UA/UI level ?
> > Yes, but you might want to provide a style for the control of it, or
> > advise that it not be turned off, or whatever.
> Er, as a user I don't want the author to decide what I can or cannot do
> using my programs on my computer.

Use a user style sheet and !important, then.

Once again, .navbar { play: optional uri(#intro); skip: true; } is the best
idea expressed in this reply. It is critical for CSS to help compliance of
WCAG for XHTML authors.

Everything else is just hacking.

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

Received on Friday, 13 October 2000 09:13:07 UTC