- From: Doug Schepers <doug@schepers.cc>
- Date: Sat, 31 Dec 2005 02:54:36 -0500
- To: "'Maciej Stachowiak'" <mjs@apple.com>, <www-svg@w3c.org>
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