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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 18 Sep 2012 15:18:14 +0200
Message-ID: <CAAWBYDDu+JXxkBT39UWDRnj+uPvG3mW-tbuA0HijiRA=pcTB3g@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
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

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.

Received on Tuesday, 18 September 2012 13:19:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:04 UTC