- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 28 May 2013 23:07:50 -0700 (PDT)
- To: www-style list <www-style@w3.org>
Tab Atkins wrote:
> > I think the hacky use of CSSStyleDelcaration in the original
> > definition of CSSFontFaceRule in CSS2 [1] should be a cautionary
> > tale, it's a bad idea to smush together objects simply because
> > they have a few fields or methods that overlap.
>
> Yes, but I don't see the relevance of that to here. CSSGroupingRule
> was defined for the sole purpose of providing the necessary APIs for
> rules that contain other rules. Subclassing it isn't hacky, it's
> the intended use.
Rules that contain other rules, but that's *not* really what we have
here, we have a block of value definitions that simply mimic the
syntax of other rules. That's why the use of CSSStyleDelcaration is
related, you're conflating two objects simply because they share part
of an interface.
To give a concrete example:
@font-feature-values Bongo {
@swash { flowing: 1; swishy: 2; }
@styleset { spiked-terminals: 4, stacked-g: 7; }
}
You're saying we should equate '@swash { ... }' with other @-rules,
@page, @media, @font-face, etc., and I'm saying I think that's an ugly
hack just to permit the use of CSSGroupingRule.
> > I think it would be simpler to leave this as an empty class for
> > now, remove the 'familyList' and 'valueText' fields at this level.
> > We can worry about what may or may not be useful once it's used
> > more widely.
>
> That's just weird, and much worse. That means you can see the rule,
> but can't tell what it is, or modify it in any way.
Tab, they are readonly properties in the current draft! The only way they
can be modified is to reconstruct the rule, not much different than having
an empty class that simply implements the ability to serialize itself via
cssText. I fail to see a huge distinction here.
Regards,
John Daggett
Received on Wednesday, 29 May 2013 06:08:21 UTC