Re: [cssom-values] Possibility of patching existing CSS strings into Values objects?

On Thu, Aug 8, 2013 at 4:55 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> I've been thinking about the CSSOM Values API today, since SVG is
>> wanting to do essentially the same thing for its attributes. One of
>> the downsides of it is that we need to expose the Value objects as
>> something separate, because we currently always return strings.
>>
>> How realistic is it to change the type of attributes like
>> el.style.color from DOMString to a CSSValue, where CSSValue has a
>> stringifier and the attribute has a [PutForwards] on it?
>
>
>
> I've something simpler for you, that I personally plan to use at some point for my getSpecifiedStyle() API:
>
> return a String object instead of a String, and add a custom expando property on it to retreive your values. That preserves all the String stuff since you actually return a String, and the only difference is that you can actually
>
>
>     var color = document.style.color.cssValue;
>     var strRGBA = color.asRGBA()
>     var strHSLA = color.asHSLA()
>
>
> The only downside is that you basically create a box. Browsers could optimize the case where you use the string value by not generating the box in this case, but sometimes you just store the thing in a variable and there's no way to tell someone will not ask for the cssValue at some point...
>
> I don't know how String boxes reduce the performance of an app. I guess not too much, but on something as critical as "style", not too much might already be too much ^_^

That doesn't really help - it's basically identical to my suggestion
of either duplicating the String methods/indexed getters, or putting
String on the prototype chain.

You still have the issue that two different String objects with the
same contents will still compare false to each other, and will never
be falsey when used directly as a boolean.

~TJ

Received on Friday, 9 August 2013 00:07:22 UTC