- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 22 Aug 2012 08:56:18 -0700
- To: www-style@w3.org
On 8/22/12 6:47 AM, Stewart Brodie wrote: > Or just leave them there - the priority parameter is already optional, > defaulting to an empty string. The point is that you have to define what happens for the various priority bits for a CSSStyleDeclaration that doesn't do priorities at all. It's not fatal, just extra spec baggage. > Alternatively, is it possible to leave the CSSStyleDeclaration as it is and > say that objects that implement the CSSStyleDeclaration interface must also > implement the appropriate supplemental interface that contains (only) > getters and setters for each of the valid items? I don't believe there's a way to do this in WebIDL, actually. Think about what the prototype chain would look like. Where would the "supplemental" getters and setters live? Unless we move away from using getters/setters here altogether and use a named getter, of course. Which has its own problems, I bet, not least of which is being somewhat slower in implementations. And implementors are not likely to want to make someElement.style.top access slower.... > I think I'd prefer that, as it should not affect web compat at all - even if > there's code out there poking around in CSSStyleDeclaration.prototype or > relying on it stringifying to "[object CSSStyleDeclaration]". Poking CSSStyleDeclaration.prototype is not an issue in either case, as long as we actually make all the relevant bits inherit from CSSStyleDeclaration. If we just care about stringification, we can do that manually if desired: WebIDL allows defining a non-default stringification, so we could make various things that are actually implementing an interface that inherits from CSSStyleDeclaration stringify as if they were implementing CSSStyleDeclaration directly. But is web compat even a concern for the thing hanging off font-face rules, say? How interoperably implemented is that right now? Do websites use it? > I tried getting the CSSStyleDeclaration for a @font-face rule and setting > its 'display' property to 'none' in various browsers. Firefox threw an > exception complaining about something about internal prototypes, Opera > ignored it, and Chrome put it in! So I think that whatever solution is > chosen for @font-face should not affect compatibility, as there isn't any > interoperability at the moment anyway. Indeed. -Boris
Received on Wednesday, 22 August 2012 15:56:48 UTC