Re: SVG12: 'display' trait

I agree with various people (Boris? Bjoern?) about consistency with CSS. 
The SVG-t 1.2 spec talks about get[***]Trait() as returning the computed 
value, which matches my memory of WG discussions and coordination 
discussions with the JSR226 EG. Since SVG is using the 'display' property 
from CSS, I believe that the SVG-t 1.2 spec needs to conform to the CSS 
rules for the computed value for the 'display' property and therefore 
getTrait() should return whatever the CSS spec says is the appropriate 
computed value for 'display'. (From 
http://www.w3.org/TR/2004/CR-CSS21-20040225/visuren.html#propdef-display: 
"The computed value is the same as the specified value").

However, I have a warning to content developers. Don't be surprised if 
implementers overlook the fine print and normalize the 'display' property 
into a binary value such that getTrait() returns either 'none' or 'inline' 
after reading the SVG spec and seeing that all values other than 'none' and 
'inherit' are equivalent to 'inline'.

Jon

PS. I just started my stopwatch. I want to see how long it takes before 
someone submits a test case to see if getTrait() on 'display' returns the 
correct original string value. (Not that I am thinking about anyone in 
particular.)

At 11:13 AM 6/9/2005, Bjoern Hoehrmann wrote:

>* Chris Lilley wrote:
> >The point is that
> >
> ><g display="
> >
> >
> >            inline-block
> >
> >
> >
> >
> >            ">
> >
> >Does not have to store, and be able to provide on request, the full
> >glory of all the carriage returns, tabs, and leading and trailing
> >spaces in the attribute value.
>
>SVG Tiny 1.2 does not allow the inline-block value for the display
>attribute and my issue is not about some white space normalization.
>It's clear from the draft that for
>
>   <svg xmlns="http://www.w3.org/2000/svg"
>        baseProfile="tiny"
>        version="1.2">
>     <g display="block" />
>   </svg>
>
>the computed value of the display property is "block", that the
>getTrait method for the "display" on the g element would return
>"block" and that getAttributeNS for the display attribute on the
>same element would return "block".
>
>The only problem is that the trait table suggests that "block"
>will *not* be returned by getTrait. That's incorrect as long as
>the draft is not changed to allow or require different behavior.
>The draft of course should not be changed to this effect.
>--
>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, 9 June 2005 21:49:35 UTC