Re: [cssom] Property Value API Ideas

On Wed, Dec 2, 2009 at 8:11 AM, Anne van Kesteren <annevk@opera.com> wrote:F
> On Mon, 30 Nov 2009 22:00:10 +0100, Garrett Smith <dhtmlkitchen@gmail.com>
> wrote:
>>
>> On Mon, Nov 30, 2009 at 12:52 AM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>> It is important to state the problem that a proposed solution is
>> intended to solve before proposing solutions.
>
> Right, the email I pointed to had some analysis of that.
>
>
>> Problem, in a nutshell, is:
>> Reading element style is a painful task for cross browser code.
>>
>> A javascript library should not be needed for that.
>>
>> Sound right?
>
> I think scripted transitions/animations are an important consideration too.
> In particular the ability to skip string manipulation.
>

OK. I can see some benefit in code clarity and performance by
replacing - parseInt( val )||0) - with just - val -.

>
>>> During TPAC some members of the CSS WG and people outside the CSS WG
>>> discussed the idea of a potential replacement for CSSValue. Inspiration
>>> came
>>> from a very old proposal by Ian Hickson which was originally Member-only
>>> but
>>> I've since made available publicly here:
>>>
>>>  http://lists.w3.org/Archives/Public/www-archive/2009Nov/0007.html
>>
>> I see two proposals there:
>> 1) element.computedStyle
>> 2) A munged data type, as you mention here
>>
>> An element.computedStyle, if imporved to element.absoluteStyle, would
>> be easy to use, useful, implies guaranteed *absolute* style units, and
>> is easy to feature test.
>>
>> A munged data type, as you mention here, has serious detrimental
>> conseqences. For one, it creates a new data type for ECMAScript; not
>> string; not object. This requires additional handling for typeof
>> operator.
>
> That depends on how we do it exactly. I agree that we probably do not want a
> new ECMAScript data type.
>

You wrote:

| The idea is to make the members of CSSStyleDeclaration return a mix
between DOMString and a real Object.

If the mixed object is not a new data type, I don't know what it is.

>
>>> The idea is to make the members of CSSStyleDeclaration return a mix
>>> between DOMString and a real Object.
>>
>> A consequences of such design is that it breaks feature detection, as
>> explained here:
>> http://lists.w3.org/Archives/Public/www-style/2009Oct/0061.html
>
> I could not find an explanation in that email but I do not see why you would
> not be able to do e.g.
>
>  if("cssText" in obj.style.width)

I do want to throw a TypeError.

>
> assuming cssText will be a member of the new value interface.
>

Changing the value type of style properties, such as style.width,
would break the web.

>
>>> This would mean that e.g. triple-equality
>>> checks would no longer work and hopefully nobody relies on those
>>> specifics
>>> but if they do we have to think of something else. (Suggestions for
>>> "else"
>>> that floated around were having a new member on CSSStyleDeclaration that
>>> gives a CSSImprovedStyleDeclaration, having a new member for each CSS
>>> property, etc.)
>>
>> Creating a new Data type that behaves in an incompatible manner with
>> ECMAScript is a bad idea.
>
> I don't think I suggested that.
>
> Essentially the new object would inherit from DOMString and implement the
> same members. At least one of the members of TC39 thought it was plausible,
> but it requires further study.
>

A string value is not an object; it is a primitive value. A primitive
value cannot have any properties.

The in operator throws TypeError when the rhs operand is a not an object.

>
>> Google Code Search for code patterns that expect style properties to
>> be string value:

[snip]

> It does not seem like a lot of these would break, but yeah we need to test
> for compatibility obviously.
>

Changing style properties from string value to Object creates a
temporal mixed environment where in some implementations, a style
property will be a string value and in others it will be an Object.

If this API design is implemented in a browser, a program tested in
that browser might perform operations on the Object that would
otherwise fail in implementations where the property value was a
string value.

[snip]

>>
>> How about an alternative to allow the developer to choose object, such as:
>>
>>  style.getValue(prop)[ unit ]
>>
>> A program could use:
>>
>>  document.body.style.getValue("width").px;
>>
>> For non-dynamic language, a corresponding method:
>>
>>  document.body.style.getValue("width").valueTypes.get("px");
>>
>> That seems to fulfill your use patterns. It won't break any existing
>> code. Feature testing the getValue method should not be a problem.
>
> Yes, see my original email for similar alternatives.
>

Rereading, I do not see such alternatives in the first message you posted.

[snip]

Garrett

Received on Wednesday, 2 December 2009 17:21:49 UTC