Inline Edit: Blanks -- initial, embedded, and trailing

Justin justin.obara at
Thu Jul 24 12:28:25 UTC 2008

There is another question here. If you trim the spaces within a field,  
should those spaces  be permanently removed or just displayed removed.  
Currently it removes it in the display but it persists in edit mode.  
This may be more confusing to the user, but it isn't destructive.

Which would be the correct approach?

- Justin

On 23-Jul-08, at 8:19 PM, Allison Bloodworth wrote:

> I agree with Daphne's proposal for the default, and think that these  
> behaviors--trimming spaces a) at the beginning and end of a field  
> and b) trimming extra spaces within a field--should be configurable.  
> I think the big difference in when you would want to do one or the  
> other is when inline edit is being used like Word/a text editor vs.  
> when it's being used to enter a (single) value into a database.  
> Advice on choosing the proper configuration could be part of the  
> design pattern.
> I wouldn't think we'd want to trim multiple tabs or multiple  
> carriage returns by default, as I'm guessing this would only be  
> allowed in the situation where inline edit is being used more like a  
> text editor when users may be using this for formatting.  But is it  
> necessary to have configuration options like this for tabs and  
> carriage returns, too?
> On Jul 23, 2008, at 9:34 AM, Daphne Ogle wrote:
>>>> Anastasia Cheetham wrote:
>>>>> On 21-Jul-08, at 8:05 PM, Paul Zablosky wrote:
>>>>>> A couple of questions:
>>>>>>     • Is the trimming and compressing of blanks part of the  
>>>>>> intended behaviour of the component?
>>>>> The compression of blanks is a side effect of the way HTML works  
>>>>> - if you put a string of spaces into HTML markup, they are  
>>>>> displayed as a single space. If you want what is called a 'non- 
>>>>> breaking space,' you have to use the special character ' '  
>>>>> instead of a regular space character.
>>>>> It's a question for the designers as to what would be the ideal  
>>>>> behaviour when a user enters a string of spaces into the edit  
>>>>> field.
>>> In this case, without know the context, I think we have to take  
>>> the users actions as intentional.   Can people think of scenarios  
>>> where a user likely enters more spaces than they meant to?  We  
>>> could make this configurable.
>>> Eli and I were just discussing this since we had fairly different  
>>> answers to this question (he thought there were rarely times when  
>>> you wouldn't want to trim the spaces).  I keep thinking about Word  
>>> and that we hear quite often from users that they just want this  
>>> stuff to work like if they were working in Word.   Although to  
>>> folks who know HTML markup it seems silly to use spaces to adjust  
>>> presentation but this is how many non-markup folks are left to  
>>> deal.  If there are spaces in the middle of a text string I think  
>>> we need to assume the user is intentionally adding the extra  
>>> spaces.  User intentions become unclear  if there is an extra  
>>> space at the beginning or end of their text because those are hard  
>>> (or impossible) to see.  And apparently extra spaces can be evil  
>>> with data normalization so minimizing those mistakes is  
>>> important.  So, my proposal is keep extra spaces mid text (like  
>>> Paul's original example) and trim extra spaces at the beginning  
>>> and end.
>>> Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> daphne at
>>> cell (510)847-0308
>>> _______________________________________________
>>> fluid-work mailing list
>>> fluid-work at
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> daphne at
>> cell (510)847-0308
> Allison Bloodworth
> Senior User Interaction Designer
> Educational Technology Services
> University of California, Berkeley
> (415) 377-8243
> abloodworth at
> _______________________________________________
> fluid-work mailing list
> fluid-work at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list