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

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect)

Description

[Dave Gross]

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 http://sniggle.net/Experiment/index5.php?entry=short.es 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

[j.j.]

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

[Dave Gross]

Attachment: Test case HTML page

Comment 3

[j.j.]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

http://www.w3.org/TR/CSS21/text.html#white-space-model 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

[Dave Gross]

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

[Dave Gross]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I do think this would be a reasonable spec change, personally.  Worth mailing www-style about it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Oh, and note that http://dev.w3.org/csswg/css3-text/#white-space-rules seems to have much the same behavior...

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

Comment 9

[j.j.]

Dave, the CSS spec is not sacrosanct.
Current editor's draft:  http://dev.w3.org/csswg/css3-text/

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

[Dave Gross]

Attachment: 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 " — " 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

[Dave Gross]

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...