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

[Jonas Sicking]

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?

/ Jonas