Mailing-List: contact batik-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: domain of thomas.deweese@kodak.com
 designates 192.232.121.200 as permitted sender)
In-Reply-To: <434D13F1.6090208@expway.fr>
To: batik-dev@xmlgraphics.apache.org
Cc: batik-dev@xmlgraphics.apache.org
Subject: Re: Custom elements and the "style" attribute
MIME-Version: 1.0
Message-ID: 
 <OF0D42AFA0.777D9444-ON85257098.004D59D6-85257098.004EB905@knotes.kodak.com>
From: thomas.deweese@kodak.com
Date: Wed, 12 Oct 2005 10:19:51 -0400
Content-Type: text/plain; charset="US-ASCII"

Hi Robin,

    Either you take my interpretation of the two specs.  I.E. 
CSS2 says that a U/A must ignore unknown properties when 
parsing and hence there are no unknown properties for the 
words in CSSStyleDeclaration to apply to.  Alternately you
must agree that the language in the two specs is fundamentally 
incompatible.   We can not both present and ignore the property
at the same time.


   I would rather think that the CSSStyleDeclaration is making a 
useless statement rather than directly violating the language of 
the spec it is building on.

   Also since this is the interface returned by the 'style' member of
SVGStylable it does effect individual elements (I suspect the situation
is similar in XHTML land as well).

   I don't think any action can be taken on this issue until the CSS/DOM 
WG clarifies the situation.

Robin Berjon <robin.berjon@expway.fr> wrote on 10/12/2005 09:47:29 AM:

> Hi Thomas, all,
> 
> thomas.deweese@kodak.com wrote:
> > Robin Berjon <robin.berjon@expway.fr> wrote:
> >>>However at the level of the DOM, this isn't needed. It's the same 
thing 
> >>>as "ignoring" elements in a namespace you don't know -- you still put 

> >>>them in the DOM.
> > 
> > This is a very poor analogy.  The DOM needs to know nothing about 
> > attributes to behave correctly an attribute is just an attribute and 
> > it has DOMString as it's value. This is not at all the case for CSS 
> > properties, they are complex typed entites, with complex rules about
> > inheritance and default values.
> 
> You may not like my analogy, but it nevertheless is the conformant 
> behaviour required by the CSSStyleDeclaration interface of DOM 2 Style 
> for CSS. It's specified in no uncertain terms:
> 
> """
> While an implementation may not recognize all CSS properties within a 
> CSS declaration block, it is expected to provide access to all specified 

> properties in the style sheet through the CSSStyleDeclaration interface. 

> Furthermore, implementations that support a specific level of CSS should 

> correctly handle CSS shorthand properties for that level. For a further 
> discussion of shorthand properties, see the CSS2Properties interface.
> """
> 
> Yes, implementations that know some properties will behave different 
> from implementation that don't. That's specified normatively. Note that 
> the situation is exactly the same in the approach you advocate: 
> implementations behave differently depending on what they know. At least 

> with the standard behaviour you get the information and can try to 
> handle the situation, whereas if you delete the properties then all is 
lost.
> 
> Note that this is at the CSS declaration level, which is separate from 
> the elements level. Still, letting the end user decide which information 

> is pertinent to her is a sounder approach. Yes you can't inherit and you 

> can't compute, but at least you let someone who knows the problem 
> they're trying to solve much better than you do decide how to best 
> handle the situation.
> 
> -- 
> Robin Berjon
>    Senior Research Scientist
>    Expway, http://expway.com/
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org