W3C home > Mailing lists > Public > www-svg@w3.org > December 2005

[SVGMobile12] SVGT12-207: "editable" attribute for text

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 28 Dec 2005 21:03:37 -0700
Message-Id: <EC5A0670-CD68-4A92-81E6-B8520A5E5605@apple.com>
To: www-svg@w3c.org



- Spec says: 'If set to "none" the contents of the text or textArea  
elements must not be editable in place through the user agent.' It  
seems inappropriate to require that the text *must* not be editable,  
even if allowed through other SVG-independent mechanisms such as  
contentEditable, designMode, CSS editability, etc.

- according to the schema, the default value is "false", but the  
allowed values are "none" and "simple" according to the text. The  
text says if the attribute is missing the default value is false: 'If  
no value is given for this attribute, the default value is "false".'  
The spec also does not define any behavior for 'false' so it's  
unclear if it is meant to be the same as 'none'.

- The spec does not make clear whether editing internally styled text  
(with <tspan>) is allowed, or if so what happens.

- The spec does not make clear what happens when you edit text with  
individual characters absolutely positioned. Is this supposed to work?

- The spec does not make clear what happens if the user attempts to  
enter a line break in a <textArea>. Should the UA enter a space?  
Beep? Enter a <tbreak> element? Enter an <html:br> element or wrap  
previous content in an <html:p> (likely behavior for existing editing  
engines in HTML/XML UAs)? Enter a newline which is not collapsed by  
the normal collapsing rules?

- What happens if the user attempts to enter more than one space in a  
row, or leading or trailing space, in xml:space="default" mode?

In general, editing seems underspecified. It seems like the intent is  
to provide plain text editing type features, but the interaction with  
the more unusual text styling like absolute positioning is completely  
unspecified.

If the desire is to provide plain text editing along the lines of  
HTML <input type="text"> and <textarea>, then separate elements  
should be provided for this purpose (or the HTML elements should be  
recommended for use), rather than trying to overload plain text  
editing onto elements used for rich text display. The specification  
for editing behavior in this spec is far too weak to be useful.

Regards,
Maciej
Received on Thursday, 29 December 2005 05:30:17 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:32 GMT