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

[Ian Hickson]

On Mon, 2 May 2011, Jonas Sicking 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.
> >> >
> >> > 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?
> >
> > 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.

[PutForwards] doesn't affect that, that's the stringifier. Location, <a>, 
and <area> all already have stringifiers, as do lots of objects in JS.

Are we really concerned about objects stringifying to "[Object Foo]"?

It seems that the usefulness of such stringification is far outweighed by 
the usefulness of being able to treat the attribute as a string attribute 
like any other reflecting attribute while also being able to use methods 
on it. In fact, it is consistent with every DOMString attribute: they 
don't stringify to "[Object String]", yet you can call methods on them. 
What's the difference?


> 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'm not particularly concerned about such edge cases (who does typeof on 
reflecting attributes in a way where the difference here would matter?). 
It's the common use that I'm concerned about.


> 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?

That's what we're doing (for legacy reasons) with className/classList and 
rel/relList, but I consider that an ugly and unfortunate wart on the API. 
As much as possible, attributes that take space-separated lists are using 
DOMSettableTokenList to avoid this (including a few legacy ones that 
aren't as high-profile as class and rel).


On Mon, 2 May 2011, Jonas Sicking wrote:
> 
> 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?

All the space-separated lists are exposed this way. It would be rather odd 
to exclude just one on the basis that we couldn't think of a reason why 
this particular one would get changed much.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'