W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] link.sizes and [PutForwards=value]

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 2 May 2011 17:50:22 -0700
Message-ID: <BANLkTin_kiRTHBZ5zHyLRQECHq5QVSoXbQ@mail.gmail.com>
On Mon, May 2, 2011 at 5:48 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Mon, May 2, 2011 at 4:37 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Wed, 5 Jan 2011, Mounir Lamouri wrote:
>>> On 01/05/2011 02:29 AM, Ian Hickson wrote:
>>> > On Thu, 14 Oct 2010, Olli Pettay wrote:
>>> >>
>>> >> may I wonder why on earth any new API, like
>>> >> link.sizes uses PutForwards?
>>> >> IMHO, PutForwards should be limited to the
>>> >> awkward DOM0 APIs like window.location.
>>> >
>>> > On Fri, 15 Oct 2010, Olli Pettay wrote:
>>> >>
>>> >> It makes getters and setters work in a very different way.
>>> >> Inconsistency in APIs isn't a good thing.
>>> >
>>> > I don't understand how they work in a different way?
>>> >
>>> > The idea is to make the attribute appear to work like a DOMString for most
>>> > purposes, but to allow methods to be invoked on it. (All the attributes
>>> > that have [PutForwards] set also have a stringifier on their object's
>>> > interface.)
>>>
>>> Is there a use case for [PutForwards] (except saving a few characters
>>> for the authors) that could justify the inconsistency?
>>
>> I don't understand how it's inconsistent. Inconsistent with what?
>>
>> The idea is to be consistent with all the other reflecting attributes,
>> which can mostly all be treated as either strings or numbers. Contrast
>> this with the way attributes are reflected in SVG, where there's a step of
>> indirection to get to the string value due to the animation API. I think
>> this is a case where [PutForwards] and stringification makes sense.
>
> It's inconsistent in that all other objects in javascript stringify to
> "[Object Foo]", whereas this object doesn't.
>
> If the concern is that link.sizes should be consistent with other
> attribute-mapping properties then you're only half-way there since
> typeof tests still behaves differently.
>
> I definitely agree that the way SVG does it is not ideal. How about
> simply creating a second property, like link.parsedSizes which returns
> the tokenlist?

Of course, an even simpler solution is to remove access to a
DOMTokenList representing link.sizes entirely. What is the use case?
Is it really that common to modify link.sizes that we need syntax
sugar for it?

/ Jonas
Received on Monday, 2 May 2011 17:50:22 UTC

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