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

On Jan 2, 2006, at 12:50 PM, Doug Schepers wrote:

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

I'm not equating it, just trying to understant what the spec is  
requiring.

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

It would be great for the diagonal text case. But what if you  
positioned the glyphs so the word runs upwards:

t
n
e
m
u
c
o
D

In the obvious implemenation, back-arrow would go down a line, and  
forward-arrow would go up a line, which would be pretty bizzarre. In  
fact, I can't even figure out where you would draw the caret in such  
a situation.


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

Most HTML UAs also have html editing support, where rich markup can  
be edited. But HTML doesn't have per-character positioning, you would  
have to put each character in a separate positioned element to  
achieve the effect you mention.

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

It's been longstanding HI design practice that for dialogs or things  
like them, "Enter" means "activate the default button". It might make  
sense as a default, even if it is possible to override it with an  
event handler.

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

There are some bad HTML editors where a second space either has no  
effect or complains at you. But Safari's HTML editing properly enters  
a second space, regardless of what the surrounding whitespace mode is.

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

Well, editing is already allowed to put you in a mode where this is  
effectively the case. Out-of-line editing seems pretty lame to me,  
and out of scope of the spec; it is achievable with pure DOM APIs if  
you really want it. And inline editing should only be specified in  
cases where the behavior can be sensible.

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

Actually, 'simple' bugs me, as it implies there is some other  
'complex' mode coming and the two would have to offer different sets  
of capabilities. I do not think adding complexity would address my  
concerns however, which are the editing behavior is either  
underspecified or specified in a way that requires a bad user  
experience in some cases.

Regards,
Maciej

Received on Tuesday, 31 January 2006 07:55:56 UTC