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

Dan Wood dw7904954 at karelia.com
Mon Feb 19 22:43:06 PST 2007


Just to clarify my needs and expectations:



When I type in the following, with _ representing option space:

We use Blammo_2, the Quicker_Picker_Upper, for our tapestry needs  
here in Nova_Scotia.

I want to ensure that the space in those places is explicitly non- 
breaking, meaning that they won't word-wrap.

When typed into TextEdit, resizing the window does the expected --  
those nonbreaking spaces never break.

When typed into Blot (not TOT, but I don't think there's much  
difference), this doesn't happen at all.  The HTML is:

<HTML><HEAD><META http-equiv="Content-Type" content="text/html;  
charset=UTF-8"></HEAD><BODY style="word-wrap: break-word; -khtml-nbsp- 
mode: space; -khtml-line-break: after-white-space; ">We use Blammo 2,  
the Quicker Picker Upper, for our tapestry needs here in Nova  
Scotia.</BODY></HTML>


Note that there is *no* distinction between what I typed as option- 
space and space.  They are all plain spaces.


What I would expect, and hope, to get would be something like this  
(ignoring the special styles):

We use Blammo&nbsp;2, the Quicker&nbsp;Picker&nbsp;Upper, for our  
tapestry needs here in Nova&nbsp;Scotia.




Anything other than this just doesn't make any sense to me!  (IMHO)


Dan


On Feb 19, 2007, at 10:05 PM, Maciej Stachowiak wrote:

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

--
Dan Wood
Karelia Software — Sandvox for the Mac
http://www.karelia.com/

We can have democracy in this country or we can have great wealth  
concentrated in the hands of a few, but we can’t have both. — Supreme  
Court Justice Louis D. Brandeis






More information about the webkit-dev mailing list