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

On May 10, 2006, at 5:49 AM, Chris Lilley wrote:

> Hello www-svg,
>
> Maciej Stachowiak <mjs@apple.com> 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.
>
> We agree, the intent was not to prevent other editing methods (like
> loading the file into an editor, even) only to indicate when the SVG
> implementation should make text editable and when it should not.
>
> We have reworded this to say that if set to none, SVG editing  
> facilities
> are not provided for the contents of the text or textArea elements.

Sounds good.

>
>> - according to the schema, the default value is "false", but the
>> allowed values are "none" and "simple" according to the text.
> The schema has been corrected.

Thanks.

>>  The
>> text says if the attribute is missing the default value is false:
> This has been corrected as well.

Thanks.

>> - The spec does not make clear whether editing internally styled text
>> (with <tspan>) is allowed, or if so what happens.
> It is allowed, but in SVG Tiny 1.2 with editable="simple" the text is
> flattened so the tspans, and any styling that went with them, is lost.

Upon further reading, I found this requirement in section 10.13,  
"Text selection and clipboard operations". I recommend that it be  
moved to a section that relates to editing, such as 10.12, "10.12  
Editable Text Fields".

> The plan is that another value, like 'rich', will allow rich text
> editing in SVG Full 1.2. This is why we changed from a true/false  
> value.
>
>> - The spec does not make clear what happens when you edit text with
>> individual characters absolutely positioned. Is this supposed to  
>> work?
> It is not clear why this would pose a problem. The layout of the text
> due the the attributes on the element  is independent of editing the
> text content of the element, which can be done by script and which can
> be done declaratively with the editable attribute.

As discussed in followup with Doug Scheppers, it could lead to a very  
weird UI, where pressing right arrow could move the caret left, or  
pressing down arrow could move the caret up. It is also not obvious  
whether the caret should blink after the character before it, or  
before the character after it, if these would be totally different  
screen positions (usually such considerations apply only at soft line  
breaks). This is why I was not sure whether this was intended to be  
allowed.

>> - 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?
>
> Entering a line break character will have the same result as if a line
> break character were inserted into the text content via script.

1) The spec does not appear to say what a textArea element should do  
if the text content contains a newline.  Section 10.10 "Whitespace"  
doesn't say, because it says xml:preserve applies only to the 'text'  
element, not 'textArea'. Section 10.11 "Text in an area" does not  
mention newlines at all. I am not satisfied with saying one behavior  
not defined by the spec should be just like another not defined by  
the spec.

2) Please also consider this as an additional comment: "How should  
newlines that appear in a 'textArea' element be rendered?"

3) If the intent is that newline is always rendered like space in  
textArea elements, the interpretation you give above would result in  
the apparent implied requirement that entering a line break actually  
has the practical effect of entering a space. This is insane user  
interface and not acceptable to me as a requirement.

>> - 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?
>
> xml:space controls whitespace handling during parsing. It has no  
> effect
> on script changes to element content after parsing, and similarly  
> has no
> effect here.

As others have pointed out, this claim appears to be contrary to the  
specification. Section 10.10 "Whitespace" says, regarding xml:space  
processing, "These are behaviors that occur subsequent to XML parsing  
[XML11] and do not affect the contents of the Document Object Model."  
Since this response is founded on an incorrect assumption, I am not  
satisfied with it.

>> In general, editing seems underspecified. It seems like the intent is
>> to provide plain text editing type features,
> right(at least for Tiny)
>
>> but the interaction with
>> the more unusual text styling like absolute positioning is completely
>> unspecified.
> As noted above, this is incorrect.

Your comment doesn't seem to explain the interaction. It covers  
modifying the text content (same for script and UI editability) but  
does not cover such things as how caret navigation should work, how  
selection should work, how inline text input methods that hold  
temporary marked text containing multiple characters should work,  
etc. None of this UI interaction applies to modifying text contents  
by script.

Regards,
Maciej

Received on Thursday, 11 May 2006 07:08:01 UTC