Re: SVG12: 'display' trait

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