<op.uaubzai2idj3kv@hp-a0a83fcd39d2.belkin>
Current votes: None.
This email contains two related rough proposals/thoughts for the ARIA sp=
ec =
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=3Demail>, <input type=3Durl> and the pattern=3D=
'' =
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=3D'' are not really appliciable, AFAICT.)
Since ARIA datatypes are, AIUI, expected to be used on any user editable=
=
region, including <div contenteditable=3Dtrue>, this begs the question a=
s to =
whether HTML 5 should adopt WF2 type=3D'email', type=3D'url' and pattern=
=3D'' =
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=3D'') (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