RE: SVG12: 'display' trait

> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> 
> * Jon Ferraiolo wrote:
> >I think you make good points here, particularly the JSR226 compatibility
> >issue and how getTrait/setTrait are different APIs than
> >getAttributeNS/setAttributeNS. (And of course different than any CSS DOM
> >APIs that might be available on the HTML side.) I think it makes sense to
> say:
> 
> getTrait, etc. on properties are defined through reference to DOM Level
> 2 getComputedStyle(), there is no difference in the latest public draft.
> 
> >* getTrait/setTrait on SVG elements only support the keywords 'inline',
> >'none' and 'inherit' (for setTrait only). Because of this, the uDOM
> section
> >should talk about "further normalization" which sometimes goes beyond
> >computed values.
> 
> Let's assume <g display="block"> and <g display="inline"> yield in a
> different computed value for the display property and let's assume that
> getTrait for both cases returns "inline", then
> 
>   g.setTrait('display', g.getTrait('display'));
> 
> would change the computed value to something completely different. Now,
> could you name two other properties where a script as above would change
> the computed value to something completely different aswell? 

No.

> If there
> are no such properties, what's the point of special-casing the 'display'
> property?

To keep the backwards compability with the JSR-226 specification. If allowing all possible display values in get/setTrait breaks JSR-226 we need to keep the spec as is, if not I think we could allow all values. I'm not sure if this particular issue is considered to break compability or not?
The same script doing getTrait("display") running on a JSR viewer and on a tiny1.2 viewer would return different results (inline and block), is this concidered a compability break? 
/ola

> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
> 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
> 

Received on Thursday, 23 June 2005 10:50:05 UTC