- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 17 Aug 2012 13:04:49 -0700
- To: Elliott Sprehn <esprehn@gmail.com>
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>, Glenn Adams <glenn@skynav.com>, www-style list <www-style@w3.org>
On Fri, Aug 17, 2012 at 12:33 PM, Elliott Sprehn <esprehn@gmail.com> wrote: > On Fri, Aug 17, 2012 at 10:27 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> However, I'm not sure what the problem is in the first place. Nested >> document have their own "window" object, so they'll have their own >> "CSS" object as well. It can return whatever answer is appropriate >> for that document's mode. > > This still feels wrong from a software design perspective. I'm not > asking if CSS supports this feature, I'm asking if /this document/ > supports this CSS feature. While that's a nice argument from theoretical purity, "document.supportsCSS" is way longer than "CSS.supports", while not buying us anything. Worse for authors cancels out marginally better for theoretical purity. > You also create a cyclical relationship between the CSS object and > document. CSS needs to account for the document state to say what is > supported, and document needs to consult the CSS object to decide > what's allowed while parsing. (Not really, but conceptually this is > what's happening). This is a concept wholly invented in your head. It does not reflect reality in any way. The "CSS" object is just a namespacing object to avoid the verbosity that's required when you put things on the global object. ~TJ
Received on Friday, 17 August 2012 20:05:41 UTC