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

On Dec 30, 2005, at 11:54 PM, Doug Schepers wrote:

> | - 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 reasons this struck me as unusual were:

- Typically when you have separately positioned runs of text, users  
tend think of these as separate editable areas
- Combined editing of multiple positioned runs of text not be very  
well reflected in the proposed possible out-of-line editing experience

That's why I specifically asked about this combination.

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

In HTML forms, pressing return in a single-line text input control  
activates the form, which is reasonable UI behavior but I'm not sure  
how well it fits SVG.

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

Good point.

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

I'm not really sure what that language in the spec is intended to  
mean. But I think that would be a pretty poor user experience, to hit  
space and have nothing happen.

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

I think it would be better to have a separate element for just the  
case of simple plain text input because it's hard to come up with a  
workable design that lets you edit internally styled text using only  
plaintext editing facilities. Using a rich text content model makes  
sense for rich text editing, but not so much for plain text editing.

Regards,
Maciej

Received on Monday, 2 January 2006 11:23:36 UTC