W3C home > Mailing lists > Public > www-style@w3.org > September 2010

RE: [cssom] Directions for better OM expansions

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Tue, 14 Sep 2010 04:08:25 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E27D05C90@TK5EX14MBXC111.redmond.corp.microsoft.com>
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, September 13, 2010 8:44 PM
> To: Sylvain Galineau
> Cc: www-style list
> Subject: Re: [cssom] Directions for better OM expansions

> The personal experience of me and Alex Russell, plus many novice
> authors we've worked with, has been that el.style looks like it should
> give us, well, the style of the element, not the @style of the
> <element>.  I *still* slip up and try to treat it like that sometimes
> (especially since jQuery lets me cheat and just use .css() to read the
> current style, no matter where it's from).

Right, so are you saying: the author should be able to retrieve a node's 
computed/used style without having to make a separate explicit method call ?

> > - The ability to serialize the computed/used style of an element to a
> declaration
> > block and vice-versa, to turn a declaration block into a style object,
> may also
> > be useful for editor-type functionality.
> Hmm, I'm not certain I understand the use-case.  Can you elaborate?

Any scenario where you want to persist the style of an element for future reuse. 
Debugging, serializing one or more nodes together with the inline style reflecting
their current state, storing custom style preferences...
Received on Tuesday, 14 September 2010 04:09:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC