- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 29 Jul 2011 01:15:51 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 28 July 2011 18:15:51 UTC