Re: [css3-fonts][cssom] proposal for revised definition of CSSFontFaceRule

On Thu, Sep 13, 2012 at 3:46 PM, John Daggett <jdaggett@mozilla.com> wrote:

>
> I think it might make sense to define a new, simpler interface for
> accessing
> descriptors in @-rules and simply define CSSFontFactRule as an interface
> containing descriptors that implements that interface.
>
>   [NoInterfaceObject] interface DescriptorAccess {
>     DOMString GetDescriptorValue(DOMString descName);
>     void SetDescriptorValue(DOMString descName, DOMString value);
>
>     readonly attribute unsigned long length;
>     DOMString item(unsigned long index);
>   };
>
>   interface CSSFontFaceRule : CSSRule {
>
>     // descriptors
>     attribute DOMString fontFamily;
>     attribute DOMString src;
>     attribute DOMString fontWeight;
>     attribute DOMString fontStyle;
>     attribute DOMString fontStretch;
>     attribute DOMString fontVariant;
>     attribute DOMString fontFeatureSettings;
>     attribute DOMString unicodeRange;
>
>     // load state - whether the font is loaded or not
>     readonly attribute boolean loaded;
>
>   };
>
>   interface CSSFontFaceRule implements DescriptorAccess;
>

In general, I support this direction, though I would suggest some minor
changes and process points:

(1) If we expect this new (descriptor collection) interface to be reused by
different rule types, then it would be best to define in the baseline CSSOM
spec directly;

(2) If we are going to make this change from the existing CSSFontFaceRule
to a new and different definition, then we should define the new
CSSFontFaceRule in CSS3 Fonts to keep it more closely tracking the other
font related interfaces defined there; also, we should be careful to define
the new version so that UAs may continue to support the older, DOM-2 CSS
definition without member name collisions;

(3) I would suggest the new descriptor interface to be defined as follows:

interface CSSDescriptors {
  readonly attribute unsigned long length;
  DOMString item(unsigned long index);
  DOMString getDescriptor(DOMString descriptorName);
  void setDescriptor(DOMString descriptorName, DOMString descriptorValue);
  getter DOMString get(DOMString name);
  setter void set(DOMString name, DOMString value);
  stringifier; // useful to define explicitly (in prose) for supporting an
outer *rule*.cssText
}

and that a new intermediate rule interface type be defined:

interface CSSRuleWithDescriptors : CSSRule {
  readonly attribute CSSDescriptors descriptors;
}

and that CSSFontFaceRule be:

interface CSSFontFaceRule : CSSRuleWithDescriptors {
  getter DOMString get(DOMString name);
  setter void set(DOMString name, DOMString value);
}

where the get/set on CSSFontFaceRule are (defined in spec prose) to forward
to the get/set on the inherited descriptors attribute; so, e.g., if you
have a CSSFontFaceRule *rule*, then

*rule*.unicodeRange is effectively translated to *rule*
.descriptors.get("unicodeRange")

if you want to use the actual (hyphenated) descriptor name (as opposed to
the camel-cased variant used as a named property), then you would use:

*rule*.descriptors.getDescriptor('unicode-range')

in other words, get(P) and getDescriptor(D) operate on different domains, P
being the set of property name  variants, i.e., camelCased descriptor names
(e.g., 'unicodeRange'), and D being the non-camelCased, i.e., hyphenated
(e.g., 'unicode-range') descriptor names, which is an important distinction
we need to maintain;

this approach permits us to help the author by abbreviating the code used
for accessing property names, while at the same time supporting access of
full descriptor names (via an unabbreviated path);

another advantage of this approach is that we don't need to enumerate the
full set of property name variants of descriptor names in the IDL itself,
but can do so in prose in a more general fashion;