You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Graham Sanderson <gr...@lombardisoftware.com> on 2005/10/12 04:59:16 UTC
Custom elements and the "style" attribute
I have an SVG with embedded custom elements which are used by javascript
within the SVG. These custom elements happen to have style attributes
with custom styles defined.
When using Batik 1.6, the style.getProperty(name) method and indeed
other style methods only return data for any style property names which
are known to Batik.
>From the CSSStyleDeclaration documentation:
"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."
Batik does not appear to do this; am I missing something? I can parse
the style in JS myself for now but I have to use the "style" attribute
value, since style.cssText also only includes property names known to
Batik.
Thanks
Graham.
P.S. moving the style properties onto real node attributes would be much
more work in this case than parsing the style attribute in JS.
Re: Custom elements and the "style" attribute
Posted by th...@kodak.com.
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 <ro...@expway.fr> wrote on 10/12/2005 09:47:29 AM:
> Hi Thomas, all,
>
> thomas.deweese@kodak.com wrote:
> > Robin Berjon <ro...@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
Re: Custom elements and the "style" attribute
Posted by Robin Berjon <ro...@expway.fr>.
Hi Thomas, all,
thomas.deweese@kodak.com wrote:
> Robin Berjon <ro...@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
Re: Custom elements and the "style" attribute
Posted by th...@kodak.com.
Hi all,
One other thing I ment to mention:
Robin Berjon <ro...@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.
thomas.deweese@kodak.com wrote on 10/12/2005 08:16:22 AM:
> Hi all,
>
> I don't consider the two contradictory at all. CSS 2 says that
we
> should treat
> the stylesheet as if the style sheet was missing the unknown properties.
> The
> CSSStyleDec says that we should report all the specified properties.
This
> does
> would not include the 'unknown' properties since CSS 2 says that we
_must_
> ignore
> them.
>
> Including would also open a huge can of worms. What is the
> computed value
> of an unknown property? What is the 'default' value of an unknown
> property? Is the
> unknown property inherited? Is the unknown property a short-hand for
other
> properties?
>
> These are all cases where an implementation that tries to 'fake
> it' will
> behave grossly different from an implementation that knows about the
> property.
>
> CSS can not function properly without understanding a property,
> which is why
> the correctly indicate that unknown properties are to be ignored.
>
>
> > Cameron McCormack wrote:
> > > That's interesting, since CSS 2 states[1]:
> > >
> > > To ensure that new properties and new values for existing
properties
> > > can be added in the future, user agents are required to obey the
> > > following rules when they encounter the following scenarios:
> > >
> > > * Unknown properties. User agents must ignore a declaration
with
> > > an unknown property. For example, if the style sheet is:
> > >
> > > H1 { color: red; rotation: 70minutes }
> > >
> > > the user agent will treat this as if the style sheet had
been
> > >
> > > H1 { color: red }
> > >
> > > This seems to contradict what's said in DOM 2 Style. Certainly
> Batik's
> > > CSS engine currently doesn't store any non-SVG CSS properties at the
> > > moment.
>
> Robin Berjon <ro...@expway.fr> wrote on 10/12/2005 06:30:45 AM:
>
> > I think this is due to a difference in what is meant by "ignore". For
> > purposes of actually styling a tree (which is what the CSS spec
concerns
>
> > itself with) indeed unknown properties must be ignored. 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.
> >
> > The SVG WG went through this discussion a while back, with input from
> > the CSS WG, and concluded on the above. This never translated into any
> > document since it would concern SVG Full 1.2 and since it's not clear
> > that such prose needs to be in our docs, and it's not clear if the CSS
> > WG has consensus or not.
> >
> > I think this would be well worth a last call comment on CSS 2.1 (which
> > has the same language) to get the CSS WG to clarify.
> >
> > --
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Custom elements and the "style" attribute
Posted by th...@kodak.com.
Hi all,
I don't consider the two contradictory at all. CSS 2 says that we
should treat
the stylesheet as if the style sheet was missing the unknown properties.
The
CSSStyleDec says that we should report all the specified properties. This
does
would not include the 'unknown' properties since CSS 2 says that we _must_
ignore
them.
Including would also open a huge can of worms. What is the
computed value
of an unknown property? What is the 'default' value of an unknown
property? Is the
unknown property inherited? Is the unknown property a short-hand for other
properties?
These are all cases where an implementation that tries to 'fake
it' will
behave grossly different from an implementation that knows about the
property.
CSS can not function properly without understanding a property,
which is why
the correctly indicate that unknown properties are to be ignored.
> Cameron McCormack wrote:
> > That's interesting, since CSS 2 states[1]:
> >
> > To ensure that new properties and new values for existing properties
> > can be added in the future, user agents are required to obey the
> > following rules when they encounter the following scenarios:
> >
> > * Unknown properties. User agents must ignore a declaration with
> > an unknown property. For example, if the style sheet is:
> >
> > H1 { color: red; rotation: 70minutes }
> >
> > the user agent will treat this as if the style sheet had been
> >
> > H1 { color: red }
> >
> > This seems to contradict what's said in DOM 2 Style. Certainly
Batik's
> > CSS engine currently doesn't store any non-SVG CSS properties at the
> > moment.
Robin Berjon <ro...@expway.fr> wrote on 10/12/2005 06:30:45 AM:
> I think this is due to a difference in what is meant by "ignore". For
> purposes of actually styling a tree (which is what the CSS spec concerns
> itself with) indeed unknown properties must be ignored. 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.
>
> The SVG WG went through this discussion a while back, with input from
> the CSS WG, and concluded on the above. This never translated into any
> document since it would concern SVG Full 1.2 and since it's not clear
> that such prose needs to be in our docs, and it's not clear if the CSS
> WG has consensus or not.
>
> I think this would be well worth a last call comment on CSS 2.1 (which
> has the same language) to get the CSS WG to clarify.
>
> --
> 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
Re: Custom elements and the "style" attribute
Posted by Robin Berjon <ro...@expway.fr>.
Cameron McCormack wrote:
> That's interesting, since CSS 2 states[1]:
>
> To ensure that new properties and new values for existing properties
> can be added in the future, user agents are required to obey the
> following rules when they encounter the following scenarios:
>
> * Unknown properties. User agents must ignore a declaration with
> an unknown property. For example, if the style sheet is:
>
> H1 { color: red; rotation: 70minutes }
>
> the user agent will treat this as if the style sheet had been
>
> H1 { color: red }
>
> This seems to contradict what's said in DOM 2 Style. Certainly Batik's
> CSS engine currently doesn't store any non-SVG CSS properties at the
> moment.
I think this is due to a difference in what is meant by "ignore". For
purposes of actually styling a tree (which is what the CSS spec concerns
itself with) indeed unknown properties must be ignored. 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.
The SVG WG went through this discussion a while back, with input from
the CSS WG, and concluded on the above. This never translated into any
document since it would concern SVG Full 1.2 and since it's not clear
that such prose needs to be in our docs, and it's not clear if the CSS
WG has consensus or not.
I think this would be well worth a last call comment on CSS 2.1 (which
has the same language) to get the CSS WG to clarify.
--
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
Re: Custom elements and the "style" attribute
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
Graham Sanderson:
> From the CSSStyleDeclaration documentation:
>
>
>
> "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."
That's interesting, since CSS 2 states[1]:
In some cases, user agents must ignore part of an illegal style sheet.
This specification defines ignore to mean that the user agent parses
the illegal part (in order to find its beginning and end), but
otherwise acts as if it had not been there.
To ensure that new properties and new values for existing properties
can be added in the future, user agents are required to obey the
following rules when they encounter the following scenarios:
* Unknown properties. User agents must ignore a declaration with
an unknown property. For example, if the style sheet is:
H1 { color: red; rotation: 70minutes }
the user agent will treat this as if the style sheet had been
H1 { color: red }
This seems to contradict what's said in DOM 2 Style. Certainly Batik's
CSS engine currently doesn't store any non-SVG CSS properties at the
moment.
Cameron
[1] http://www.w3.org/TR/CSS2/syndata.html#parsing-errors
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org