Re: @role in SVG

On 10/10/07, "~:'' ありがとうございました。" <j.chetwynd@btinternet.com> wrote:
>  as I previously mentioned it appears that there has been no response from
> any naive users.

What does that mean?  Jonathan, I have much difficulty sorting out
what it is that you are talking about.  Maybe it's because I'm a geek,
and therefore naive, but I've read back through some of your emails
and I see phrases like 'the pre-literate author when composing' which
I don't understand.  How can you be an author if you are illiterate?
( I'm naively assuming that pre-literate is PC for illiterate, but
could learn someday. )

I don't understand why you would ask anyone about a topic when they
are considered naive.  You would have to educate them first, and in
doing so doubtless they would borrow your opinions for quite a while
before forming their own.

I'm obviously missing some broad concept here.

>
> It's my opinion, already expressed that this change has not been presented
> in a means presentable to such an audience.
>
> I am for instance not able to ask non-expert audiences for their opinion to
> feed back into discussions.
>
> I do not consider it sufficient that the WG is excited by this possibility.
>
> Rather than imagining the pros and cons.
> Please take the opportunity to ask.
>
> regards
>
>
> Jonathan Chetwynd
> Accessibility Consultant on Media Literacy and the Internet
>
>
>
>
>
> On 10 Oct 2007, at 01:59, Doug Schepers 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:12 UTC