Closed
Bug 41865
Opened 24 years ago
Closed 24 years ago
First single space not shown in editor
Categories
(Core :: Layout, defect, P1)
Core
Layout
Tracking
()
VERIFIED
INVALID
M17
People
(Reporter: BenB, Assigned: buster)
Details
(Whiteboard: [dogfood-][nsbeta2+][6/22])
Reproduce: 1. Open Mailnews HTML composer 2. *Type* exactly the following lines: foo foo foo 3. Look at the result as shown in the canvas 4. Do Debug|OutputHTML Actual result: - After 3., you see foo foo foo - After 4., you see in part something like foo<br> foo<br> foo Expected result: Editor's policy is to preserve all spaces the user enters. So, I'd expect - After 3. foo foo foo - After 4. in part foo<br> foo<br> foo Additional comments: I actually found this bug in the Mailnews flowed converter first, where we emulate the editor behaviour. So, I'd be interested in the algorithm you use.
Reporter | ||
Comment 1•24 years ago
|
||
...to fix this bug.
Updated•24 years ago
|
Summary: First single space not shown → First single space not shown in editor
Comment 3•24 years ago
|
||
spaces are preserved. The nbsp is a space, in rendering terms. If we didnt put in the nbsp, html would render the two spaces as one. As for the first space not showing up, this is a new problem, and is a layout problem. The space is there in the content model and should be rendered. assigning to layout. nominating for dogfood. We need this for the editor to work properly.
Comment 4•24 years ago
|
||
cc'ing me
Comment 5•24 years ago
|
||
Reassigning to buster... (Triaging clayton's bug list).
Assignee: clayton → buster
Reporter | ||
Comment 6•24 years ago
|
||
> As for the first space not showing up, this is a new problem, and is a layout
> problem. The space is there in the content model and should be rendered.
I am not an layout master, but I'd expect it *not* to render, because I consider
both "<br>" and " " to be whitespace and thus the space to be collapsed.
Comment 7•24 years ago
|
||
newlines are whitespace. <br> is a break node. text inserted into the editor undergoes a conversion, where newlines are converted to break nodes. So if you type or paste in "foo\n foo\n foo", you get, from a content perspective: <text node "foo"> <br> <text node " foo"> <br> <text node "{nbsp} foo"> where I use {nbsp} to stand for 0xA0 (I think), which is the byte code used by layout for nbsp. If we used actual newline characters instead of break nodes, you wouldn't even see the foo's draw on different lines. Newlines only cause a new line to be started if there is a "white-space: pre" style in force. As it happens, even if there is a pre style in force, we still convert newlines to break nodes; but that's a different story to painful to be recounted here. :-P Anyway, the break node causes any whitespace after it to be significant. That's why we don't need an nbsp prior to the second "foo".
Updated•24 years ago
|
Whiteboard: [dogfood-][nsbeta2+][6/22]
Comment 8•24 years ago
|
||
Not dogfood, but will take fix for nsbeta2 if done by 6/22
I'm not quite with you on this one, Joe. Given this input: foo<br> foo<br> foo Nav4, IE5, and gecko all render the same: foo foo foo and given the input: foo<br> foo<br> foo all 3 render: foo foo foo So I don't see any bug. Gecko is compatible with the 2 main browsers.
Comment 10•24 years ago
|
||
Wow. I wonder if the behavior changed recently. If not I'm absolutely astounded that no one noticed this until now. This is going to complicate the whitespace conversion. Waaah. I can't find anything in the 4.0 spec that addresses this definitively. A <br> node is definitely not whitespace, and it makes no mention of collapsing whitespace to nothing except for at the beginning of a block (like leading whitespace in a <p>). Oh well. Close it out I guess. I'll open a new bug against myself to add to the editor's whitespace logic: considering the presence of <br>s adjacent to other whitespace.
Assignee | ||
Comment 11•24 years ago
|
||
Joe: you say the HTML 4 spec does specify that leading whitespace is compressed to nothing at the beginning of a block. Well, the BODY is a block, so AFAICT we're doing the right thing.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Comment 12•24 years ago
|
||
I agree that layout is doing the right thing, but the space in question is not at the start of a block. It is after a break, which is an inline element. I haven't been able to find any rational in the spec for this behavior, but if everybody's doin' it, it must be good! :-P
Reporter | ||
Comment 13•24 years ago
|
||
jfrancis, IÄm not yet completely sure which argumentation tofollow, but consider
this:
foo<br>
bar
Between <br> and bar, there is whitespace. So, if whitespace after <br> is not
removed, this would have to render as
foo
bar
Propably not what the author intended.
> I'll open a new bug against myself to add to the
> editor's whitespace logic
Please cc me.
Reporter | ||
Comment 14•24 years ago
|
||
my whitespace has been aten. Correct is: [...] this would have to render as foo bar [...]
Comment 16•24 years ago
|
||
Adding keyword to bugs which already show a nsbeta2 triage value in the status whiteboard so the queries don't get screwed up.
Keywords: nsbeta2
You need to log in
before you can comment on or make changes to this bug.
Description
•