RE: SVG12: 'display' trait

Hi Björn,
You're correct, we do not require implementations to normalize and therefore we should allow all display values to be accessible through traits.

So getTrait can return:
inline | block | list-item |
run-in | compact | marker |
table | inline-table | table-row-group | table-header-group |
table-footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none 

And setTrait:
inline | block | list-item |
run-in | compact | marker |
table | inline-table | table-row-group | table-header-group |
table-footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none | inherit

Comments: In an SVG context many of the possible display values are resulting in the same behavior. Therefore the user should be aware that an SVG Tiny implementation often will normalize the display value to 'inline' or 'none' and the originally specified display value (e.g. table-row) will be lost.    

I've not done these changes yet in the spec but if you approve to them I'll go ahead. I've come to realize that it's better to have your approval *before* doing the editing ;-)
/ola



> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> Sent: den 7 juni 2005 12:35
> To: Ola Andersson
> Cc: www-svg@w3.org; WG SVG
> Subject: Re: SVG12: 'display' trait
> 
> * Ola Andersson wrote:
> >We've now added the following wording to the 'display' trait
> >description:
> >
> >The table [referring to the 'display' entry in the table that
> >you referred to] shows the recommended values in the SVG context.
> >However, the list of values that can be set is the same as the
> >list of valid values for the 'display' property in markup (see
> >the Controlling visibility section). In the SVG context, the
> >returned value for 'display' is limited to 'inline' and 'none'
> >because implementations further normalize the computed value.
> 
> Where does the draft require implementations to normalize computed
> property values? The draft does allow implementations to normalize
> attribute values so e.g.
> 
>   <g fill="red"> and <g fill="#ff0000">
> 
> may be considered equivalent for all purposes of SVG processing
> (even though that's not really well-defined in the draft) but I
> could not find the requirement the new text refers to. The
> getAttributeNS() method does not operate on this value space, so
> do I understand correctly that even if getTrait behaves as you
> describe, for
> 
>   <g display="block">
> 
> getAttributeNS(null, "display") would return "block" and "block"
> is the computed (base) property value? Are there other properties
> for which the computed value is "normalized"?
> --
> 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 Wednesday, 8 June 2005 07:06:32 UTC