- From: Ola Andersson <Ola.Andersson@ikivo.com>
- Date: Fri, 10 Jun 2005 09:43:03 +0200
- 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 UTC