[whatwg] Placeholder option for text input boxes

Kristof Zelechovski giecrilj at stegny.2a.pl
Wed Oct 1 07:04:12 PDT 2008

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?

-----Original Message-----
From: Joao Eiras [mailto:joao.eiras at 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.

More information about the whatwg mailing list