- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 30 Jan 2006 22:21:41 -0800
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: www-svg@w3.org
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