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

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.

~TJ

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