[webkit-dev] Should editable webkit accept option space to insert
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
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 2, the Quicker Picker Upper, for our
tapestry needs here in Nova Scotia.
Anything other than this just doesn't make any sense to me! (IMHO)
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
>>> 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
> I'm sure it's possible to make it all work as desired but I suspect
> it would be pretty complicated.
Karelia Software — Sandvox for the Mac
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