- From: Kristof Zelechovski <giecrilj@stegny.2a.pl>
- Date: Wed, 1 Oct 2008 16:04:12 +0200
While it is not my reasoning, I rather agree. DOM properties and attributes are different things. Attributes go to the source code, properties do not. Attributes have DOM nodes, properties do not. The idea is to make these sets disjoint. This makes the text verbose; this is a problem for execute-once scratchpad scripts (that can rely of what the implementation gives anyway, and the implementation is likely to provide attributes dressed up as properties) but not for code that is general enough, such as feature support detection. Which attributes return a number directly? Which attributes return a function directly? Chris -----Original Message----- From: Joao Eiras [mailto:joao.eiras@gmail.com] Sent: Wednesday, October 01, 2008 3:33 PM To: Kristof Zelechovski Cc: whatwg at whatwg.org Subject: Re: [whatwg] Placeholder option for text input boxes > This usage is deprecated because it can not be generalized to all possible attribute names > We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. Although I understand your reasoning, I disagree. The DOM does not exist only to wrap the representation of the original document markup. The DOM is a programming API and programmings API should make programs more easy to code nd more performant. Having a get/setAttribute indirection plus type conversions between serialized strings and back to a usable type (number, function) are not friendly at all. The idea of dom properties for attributes is not to find a generic structure for all atributes, but to have support for known attributes with known behavior. Please, don't make such claim again, they are misleading, and clearly not realistic.
Received on Wednesday, 1 October 2008 07:04:12 UTC