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

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

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Fri, 24 Aug 2012 12:08:44 +0200
Message-ID: <0A7719951B9C41C89F30056F0507F683@FREMYD2>
To: "Glenn Adams" <glenn@skynav.com>, "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, <www-style@w3.org>
I don’t see the point of doing this, as this will make the code slower and show no real benefit. Implied partial interface is more than enough.

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.

From: Glenn Adams 
Sent: Friday, August 24, 2012 11:58 AM
To: Boris Zbarsky 
Cc: Tab Atkins Jr. ; 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).
Received on Friday, 24 August 2012 10:09:05 UTC

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