W3C home > Mailing lists > Public > www-style@w3.org > September 2012

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

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 18 Sep 2012 21:40:02 +0800
Message-ID: <CACQ=j+cxji-pcLBEMDwN1BKFS8rD4ODcnGKat8fueucxnoBhyQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
On Tue, Sep 18, 2012 at 9:18 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Sep 18, 2012 at 3:05 PM, Glenn Adams <glenn@skynav.com> wrote:
> > On Tue, Sep 18, 2012 at 8:12 PM, John Daggett <jdaggett@mozilla.com>
> wrote:
> >> This seems okay to some degree, I just wonder if it's not a little bit
> of
> >> overkill.  Why the need for getter/setter *and*
> >> getDescriptor/setDescriptor?
> >> That almost seems java-esque.
> >
> > It depends on whether we want to only support the camel cased domain of
> > descriptor names, call it D(CC), or we want to support both D(CC) and the
> > original hyphenated domain (as found in stylesheet) of descriptor names,
> > call it D(HY). If we want both, then we need to have different flavors of
> > getters/setters which make clear which domain they operate with. If we
> want
> > only D(CC), then we won't need both.
> >
> > E.g., which of the following do you wish to work?
> >
> > (1) descriptors['unicode-range']
> > (2) descriptors.unicodeRange
> > (3) both (1) and (2)
>
> (2) is a necessity - it's what people are used to when working with
> the 'style' DOM property, and it's quite natural to want to keep using
> that.
>
> I have no strong opinion on whether we want (3) or not.  It seems
> convenient to authors to support both of them.
>
> I agree with Boris that this is orthogonal to whether we have a named
> getter/setter (the get() and set() functions in your example) or the
> getDescriptor/setDescriptor functions.  These all seem unnecessary.
> WebIDL already has the point that languages which don't support
> getters/setters must expose the functionality in some standard way.
> We should consider the getProperty/setProperty pair from
> CSSStyleDeclaration as a legacy mistake.
>

I wouldn't mind eliminating option (1) above, i.e.,
descriptors['unicode-range'], and its functional counterpart, for which I
suggested get/setDescriptor above (as counterpart to the legacy
getPropertyValue/setProperty). If we eliminate this, then we only have left
the D(CC), i.e., camel-cased descriptor name domain, and we can define
generic get/set on CSSDescriptors to support it. We can also define a
forwarding get/set on CSSFontFaceRule as I suggested above as a short cut,
i.e., rule.unicodeRange as shorthand for rule.descriptors.unicodeRange, or,
in more long-hand terms:

rule.unicodeRange =>
  rule.get('unicodeRange') =>
    rule.descriptors.get('unicodeRange')

is same as

rule.descriptors.unicodeRange =>
  rule.descriptors.get('unicodeRange')

Doing this, we would have no such thing as descriptors['unicode-range'] or
descriptors.getDescriptor('unicode-range'). I can certainly accept that.
Received on Tuesday, 18 September 2012 13:40:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:00 GMT