Re: @role in SVG

I really like the idea of a role attribute, I have what I now consider
existing workarounds.  Things like custom markup and id's with a
certain suffix or prefix.  Hacks basically for what you are proposing,
which would be the proper way to do it.

One thing that might be considered, is, a: would other markups
benefit, b: would most markups benefit, c: would all markup benefit.

One thing is clear, both xhtml and svg could use this feature to
supply a common ecmascript requirement.  What is this node for?.  As I
said earlier, I could certainly use it now.  And if that is the case,
there should be a normative description in one place, not both specs.
Somehow I don't like the idea of using the XHTML namespace in SVG or
vice versa.

Could it be defined in the xhtml spec, referenced by the svg spec, and
native in both?  (Or others)  Is that bad design?

Xlink is meant to define a document reference usually, but there are
little used attributes there like xlink:role, xlink:arcrole, and
xlink:title already there that fulfill a similar purpose.  (I never
thought of using those, whee!!!)

http://www.w3.org/TR/xlink/#link-semantics

If it could be argued that role attribute is a truly generic use case,
which should be considered, it might be at home next to xml:id.  (But
that would take too long)

On 10/9/07, Doug Schepers <schepers@w3.org> wrote:
>
> Hi, SVG community-
>
> The SVG WG likes the functionality and extensibility that the 'role
> attribute affords, and the potential for increased accessibility, so we
> do want to include it in SVG (and to see it implemented as soon as
> possible, so authors can use it right away).  We've talked about how
> best to do so, and we'd like to solicit opinions from interested
> parties, including the other Working Groups involved, implementors, and
> authors.
>
> To summarize the options, we can include the 'role' attribute in the
> XHTML namespace, or as a native null-namespace attribute.  Each approach
> has benefits and problems.
>
> 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>
>
> Pros:
> * does not require any changes to SVG syntax... automatically available
> via XML's innate extensibility mechanism
> * conforms to current version of the Role spec [1]
>
> Cons:
> * is slightly harder to author (requires working knowledge of
> namespaces, or good voodoo skills)
> * differs in syntax from how it would work in XHTML and HTML5 (so may be
> harder to learn, and possibly to implement)
> * more verbose
>
>
> 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>
>
>
> Pros:
> * more similar in syntax to XHTML and HTML5 (easier to use and maybe
> implement)
> * less verbose
> * maybe less error-prone for authoring, mash-ups, compound documents
>
> Cons:
> * would require a change to SVG (see details below)
> * would require change to Role spec to allow "host language" (SVG) to
> incorporate it into its own language (note that there is precedent for
> this in the previous version of the Role spec [2], not sure why it was
> changed)
>
> Neutral:
> * still requires knowledge of namespaces, but only for including ARIA
>
>
> Changes Required to SVG Specifications
>
> As mentioned, including 'role' via the XHTML namespace requires no
> changes to SVG (though would benefit from a Note on the details), but I
> understand that some might not find it the cleanest or most
> author-friendly solution.  So, the SVG WG is open to include it directly
> in the SVG language, if that's the solution the community feels is best
> (and if it is allowed by the Role spec).
>
> If we are to include it in the language, just how we do so depends on
> which version of SVG.  We can't add it as a feature to SVG 1.1 or before
> (adding features that change conformance to a past version is not
> allowed in the W3C Process), but we could do so for SVG 1.2 Full with
> few or no problems.  There is a chance we could do it for SVG 1.2 Tiny,
> because it's not yet in PR, but adding features at this late stage might
> not sit well with the standards community (though the implementors on
> the WG assure us that merely adding an attribute is trivial).  We would
> like to do it, but not if it's seen as unacceptable by the standards
> community.
>
> Another factor is that we don't want to be dependent upon the Role
> Attribute  and the CURIE specs for our Rec-Track exit criteria.  But
> neither do we want to specify it separately (or differently) than that
> spec.  A possible solution is that, for SVG 1.2 Tiny, we would include
> it as an attribute whose value is a space-separated list of strings, and
> when the Role and CURIE specs are more mature, in the SVG 1.2 Full
> timeframe, we would change the specification of 'role' to refer to those
> specs.  This is not a very clean solution, but it would get the 'role'
> attribute out there, and let authors create content now in as easy a
> manner as possible.
>
>
> Changes Required to Role Attribute Specification
>
> As mentioned before, for this to happen, the Role Attribute spec would
> need to explicitly allow SVG to do it.  We'd like feedback from the
> XHTML2 WG on this.  It would be ideal, perhaps, if the Role spec
> optionally allowed the values to be strings instead of CURIEs (as
> specified in a host language), but that may be a bridge too far.
>
>
> Prompt feedback on this issue would be greatly appreciated.
>
>
> [1] http://www.w3.org/TR/xhtml-role/
> [2] http://www.w3.org/TR/2006/WD-xhtml-role-20060725/#docconf
>
> Regards-
> -Doug Schepers
> W3C Staff Contact, SVG, CDF, and WebAPI
>
>
>
>


--
Cheers!
Rick


-- 
Cheers!
Rick

Received on Wednesday, 10 October 2007 13:03:37 UTC