W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: PROPOSAL: Expressing WAI-ARIA in CSS

From: Reece Dunn <msclrhd@googlemail.com>
Date: Tue, 15 Jan 2013 01:02:39 +0000
Message-ID: <CAGdtn24MD6kS8YRNULeS3TC7TA_AXfDz5sFWXavvwZTwwzN3Lw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: capi etheriel <barraponto@gmail.com>, www-style list <www-style@w3.org>
On 14 January 2013 23:11, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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

If you want to find out what font style to render some text block in you
query CSS, for the WAI-ARIA role you need to query the XML attributes.

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

I suppose it is a matter of context: at the moment, I am not generating a
DOM or preserving the XML structure after reading the document. I am using
a reader-style parser generating a simplified document model as a series of
events. I am tagging a CSS style with each event, allowing those properties
to be queried by the rendering/processing engine.

Therefore, for me to support ARIA via attributes would be a bigger effort
than mapping it to CSS or similar.

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

I got that impression from the article that capi linked to -- "Cascading
Stylesheets are awesome, why not take the same idea and apply it to HTML

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

The whole point of me using CSS is to have a generic XML document processor
instead of a HTML, NCX, ODF, DocBook, ... processor. The CSS file would
describe everything about the XML structure.

NOTE: I am aware that this will require me to add several things that are
not covered by CSS (e.g. implicit close tag on the img tag for example,
which I don't intend providing a proposal).

My other choice would be to create a custom file format, but CSS gets me
most of the way there.

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

I am thinking about it from a maintenance point of view -- I'd rather have
one file that specified how HTML behaved than several covering similar

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

So to clarify your point -- for HTML5 elements that do not have an explicit
xmlns, HTML elements map to the HTML namespace, SVG to the SVG namespace
and MathML to the MathML namespace? What about for documents that include
SVG and MathML markup but put them in the HTML namespace?

NOTE: I am also intending on supporting some of the Word generated HTML
files that use <html xmlns="http://www.w3.org/TR/REC-html40"> instead of
the correct HTML xmlns.

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

I am thinking of things like:

    [aria-hidden=true] { display: none; }
    [aria-invalid=true] { border-bottom: 2px solid red; }

where the ARIA attributes control presentation. If these were just
implemented via CAS, the renderer would need to use both CSS and ARIA to
determine presentation (including resolving user-specified styling for ARIA
attributes). Therefore, you need some of ARIA's behaviour to be expressed
in CSS.

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.

My application -- Cainteoir Text-to-Speech [1] -- is not a browser, but is
a combined document viewer/text-to-speech program.

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.

I haven't looked into what would be required to fully implement ARIA yet --
in CSS or otherwise. I am working on implementing the different CSS specs
first :).

Given the general view from the responses so far that WAI-ARIA does not
belong in CSS, I don't see my proposal going much further. I do still
intend on implementing them via CSS, they will just be implemented as
vendor prefixes.

[1] https://github.com/rhdunn/cainteoir-engine

 - Reece
Received on Tuesday, 15 January 2013 01:03:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:25 UTC