- From: Matt Garrish <matt.garrish@bell.net>
- Date: Tue, 14 Apr 2015 08:22:37 -0400
- To: "Liam R. E. Quin" <liam@w3.org>
- CC: "Bill Kasdorf" <bkasdorf@apexcovantage.com>, "Nick Ruffilo" <nickruffilo@gmail.com>, <public-digipub-ig@w3.org>
> The ARIA spec could have a built-in list of prefixes, too, rather like > the data-* attributes in HTML 5, where the prefix "data-" is pre- > registered. Right, that's not a stretch from rdfa initial context documents and their predefined prefixes, either, which is what epub takes advantage. There's always the theoretical concern that someone will be using a prefix before you reserve it, but it's easy spin wheels thinking about what might go wrong. What we need is clarity in the ARIA spec at the same time, assuming we are required to move our roles off into a separate "namespace". I haven't heard that's a given, or widely desired, so I'm still hoping it doesn't come to pass. > So it might be that some form of subclassing approach would work > -- role="abstract.wsj" I prefer this approach to making a mess with labels. I don't expect the differences in abstracts would be all that wide, and if you really need to express abstract.legal or, say, differentiate act.play from act.legal, that seems simpler than defining a new role module. It's also a lot cleaner than trying to remember a bunch of hyphenated labels. There's still an issue of inheritance because of tie-in with states and properties, and assuming only the base class is recognized by some set of processors, so a mixing of labels and subclasses is maybe inevitable. I really don't know. At this point, ARIA essentially only defines document structure/landmark roles and interactive element roles, so the concerns may be more theoretical than practical, too. We're not trying to replace RDFa/microdata, so many conflicts I've been used to seeing probably will never come to pass. It's a fair critique that part could be a grouper of chapters, a grouper of sections within a structure like an index, or a generic region of the page, and we need to be careful of over-generalizing, but the roles we're suggesting generally have pretty unique meanings, even if there are slight differences between publishing contexts. I think some of the concern here is also rooted in the age-old question of whether people bother to read specs or just use roles/element/attributes however they personally interpret their names. We'll never solve that problem. But I'm just rambling again... Matt
Received on Tuesday, 14 April 2015 12:23:06 UTC