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

RE: SVG12: 'display' trait

From: Ola Andersson <Ola.Andersson@ikivo.com>
Date: Fri, 10 Jun 2005 09:43:03 +0200
Message-ID: <586AE9F507AF5E4AA45364333D9E2FA201093CE3@sesthsrv02.zoomon.local>
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>, "Jon Ferraiolo" <jon.ferraiolo@adobe.com>
Cc: "Bjoern Hoehrmann" <derhoermi@gmx.net>, <www-svg@w3.org>, "WG SVG" <w3c-svg-wg@w3.org>

Hi Boris,
I'm sorry for not addressing your particular example which I of course
should have done:
<svg:foreignObject>
   <html:html style="display: inherit" />
</svg:foreignObject>

The problem with the spec is that it talks about "further normalize the
computed value" without actually specifying what that is. It should
explicitly say that an SVGT1.2 UA is allowed to map the different
display values (block, compact, marker, ...) to inline since the
different values have no meaning in a pure SVGT viewer. However, *if*
the SVGT1.2 UA also supports other document formats (through
foreignObject), and those formats have the display property (like html),
no mapping (a.k.a. further normalization) of display is allowed in the
UA.
This is not only affecting the traits and should therefore not be in the
traits section, same goes for getAttribute method. This write-up should
probably go in the display definition in the spec. Note that this
behavior with "further normalize" is present on other attributes too,
e.g. path data.

I think the above solution is good because it is backwards compatible
with JSR-226. But I also think the solution is quite ugly and will cause
compability problems between different UAs (script in those supporting
embedded html will need to be different than scripts in those only
supporting svgt). We could do as (I think) you all propose, to require
the SVG UA to distinguish between all the possible display values and
have no notion of "further normalizing". This is the clean solution and
not very expensive to implement (ok, a few more constants but what's
that compared to everything else..). Drawback with that is that it
breaks backwards compability with SVGT1.1 and JSR-226. 

Anyway, I have no strong opinion either way. As a side note I think
Boris' issue actually was a non-issue from the beginning since getTrait
only applies to SVGElement and not to Element so you can never query an
html element for its display trait ;-)

/ola      


> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> Sent: den 9 juni 2005 17:23
> To: Jon Ferraiolo
> Cc: Ola Andersson; Bjoern Hoehrmann; www-svg@w3.org; WG SVG
> Subject: Re: SVG12: 'display' trait
> 
> Jon Ferraiolo wrote:
> > Probably Ola was referring to foreignObject with an xlink:href?
> 
> My initial objection is of course not an issue in that case.  I
> initially brought up foreignObject in the very specific context of it
> having inline content.
> 
> In any case, if the trait is not actually returning the computed value
> then I have no particular opinions what the trait should or should not
> be returning. ;)
> 
> -Boris
Received on Friday, 10 June 2005 07:43:17 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:30 GMT