- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Thu, 09 Jun 2005 14:49:18 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>, Chris Lilley <chris@w3.org>
- Cc: www-svg@w3.org, WG SVG <w3c-svg-wg@w3.org>
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