RESOLVED FIXED 5318
forced line break should not be allowed after a list marker
https://bugs.webkit.org/show_bug.cgi?id=5318
Summary forced line break should not be allowed after a list marker
Antti Koivisto
Reported 2005-10-09 22:55:39 PDT
It does not make much sense to break line after a list marker, the behaviour does not match other browsers either.
Attachments
test case (256 bytes, text/html)
2005-10-09 22:56 PDT, Antti Koivisto
no flags
patch (1.25 KB, patch)
2005-10-09 23:02 PDT, Antti Koivisto
hyatt: review-
updated test case (517 bytes, text/html)
2005-10-11 20:53 PDT, Antti Koivisto
no flags
updated patch (1.31 KB, patch)
2005-10-11 21:05 PDT, Antti Koivisto
hyatt: review+
Antti Koivisto
Comment 1 2005-10-09 22:56:20 PDT
Created attachment 4284 [details] test case
Antti Koivisto
Comment 2 2005-10-09 23:02:05 PDT
Created attachment 4285 [details] patch this fixes the problem for list markers only, however there might be a need for more generic fix based on this comment in the code: // FIXME: This does not match WinIE, Opera, and Mozilla. They treat replaced elements // like characters in a word, and require spaces between the replaced elements in order // to break.
Darin Adler
Comment 3 2005-10-09 23:36:22 PDT
Comment on attachment 4285 [details] patch r=me
Dave Hyatt
Comment 4 2005-10-10 02:24:42 PDT
Comment on attachment 4285 [details] patch I'm minusing this, since I think the code needs better commenting, and because as you discovered, this problem is not unique to list markers. I'd rather see this fixed for replaced elements and list markers together than to just have some special-case code introduced for list markers.
Dave Hyatt
Comment 5 2005-10-10 02:27:02 PDT
I think this may need a consult from Hixie actually. When considering ordered lists, there is an actual space generated between the "1." and the rest of the text, so it seems logical to me that this would provide a breaking opportunity. However, as you pointed out, it looks ugly. Hixie, what do you think?
Dave Hyatt
Comment 6 2005-10-10 02:27:46 PDT
If we do decide that "1. " should not break despite having a space, then it probably is ok to special-case list markers. :)
Dave Hyatt
Comment 7 2005-10-10 02:29:29 PDT
Comment on attachment 4285 [details] patch Bah, let's just land it and if it turns out to be wrong we can fix it later. :)
Antti Koivisto
Comment 8 2005-10-10 09:46:25 PDT
I don't think it matters whether the list marker has space in it or not. It is treated as a replaced element so the space there is not a factor at all. Anyway, the patch only changes behaviour for forced line breaks, if the algorithm finds a normal break point then that is handled as before.
Ian 'Hixie' Hickson
Comment 9 2005-10-10 15:13:34 PDT
If it's list-style-position: inside then it's just an inline element on the line and it should obey 'white-space' (the space is in the ::marker, and the property inherits from the display:list-item element). If it's list-style-position: outside then it should not wrap, it should be on the first line box, before the start of that line box, and thus should not be affected by wrapping or anything (and it's an inline-block, so white-space would only affect within the ::marker box anyway). HTH.
Dave Hyatt
Comment 10 2005-10-10 16:27:37 PDT
Comment on attachment 4285 [details] patch Ok, so sounds like only outside list markers should ignore white-space rules, from what you're saying, so that's how we should refine this. Minusing for a new patch that checks listStylePosition
Antti Koivisto
Comment 11 2005-10-11 20:53:44 PDT
Created attachment 4317 [details] updated test case
Antti Koivisto
Comment 12 2005-10-11 21:05:58 PDT
Created attachment 4318 [details] updated patch Allow breaks after marker for list-style-position:inside. This should give the right behaviour. Markers are pretty much a hack, real (CSS3) markers would require some work.
Dave Hyatt
Comment 13 2005-10-16 23:47:46 PDT
Comment on attachment 4318 [details] updated patch r=me
Beth Dakin
Comment 14 2005-10-24 10:47:44 PDT
I committed the fix for this bug.
Note You need to log in before you can comment on or make changes to this bug.