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

RE: Would it be possible to make IE act as if it did this as far as DOM and JS
exposure goes?

We can look into this. It seems like adding a DOM attribute through the simplified programming model of elm.foobar = 'x' instead of setAttribute() is beneficial to authors in terms of ease-of-coding. Let's talk about the pros and cons of this at one of the next ARIA conference calls.

-----Original Message-----
From: Simon Pieters [mailto:simonp@opera.com]
Sent: Friday, March 14, 2008 1:40 AM
To: Marc Silbey; Anne van Kesteren; Dave Pawson; w3c-wai-pf@w3.org; Chris Wilson
Cc: Cullen Sauls; Jon Gunderson; Aaron M Leventhal; Charles McCathieNevile; David Poehlman; www-archive@w3.org; Richard Schwerdtfeger
Subject: 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 Saturday, 15 March 2008 01:07:35 UTC