Re: IE8 incompatibility issues (was: Re: Issue: IE 8 adds new DOM Properties for ARIA -- not compatible with other impls)

On Thu, 13 Mar 2008 18:16:59 +0100, Marc Silbey  
<marcsil@windows.microsoft.com> wrote:

> Cullen (on CC) is one of our OM developers and he implemented ARIA:
>
> ------
> "In IE, attributes need a name. The name needs to be defined such that  
> we can provide programmatic access to it. For example, a name of  
> “aria-busy” cannot be used in the COM accessor method names  
> (get_aria-busy() is invalid syntax). Therefore, the property needs a way  
> to expose both the dash-syntax as well as a way for the COM interface to  
> access the property. Our convention in IE is to camel-case the name in  
> place of the dash (aria-busy becomes ariaBusy). Then, we specifically  
> say that the property’s true name is “aria-busy” such that it is parsed  
> in the HTML and that get/setAttribute() methods work as expected (in IE8  
> mode). Because the attribute name contains a dash, the accessor syntax  
> in JavaScript that uses the format of element.foo cannot use the true  
> name of the property (element.aria-busy is invalid syntax), so IE  
> exposes the property via the camel-case format.
>
> All of this is done automatically by our tools that take our interface  
> definitions (including property and method definitions) and generate the  
> necessary code for them. Our ARIA implementation did not add anything in  
> the way attributes are handled. The behavior being observed is just how  
> IE exposes properties/methods that have a name that contains invalid  
> characters for programmatic purposes."
> ------

I understand that IE works this way internally, but this behavior -- that  
all attributes are reflected by DOM attributes and that any DOM attributes  
(or JS properties) on elements also turn into real attributes -- is not  
backed up by any DOM spec, and Opera, Safari and Firefox don't do this. In  
those browsers, unknown attributes are only accessible with  
getAttribute(), and saying elm.foobar = 'x' just creates a JS property  
"foobar" without adding/changing the "foobar" attribute on the element.

Would it be possible to make IE act as if it did this as far as DOM and JS  
exposure goes? This would solve two problems in one go -- ARIA attributes  
and unknown attributes/properties.


> If together we decide that we don't want to allow this DOM attribute  
> behavior then we can either advise developers not to use it in the best  
> practices document

This doesn't sound like a reliable method to me -- I would expect many  
authors to go by trial-and-error and copy-paste rather than read best  
practices documents.


> or we (IE) will look into doing extra work to remove the functionality  
> in our ARIA implementation. I'd like to talk about these options and any  
> others on one of the next wg calls.

-- 
Simon Pieters
Opera Software

Received on Friday, 14 March 2008 08:40:54 UTC