W3C home > Mailing lists > Public > www-svg@w3.org > June 2005

Re: SVG12: 'display' trait

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sat, 11 Jun 2005 15:52:18 +0200
To: Jon Ferraiolo <jon.ferraiolo@adobe.com>
Cc: www-svg@w3.org, WG SVG <w3c-svg-wg@w3.org>
Message-ID: <42b2ea69.245936546@smtp.bjoern.hoehrmann.de>

* 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? If there
are no such properties, what's the point of special-casing the 'display'
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 Saturday, 11 June 2005 13:51:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:07 UTC