- From: Jon Barnett <jonbarnett@gmail.com>
- Date: Sun, 2 Dec 2007 12:04:26 -0600
- To: "Arne Johannessen" <arne-list@thaw.de>
- Cc: "Adam van den Hoven" <adam.vandenhoven@gmail.com>, public-html@w3.org
On Dec 1, 2007 6:02 AM, Arne Johannessen <arne-list@thaw.de> wrote: > > Adam van den Hoven wrote: > >>> Karl Dubost wrote: > >>> > >>>> [@style] > >>>> > >>>> [...] we really should find a way to strongly discourage its use > >>>> (and the use of its DOM attribute) for non-WYSIWYG authors. > > > > That's all well and good in theory but I believe that most effects > > libraries rely on node.style.propName to do their thing. [...] > > Droping support for node.style is going to hurt a lot of people. > > I understand the idea was not to remove it from the supported > language, but to remove it from the conforming language -- in other > words, to discourage its use. > > <http://www.w3.org/TR/2007/WD-html-design-principles-20071126/ > #conformance> > I don't think it has ever been the intention to deprecate or remove the .style DOM property. It's a part of the CSSOM specification and really out of scope for HTML 5. The problem is that setting any .style.x properties will change the style="" element when the UA serializes the element. UAs current do this differently: some UAs use shortcut properties such as "border" and some will serialize without shortcut properties by using "border-left-width", "border-left-color" etc. (I don't think the differences in serialization are a big problem in practice, though I think they could cause some strange cascading issues... I'm digressing...) Removing @style leaves the serialization of .style undefined. It's important that changes to .style.x properties be serializable. Our solution should take that into account. If we use <style scoped>, one solution would for the UA to generate a serializable rule in the nearest <style> element, and that rule must uniquely select the given element. If the element doesn't have an ID, then I guess you'd have to generate one. It's not elegant. If we extend the @style attribute, this isn't really a problem - setting .style.x properties can be serialized the same way they are today. One issue might be how @style's new syntax affects the .style property, if at all, but I think that can be done in a backward-compatible way. -- Jon Barnett
Received on Sunday, 2 December 2007 18:04:44 UTC