229408 - Extraneous Blank Character Before <br>

Status: RESOLVED DUPLICATE of bug 132561

(Core :: Layout, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007

If a block is defined within the body of a page, the style includes "font-align:
left", and line breaks are forced with the <br> tag, an extra line-break may be
inserted after a line that ends very near the right margin.  

Reproducible: Always

Steps to Reproduce:
1.  Go to cited page.  
2.  Set browser window to "normal" (not maximized).  
3.  Very slowly change the width of the window.  

Actual Results:  
As the size of the inner box shrinks to the length of a line, a blank line will
suddenly appear after that line (just before the line wraps).  

Expected Results:  
There should be no blank lines within the lines of text in the inner box.  

This problem was first observed within a table cell.  However, since that page
is frequently changed, a contrived test case was developed, which uses blocks
instead of a table.  

The ease of seeing this problem varies with the font and its size.  I readily
see it using Georgia at 13px.  It's still visible with Times New Roman at 13px
but not as readily.  Using Georgia at 11px, I had to be very careful in resizing
the window to see the problem.

Comment 1

[Jason Barnabe (np)]

http://www.w3.org/TR/html4/types.html#h-6.2

"# CDATA is a sequence of characters from the document character set and may
include character entities. User agents should interpret attribute values as
follows:

    * Replace character entities with characters,
    * Ignore line feeds,
    * Replace each carriage return or tab with a single space."


Carriage returns in code are replaced by single spaces. So in your code, 

<br>text text text text text text text text end
<br>text text text text text text text text abc text text end

there is a carriage return after the first end, which is replaced by a space,
making the line "text text text text text text text text end ". The space is
what's wrapping. To avoid this, put the <br> right beside the end and not on a
new line.

Marking invalid.

Comment 2

[Hixie (not reading bugmail)]

I don't think this is invalid -- a space before a linebreak should collapse away
in white-space: normal mode, it should never be possible to have an empty line
like that.

I can't repro on my machine, though.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

it might be worksforme, but it doesn't seem to be invalid.

Comment 4

[David E. Ross]

It is my understanding that the presentation of a Web page should depend on the
markups and not on the layout of the source HTML (except, of course, for such
situations as <pre> </pre>).  Thus, if I compose my HTML with a new line for
each blank or with the entire file as one continuous line, the page should
display the same.  

I know this is not true with Mozilla.  
<p align="right">abcd<br>efgh
results in the two strings having d and h aligned.  However, 
<p align="right">abcd
<br>efgh
results in the h slightly to the right of the d.  
(An example of this is being added to the test page I cited when I wrote this
bug.)  

Yes, in the test page, I can eliminate the problem by making the text all one
lone line.  But that means my understanding (at the beginning of this comment)
is wrong.  This raises the question:  To what extent does the layout of source
HTML affect the resulting Web page display?  Note that source HTML is often
formatted to enhance readability and thus maintainability without intending to
affect the resulting display.  

I readily see the problem on the test page when my Preferences for Appearance >
Fonts indicate the default Proportional font is Serif and the default Serif font
is truly a proportional font.  I expect the problem cannot be seen with a
mono-space font, but I have not tested that conjecture.  

Comment 5

[Hixie (not reading bugmail)]

Yes, the above (<p align="right">abcd <br>efgh</p>) is rendered wrong by moz.

is that the bug here?

Comment 6

[Jason Barnabe (np)]

The layout of the HTML doesn't depend on whitespace - except for the first space. 

It doesn't render differently for other inline tags. For example,

<p><span>This is</span> text</p>

renders "This is text" and not "This istext". Why should 

<p>This is <br>text</p>

be any different? It should render "This is (line break)text" not "This is(line
break)text"

The same behaviour is apparent in IE.

All that being said, I'll defer to authority.

Comment 7

[David E. Ross]

Reference comment #5.  

This is another symptom of the problem.  My original Description and Summary
reflected the first symptom that I noticed.  

However, the real problem is implied in comment #1.  When the source HTML
contains a line that ends in a line break and is then followed by a <br> tag to
force a line break in the displayed page, a blank character is inserted at the
end of the line.  This really has nothing to do with text being within a CSS
block, but the effect is more striking in that situation.  

I have updated the Summary accordingly.  

Note that the problem does not occur when the <p> tag replaces the <br> tag. 
The test page at the cited URL now has examples of both tags.  

Comment 8

[Jason Barnabe (np)]

Re comment 7:

"# CDATA is a sequence of characters from the document character set and may
include character entities. User agents should interpret attribute values as
follows:

    * Replace character entities with characters,
    * Ignore line feeds,
    * Replace each carriage return or tab with a single space."

Emphasis on "Replace each carriage return or tab with a single space.".

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

http://www.w3.org/TR/CSS21/text.html#q8 :

   3. If a space (U+0020) at the end of a line has 'white-space' set to
'normal', 'nowrap', or 'pre-line', it is also removed.

Comment 10

[Jason Barnabe (np)]

Thanks David B.

So isn't this the issue as bug 132561?

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

*** This bug has been marked as a duplicate of 132561 ***