Sander Tekelenburg wrote:
> At 21:50 -0400 UTC, on 2007-09-27, Matthew Raymond wrote:
>> [...] so long a |role| hasn't reached critical mass in the
>> authoring community, I could care less how it disrupts the W3C. The W3C
>> is here to create good specifications, and if they have to start over
>> with some of them because a specific technology falls out of favor, so
>> be it. Better to break unimplemented specs that to try to fix the ones
>> already implemented.
>
> Agreed in principle. However, UA vendors are already calling changes to
> completely new features in the current draft "impossible" because it would
> break existing content:
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-September/012595.html>.
Deprecating |role| entirely and adding a new attribute does not
require altering existing implementations. The existing implementations
can continue to exist. They just won't be updated.
>> The |role| attribute is an elegant solution to a problem that doesn't
>> exist. There is nothing the it can express that couldn't be expressed
>> with elements or simple attributes. It's greatest use case are the ones
>> that have been specifically tailored to use |role| instead of other
>> solutions that would be greater extensible, easier validation and
>> parsing, and more structured markup.
>
> What about the problem Maciej raised in
> <http://www.w3.org/mid/B2750F31-8ACF-4B46-8D02-44371AEE4C9F@apple.com>, for
> which @role would appear to be a solution? Does that problem not exist?
I'm not sure what you're referring to. There is no apparent use of
|role| in the message you cite. How is |role| uniquely suited to solving
the accessible shortcuts problem? Personally, I think a combination of
<link> elements and |id| attributes would serve just fine if you want
auto-assigned or user-assigned keys, and message and its the replies
discuss several solutions unrelated to |role|. Furthermore, many
browsers already have special key combinations for access keys. (Mozilla
uses [Shift]+[Alt]+[Access Key].)
Yes, the |role| attribute could be used, but the point is not whether
you can invent uses for |role|. The point is that |role| doesn't provide
any unique or significant advantage over other technologies. Take a look...
XHTML + |role|:
| <div xmlns:namespace="[Url]" role="namespace:rolename"></div>
XHTML (attributes using namespaces):
| <div xmlns:namespace="[Url]" class="namespace:rolename"></div>
| <div xmlns:namespace="[Url]" namespace:rolename="true"></div>
| <div xmlns:namespace="[Url]" namespace:rolename="rolename"></div>
Attributes using HTML + namespaces:
| <div xmlns:namespace="[Url]" namespace:rolename></div>
XHTML/HTML (attributes in XHTML namespace):
| <div namespace-rolename="true"></div>
| <div namespace-rolename="namespace-rolename"></div>
| <div new-attribute-with-specific-semantic-scope="rolename"></div>
HTML non-namespaced attribute with minimization:
| <div namespace-rolename></div>
Elements in XHTML/HTML:
| <namespace:rolename><div></div></namespace:rolename>
| <namespace-rolename><div></div></namespace-rolename>
| <rolename><div></div></rolename>
| <link rel="namespace:rolename" href="#myid"><div id="myid></div>
| <link rel="namespace-rolename" href="#myid"><div id="myid></div>
| <link rel="rolename" href="#myid"> [...] <div id="myid></div>
So I must ask again: What it the specific problem that |role| is the
sole solution to? Is there even a problem for which it is the /optimal/
solution? I'm just not seeing the benefit.