Re: [css-variables] How to spec the OM for vars?

On Fri, Aug 24, 2012 at 6:08 PM, François REMY <fremycompany_pub@yahoo.fr>wrote:

>   I don’t see the point of doing this, as this will make the code slower
> and show no real benefit.
>

speculation


> Implied partial interface is more than enough.
>

i don't like it


>
> Also, don’t forget that the DOM also need to be accessed by non-javascript
> engines such as WYSIWIG ediors and browser wrappers (PhoneGap...) which use
> native C++ (or .NET or something else). Using a g/s interface would be a
> pain for them while using std properties is much easier.
>

it's up to those platforms to optimize a WebIDL binding


>
>
>
>   *From:* Glenn Adams <glenn@skynav.com>
> *Sent:* Friday, August 24, 2012 11:58 AM
> *To:* Boris Zbarsky <bzbarsky@mit.edu>
> *Cc:* Tab Atkins Jr. <jackalmage@gmail.com> ; www-style@w3.org
> *Subject:* Re: [css-variables] How to spec the OM for vars?
>
> On Fri, Aug 24, 2012 at 5:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 8/24/12 2:46 AM, Glenn Adams wrote:
>>
>>> I refer again to the spec maintenance problem of introducing a never
>>> ending series of partial interfaces on CSSStyleDeclaration. You don't
>>> seem to think that's bad, but as a spec writer, I think it should be
>>> avoided if at all possible.
>>>
>>
>> Given that people keep wanting to come up with a better object model for
>> CSS, one where things are exposed as something property-specific and not
>> just a string, it seems like we'll end up there anyway in the end.
>>
>> That said, we could have some global language about the partial
>> interfaces being implied when a property is implemented, if desired...
>
>
> My preference is to retain the explicit property attributes for the
> existing, legacy usage coming from CSS2Properties and use generic prose on
> g/s to handle new properties beyond CSS2Properties (as well as variables).
> I realize this creates an asymmetry of a sort but we need to both serve
> legacy needs (aka CSS2Properties) and serve future extensibility needs
> (which I believe drives towards using g/s).
>