[webkit-dev] Differentiating between JS object properties and DOM
attributes
Darin Adler
darin at apple.com
Fri Mar 9 17:24:27 PST 2007
On Mar 9, 2007, at 4:32 PM, Christian Cantrell wrote:
> I recently noticed something that surprised me in a new build of
> WebKit. I found that some dashboard widgets don't run, including
> some Apple widgets like Stocks. When I investigated, I found that
> some widgets access custom DOM attributes using dot notation rather
> than the getAttribute function. For instance, with HTML like this...
>
> <table>
> <tr id="tr" foo="bar">
> <td>hi.</td>
> </tr>
> </table>
>
> ... they might access the value of foo like this...
>
> document.getElementById("tr").foo;
>
> ... rather than this...
>
> var tr = document.getElementById("tr").getAttribute('foo');
>
> I understand that this is considered a "fix" or a move toward more
> standardization, but I'm worried that this will break a lot of
> existing content, including some dashboard widgets written by Apple.
That's right. It was this change, made about a year ago: <http://
trac.webkit.org/projects/webkit/changeset/14069>.
It's not a "fix" in quotes -- it's a real life fix to actual
websites. It was motivated by the desire to fix those sites, not an
abstract urge for standardization.
Ultimately when we need a change like this for website compatibility
we have a tough decision to make about WebKit-specific content like
widgets that has not been tested with other engines. In some cases we
create application-specific quirks, but we try to avoid creating long
term differences between, say, the behavior of Dashboard and Safari
with the same content.
> Does anyone have an insight into this issue? Will everyone just
> need to update their content when Leopard comes out?
Yes, some widgets will need to be updated. There's no need to wait
for Leopard to come out; an updated widget would be backward compatible.
As far as websites are concerned, I assume few sites depend on this
behavior since Firefox's Gecko matches the new WebKit behavior.
-- Darin
More information about the webkit-dev
mailing list