Re: SVG12: 'display' trait

At 12:26 PM 6/10/2005, Chris Lilley wrote:
>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.

Yes.

Jon


>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 20:38:21 UTC