I think we could say it's useful but the problem is it's not spec'd. So
authors that use it will get broken content everywhere but IE.
This isn't an ARIA-specific issue. Since it's arguably useful you could
try to get attribute mirroring into the relevant specs. If it's not in a
speci do not support it or you break everyone else.
- Aaron
Chris Wilson <Chris.Wilson@microsoft.com>
03/14/2008 01:47 PM
To
Simon Pieters <simonp@opera.com>, Marc Silbey
<marcsil@windows.microsoft.com>, Anne van Kesteren <annevk@opera.com>,
Dave Pawson <dave.pawson@gmail.com>, "w3c-wai-pf@w3.org"
<w3c-wai-pf@w3.org>
cc
Cullen Sauls <cullens@microsoft.com>, Jon Gunderson <jongund@uiuc.edu>,
Aaron M Leventhal/Cambridge/IBM@IBMUS, Charles McCathieNevile
<chaals@opera.com>, David Poehlman <poehlman1@comcast.net>,
"www-archive@w3.org" <www-archive@w3.org>, Richard
Schwerdtfeger/Austin/IBM@IBMUS
Subject
RE: IE8 incompatibility issues (was: Re: Issue: IE 8 adds new DOM
Properties for ARIA -- not compatible with other impls)
Simon Pieters [mailto:simonp@opera.com] wrote:
>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.
IIRC, this does not necessarily happen with unknown attributes - only with
known attributes. If it's a known attribute, it gets reflected into the
DOM with camelCasing. If it's an unknown/unrecognized attribute, it is
only accessible via getAttribute().
-Chris