- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 29 May 2013 08:41:31 -0700
- To: John Daggett <jdaggett@mozilla.com>
- Cc: www-style list <www-style@w3.org>
On Tue, May 28, 2013 at 11:07 PM, John Daggett <jdaggett@mozilla.com> wrote:
> 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.
Something with the syntax of an at-rule is an at-rule. The definition
of an at-rule is literally "a rule that starts with an at-keyword".
There's no way to argue around it - the stuff inside of
@font-feature-values are at-rules. In some of the previous syntax
incarnations, they were qualified rules (rules with selectors).
Regardless, they've always been rules of some kind.
> 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.
No, it's the correct and simple way to represent a rule that contains
other rules, which this manifestly is.
>> > 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.
Why are they readonly? That seems silly, considering you can change
them by, as you say, deleting and reconstituting the rule via an
altered string.
An empty class that nonetheless contains useful information, but uses
it only to serialize itself, is a terrible, terrible API. I'll object
if you try to do that.
~TJ
Received on Wednesday, 29 May 2013 15:42:21 UTC