Re: [cssom] .style on CSSFontFaceRule and CSSPageRule should probably not be CSSStyleDeclarations as that interface is currently defined

Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Aug 21, 2012 at 11:30 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 8/21/12 2:21 PM, Tab Atkins Jr. wrote:
> >> Actually, that seems about right.  Having a common Declaration
> >> interface for the things that use that seems useful, and then
> >> subclassing the interface for each individual use lets you specialize
> >> the list of exposed properties.
> >
> > If we want a common Declaration interface, should it have
> > getPropertyPriority on it?  Should it have a "cssText"?  Should it even
talk
> > about "property"?   Should it have a setProperty that takes a priority
> > argument?
> >
> > I'm OK with the answer being "yes" to all of those, for backwards compat
> > reasons, but it seems like having to define the property priority stuff
> > behavior for various consumers like font-face is a bit annoying.
> 
> Eh, the priority stuff can just no-op by default, and have a real
> meaning on the style='' one.
> 
> However, if it's possible to move the style attribute toward returning
> a sub-interface, then we should be able to just move all of those to
> the sub-interface as well, and define priority-less versions for the
> super-interface, since most extensions will be at-rules with
> descriptors that have no concept of priority.

Or just leave them there - the priority parameter is already optional,
defaulting to an empty string.

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?  Then each place that
returns a CSSStyleDeclaration just states which supplemental interface the
object implements.  The item() and length still need to be implemented
differently for each sub-interface, though.

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]".  Each
supplemental interface can then define its own set of valid names and avoid
confusing people with things that aren't applicable.

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.


-- 
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited

Received on Wednesday, 22 August 2012 13:47:26 UTC