at end-of-line causes line not to be justified in otherwise justified paragraph




7 years ago
7 years ago


(Reporter: dave, Unassigned)




Firefox Tracking Flags

(Not tracked)



(2 attachments)



7 years ago
User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11

Steps to reproduce:

In a paragraph that is {text-align: justify}, I have —es that are offset from the text by being sandwiched in   characters: e.g. "something — something".  If the — and its  s appear at the end of the line, the final   is rendered as a space, which messes up the justification of the line (making it short by a   width).

Actual results:

See and in particular the paragraph beginning "Creo que debemos construir un país del cual podamos estar orgullosos  — con..."

Expected results:

If a   appears at the end of a line in a justified paragraph, it should not render, the same as an ordinary space.

Comment 1

7 years ago
Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1

Cannot reproduce with your URL, there is no dash on line's end here. 
Please try to create a simple HTML test case and attach it here (use the "Add an Attachment" link above)

Comment 2

7 years ago
Created attachment 644709 [details]
Test case HTML page


7 years ago
Attachment #644709 - Attachment mime type: text/plain → text/html

Comment 3

7 years ago
I see your problem but it's the same in other browsers (Opera, Safari, Chrome, but not in IE8). No clue what the right thing should be.
Severity: normal → trivial
Component: Untriaged → Layout: Text
Keywords: testcase
OS: Linux → All
Product: Firefox → Core
Hardware: x86 → All
Version: 14 Branch → Trunk special-cases certain unicode characters in terms of what happens at the ends of lines.  In particular, U+0020 at end of line is removed, but nothing like that is defined to happen for any other characters.

It sounds like you're arguing for a change to the spec to include more Unicode characters in the "removed at end of line" behavior?

Comment 5

7 years ago
Hmmm... I see what you mean. The spec only explicitly mentions U+0020 as a white-space space character there, though there are several other unicode spaces that ought (IMHO) to be considered white-space in such contexts (and the spec doesn't seem to suggest that implementors must /only/ apply this behavior to the U+0020 space).

I notice, though, that FF exhibits the same behavior with   and   (as does Chrome).

I'd hate to think that these space characters are only to be used to position items in particular ways and can't be relied on to behave typographically like spaces, but maybe that's the case.

Comment 6

7 years ago
I do note, though, that FF is careful never to /begin/ a line with any of these space characters, so it and/or the spec is sensitive to the nature of those characters to that extent.
For what it's worth, I do think this would be a reasonable spec change, personally.  Worth mailing www-style about it.
Oh, and note that seems to have much the same behavior...

And the address to mail is <>.  Sorry if that wasn't clear.  ;)

Comment 9

7 years ago
Dave, the CSS spec is not sacrosanct.
Current editor's draft:

You can join the www-style mailing list and ask for a change.
Links are in the "Status of this document" section of the specification.
Search the archive for previous discussions and read the instructions before sending a mail (a lot of very busy people will read it). 
And keep in mind that usually things are the way they are for good reasons. It's not always immediately apparent why.

Comment 10

7 years ago
Created attachment 645048 [details]
Second test case with even weirder behavior

In some cases, this test case exhibits an even worse (and more unambiguous) bug.

This test case includes several words that are separated only by this "&thinsp;&mdash;&thinsp;" separator.  By resizing the viewport, you can provoke FF to screw up the justification of the right margin of a line by as much as a complete *word* length.

Comment 11

7 years ago
Comment on attachment 645048 [details]
Second test case with even weirder behavior

On second thought, this might not be as buggy as I'd assumed. The "bug" only manifests itself when there's *nothing but* thinsp whitespace on the line, so there's ambiguity about whether the correct behavior is to respect the thinsp as such or to respect the line justification by expanding the thinsp or character spacing...


7 years ago
Attachment #645048 - Attachment mime type: text/plain → text/html
You need to log in before you can comment on or make changes to this bug.