- From: Chris Lilley <chris@w3.org>
- Date: Fri, 10 Jun 2005 21:26:26 +0200
- To: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Cc: Ola Andersson <Ola.Andersson@ikivo.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Bjoern Hoehrmann <derhoermi@gmx.net>, <www-svg@w3.org>, WG SVG <w3c-svg-wg@w3.org>
On Friday, June 10, 2005, 9:13:56 PM, Jon wrote: JF> Ola, JF> I think you make good points here, particularly the JSR226 compatibility JF> issue and how getTrait/setTrait are different APIs than JF> getAttributeNS/setAttributeNS. (And of course different than any CSS DOM JF> APIs that might be available on the HTML side.) I think it makes sense to say: JF> * getTrait/setTrait on SVG elements only support the keywords 'inline', JF> 'none' and 'inherit' (for setTrait only). To clarify - inline and none for getTrait, and inline, none and iherit for setTrait. Right? Because if getTrait returns a normalised version of the computed value, then it will never have inherit. JF> Because of this, the uDOM section JF> should talk about "further normalization" which sometimes goes beyond JF> computed values. JF> * But getAttributeNS/setAttributeNS and any CSS DOM APIs that might be JF> implemented on SVG elements (e.g., in SVG Full implementations that also JF> support Tiny) should be compatible with the CSS spec and thus allow JF> setAttributeNS('display', 'block') and should return "block" if JF> getAttributeNS('display') is specified as the next statement in the script. JF> Jon JF> At 12:43 AM 6/10/2005, Ola Andersson wrote: >>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 -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead
Received on Friday, 10 June 2005 19:26:40 UTC