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 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)
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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
