W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2010

[whatwg] Why [PutForwards=value] for htmlFor output element attribute ?

From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
Date: Tue, 13 Apr 2010 19:02:43 +0200
Message-ID: <4BC4A3B3.7080107@pvv.org>
On 08.04.2010 16:07, Olli Pettay wrote:
> On 4/5/10 3:21 PM, Mounir Lamouri wrote:
>> Hi,
>>
>> I'm wondering why the [PutForwards=value] extended attribute is needed
>> for the htmlFor output element attribute ?
>> It is making things pretty ugly for a need I do not really get.
>>
>> Thanks,
>> --
>> Mounir
>>
>
> I agree. In general PutForwards makes APIs strange, IMO
> Location is a good example of a pretty awkward API.
> In the case of output element,
> element.htmlFor.value = "Something" isn't really
> more difficult than element.htmlFor = "something";
>
> Though, .htmlFor accept setting a string value in other
> interfacase, but in those cases the type of the attribute
> is DOMString.
> It is a bit ugly that one .htmlFor is DOMSettableTokenList,
> but other .htmlFors are DOMStrings

The PutForwards attribute mitigates this problem, by letting you treat 
the property as if it were a DOMString if you want.

You could argue that every DOMSettableTokenList should have 
PutForwards=value behavior by default, since it already forwards on getting.

> Would be at least great to know some good reasoning for
> using PutForwards.
>
> Btw why doesn't .classList have PutForwards
> (in which case it could use DOMSettableTokenList)

Direct access to the raw class attribute already exists as .className, 
so there's no need.

-- 
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."
Received on Tuesday, 13 April 2010 10:02:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:22 UTC