W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [DOMCore] Attr

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Sun, 12 Sep 2010 00:17:51 -0400
To: "Anne van Kesteren" <annevk@opera.com>, "Maciej Stachowiak" <mjs@apple.com>
Cc: "Ojan Vafai" <ojan@chromium.org>, "Jonas Sicking" <jonas@sicking.cc>, "Boris Zbarsky" <bzbarsky@mit.edu>, "Olli@pettay.fi" <Olli@pettay.fi>, "Adrian Bateman" <adrianba@microsoft.com>, "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.viwjj00o1ejg13@sandra-svwliu01>
On Fri, 10 Sep 2010 19:05:56 -0400, Maciej Stachowiak <mjs@apple.com>  

> On Sep 10, 2010, at 5:35 AM, Anne van Kesteren wrote:
>> Hi,
>> I thought I'd email some people directly to figure out what we can do  
>> with Attr as it is one of the last bits not defined yet in Web DOM Core  
>> and I would sort of like to handle it so the specification is  
>> "complete" (at least beyond the initial 80%).
>> Attr nodes have traditionally allowed child nodes to account for  
>> EntityReference nodes, a concept which no browser vendor implemented.  
>> While it is great nobody implemented the complexity that is  
>> EntityReference, it has left us with a fair bit complexity for Attr  
>> nodes, which is implemented.
>> There are several ways we can simplify Attr nodes (some are orthogonal):
>> 1) We can drop the concept of Attr nodes having children. In Gecko it  
>> already depends on how you created the Attr node [1][2] whether it can  
>> have children or not. I think we should either consistently allow  
>> children or not at all (preferred).
>> 2) We can drop the concept of Attr being a Node. This would drastically  
>> reduce the footprint of the object. The difficulty would be in figuring  
>> out what we would need to preserve. Ideally someone implements this in  
>> a nightly and figures it out.
>> 3) We can drop the concept of Attr being an object altogether. I do not  
>> think this is doable compatibility-wise, but not having  
>> Node.attributes, Attr, and just using  
>> getAttribute/getAttributeNS/setAttribute/setAttributeNS would be very  
>> nice complexity-wise.
>> If there is anything else I have not considered that can we try out  
>> please mention it! Any input on this is much appreciated.
> My preference would be to simplify as much as we can get away with  
> consistent with Web compatibility, all the way up to removing Attr nodes  
> entirely if we can.
> I do not know the Web compat impact of different options though.

<http://site.games.betfair.com/betting/MarketView.do?gsi=1444089> at one  
time made use of attr_node.firstChild.nodeValue instead of attr_node.value  
and used to break in Opera since Opera didn't support that. Opera was  
fixed so that worked (as quite a few users complained about that site).

The site might still require that.

I think it was in  
<http://site.games.betfair.com/201007-1008/js/dataObject.js> in  
models_Base_Data.prototype.getText where other code was using that  
function not just on regular text nodes but Attr text nodes to get the  
attribute's value. I'm not sure if the code has changed since I last  
checked in Jan or 2008 though.

At the time, I made  
<http://shadow2531.com/opera/testcases/attr/suite0.html> to test some  
things with Attr nodes. (Note that the description on that page is  

Received on Sunday, 12 September 2010 04:18:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC