Re: State and Status of WAI-ARIA approach to host-language embedding [ISSUE-51 standardizedFieldValues ISSUE-54 TagSoupIntegration]

On Tue, 2008-02-26 at 00:06 +0100, Al Gilman wrote:
> [...]
> We of PFWG have requested that the TAG review
> what we are doing in the area of host-language
> insertion.
> [...]
> http://www.w3.org/TR/wai-aria/#implementation

I am reasonably content with this approach. It seems
to be a result of following this pattern:

"A pattern that I'd like to see more of is
  1. start with a URI for a new term
  2. if it picks up steam, introduce a synonym that
     is a short string thru a fair/open process "
 -- http://lists.w3.org/Archives/Public/www-tag/2005Apr/0033

The ARIA design started by developing a vocabulary using fully
qualified URIs so as not to squat on anyone else's namespace.

Then vocabulary "picked up steam" to the point where pretty
much all web content authors should be aware of it; at that
point, the cost of having all the web content authors manage
the full URIs dominates the cost of re-negotiating the design
details so that authors can deal with short strings.

The early stages of the design observed this principle:

"Principle: Orthogonality

 Orthogonal abstractions benefit from orthogonal specifications."
 -- http://www.w3.org/TR/webarch/#orthogonal-specs

but as the design matured, interactions between ARIA and
the HTML-as-she-are-spoke host language dominated the
business of getting the value of ARIA into the hands of
the most authors.

Meanwhile, the URI-based design remains part of the ARIA
spec for use in contexts where the deployed base of HTML
content and software doesn't dominate the deployment considerations.

Anyone who wants a URI for checkbox can use:
  http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#checkbox

This follows:

"Good practice: Namespace adoption

 A specification that establishes an XML vocabulary SHOULD place all
element names and global attribute names in a namespace."
 -- http://www.w3.org/TR/webarch/#use-namespaces

and

"Good practice: Identify with URIs

 To benefit from and increase the value of the World Wide Web, agents
should provide URIs as identifiers for resources."
http://www.w3.org/TR/webarch/#pr-use-uris



Hmm... I do have one change to consider:
perhaps the reservation of aria-* beyond HTML 5 is
too broad:

"To support compatibility with future versions of ARIA, attribute names
beginning with "aria-" should be treated as reserved in host languages
likely to use ARIA. This is not a conformance requirement, but a request
to enhance compatibility."
  -- 5.1 Implementation in HTML and other markup languages without
requiring namespace support
  http://www.w3.org/TR/wai-aria/#impl_nonamespace

I think reserving aria-* in HTML 5 is cost-effective, but
asking that it be reserved it in other host languages seems
like premature standardization.


I note that some of the "how does this fit with HTML deployment?"
and such questions that came up in recent TAG teleconferences
are addressed not in the ARIA specification document but in
the roadmap...

> The Roadmap takes a technology assessment and
> planning perspective.
> 
> http://www.w3.org/TR/wai-aria-roadmap

Section 4.1 Roadmap Deliverable Timeline has all the relevant
pieces in one place.
http://www.w3.org/TR/wai-aria-roadmap/#desktop_timeline


On Thu, 2008-03-20 at 15:01 -0400, Al Gilman wrote:
> On 13 Mar 2008, at 1:19 PM, Dan Connolly wrote:
> 
> >
> > Al Gilman wrote:
> > [..]
> >>>      -- What is et problem with browsers handling a colon in an HTML
> >>> tag name?  Pointers?
> >>>
> >> The colon works in three mutually incompatible ways in
> >>  1) text/html in IE
> >>  2) text/html in Gecko/WebKit/Opera
> >>  3) XML (including application/xhtml+xml in Gecko/WebKit/Opera)
> >
> > Would you please elaborate? preferably in the form of test cases?
> > i.e. specific example documents?
> 
> Henri Sivonen and Simon Pieters contributed the discussion quoted
> below, that I can't improve upon.
[...]

Thanks. That helped me.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 15 April 2008 17:01:26 UTC