- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 2 Jan 2006 03:22:28 -0800
- To: Doug Schepers <doug@schepers.cc>
- Cc: www-svg@w3c.org
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