Re: SVG12: 'display' trait

On Thursday, June 9, 2005, 10:53:08 AM, Bjoern wrote:


BH> * Ola Andersson wrote:
>>Comments: In an SVG context many of the possible display values are
>>resulting in the same behavior. Therefore the user should be aware
>>that an SVG Tiny implementation often will normalize the display
>>value to 'inline' or 'none' and the originally specified display
>>value (e.g. table-row) will be lost.    

BH> Well, trait getters on properties are essentially defined to return the
BH> computed property value as defined in section 6.7 of the draft; the com-
BH> puted value for display="block" is the specified value "block" so if an
BH> implementation returns "inline" it will either not return the computed
BH> value (which does not seem to be allowed) or the computed value of the
BH> property is "inline" (which is not defined in the draft either).

BH> I do not think SVG Tiny 1.2 should re-define the computed value of the
BH> display property

I agree.

BH> as that would be incompatible with SVG 1.1 and CSS, and I see no
BH> reason for the trait getters to return something but the computed
BH> property value,

They can return normalized values, to reduce the storage requirements.
For SVG, unmixed with any other namespace, the relevant values for
display are 'none' and "NOT none". There is a fairly obvious pressure
therefore, to store this information in one bit.

For a mixed-namespace CDI use case, the computed value of the display
property is certainly important, if the immediate non-SVG child of a
foreignObject element has set display:inherit and the foreignObject has
also set display:inherit. display itself is a non-inherited property.

The root of this is that the display property is heavily overloaded. It
should have been factored into several properties, one of which
determines whether an entire element including any children participates
in the rendering tree at all (SVG uses that) and one or more of which
set whether, in the CSS box model that SVG (and SMIL and MathML and ..)
does not use, whether it is block or inline and also what specific type
it is (that decomposition would also have allowed a more natural way of
describing things like inline blocks, inline tables, and so on without
creating al possible combinations).

BH> that would just make the model more complex
BH> and cause various other problems, so I do not think implementations
BH> should be allowed to return "inline" for display="block".

As the computed value, no. As a normalized value, it does make sense.
But perhaps the trait could instead return a value such as 'not-none' so
as to avoid any confusion with computed values.

BH> As I think the draft does not allow implementations to do that anyway,
BH> your changes to the trait table without the comment above would address
BH> my concern.




-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

Received on Thursday, 9 June 2005 11:47:36 UTC