W3C home > Mailing lists > Public > public-html@w3.org > December 2007

Re: style attribute, only on font?

From: Jon Barnett <jonbarnett@gmail.com>
Date: Sun, 2 Dec 2007 12:04:26 -0600
Message-ID: <bde87dd20712021004p6d6be7d0hf6493d3743068f5e@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:51 UTC