Re: Ideas for the ACSS module of CSS3

On Fri, 13 Oct 2000, Sean Palmer wrote:
>>
>> (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.

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.


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

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.

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.

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?

This still doesn't define how we establish that two documents have
equivalent elements that should be considered the same and skipped as
appropriate.

Maybe out of band links really would be a better way...?


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


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

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


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


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


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

-- 
Ian Hickson                                     )\     _. - ._.)       fL
Cat Lover                                      /. `- '  (  `--'
+1 650 937 6593                                `- , ) -> ) \
irc.mozilla.org:Hixie _________________________  (.' \) (.' -' __________

Received on Friday, 13 October 2000 09:33:03 UTC