Re: @role in SVG

On Oct 10, 2007, at 03:59, Doug Schepers wrote:

> 1) XHTML Namespace
> <svg
>   xmlns="http://www.w3.org/2000/svg"
>   xmlns:xlink="http://www.w3.org/1999/xlink"
>   xmlns:xhtml="http://www.w3.org/1999/xhtml"
>   xmlns:aaa="http://www.w3.org/2005/07/aaa">
>   <g xhtml:role="checkbox" aaa:checked="true">...</g>
> </svg>

> 2) Native Non-Namespaced Attribute
> <svg
>   xmlns="http://www.w3.org/2000/svg"
>   xmlns:xlink="http://www.w3.org/1999/xlink"
>   xmlns:aaa="http://www.w3.org/2005/07/aaa">
>   <g role="checkbox" aaa:checked="true">...</g>
> </svg>

I'm curious why a third way isn't mentioned:
3) Non-Namespaced Attributes for both role and states/properties with  
the latter prefixed with "aria-" (and no qNames in content but opaque  
strings):
<svg
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink">
   <g role="checkbox" aria-checked="true">...</g>
</svg>

Pros:
  * Matches what has recently been proposed for (X)HTML5 and XUL.  
Good both for implementation and author skill portability.
  * Fewer namespaces to deal with (i.e. easier).
  * Copy-paste-friendly.
  * DOM-friendly. (qNames in content are *bad* in the DOM.)
  * Not a chameleon namespace per se. The attributes would be in no  
namespace in XHTML5, SVG and XUL.
  * Semantics and processing can still be imported by normative  
reference from wherever they get defined for HTML5. No need to spec  
all this in the SVG spec.

Cons:
  * Not what the WAI PFWG draft currently says.
  * Unorthodox in terms of XML architecture.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/