Closed
Bug 4248
Opened 26 years ago
Closed 22 years ago
[INLINE-H][WHITESPACE]{ll} Trailing spaces on inline elements wrapping at boundary poorly treated
Categories
(Core :: Layout: Block and Inline, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: ian, Unassigned)
References
()
Details
(Keywords: testcase, Whiteboard: [bae:20011119][Hixie-P3])
Attachments
(1 file)
(deleted),
image/png
|
Details |
See test three on the test page:
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/emptyinline.html
PROBLEM: An inline element with a space trailing at the end which wraps at the
block box boundary does not have a closing border.
SOLUTION: The 'correct' behaviour is not defined by any spec AFAIK. I suggest
emulating the behaviour of Opera 3.51, a trial copy of which is downloadable
from
http://www.operasoftware.com/
This basically involves collapsing the space into the newline, realising this
has happened, and strategically moving the newline outside the inline element,
so that the inline element simply loses its space and is placed at the end of
the line as if it had never had the space.
David Baron has kindly donated a screen shot of the current behaviour:
http://www.fas.harvard.edu/~dbaron/tests/nglayout/ieh_inl.gif
As can be seen, the current behaviour is suboptimal at best.
Reporter | ||
Comment 1•26 years ago
|
||
Adding David to cc list. I meant to do that yesterday, but forgot.
Reporter | ||
Comment 3•26 years ago
|
||
Bug 1519 dealt with this issue in the case of underlining and trailing spaces.
The URI was: http://www.w3.org/Style/CSS/Test/adhoc/nov23.html
In Section (7), the underlined space character after "the text." should have
been collapsed, as should the the underlined space characters at the end of each
line in section (6).
Summary: Trailing spaces on inline elements wrapping at boundary badly treated → {ll} Trailing spaces on inline elements wrapping at boundary badly treated
Why are you re-reassing layout bugs? Do NOT touch layout bugs.
The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.
mass moving all Kipp's pre-beta bugs to M15. Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.
low priority bug. I agree what we do isn't the best.
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: M16 → M20
Comment 10•25 years ago
|
||
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M20 → M22
Comment 11•25 years ago
|
||
This bug is marked "future" because it is not critical for RTM (Release To
Manufacturing). If anyone believes it is critical, please explain why
in this bug.
Target Milestone: M22 → Future
Comment 12•25 years ago
|
||
Updated•25 years ago
|
Summary: {ll} Trailing spaces on inline elements wrapping at boundary badly treated → [INLINE-H][WHITESPACE]{ll} Trailing spaces on inline elements wrapping at boundary badly treated
Reporter | ||
Comment 13•25 years ago
|
||
Has this fixed itself? I cannot reproduce the bad behaviour with Win2K
commerical build 6.0.17.200072811.
Reporter | ||
Comment 14•24 years ago
|
||
Taking QA per managerial policy.
QA Contact: petersen → py8ieh=bugzilla
Reporter | ||
Updated•24 years ago
|
Whiteboard: [Hixie-P5] if not WORKSFORME...
Reporter | ||
Comment 15•24 years ago
|
||
Actually, now we almost do it right, except that we overlap the border and the
last letter slightly.
Summary: [INLINE-H][WHITESPACE]{ll} Trailing spaces on inline elements wrapping at boundary badly treated → [INLINE-H][WHITESPACE]{ll} Trailing spaces on inline elements wrapping at boundary poorly treated
Whiteboard: [Hixie-P5] if not WORKSFORME... → [Hixie-P5]
Comment 16•24 years ago
|
||
Ian attached some interesting testcases to bug 86746 that are really more
related to this bug (or something related to this):
------- Additional Comments From Ian 'Hixie' Hickson 2001-06-19 18:22 -------
The problem is actually that there is a space at the start and end of the
float's contents, which is rather strange. See the following tests:
http://www.hixie.ch/tests/adhoc/css/box/float/011.xml
http://www.hixie.ch/tests/adhoc/css/box/float/012.xml
http://www.hixie.ch/tests/adhoc/css/box/float/013.xml
Note. You will need the Ahem font for these tests. You may obtain a copy here:
http://www.hixie.ch/resources/fonts/
Reporter | ||
Updated•24 years ago
|
Whiteboard: [Hixie-P5] → [Hixie-P3]
Updated•24 years ago
|
Priority: P4 → P2
Comment 17•24 years ago
|
||
*** Bug 68115 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
This bug has been fixed. I am not getting the screenshot with a current build.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 19•24 years ago
|
||
Not all the issues here have been fixed, and I've marked some recent bugs as
duplicates of it since they haven't been fixed. If you're going to mark this
one fixed, could you at least figure out what the others should be dups of?
Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 20•24 years ago
|
||
(I think the original symptom is gone but the underlying problem still exists.)
Comment 21•24 years ago
|
||
This is perhaps a manifestation of the following observation reported in the code
comments -- I also encountered this while working on the font stuff. (I haven't
done any testing w.r.t. to this bug so I am not really sure.)
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&file=nsLineLayout.cpp&rev1=3.101.2.2&rev2=3.101.2.3&root=/cvsroot
Comment 22•23 years ago
|
||
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: REOPENED → NEW
Comment 23•23 years ago
|
||
reduced priority to P4
Priority: P2 → P4
Whiteboard: [Hixie-P3] → [bae:20011119][Hixie-P3]
Comment 24•23 years ago
|
||
Apparently WorksForMe using FizzillaCFM/2002070913 (testing for possible
platform=all). With the browser window sized so that the "STRONG" inline box is
at the end of a line, the line below doesn't appear to be at all affected by
borders or weird line height; certainly nothing like the screenshot. Am I
looking at this right? Is this still a problem, or a genuine PC-only problem?
Reporter | ||
Comment 25•23 years ago
|
||
this does seem to be worksforme now, yeah. cool. wonder what happened.
Comment 27•22 years ago
|
||
block/inline
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: ian → moied
Reporter | ||
Comment 28•22 years ago
|
||
None of the testcases attached to or mentioned on this bug fail any more, they
all work very nicely. WORKSFORME?
Comment 29•22 years ago
|
||
See comment 19 - comment 20. If you want to resolve this one, make sure another
one is open to cover the other issues, if they still exist.
Reporter | ||
Comment 30•22 years ago
|
||
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•