Closed Bug 2418 Opened 22 years ago Closed 14 years ago

Line break allowed after :first-letter


(Core :: Layout: Block and Inline, defect, P3)






(Reporter: bratell, Assigned: mats)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: css1, testcase, Whiteboard: [CSS1-2.4][CSS1-5.5.25])


(3 files)

If you make the window so narrow that the whole first word in a sentence doesn't
fit, instead of letting the word go outside the window, a line break is inserted
between the first letter in the first word and the second letter in it.

I guess this has something to do with the firstletter property.
Assignee: rickg → kipp
Setting all current Open/Normal to M4.
Product: MozillaClassic → Browser
Summary: line break inside first word in paragraph → line break inside first word in paragraph {first-letter bug}
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at
Severity: normal → trivial
Priority: P2 → P3
Target Milestone: M6 → M15
Summary: line break inside first word in paragraph {first-letter bug} → {first-letter} line break inside first word in paragraph
Whiteboard: (py8ieh:will examine)
Target Milestone: M15
This may have been solved when first-letter was rewritten recently. I will
examine this.

[dbaron:I have removed the M15 marker until this bug is re-confirmed]
Whiteboard: (py8ieh:will examine) → (py8ieh:create generic test case)
Target Milestone: M15
This still occurs. The error may also be that word endings for purposes of
line wrapping are assumed to occur on element boundaries as well as whitespace
boundaries, e.g.:  "<a>first</a><b>second</b>" may split between the elements.
If this is the case then it is a more generic bug than just :first-letter.

I intend to write a test case for this sometime soon.
Closed: 22 years ago
Resolution: --- → FIXED
This is working as expected in the 19990707-08 build. Marking the bug FIXED even
though I don't know when or by who.
Whiteboard: (py8ieh:create generic test case)
I can't reproduce the problem described in the original description. Tested with
July 9 build (1999070908). Marking as verified fix.
*** Bug 14321 has been marked as a duplicate of this bug. ***
Reopening since this is back per bug 14321.
Resolution: FIXED → ---
Clearing resolution.
The bug does indeed occur on M9 Apprunner / WinNT4 SP5.
Could this be related to bug 14280 ?
Target Milestone: M15 → M20
The issue here is a conflict between perception and the css2 expected behavior
of floaters. In particular, if there is content to the right of a left floater
and that content doesn't fit then it is *supposed* to be placed below the
floater. Which is what we are doing...
I think float on first-letter may be special.  Ask the WG...  Anyway, shouldn't
you treat the rest of the word as the first inline-box and force *something* to
be on every line (as you do elsewhere, or do you still do that)?
We don't do that anymore; otherwise we don't pass some of your tests :-)
Notably, the ones with those darn little orange boxes...
Perhaps you should do it for just this one case...

(I do remember not liking the behavior.  But I don't remember tests with little
orange boxes off the top of my head.  I've written a lot of tests...)
Would the tests with the darn orange boxes be the ones that we used in the WaSP
reviews and the CSS1 Test Suite? I think Eric wrote those, didn't he?

David: Here is a test with a floater the same size as its container:
Presumably, you would want the first word to appear on the second line box, not
the first, right? (That is what we do now.) [This is not a first-letter test!]

I think this has got to be a special case. If the :first-letter is floating,
and it is not followed by white space, then the next word should be forced to
be in the first line box. Otherwise it looks silly... I think you should ask
the WG about this, though.
Closed: 22 years ago21 years ago
Resolution: --- → LATER
Well, I improved it ever so slightly. Now the word-fragment that follows a
*floating* first letter will stick to the first-letter. Of course if that word
fragment has style changes in it (example: <div>He<b>ros are made, not
born</b></div>) then all bets are off. I tried, but the current line layout
logic isn't up to it.

I'm going to later this bug because its really a minor cosmetic issue, not
something that should hold up the release. And reworking the line-layout logic
to fix this is a *big* deal.
Marking as a verified later.
REMIND is deprecated per bug 35839.
Keywords: css1
Resolution: LATER → ---
Summary: {first-letter} line break inside first word in paragraph → Problems with floating :first-letter
Whiteboard: [CSS1-2.4][CSS1-5.5.25]
Assigning to default layout owner.
Assignee: buster → attinasi
Target Milestone: --- → Future
Adding qawanted: needs a testcase.
Keywords: qawanted
Attached file testcase
Demonstrates original bug as referenced in comment #1 as well as the more
specific (resolved) case referenced in comment #17.

(Note the original bug occurs without altering float property of first-letter
pseudo element; perhaps bug should be retitled?)
Reconfirmed using FizzillaCFM/2002070913. Setting All/All, adding testcase, and
removing qawanted.
Keywords: qawantedtestcase
OS: Windows NT → All
Hardware: PC → All
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: petersen → ian
*** Bug 78147 has been marked as a duplicate of this bug. ***
Attached image IE vs FF Narrow window
Still prob exist
Attached image IE vs FF Normal View
Assignee: core.layout.block-and-inline → mats.palmgren
Depends on: 45091
Target Milestone: Future → ---
Comment #17 reports that the floating case was resolved, and the testcase confirms this. (Looking back at the bug's history, it also appears that the mention of "floating" in the bug summary was added at a late stage (April 2002)).

So this currently seems like a line-breaking bug, perhaps even one that will be fixed by ROC's patch for bug 343445.

I'm changing the summary accordingly. Please smack me on the head if I'm wrong.
Summary: Problems with floating :first-letter → Line break allowed after :first-letter
WFM Mac trunk.
WFM Windows trunk too.
Severity: trivial → minor
Closed: 21 years ago14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.