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