[INLINE-H][WHITESPACE]{ll} Trailing spaces on inline elements wrapping at boundary poorly treated

RESOLVED WORKSFORME

Status

()

P4
normal
RESOLVED WORKSFORME
20 years ago
16 years ago

People

(Reporter: ian, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
Windows 98
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

20 years ago
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.

Updated

20 years ago
Assignee: troy → kipp

Updated

20 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 1

20 years ago
Adding David to cc list. I meant to do that yesterday, but forgot.
(Reporter)

Comment 2

20 years ago
*** Bug 1519 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 3

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

Updated

19 years ago
Summary: Trailing spaces on inline elements wrapping at boundary badly treated → {ll} Trailing spaces on inline elements wrapping at boundary badly treated

Updated

19 years ago
Target Milestone: M17 → M13

Comment 4

19 years ago
Updating to default Layout Assignee...kipp no longer with us :-(

Comment 5

19 years ago
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.

Comment 6

19 years ago
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.

Comment 7

19 years ago
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster

Comment 8

19 years ago
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16

Comment 9

19 years ago
low priority bug.  I agree what we do isn't the best.
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: M16 → M20

Comment 10

19 years ago
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M20 → M22

Comment 11

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

19 years ago
Has this fixed itself? I cannot reproduce the bad behaviour with Win2K 
commerical build 6.0.17.200072811.
(Reporter)

Comment 14

18 years ago
Taking QA per managerial policy.
QA Contact: petersen → py8ieh=bugzilla
(Reporter)

Updated

18 years ago
Whiteboard: [Hixie-P5] if not WORKSFORME...
(Reporter)

Comment 15

18 years ago
Actually, now we almost do it right, except that we overlap the border and the
last letter slightly.
Keywords: css1, mozilla1.0, testcase
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/

(Reporter)

Updated

18 years ago
Whiteboard: [Hixie-P5] → [Hixie-P3]

Comment 18

18 years ago
This bug has been fixed. I am not getting the screenshot with a current build.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 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.)

Comment 21

18 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
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: REOPENED → NEW

Comment 23

17 years ago
reduced priority to P4
Priority: P2 → P4
Whiteboard: [Hixie-P3] → [bae:20011119][Hixie-P3]

Comment 24

17 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

17 years ago
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
(Reporter)

Comment 28

16 years ago
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.
(Reporter)

Comment 30

16 years ago
I reopened bug 68115, bug 1519 is fixed now. Marking WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.