Re: PROPOSAL: Expressing WAI-ARIA in CSS

On Sun, Jan 13, 2013 at 3:55 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> Cascading Attribute Sheets don't fit my requirements for several reasons:
>
> 1.  I want one model for interpreting content meaning -- that is, I don't
> want to query both CSS properties and XML attributes to deduce the meaning;
> I just want to query CSS properties.

This seems incorrect.  If you used CAS, you'd just query attributes.
Information doesn't live in two places.

> 2.  I want the processing to be simple -- requiring attribute modification
> for CAS to work is overly complex and would require querying the generated
> WAI-ARIA properties to deduce the semantics.

I don't understand this objection.  The processing of CAS is roughly
identical to CSS.  The semantics of ARIA in an attribute are already
specified by the ARIA spec.

> 3.  CAS appears to apply only to HTML -- I want something that is applicable
> to any XML format (DocBook, NCX, OPF, ODF, ...).

I don't know why you would think that.  CAS applies attributes, and is
desugared to plain DOM operations.  It works on any language with a
DOM representation (all XML languages), and can be easily translated
to anything with roughly corresponding structure.  (That said, there's
likely namespace-related things I need to clean up.)

> 4.  CAS does not mention anything about vendor-based CAS -- that is, CSS has
> the notion of a default stylesheet for rendering content; I want something
> similar to express the default WAI-ARIA/semantic nature of the XML elements.

This is potentially fixable, but equally it can just be done like what
HTML does, by defining the default aria semantics for things directly.

> 5.  I ideally want to specify everything in a single place (i.e. one file
> per XML format) -- using both CAS and CSS would produce a lot of related
> files. This gets complicated with things like HTML having namespaced and
> unnamespaced variants and pulling in the svg and mathml content, but these
> can be handled with @import and @namespace CSS at-rules; duplicating that
> behaviour for the CAS rules (including ensuring they match up) will increase
> the scope for bugs.

I don't understand this requirement.  CAS can be written inline in an
XML file, same as CSS.  They can't be mixed, but neither can CSS and
JS.

(Note: HTML doesn't have un-namespaced things.  When writing HTML in
HTML serialization, there's no need to use namespaces explicitly, but
they're implied and are present in the DOM automatically.)

> 6.  Using CAS would require part of the WAI-ARIA spec to be implemented as
> CSS (e.g. for aria-hidden) and some as CAS. This gets harder to maintain
> when you have WAI-ARIA properties that need both.

I don't understand what you're saying here.  Can you elaborate as to
why you believe some parts of ARIA must be implemented as CSS, or why
something would have to be implemented as both?



The most important argument against CAS is simply that no browser has
plans to implement it so far, though of course you could if you
control a processor.

Ignoring market dynamics, the most important argument against CAS, and
for specifying ARIA stuff in CSS, is that you can't use CAS (or normal
attributes) to give aria semantics to generated content, such as
::before.

~TJ

Received on Monday, 14 January 2013 23:12:01 UTC