Re: New file locations for LINK and ROLE test files

At 10:49 AM -0400 5/11/05, Aaron Leventhal wrote:
>Al Gilman wrote:
>
>>[distribution note: Jon, I would like to allocate this thread to 
>>XTECH (note Cc: above). Is that OK? - Al]
>>
>>At 11:05 PM -0400 5/10/05, Aaron Leventhal wrote:
>>
>>>Jon,
>>>
>>>Is there a way to expose states using link/rel ?
>>>Without the states, the roles are limited in use.
>>>
>>>- Aaron
>>
>>
>>I was musing about this just the other day.
>>
>>I think that this was why I was muttering things about sXBL.
>>
>>But we don't necessarily need W3C XBL to do this, if we are brash and lucky.
>>
>>Here is a rough sketch of how it might go. Note: I speak as a fool. Here
>>I am parroting things I have heard but don't really understand. Please listen
>>with optimistic ears.
>>
>><sketch>
>
>My understanding is that it's not against the rules for scripts in 
>HTML to use setAttributeNS to attributes (xhtml2:role or 
>waistate:foo). This is because the DOM spec is still the same in 
>HTML vs. XHTML. The namespaces just can't be used declaratively in 
>HTML.
>
>However, if we're going to use that trick I'm not sure what use the 
>rel/link role has.

the recognized keyword in html4:link.rel [alternately in self.class] 
triggers things like
[XBL or an on-load script] populates the Roadmap state attributes on selected
elements per the role indications [in link.rel etc.] and the 
templates in the standard
ontology for these roles.

The author should still be able to mark the roles by a simple mechanism and get
constructor functionality from the utilities that we provide, whether 
it is in the
browser or in a script library in the HTML4 incarnation.

>Gecko XBL could be used to map the class attribute to namespaced 
>attributes via the <constuctor> segment. For example, one could have:
><div tabindex="0" class="checkbox checked">My checkbox</div>
>and then have the XBL set xhtml2:role="wairole:checkbox" and 
>waistate:checkbox="true"
>
>That's not a bad trick -- it wouldn't work in anything besides 
>Gecko-based browsers, but then again it would degrade gracefully. It 
>could hold us over until support for XHTML and DHTML accessibility 
>becomes more prevalent.
>
>Al, does it look like I understood your suggestion?

Yes!  Consider how micro-level the clarification offered above is.

Al

>- Aaron
>
>>The key is the custom widgets in Firefox 1.1 that implement the API
>>binding of the role-marked elements.
>>
>>The states don't have to be in the HTML to be implemented in the
>>Gecko binding. All the Gecko binding needs from the HTML is a
>>sufficient key to recognize that certain elements in the HTML are
>>supposed to have known roles. The code that binds to the custom
>>widgets in Gecko *knows* that if it gets role X it gets states Y and
>>Z. Anywhat that's the dream.
>>
>>The question is, then how does the script programmer get access to
>>the unmanaged states? One option is that the same code that
>>injects the API binding edits the DOM to add the states. Then the
>>script can twiddle them. Or the script uses DOM access to the
>>as-rendered object. That take conferring with the sXBL folks about
>>DOM access to the view layer.
>>
>>Or is the HTML4 version of all this limited to Browser-managed states?
>>Anyway, send your mind in this direction. A phone call would not
>>be wasted, IMHO.
>>
>></sketch>
>>
>>Al

Received on Wednesday, 11 May 2005 15:09:36 UTC