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.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

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]

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.

This is working as expected in the 19990707-08 build. Marking the bug FIXED even though I don't know when or by who.

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.

Clearing resolution.

The bug does indeed occur on M9 Apprunner / WinNT4 SP5.

Could this be related to bug 14280 ?

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: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/floatlinebox.html 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.

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.

Assigning to default layout owner.

Adding qawanted: needs a 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.

.

*** Bug 78147 has been marked as a duplicate of this bug. ***

Still prob exist

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.

WFM Mac trunk.

WFM Windows trunk too.