- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 14 Sep 2010 09:32:09 +0200
- To: "www-style list" <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Tue, 14 Sep 2010 03:36:19 +0200, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > We've been mostly discussing Anne's proposed Values API. I think it's > a great start, but doesn't address the larger problem that the shape > of the APIs surrounding CSS is somewhat crazy. They don't work > together - you've got el.style pointing to the @style attribute on an > element, el.ownerDocument.defaultView.getComputedStyle('someproperty') > to get a resolved value (sometimes a 'computed', sometimes a 'used' > value), and the stylesheet-based API. These all work *completely* > differently, with vastly different access patterns, some being > writable while other are readonly, etc. It's just a bad situation > overall. Why? They have vastly different use cases. It seems perfectly logical to me, too, that the resolved values are readonly. They are after all based on all the rules in the style sheet. What would it even mean to edit them? > So, I've boiled down the use-cases I think are useful to address (not > included in this email for brevity, but can be provided upon request) Please do email these. > [...] Most of your proposals have been planned as additions to the CSSOM for a long time and have been discussed to on www-style as well. Basically by providing different accessors, e.g. ele.cascadedStyle, ele.usedStyle, and maybe also what IE has already implemented for override style sheets, ele.runtimeStyle. However, before we add these I think we should first sort out how we want to do value manipulation. Otherwise people will still be stuck with string manipulation. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 14 September 2010 07:32:45 UTC