W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

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

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 31 Jan 2006 08:23:29 +0100
To: Maciej Stachowiak <mjs@apple.com>
Cc: www-svg@w3.org
Message-ID: <mf3ut1pkhsk3aq60rei8mtkbo728t4ji3n@hive.bjoern.hoehrmann.de>

* Maciej Stachowiak wrote:
>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">
>will render as "foobar", not "foo bar", which is something that will  
>be highly surprising to web content authors.

There are many aspects of SVG processing that can't be directly mapped
to CSS idioms, I don't think that's a particular incompatibility. It's
true that this might be surprising in a way, just like it's surprising

  <svg:text xml:space='preserve'>

renders as a single line of text. Maybe it's a good idea to change it
any maybe now is a good time to do it, but I'd rather not say this is
necessary due to some incompatibility with CSS. I note though that
there is some desire that SVG 1.1 and SVG 1.2 content behaves in the
same way and we've already got lots of cases where this isn't so, along
with no documentation of the problems.

>>> 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.

The implication is of course that authors are going to create SVG Tiny
1.2 content that depends on these defaults, so it's likely that we are
going to either have lots of implementations where hasAttribute returns
false and getAttribute something but the empty string or SVG DOMs where
all attributes are always specified.

>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).

Well, we should either deprecate it for all XML content or for no XML
content, having xml:space a little bit deprecated in some cases is not
a good idea.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 31 January 2006 07:22:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC