Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace

On Jan 30, 2006, at 7:14 PM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>> I that case, here's some alternate proposals:
>>
>> A) When xml:space is not specified, the document should be preserve
>> all whitespace, and in general act as specified for
>> xml:space="preserve".
>
> You should say what you mean by "preserve", should it be in the DOM,
> should you see it in the rendering, how does it look like, etc.

I mean the behavior of "preserve" as written in my original proposal,  
in other words, it exactly preserves the DOM, and defines the text  
rendering behavior in terms of whitespace properties compatible with  
CSS. I say this because the "default" behavior is particularly weird,  
in that

<text xml:space="default">
foo
bar
</text>

will render as "foobar", not "foo bar", which is something that will  
be highly surprising to web content authors.

>> B) SVG could add a DTD or some other mechanism to set a default value
>> for the attribute.
>
> I gather people dislike when things magically appear in the DOM. On  
> the
> other hand, as I read the SVG Tiny 1.2 draft, getAttributeNS will  
> return
> "default" values whenever attributes are not specified, and  
> hasAttribute
> is not part of the DOM subset, so the people who dislike that might  
> have
> a problem...

I don't have strong feelings about that either way.

>
>> C) If xml:space="default" is defined to not modify the text in the
>> DOM but only apply styling, then there is no need to set a default
>> value or define what any of the values do to parsing.
>
> Yes, xml:space has no effect whatsoever on what's in the DOM. That's
> only a myth spread by the HTML Working Group, as far as I can tell,
> all SVG says is how the attribute affects SVG processing in terms of
> rendering and some APIs.

Great, then it shouldn't be a problem to state this explicitly in the  
spec, and to define xml:space for SVG as a presentational attribute  
in terms of properties (and perhaps deprecate its use as a  
presentational attribute, since having one from a foreign namespace  
is a little weird).

Regards,
Maciej

Received on Tuesday, 31 January 2006 06:21:53 UTC