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