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

Hi, Maciej-

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

No offense, but I think you are too strongly equating SVG with HTML, and in
particular with traditional HTML-designed interfaces. Off the top of my
head, I can think of several pragmatic examples of positioned characters
that it would be unintuitive to break apart as editable entities:
a) A word or phrase that is written diagonally down and across the page,
such as might be part of an advertisement or artistic expression;
b) Text in a comic-strip voice bubble where the glyphs are oddly distributed
to reflect the speaker being in an earthquake ("shaken up");
c) Individual notes in a editable musical score, which are up and down the
scale and broken up over several lines.

I could think of more, but I think that gets my point across. Those first
two may not seem to be common cases for editability, but they are in fact
based on requirements I've had for actual mechanisms requested by clients
(abstracted a bit to protect IP). Interactions in SVG are not necessarily as
linear as in HTML, where text input is primarily form-based.  


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

Depending on if I'm doing a form in SVG, or something eclectic, I would say
it fits very well or poorly. This is why I think it should be controllable
by the author (like other dynamic interactions in SVG), not built into the
UA.

<rant>
The legacy of combining 'newline' with 'submit' is bizarre at best. If I had
my druthers, the 'caps lock' key (an almost-useless key with a undeservedly
prominent size and position on the keyboard) would be replaced with a 'new
line' key, but that just ain't gonna happen. ;)
</rant>


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

Yeah, I kinda have to agree, but that particular one would not be
unprecedented.


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

I don't think this really solves the problem, and would introduce
unnecessary comlexity to the Spec. As an author, I would only be frustrated
if there were yet another text element, which I could not style or wrap or
fit to a path, and which was not interchangeable with other text elements.
If these abilities were added to it, then we would be back where we started.


While I maintain that my solution is superior to the proposed
attribute-based editibility, I do applaud the use of the value keyword
'simple' to allow for more complex editing abilities in the future, which
addresses your concern.
 

Regards-
Doug

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

Received on Monday, 2 January 2006 20:50:23 UTC