Inline Edit: Blanks -- initial, embedded, and trailing
Justin
justin.obara at utoronto.ca
Tue Jul 22 14:05:03 UTC 2008
Hi Paul,
I've noticed this behaviour as well. It doesn't appear that this is
part of the intended behaviour, so I filed them as bugs. (bugs listed
at the bottom of message)
There has been some discussion about what to do with newline
characters, whether to accept it or ignore it. I'm not sure if this
should follow the same line of thought or not, as the user may have
entered those spaces to adjust presentation.
As for the field not displaying the full line of text, I would assume
this is a bug as well. The user should be able to see the whole line.
That being said, maybe there should be a standard fixed length that
the editable field displays, rather than adjusting to the length of
text currently displayed. For now I'll file it as a bug.
Fluid-887:
http://issues.fluidproject.org/browse/FLUID-887
Fluid-886:
http://issues.fluidproject.org/browse/FLUID-886
Fluid-972:
http://issues.fluidproject.org/browse/FLUID-972
- Justin
On 22-Jul-08, at 9:08 AM, fluid-work-request at fluidproject.org wrote:
> From: Paul Zablosky <Paul.Zablosky at ubc.ca>
> Date: July 21, 2008 8:05:39 PM GMT-04:00
> To: "fluid-work at fluidproject.org" <fluid-work at fluidproject.org>
> Subject: Inline Edit: Blanks -- initial, embedded, and trailing
>
>
> I've been trying to get a feeling for how the Inline Edit demo
> handles multiple blanks in text.
>
> If I edit a field containing:
> |The value is close to X|
> and I change it to:
> |The value is X|
>
> then when I complete the edit, what I see displayed is:
> |The value is X|
>
> So it looks like multiple blanks get compressed out. But have I
> changed the value of the stored field or not? It's hard to tell.
>
> When I go back and edit the field again, I see:
> |The value is |
>
> This is a surprise. What happened to the X? If I scroll the field
> over with the arrow key, I find that the blanks and the X are still
> there, but hidden because the width of the box in which the string
> is displayed is compressed textwidth.
>
> A couple of questions:
> Is the trimming and compressing of blanks part of the intended
> behaviour of the component?
> Shouldn't the width of the edit box be the same as the editable text
> width?
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080722/c407ba3d/attachment.html>