- 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>
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, etc. -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 4 July 2011 15:47:18 UTC