RE: SVG12: 'display' trait

Ola,
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/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.

* But getAttributeNS/setAttributeNS and any CSS DOM APIs that might be 
implemented on SVG elements (e.g., in SVG Full implementations that also 
support Tiny) should be compatible with the CSS spec and thus allow 
setAttributeNS('display', 'block') and should return "block" if 
getAttributeNS('display') is specified as the next statement in the script.

Jon

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

Received on Friday, 10 June 2005 19:19:26 UTC