- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 2 Jul 2013 01:44:29 -0700 (PDT)
- To: www-style list <www-style@w3.org>
Tab Atkins wrote:
> 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.)
Based on a brief discussion with Cam regarding the new [MapClass]
thingy in WebIDL, I put together this first attempt at the sort of
CSSFontFeatureValuesRule definition Tab was asking for:
[MapClass(DOMString, long)]
interface FontFeatureMapSingle {
long get(DOMString valueName);
boolean has(DOMString valueName);
void set(DOMString valueName, long value);
boolean delete(DOMString valueName);
}
[MapClass(DOMString, sequence<long>)]
interface FontFeatureMapMulti {
sequence<long> get(DOMString valueName);
boolean has(DOMString valueName);
void set(DOMString valueName, sequence<long> values);
boolean delete(DOMString valueName);
}
interface CSSFontFeatureValuesRule {
attribute DOMString familyList; /* font family list */
attribute FontFeatureMapSingle stylistic;
attribute FontFeatureMapMulti styleset;
attribute FontFeatureMapMulti characterVariant;
attribute FontFeatureMapSingle swash;
attribute FontFeatureMapSingle ornaments;
attribute FontFeatureMapSingle annotation;
}
The 'styleset' and 'character-variant' values for
'font-variant-alternates' take *multiple* values, while the other
values only use a single value. Thus the map associated with each of
these values reflects that.
The error handling here is a bit tricky (dodgy?). For the
'character-variant' value only two values are permitted, so what
should happen with 'rule.characterVariant.set("blah", [1, 2, 3])'?
Thoughts? I should note that I'd be just as happy with "no OM at this
level" but others in the group seem to want a more fully sketched out
OM.
Regards,
John Daggett
Received on Tuesday, 2 July 2013 08:44:56 UTC