13610 - ::first-letter does not inherit from ::first-line when floated

Status: NEW

(Core :: Layout: Floats, defect, P3)

Description

[Ian Graham]

When formatting is assigned using both :first-line and :first-letter,
then the :first-letter pseudo-element should inherit the formatting
properties assigned to :first-line.  This indeed happens if the
first-letter is not floated. However, if float: is applied to the
:first-letter pseudo-element, then it no longer inherits the properties
set for the first line.

This was tested on Win 98, Seamonkey M9 build. The URL references a
test document demonstrating the two cases.

Comment 1

[Peter Linss]

The floated first-letter's style context is being created with the wrong parent.

Also, the style context in the placeholder frame for floated first-letter frames
is a sibling of the first-letter style context. All other placeholder contexts
are *children* of the floated style context.

Two more problems on this page:
1) by resizing the page horizontally you'll see words at the end of the
first-line that are not in first-line style (they get pushed because they don't
fit, then they get pulled back because they do fit in the smaller size).
2) slowly resize the page smaller so that the <b><i>does not</i></b> text barely
does not fit on the first line. The word "not" shows on the second line still in
the first line style.

Comment 2

[Ian Graham]

I was unable to reproduce the two additional problems noted by Peter. Could
processor speed/memory size be a factor (this seems like some part of the
rendering system isn't catching an event at the right time)? I am testing with
a 450MHz PIII with 128Meg -- and tried for several minutes (with M9 build) to
reproduce the weirdness Peter saw.

Comment 3

[kipp]

I think that the style issue has been resolved. I now see gree text in a
particular font for the first-letter in both floating and non-floating
situations.

However, I *do* see the bug that peter pointed out...

Comment 4

[kipp]

The wrapping bug was caused by a tiny error in the block code where it would
(sometimes) pull up a frame following a line-break onto the same line. The only
case it would do is if  first-letter style was in effect AND the frame was a
line-frame (which means you needed first-line style too...)

I found the relevant line of code in the block frame and fixed it to prevent
such pull-ups.

Comment 5

[Ian Graham]

Is this fix checked in? Using the Nov 8 daily build (on Windows 98), I still
 see the floated :first-letter textin the wrong color (black) and font (default
font).

Comment 6

[Christine Hoffman]

Using 11/16 build the problem still exists regarding the floated first letter.
As the reporter stated, it should be inheriting the properties of the first
line. Reopening bug.

Rick - Is there a new assigned engineer on this one?

Comment 7

[leger]

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

Comment 8

[troy]

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 9

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 10

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 11

[rickg]

moving all buster m15 bugs to m16.

Comment 12

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 13

[buster]

here's a style context issue for you Marc.  Can you verify Peter's assertion 
that the parentage of the style contexts is incorrect?  Kipp at one point 
thought that issue was resolved, but the bug is still easily reproducable.  If 
the style context parentage is wrong, it should be an easy fix.

This isn't a real high priority, though it is a CSS-1 compliance issue.  But 
I'd hate for an easy one to slip through without a little effort. If we can't 
solve it in less than an hour, I say "future" it.

Comment 14

[Marc Attinasi]

Style context parentage looks correct - there is no problem verifying the style 
tree and that would indicate a parentage problem. The problem of the floated 
first-letter not getting the style is stille there, as is the problem of the 
first-lin style wrapping to the second-line on a resize...

Comment 15

[Marc Attinasi]

Interestingly, the :First-Letter pseudo-class does inherit the color from the 
BODY, just not from the :first-line pseudo...

It looks like the style context for the text frame in the letter frame in the 
floater list is just plain wrong: it is empty. 

My guess from a 1-hour investigation is that the creation of the floating 
placeholder frame causes the pseudo-style to be resolved incorrectly. This jives 
with other similar problems I have seen where frame construction for floaters is 
not following the same path as normal frame construction (eg. floated list items 
do not get bullet frames created).

I'll attach a dump of the relevant frame and style context data for later 
investigation (no time at present).

Comment 16

[Marc Attinasi]

Attachment: FRAME and STYLE CONTEXT dump showing incorrect style data referenced in floter-frame

Comment 17

[Marc Attinasi]

This bug has been marked "future" because we have determined that it is not 
critical for netscape 6.0. If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.

Comment 18

[timeless]

nsbeta3- and rtm- it if need be, but we claim to support css1. this should make 
relnotes3/relnotes rtm.

Comment 19

[Marc Attinasi]

Why was this removed from my bug list and assigned to nobody?

If you want to discuss or agrue about the FUTURE status that is fine, but do not 
just unilatterally change the milestone and do not reassign them.

Please indicate why you believe this should not be 'futured' - are there 
specific real-world cases of floats using :first-letter inheriting from 
:fist-line that you are concerned about? This still seems like a very esoteric 
problem to me...

Comment 20

[Blake Ross]

If you have any time, it would be great if you could get to this, to really 
back our claim of true CSS1 support.

Comment 21

[ekrock's old account (dead)]

correctness but edge case. Because NS engineering is overburdened, recommend
nsbeta3- and relnote.

Comment 22

[ekrock's old account (dead)]

[nsbeta3-] and removing rtm nomination. relnote. Note that the workaround is to 
write correct CSS that will explicitly set this up so it works both with the bug 
(now) and after we've fixed it (future). For relnote, ask [e-mail] for 
explanation of how to write such CSS.

Comment 23

[Hixie (not reading bugmail)]

Just a clarification: The relnote isn't 'contact Ian'. ;-)

The relnote should be (something slightly more readable than):

   "Gecko currently does not inherit style from the :first-line pseudo-element
    to the :first-letter pseudo-element if the :first-letter pseudo-element is
    floated. To work around this issue, simply give :first-letter all the
    inheritable properties explicitly. For example, instead of:
       :first-line { color: blue; }
       :first-letter { float: left; }
    ...say:
       :first-line, :first-letter { color: blue; }
       :first-letter { float: left; }
    ...to get a blue first letter."

Comment 24

[ekrock's old account (dead)]

Nom. nsbeta1. Correctness of CSS1 compliance. Want these pseudo selectors to
play nicely together & inherit right.

Comment 25

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 26

[Hixie (not reading bugmail)]

cc'ing hyatt as this is possibly related to inheritance code he knows... :-)

Comment 27

[Greg K.]

Original problem as reported also confirmed using FizzillaCFM/2002070913.
Setting All/All.

Comment 28

[Christopher Aillon (sabbatical, not receiving bugmail)]

->Floats

Comment 29

[Mats Palmgren (inactive)]

The URL is 404,  if anyone have a copy of the testcase please attach it to
this bug.  Thanks.

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase

Here's a testcase made from the description.  I'm not really sure what the
correct behavior is, though. :-)

Comment 31

[Ian Graham]

Sorry, the server died. I'm getting a backup of the system next week, and will 
upload a copy of the original example(s) as soon as possible.

Comment 32

[Ian Graham]

Attachment: Original testcase

This is the original testcase (showing behavior for :first-letter with and
without a float property).  I've checked this against IE 6 and Opera 7.23 --
opera gets this wrong too (worse, actually), while IE gets the inheritance
right (but wrong spacing inside the inline box).

Comment 33

[Xanthor Sccas]

Sorry for the spam, but is this bug still valid ?
Because I see the correct behaviour for both testcases with Mozilla 1.8a3
(GNU/Linux)

Comment 34

[Ian Graham]

Hmmm, I just tested this on WinXP:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040831
Firefox/0.9.1+
And both test cases are still broken... What was your build ID?  

Comment 35

[Xanthor Sccas]

(In reply to comment #34)
> What was your build ID?  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

Maybe I don't understand the testcases, but in first one, the first letter "T"
is green, and in the second one, in both paragraphs the first letter "H" is
green, bold and bigger..

Comment 36

[Ian Graham]

That's very strange -- on WinXP the leading letter is red in the first testcase,
and in black and times-roman (it should be arial) in the second...  I will
attach screen captures to show this.... I also confirmed this using today's (1
Sept) trunk build ... 

It seem very odd that this logic would behave differently on the linux build.
Can you test on any other platform?
 

Comment 37

[Ian Graham]

Attachment: Graphic showing incorrect rendering of testcase (attachment 127576)

Note how the leading text is the wrong color: also, somehow, the incorrect
formatting (red color) is inherited by text flowed onto the second line!

Comment 38

[Ian Graham]

Attachment: incorrect rendering of original testcase (attachment 143012)

Incorrectly rendered content: the leading floated letter (H) should be green,
and in a sans-serif font.

Comment 39

[Xanthor Sccas]

(In reply to comment #36)
> Can you test on any other platform?
No sorry, I haven't got other plateforms.
I've tested on another computer with linux, and the testcases are still correct
with Mozilla1.8a3 :
http://www.megspace.com/lifestyles/taupe/first.png   

Comment 40

[Xanthor Sccas]

sorry : the good URL to the screnshoots http://taupe.100free.com/first.png
Just to add, with Mozilla1.8a2 the bug are still here

Comment 41

[Ian Graham]

Weird.  I poked about a bit with tinderbox, but couldn't see any obvious
checking between 1.8a2 and a3: but then I don't know the code layout that well,
so probably just missed it. It is odd it works on LInux and not on WinXP ...
HOpefully someone else will pick up on this: all I guess we can do is keep
monitoring it. 

Comment 42

[Biju]

Attachment: IE comparison

Comment 43

[Chris Casciano]

Just to poke my head in the bug is still present on camino 2004100608/OS X and
firefox 2004100708-trunk/win2k... is everyone on linux WFM? anyone care to
verify the last few comments with more recent builds?

Comment 44

[Ian Graham]

Still not fixed in FF 3.0 (hence Gecko 1.9). 

Comment 45

[Ryo Onodera]

Attachment: a tweaked testcase.

I've researched about this issue. Here is the five screen shots from various browsers. Apparently, there is no consensus between we, browser makers... Well, what does the spec say? Anyway, the current blatant behavior of Firefox not inheriting from ::first-line is not desired... I'll dig the codebase to fix this from now.

http://www.flickr.com/photos/39168120@N03/sets/72157619819484030/detail/

Comment 46

[Ryo Onodera]

Attachment: a tweaked testcase. v2

I added another screen shot for IE8. Originally, IE8 didn't open xhtml files, so I created a symlink with the html suffix refering to the xhtml file. It seems that IE rendered it in a non-standards-compliant way. I've added the XML declaration and the doctype to the testcase. The rendering behavior vastly differs only in IE with or without the two. Well, I should do that from start.

Comment 47

[Ryo Onodera]

Attachment: a hack

Well, originally by educated guess, I made the attached hack. And it fixed this bug. Yet, running the reftest turned out that it caused regressions of tests added in Bug 395623.
By reading the bug report, I realized that there IS the reason in this bug for not being fixed for so many years. At this moment, I'm only aware that reparenting handling is causing this mess. And, the code for it is in the various parts of the codebase, to the extent I'm really not sure where this should be fixed at, moreover, whether I should try to fix this at all.

Comment 48

[Kuba Niewiarowski]

Update after Servo?

Comment 49

[Emilio Cobos Álvarez (:emilio)]

(In reply to Kuba Niewiarowski from comment #48)
> Update after Servo?

The short answer is no, we kept Gecko behavior for first-letter / first-line :/

Comment 50

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 10 votes.
:TYLin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 51

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 52

[briannapatricia7]

HELLO, can i take over this bug. I am an outreachy applicant. but passionate to work on it . thanks