Re: SVG12: textArea vs xml:space

bulia byak wrote:
> On 4/17/05, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>>  In http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/text.html it is
>>proposed that text and textArea element imply xml:space="preserved" when
>>they are editable. This is a poor proposal as it is guranteed to yield
>>in undesired side-effects. Authors would have to be careful to include
>>white-space in a way that does not yield in unreasonable rendering, and,
>>probably worse, dynamically making an element (un)editable would likely
>>cause strange changes to the text. To prevent this, authors would have
>>to use xml:space="preserve" themselves in which case this inconsistent
>>default is useless anyway. Please change the draft such that this re-
>>quirement is removed and that it is clearly pointed out why authors
>>might want to set xml:space="preserve".
> 
> I second this. It's never a good idea to selectively override the
> standard expected behavior, especially if it  is defined outside of
> SVG (as is xml:space). So please remove this requirement.

I believe you are referring to the text which says "if a text or 
textArea element is editable, then the SVG user agent must preserve 
whitespace conforming to the SVG language defined behavior for 
xml:space="preserve" even if the given element has 'xml:space' has a 
value of "default"."

The intention there is not to override xml:space's behaviour and 
definition, as all that is describe here happens post-parsing. SVG 
describes how

  a) it is expected to *render* text depending on the value of xml:space
     (higher up in the document), including how that integrates with the
     editable attributes; and
  b) how it is expected to handle text when an editable text element is
     modified, for which the rendering is as if xml:space was set to
     preserve.

This is similar to a DOM Text node which you add somewhere and that will 
not normally take xml:space into account when inserted into the tree. 
The text could be clarified in this respect but it certainly has no 
intention of changing the behaviour of xml:space as (under)specified 
elsewhere.

-- 
Robin Berjon
   Research Scientist
   Expway, http://expway.com/

Received on Monday, 18 April 2005 12:25:45 UTC