Replace aria-datatype and evolve contenteditable

This email contains two related rough proposals/thoughts for the ARIA spec  
and the HTML 5 spec:

   1. Replace aria-datatype with something that works in HTML.
   2. Perhaps evolve HTML 5 contenteditable to support WF2 features.


Regarding http://www.w3.org/TR/wai-aria/#datatype

aria-datatype seems to be incompatible with HTML requiring QNames with  
associated namespace declarations being in scope, since text/html doesn't  
support namespace declarations. (Moreover, it's unclear how to implement  
aria-datatype and XSD seems suboptimal; see  
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0062.html  
.)

For ARIA, I'd suggest to align with or adopt data types in Web Forms 2.0,  
in particular <input type=email>, <input type=url> and the pattern=''  
attribute.

    http://www.whatwg.org/specs/web-forms/current-work/#email
    http://www.whatwg.org/specs/web-forms/current-work/#url
    http://www.whatwg.org/specs/web-forms/current-work/#pattern

(The other values for type='' are not really appliciable, AFAICT.)

Since ARIA datatypes are, AIUI, expected to be used on any user editable  
region, including <div contenteditable=true>, this begs the question as to  
whether HTML 5 should adopt WF2 type='email', type='url' and pattern=''  
for contenteditable elements as well. Either they are useful for  
contenteditable, and HTML 5 should have them, or they are not, and ARIA  
should restrict its data types to HTML <input> (and <textarea> for  
pattern='') (in which case, ARIA can simply drop aria-datatype and let the  
above WF2 features replace it, or adopt the WF2 features without aria-  
prefix as with tabindex).

If the former, then should readonly, disabled, required, etc. also apply  
to contenteditable? It would make sense as far as AT exposure goes, but  
contenteditable doesn't take part of WF2 form validation or submission, so  
it would be a bit inconsistent. Perhaps there should be an attribute on  
<div> saying that the element is a form control that accepts normal form  
control related attributes and takes part of form validation and, if the  
element is successful, submits its innerHTML. (Same with <iframe> in  
combination with designMode, submitting its contentDocument.innerHTML?)

-- 
Simon Pieters
Opera Software

Received on Thursday, 8 May 2008 15:01:18 UTC