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

Re: PROPOSAL: Expressing WAI-ARIA in CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 14 Jan 2013 17:53:23 -0800
Message-ID: <CAAWBYDAmqpLL-rxZYRNzgA_UUDChXSrUDeFAggTCus4CKBvGuQ@mail.gmail.com>
To: Reece Dunn <msclrhd@googlemail.com>
Cc: capi etheriel <barraponto@gmail.com>, www-style list <www-style@w3.org>
On Mon, Jan 14, 2013 at 5:02 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> 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.

And?  If you want to find out what type of input element you have, you
need to query the attributes too.  Some information lives in the DOM,
some lives in CSS.  This doesn't seem controversial or amenable to

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

If you're not using the DOM, then you can map CAS's attribute changes
to whatever roughly equivalent concept you have.  The only real
difference is that CAS is applied to each element only once per
document insertion, rather than continuously.  Since it sounds like
your reader doesn't do continuous CSS anyway, it's fine.

In other words, feel free to *interpret* CAS as doing CSS-type changes.

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

Yes, that's the impetus, but it uses only DOM operations, which apply
to anything with a DOM or something similar.

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

(Not really - if you want to use an XML processor, you just have to
use the XML serialiation of HTML.  If you try and apply "quick fixes"
to the HTML serialization to make it look like XML, you're in for a
bad time.  Don't do it.  Instead, put an HTML parser in front,
serializing the page to XML that the rest of your pipeline can use.)

My point is that if you have the equivalent of a UA style sheet, it
obviously only applies to particular languages that you've built in.
You can equally build the same functionality into somewhere else in
your program.  It doesn't add any more language-specificness than what
is required by the very premise of the request.

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

You'll forgive me for saying that this is not a major concern for us
as a standards body.  ^_^  On the web in general, while it's valuable
to minimize requests, having one additional file for a new language is

Further, as I stated, there's no need for you to have this on your
processor side.  Instead, for example, you can just have code in your
emitter that checks the tag's full name, and acts as if additional
aria attributes were present on it.

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

Reading the HTML parser would be instructive.  HTML written *in the
HTML serialization* doesn't use explicit namespaces at all; xmlns
attributes do nothing, and using : in a tagname is a syntax error.
HTML elements are automatically put into the HTML namespace, SVG into
the SVG namespace, and MathML into the MathML namespace.

HTML written *in the XML serialization* just follows normal XML rules.

Don't confuse the two serializations, or you're in for a lot of
confusion and pain.

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

You misunderstand CAS, I think.  CAS would *set* the aria attributes
(that's all CAS is - a convenient way to set attributes en masse).
You can then use your selectors as above without any change.

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

You seem to have misinterpreted my email.  I wasn't shooting down your
email.  ^_^  I was just responding to your arguments against CAS,
which appeared to be mostly mistaken.  I'm still somewhat neutral on
the idea of applying ARIA via CSS.

Received on Tuesday, 15 January 2013 01:54:11 UTC

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