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)

x86
Windows 98
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: ian, Unassigned)

References

()

Details

(Keywords: testcase, Whiteboard: [bae:20011119][Hixie-P3])

Attachments

(1 file)

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.
Assignee: troy → kipp
Status: NEW → ASSIGNED
Adding David to cc list. I meant to do that yesterday, but forgot.
*** Bug 1519 has been marked as a duplicate of this bug. ***
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
Target Milestone: M17 → M13
Updating to default Layout Assignee...kipp no longer with us :-(
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.
mine! mine mine mine! all mine! whoo-hoo!
Assignee: kipp → buster
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
low priority bug. I agree what we do isn't the best.
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: M16 → M20
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M20 → M22
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
Attached image screenshot of current behavior (deleted) —
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
Has this fixed itself? I cannot reproduce the bad behaviour with Win2K commerical build 6.0.17.200072811.
Taking QA per managerial policy.
QA Contact: petersen → py8ieh=bugzilla
Whiteboard: [Hixie-P5] if not WORKSFORME...
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]
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/
Whiteboard: [Hixie-P5] → [Hixie-P3]
Priority: P4 → P2
*** Bug 68115 has been marked as a duplicate of this bug. ***
This bug has been fixed. I am not getting the screenshot with a current build.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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 → ---
(I think the original symptom is gone but the underlying problem still exists.)
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
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: REOPENED → NEW
reduced priority to P4
Priority: P2 → P4
Whiteboard: [Hixie-P3] → [bae:20011119][Hixie-P3]
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?
this does seem to be worksforme now, yeah. cool. wonder what happened.
Removing css1 since there seems to be no governing spec.
Keywords: css1
block/inline
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: ian → moied
None of the testcases attached to or mentioned on this bug fail any more, they all work very nicely. WORKSFORME?
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.
I reopened bug 68115, bug 1519 is fixed now. Marking WORKSFORME.
Status: NEW → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: