W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: [CSS OM] list of issues

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 04 Jul 2011 17:46:33 +0200
To: "www-style@w3.org" <www-style@w3.org>, "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>
Message-ID: <op.vx3p3vwb64w2qv@anne-van-kesterens-macbook-pro.local>
On Fri, 27 May 2011 12:30:14 +0200, Daniel Glazman  
<daniel.glazman@disruptive-innovations.com> wrote:
> 1. disabled attribute
>     one HTML 4 erratum often listed between 1998 and now is about
>     the lack of a disabled HTML attribute on <link> and <style> to
>     reflect the CSS OM disabled attribute on stylesheets. Because of
>     that, it is impossible to save the disabled status of an embedded or
>     linked stylesheet. I think we should add at least a note here
>     and make sure the WHATWG and HTML WG have that on their radar.
>     We need a similar mechanism for the XML processing instruction.

There is a lot of state that cannot be serialized at the moment. E.g. the  
alternate style sheet API. I am not really sure it is that desirable  
either. This is mostly something scripts want to do on the fly, not  
something that needs to be persisted by editors.

> 2. interface CSSStyleSheet, serialization
>     I think it is a pity that interface does not have a cssText
>     attribute for complete serialization of the stylesheet.

It might make sense to do this eventually, but for now there is plenty to  
fix with cssText on other objects.

>     (note: could the serialization be done according to the
>      presence of a @charset rule in the sheet?)

It would always serialize to a DOMString, so it could just ignore @charset.

> 3. interface CSS, rule insertion and deletion
>     the insertRule() and deleteRule() methods are string-based.
>     This is suboptimal for embedders. Please see
>       http://is.gd/6s08Sr
>     for a detailed explanation. We could even have
>       insertCSSRuleBefore(rule, targetRule)

That would also require a way to construct rules. Again it seems better to  
wait until we have more complete implementations of the current draft  
before adding more features.

> 4. interface CSSImportRule, href
>     href on that interface is readonly while it could be read-write.
>     For an content editor, it forces the code willing to tweak an
>     existing @import rule to create a new rule and delete the existing
>     one.

I am not sure this object model is good to use in an editor in that way.  
For editors you want more control over a lot of other aspects as well.  
Also, what would you propose the affect to be on browser implementations?  
E.g. if someone changes that on a "live" website?

> 5. interface CSSImportRule, creation
>     It could be useful to be able to have some sort of listener notified
>     when the stylesheet loaded by a newly inserted @import rule is
>     loaded and available through the CSS OM. Could also be useful to
>     notify load errors or security warnings (same origin, file URIs, ...)
> 6. global
>     It could be useful to be able to have mutation listeners on
>     stylesheets.

I suspect it is better to wait with these too until implementations are a  
bit more mature.

> 7. getComputedStyle
>     One of the big lacks of the existing CSS OM is the impossibility to
>     get the computed style of an element if a dynamic pseudo-class is
>     applied. It would be really cool to extend getComputedStyle() and
>     allow for instance ":hover" in the second parameter.

Then it is no longer the computed style for the element, but the computed  
style for the element under a given condition. I am not sure it is a good  
idea to change the semantics of the method in that way. (If you do  
getComputedStyle on a focused control today it will include the styles  
declared for :focus.)

>     Similarly, it's currently impossible to find the specified value
>     for a given property for a given element. There are tons of use
>     cases for online content editors. I think it would be great to
>     finally have getSpecifiedStyle(elt, pseudo) replying the result
>     of the cascade.

Yeah, we should probably add something like that in due course, though it  
is somewhat difficult with user style sheets, cross-origin style sheets,  

Anne van Kesteren
Received on Monday, 4 July 2011 15:47:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:47 UTC