[webkit-dev] Should editable webkit accept option space to insert non-breaking space?

Maciej Stachowiak mjs at apple.com
Mon Feb 19 22:05:27 PST 2007


On Feb 19, 2007, at 9:49 PM, Rob Burns wrote:

>
> On Feb 19, 2007, at 11:30 PM, Maciej Stachowiak wrote:
>
>>
>> On Feb 19, 2007, at 9:04 PM, Dan Wood wrote:
>>
>>> Running blot, it appears that editable divs in webkit treat  
>>> option-space as a regular space, not as a non-breaking space.  I  
>>> can't believe this could have been neglected, so maybe it's not a  
>>> bug?
>>>
>>> Personally, I'd like to be able to insert non-breaking spaces,  
>>> since it would mirror other text fields.
>>>
>>> Any thoughts?  Should I file a bug?
>>
>> I think the reason this is done is because we use a sequence of  
>> alternating normal spaces and non-breaking spaces, plus some  
>> special WebKit-specific CSS properties, to achieve desired  
>> whitespace behavior. We want multiple spaces to show up in the  
>> middle of a line, but collapse away at the end, as in normal text  
>> editors.
>>
>> In WebKit-based clients, like Safari or Mail, we can get the  
>> display to be just right, using a special CSS property. In other  
>> clients, we want decent fallback. The closest you can get is  
>> alternating space / nbsp, which preserves the multiple spaces but  
>> will break in the middle if needed.
>>
>> An alternate design for this that still allowed entering true non- 
>> breaking spaces would be welcome - we could not figure out how  
>> last time we thought about this.
>
>
> Perhaps I'm not understanding this correctly, but the alternating  
> of non-breaking spaces with spaces should not prevent the  
> deliberate insertion of a non-breaking space. If a user is actually  
> hodling down the option key while typing space, the editor should  
> insert a non-breaking space. While this could create rendering  
> problems, that would just be the result of a user intentionally  
> putting in too many non-breaking space. The user would be aware of  
> what caused the problem. It's often necessary to deliberate use non- 
> breaking spaces. The Cocoa text system allows this. For example, if  
> I'm trying to prevent a runt at the end of paragraph I might want  
> to type <option>-<space> before the final word of a paragraph.
>
> The alternating space non-break-space prevents the usual HTML/XML  
> treatment of whitespace by collapsing multiple consecutive spaces  
> into one space. Again, nothing should prevent WebKit from allowing  
> users to intentionally insert a non-break-space.


The problems are:

1) WebKit's special property for these space / nbsp sequences makes  
it treat both the same, so the literal non-breaking space would still  
be treated by layout the space as a normal space.

2) WebKit reformats whitespace as you edit (deleting or inserting  
spaces) to preserve alternating space/nbsp sequences, this would  
smash any directly user-entered non-breaking spaces.

3) If you are in the middle of one of these space/nbsp sequences,  
inserted a non-breaking space directly will not do what you expect.  
you will be making a bigger cluster of non-breaking spaces than you  
think.

I'm sure it's possible to make it all work as desired but I suspect  
it would be pretty complicated.

Regards,
Maciej




More information about the webkit-dev mailing list