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

On Thu, May 30, 2013 at 12:07 AM, John Daggett <jdaggett@mozilla.com> wrote:
> 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).

We definitely need better consistency in our OM-related APIs.  I'm
trying to forge these kinds of rules for that very purpose.  ^_^

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

Readonly-ness when not necessary is kinda terrible - it doesn't
restrict authors from making changes, it just makes it much less
convenient.  They have to instead create a string for the altered
rule, remove the old rule, and insert the new rule.

Yes, that means CSSCounterStyleRule is wrong.  So sue me, I wrote it a
long time ago.  ^_^  I'll go fix it today.

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

The problem is that you're suggesting that it's not even *readable*,
except through getting a serialized version and reparsing it yourself.
 That's just silly.

Making things readable doesn't *necessarily* mean that it needs to
expose thing via nested rules, of course.  In fact, slavishly
reflecting the input syntax in the OM tree is often an anti-pattern -
it's easy, but often has terrible usability.  I'd be happy to explore
alternate ways of readably exposing the information.  For example, it
could look something like (using pseudo-WebIDL, because I don't want
to worry too hard about the right syntax for some of this):

interface CSSFontFeatureValuesRule {
  attribute Arraylike<DOMString> familyList; /* An array of family
name strings. */
  attribute Maplike<DOMString, DOMString> swash; /* A map of feature
names -> feature values */
  attribute Maplike<DOMString, DOMString> styleset; /* Ditto */
  attribute Maplike<DOMString, DOMString> ornaments; /* Ditto */
  ...
}

Where Arraylike<> is whatever the right way is to define an Array in
WebIDL, and Maplike<> is the same but for Maps.  (I started a thread
yesterday in public-webapps about defining something for "map-like"
interfaces in webidl.)

Would this satisfy you better?  I think I like it better than using
nested interfaces.  It does mean that we lose some syntax details (two
@swash rules get merged undetectably into the .swash map), but that's
likely okay.  Interestingly, it doesn't prevent us from extending
@swash/etc in the future by nesting more at-rules inside of them (even
if you never think we'll do it, our usage here is precedent for more
interfaces in the future), because we can always add a .childRules
attribute to the .swash map.

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

As Simon said in another thread, this is just because he hasn't gotten
around to defining it yet.  It's in the plans to add such a thing.

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

It's all the difference in the world if you actually want to inspect
or alter the stylesheet with JS without jumping through a bunch of
ridiculous parsing hoops.

~TJ

Received on Thursday, 30 May 2013 18:25:55 UTC