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

Hi-

Maciej Stachowiak wrote:
| 
| - 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.

While I'm not convinced of the cases cited, I agree that this should be a
'should', not a must. Another example of this is that editability may be
provided via scripting, for whatever reason, rather than by the UA's
inherent capability. Consider also that this may cause confusion as regards
script-based 'dropdowns' where the text value is changed, and the alteration
of 'tref' sources.


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

Clearly, this should be 'none' and 'simple' in all cases (which is much
better than 'true'/'false', a correction I applaud).

Another error in this paragraph [1] regards the 'focusable' value, which
should instead read:

"Whenever the editable attribute is set to 'simple', the focusable attribute
is considered to be set to 'true' [not 'simple'], irrespective of what the
actual value is."


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

True. Depending on the scope of the editable attribute, I should think that
editing a 'tspan' child takes on the styling of that 'tspan', while removing
all characters in that 'tspan' would remove the 'tspan' as well.


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

I don't see why it wouldn't... users can still navigate to the variously
positioned characters in their structural sequence.


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

I agree that the Spec should clarify this. I am of the mind that for
'textArea' elements, a 'tbreak' element should be inserted, while in other
text elements, it should either insert a space or do nothing (not sure
which, though I lean toward inserting a space). 

However, this points out another wrinkle: how is a user supposed to enter a
linebreak, when the Spec allows the 'enter' key to end the text input? This
could be controlled by the author in a more sophisticated mechanism [2].


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

I think that it should only insert a single space, or no leading/trailing
space, since the Spec states that "the text events returned by DOM 3
correspond to the actual text entered (eg the Kanji character, or the Latin
character) and not to the keyboard or mouse gestures needed to produce it".


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

I disagree. As a seasoned author of SVG content, I think that even this
limited text editing facility would be useful.

That being said, I disagree with the approach of having 'editable' as an
attribute, rather than as an SMIL-type element, as I outlined before on this
list (with my rationale and solution) [2]. This is a dynamic interaction,
which is much more suited to the existing style of declarative syntax (that
is, element-based) than the unprecedented introduction of an attribute which
dictates interaction. Furthermore, having an 'textEdit' (or similar) element
would allow for future expandibility of the text-editing facility based on
implementor, author, and user feedback, while an attribute-based scheme is
far more limited in the parameters it could take.  


[1]
http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/text.html#editable-attribu
te
[2] http://lists.w3.org/Archives/Public/www-svg/2005Oct/0052 

Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Saturday, 31 December 2005 07:55:19 UTC