- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Mon, 30 Nov 2009 13:00:10 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: CSS WG <www-style@w3.org>
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.
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?
> 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.
> 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
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.
Google Code Search for code patterns that expect style properties to
be string value:
typeof x.style
That is a common and obvious way to feature test style properties.
A google code search for:
typeof\s+(\w+\.)style[\[\.] lang:javascript
- resulted in about 2000 hits.
http://www.google.com/codesearch?hl=en&lr=&q=typeof%5Cs%2B%28%5Cw%2B%5C.%29style%5B%5C%5B%5C.%5D+lang%3Ajavascript&sbtn=Search
Those programs should continue to function. Those programs should be
checking against "undefined", but that is beside the point. (An
implementation might use null instead of empty string for unset, but
present properties.
Creating a new data type that is incompatible with ECMA-262 (no string
value with properties) adds too much complexity.
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.
A comprehensive test suite would help to get better perspective on
edge cases, such as trying to read hsla, background color, shorthand
values.
Another proposed idea was document.defaultView.getAbsoluteStyle.
Garrett
Received on Monday, 30 November 2009 21:00:50 UTC