- From: L. David Baron <dbaron@dbaron.org>
- Date: Fri, 24 Aug 2012 21:11:57 -0700
- To: François REMY <fremycompany_pub@yahoo.fr>
- Cc: Glenn Adams <glenn@skynav.com>, Boris Zbarsky <bzbarsky@mit.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
On Friday 2012-08-24 12:08 +0200, François REMY wrote: > 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. Given that these getters/setters are syntactic sugar for getPropertyValue and setProperty, I'm not that concerned about this. The syntactic sugar is important for JavaScript; in languages where it doesn't make sense they can use getPropertyValue and setProperty. Glenn Adams wrote: > 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). I'm opposed to having an observable distinction between how existing CSS properties are exposed and how new ones are exposed. This seems likely to interfere with techniques that authors use to detect property support in browsers. (I'm fine with variable properties being different since their names aren't known in advance.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Saturday, 25 August 2012 05:27:45 UTC