-moz-pre-wrap
rocal...@gmail.com
<div style="white-space:-moz-pre-wrap; font-size:200px;"><span
style="background:yellow;">Hello Kitty</span></div>
When the line breaks, how should the space be treated? Should it be
displayed in yellow at the end of the line? Or should it collapse away
to nothing?
Right now on trunk it is displayed --- until you make the window
narrow enough that the space overflows on the right, then it
disappears. This seems clearly wrong.
Consider also the variant with two spaces. Currently they are both
displayed, and then both disappear.
I kinda lean towards always displaying the spaces, just on the grounds
that preformatted spaces should always be displayed.
Rob
Boris Zbarsky
> I kinda lean towards always displaying the spaces, just on the grounds
> that preformatted spaces should always be displayed.
That would make sense to me, especially if it doesn't break editor in the process.
-Boris
Jonas Sicking
Wouldn't that mean that you could get very ugly margins? Say for markup like
<div style="white-space:-moz-pre-wrap; border: 5px solid black;">
<span style="background:yellow">
Word Word Word Word Word Word...
</span>
</div>
The spaces between the words might overlap into the margin of the div,
and that overlap will vary from row to row. I've seen some editing
programs do this when you select text (i.e. the selected spaces off the
end are rendered) and it looks horrible.
I would suggest we always collapse them instead. I suspect people are
using white-space:pre and white-space:-moz-pre-wrap to get spaces
between words rendered, not spaces at the end of lines.
/ Jonas
Jonas Sicking
looks uglier than if the spaces are collapsed.
/ Jonas
Boris Zbarsky
> I would suggest we always collapse them instead. I suspect people are
> using white-space:pre and white-space:-moz-pre-wrap to get spaces
> between words rendered, not spaces at the end of lines.
Editor depends on spaces at the end of lines being rendered in pre-wrap text to
show the space when you hit the space bar....
-Boris
Jonas Sicking
Ugh, I hate making webpages uglier for the sake of editor. Couldn't
editor add an and then convert that to a space once you type
something.
Alternatively we simply don't draw the background, the cursor will still
get the right position, right?
/ Jonas
Boris Zbarsky
> Ugh, I hate making webpages uglier for the sake of editor. Couldn't
> editor add an and then convert that to a space once you type
> something.
That doesn't behave right wrt wrapping (e.h. hitting space after a word that
fits should NOT wrap it to the next line, which adding an could do).
I suppose we could introduce Yet Another Value for white-space to handle this
case, but....
-Boris
Jonas Sicking
The problem I see is what happens if the user types space and then
nothing more but instead saves the file. If we only render the space in
editor using a special white-space value that means that the file will
look different when the user opens it in the browser.
It seems to me like it's not a terrible idea to not render the space
until the user types characters after the space. But I'm biased :)
/ Jonas
Jonas Sicking
> complaints from the Thunderbird folks. Valid ones, really. It's really
> weird to type like that.
Really? It should only be noticeable when the inline element has a
background since the cursor will move as normal, it's just that spaces
won't get a background until you've typed something after them.
But that could be common enough and look weird enough that it's not an
acceptable solution.
/ Jonas
Boris Zbarsky
> Really? It should only be noticeable when the inline element has a
> background since the cursor will move as normal, it's just that spaces
> won't get a background until you've typed something after them.
Oh, if the cursor moves as normal then it should be fine, sure.
-Boris
rocal...@gmail.com
> Ugh, I hate making webpages uglier for the sake of editor. Couldn't
> editor add an and then convert that to a space once you type
> something.
And I hate making editor trickier because of deficiencies in
layout :-)
Rob
rocal...@gmail.com
> rob...@ocallahan.org wrote:
> > I kinda lean towards always displaying the spaces, just on the grounds
> > that preformatted spaces should always be displayed.
>
> Wouldn't that mean that you could get very ugly margins? Say for markup like
>
> <div style="white-space:-moz-pre-wrap; border: 5px solid black;">
> <span style="background:yellow">
> Word Word Word Word Word Word...
> </span>
> </div>
>
> The spaces between the words might overlap into the margin of the div,
> and that overlap will vary from row to row.
That brings up a related question: with pre and pre-wrap, should we
still be allowing an arbitrary amount of trailing whitespace at the
end of a line, regardless of available width? Or should we break
inside the whitespace and allow whitespace to start the next line? I
think the latter is actually the simplest and most accurate
interpretation of pre-wrap. It would solve this problem with overflow
spaces. It would not solve the issue of spaces at the ends of lines
showing when selected.
I don't much like the solution "don't render the space, but move the
cursor". The question is then does the frame size include the trailing
spaces or not. If it does, then we have a problem with text-
decorations, which are usually painted by container elements --- for
example, suppressing underline on trailing spaces will be difficult.
If it doesn't, then you'll be able to move the caret arbitrarily far
past the visible end of the line by typing, but you won't be able to
click there unless we throw in yet more hackery.
How about this proposal for pre-wrap:
1) spaces are always displayed
2) a run of spaces at the end of the line can be broken in the middle
of the run, allowing spaces to start the next line
3) we only allow a line break after a space, not before (so text with
only one space between each word won't get spaces at the start of
lines)
Then selection will show spaces at the end of lines, but I personally
don't think that's a big deal.
Rob
Boris Zbarsky
> 2) a run of spaces at the end of the line can be broken in the middle
> of the run, allowing spaces to start the next line
I like that conceptually, but it might lead to oddities when people hit the
spacebar twice at the end of a sentence in mailnews near the end of the line...
Similar for textarea rendering and possibly reading plaintext mail.
-Boris
fantasai
CSS2.1 defines this:
http://www.w3.org/TR/CSS21/text.html#q8
Basically, you're allowed to break at the end of sequence of spaces, but
not before. So "word1 word2 " can only break between word1 and word2.
However, the spaces after word2 can be (but do not have to be) "visually
collapsed" to nothing.
I really don't like the idea of collapsing spaces in a plaintext editing
environment. If there are multiple invisible spaces at the end of the line,
they'll appear when the text rewraps to a different width--and that would
often be after the text has been submitted (in a form, via email, etc).
~fantasai
rocal...@gmail.com
> CSS2.1 defines this:
> http://www.w3.org/TR/CSS21/text.html#q8
>
> Basically, you're allowed to break at the end of sequence of spaces, but
> not before. So "word1 word2 " can only break between word1 and word2.
> However, the spaces after word2 can be (but do not have to be) "visually
> collapsed" to nothing.
Good point, thanks. I guess I'll just go ahead and implement that
directly. I think we won't trim trailing pre-wrap spaces.
Rob