Re: @role in SVG

Hi Henri,

In order for the non-namespaced version to be included, the attributes
would need be part of the base language. After some work we have uncovered
bugs int the IE implementation of namespaced attributes. Microsoft is
tracking those down but the bottom line is using setAttributeNS is a major
problem. It gets exacerbated when mixing document formats like SVG.

This deficiency requires people to use JavaScript to initiate UI updates
because we can't just have have a style sheet trigger off a CSS property in
html. Now we can say that well we should not be catering to IE bugs but the
reality is we are dealing with a browser with a very large marketshare.

Now this may not all be a problem for SVG plug-ins but it would be easier
for the developer to be able to set an attribute for a cross-cutting
technology without using a namespace.

In the UI realm I view roles and states and properties as cross-cutting
technologies. It would be nice to make it possible to set cross-cutting
attributes consistently across UI technologies.

Rich


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             Henri Sivonen                                                 
             <hsivonen@iki.fi>                                             
             Sent by:                                                   To 
             public-xhtml2-req         Doug Schepers <schepers@w3.org>     
             uest@w3.org                                                cc 
                                       www-svg <www-svg@w3.org>,           
                                       public-xhtml2@w3.org, Simon Pieters 
             10/10/2007 10:21          <simonp@opera.com>, Aaron M         
             AM                        Leventhal/Cambridge/IBM@IBMUS, Dave 
                                       Raggett <dsr@w3.org>,               
                                       public-cdf@w3.org                   
                                                                   Subject 
                                       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/