W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2010

Re: DOMString-like objects for the CSSOM

From: Mark S. Miller <erights@google.com>
Date: Fri, 19 Feb 2010 08:32:32 -0800
Message-ID: <4d2fac901002190832t3d5edd7ey2202dc36baf58077@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Feb 19, 2010 at 8:24 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/19/10 11:20 AM, Mark S. Miller wrote:
>> Is it a string right now? If it is...
> Yes, it is.  Anne said so in the original post in this thread.  You did
> read that post, yes?
> Yes. I just reread it. It makes no mention of foo.style.top, but I take
your point.

>       So if we want to allow doing |foo.style.top.px = 200|
>> Why would you want that?
> Because string-to-number and number-to-string conversions are expensive.
>  Right now, moving things around via style.top/left involves two such
> conversions on every set: number to string in the JS and then string to
> number in the C++.  This is showing up as a significant performance cost on
> web sites.  So there needs to be an API that allows setting numbers
> directly.
> The idea of hanging that API off the existing .top and .left is appealing
> in an API design sense.
>  I suggest that once you appreciate the costs of
>> that desire, you will no longer want that.
> What are the costs, exactly?
> !, ===, typeof. Also, every single place in ES5 where there's an observable
difference between primitives and objects. For example:

'f' in 'x'
TypeError: Cannot use 'in' operator to search for 'f' in x
'f' in Object('x')

Your DOMString-like object would fail to fail an 'in' test, as does the
wrapper above. (Again, I think this variation in 'in's behavior is a
mistake. But it's again a mistake we must learn to live with.)

> -Boris

Received on Friday, 19 February 2010 16:33:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC