Re: [css3-fonts][cssom] CSSFontFeatureValuesRule vs. CSSKeyframesRule

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.

Maybe it's a good idea to generalize our model of @-rules like this
but there isn't really any such consistency in our current set of
OM-related API's (both in the OM spec and included all the various
tidbits sprinkled around in individual specs).

The problem with this line of reasoning is that it doesn't
differentiate between nuggets of syntax that only live within a single
given @-rule and *not* contain other rules (e.g. @font-feature-values)
and rules intended to contain other rules such as @supports or @media.

> >> > 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.

We have *lots* of existing OM interfaces with readonly fields. Doesn't
the same argument apply to the fields of CSSCounterStyleRule, which
are all marked as read-only? :P

Part of the problem here is that there's very little implementation
support for editable members of CSSRule objects.  The 'cssText' member
of CSSRule is *not* marked as read-only, yet most implementations make
it read-only.  Hence my reluctance to add elaborate nested rule OM
API's for stuff that is unlikely to be used that frequently.

I was hoping Anne would comment, since I know he definitely thinks the
CSSRule classes are a bit of a waste of time since they aren't used
very much at all.

> 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.

This applies to all @-rules with no defined OM.  Look at css-page,
@page is defined with a slew of @-rule thingies, each of which would
seem to require a new CSSRule subtype and a clear OM definition, yet
there's no such definition.

The practical difference between a class with familyList and
valuesList and one without is very, very small.

Cheers,

John Daggett

Received on Thursday, 30 May 2013 07:07:56 UTC