Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

NEW
Unassigned

Status

()

Core
Layout: Floats
P3
minor
18 years ago
2 years ago

People

(Reporter: Ian Graham, Unassigned)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
Future
css1, css2, helpwanted, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P3] [nsbeta3-][CSS1-2.4][CSS1-5.5.25] relnote-devel)

Attachments

(8 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Updated

18 years ago
Assignee: peterl → kipp
Component: Style System → Layout

Comment 1

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

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15
(Reporter)

Comment 2

18 years ago
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

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

Updated

18 years ago
Target Milestone: M17 → M15

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 4

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

Comment 5

18 years ago
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).

Updated

18 years ago
Status: RESOLVED → REOPENED

Updated

18 years ago
Resolution: FIXED → ---

Comment 6

18 years ago
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

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

Comment 8

18 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.
Summary: Possible problem with combined :first-line and :first-letter selectors → {css1} :first-letter does not inherit from :first-line when floated

Updated

18 years ago
Summary: {css1} :first-letter does not inherit from :first-line when floated → {css1} [FLOAT] :first-letter does not inherit from :first-line when floated
Keywords: css1
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...

Updated

18 years ago
Summary: {css1} [FLOAT] :first-letter does not inherit from :first-line when floated → [FLOAT] :first-letter does not inherit from :first-line when floated

Comment 10

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

Comment 11

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

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M16 → M18

Comment 12

17 years ago
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19

Comment 13

17 years ago
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.
Assignee: buster → attinasi
Status: ASSIGNED → NEW

Comment 14

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

Status: NEW → ASSIGNED

Comment 15

17 years ago
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

17 years ago
Created attachment 9725 [details]
FRAME and STYLE CONTEXT dump showing incorrect style data referenced in floter-frame

Comment 17

17 years ago
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.
Target Milestone: M19 → Future

Comment 18

17 years ago
nsbeta3- and rtm- it if need be, but we claim to support css1. this should make 
relnotes3/relnotes rtm.
Assignee: attinasi → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted, nsbeta3, relnote2, rtm
Target Milestone: Future → ---

Comment 19

17 years ago
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...
Assignee: nobody → attinasi
Target Milestone: --- → Future

Comment 20

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

Updated

17 years ago
Status: NEW → ASSIGNED
correctness but edge case. Because NS engineering is overburdened, recommend
nsbeta3- and relnote.
Keywords: correctness
[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 ianh@netscape.com for 
explanation of how to write such CSS.
Keywords: rtm → relnote
Whiteboard: [nsbeta3-]
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."
Severity: normal → minor

Updated

17 years ago
Keywords: relnote2
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
Nom. nsbeta1. Correctness of CSS1 compliance. Want these pseudo selectors to
play nicely together & inherit right.
Keywords: nsbeta1
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...
QA Contact: chrisd → ian
Blocks: 78094
cc'ing hyatt as this is possibly related to inheritance code he knows... :-)
Whiteboard: [nsbeta3-] relnote-devel → [Hixie-P3] [nsbeta3-] relnote-devel

Updated

16 years ago
Blocks: 104166
Whiteboard: [Hixie-P3] [nsbeta3-] relnote-devel → [Hixie-P3] [nsbeta3-][CSS1-2.4] relnote-devel
Whiteboard: [Hixie-P3] [nsbeta3-][CSS1-2.4] relnote-devel → [Hixie-P3] [nsbeta3-][CSS1-2.4][CSS1-5.5.25] relnote-devel

Comment 27

15 years ago
Original problem as reported also confirmed using FizzillaCFM/2002070913.
Setting All/All.
OS: Windows 98 → All
Hardware: PC → All
->Floats
Assignee: attinasi → float
Status: ASSIGNED → NEW
Component: Layout → Layout: Floats
Priority: P3 → --
Summary: [FLOAT] :first-letter does not inherit from :first-line when floated → :first-letter does not inherit from :first-line when floated
Target Milestone: Future → ---

Updated

14 years ago
Priority: -- → P3
Target Milestone: --- → Future
The URL is 404,  if anyone have a copy of the testcase please attach it to
this bug.  Thanks.
Created attachment 127576 [details]
testcase

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

Comment 31

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

Updated

14 years ago
Keywords: testcase

Updated

14 years ago
(Reporter)

Comment 32

14 years ago
Created attachment 143012 [details]
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).

Updated

14 years ago
Keywords: css2
Summary: :first-letter does not inherit from :first-line when floated → ::first-letter does not inherit from ::first-line when floated

Comment 33

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

Comment 34

13 years ago
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

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

Comment 36

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

Comment 37

13 years ago
Created attachment 157674 [details]
Graphic showing incorrect rendering of testcase (attachment 127576 [details])

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!
(Reporter)

Comment 38

13 years ago
Created attachment 157675 [details]
incorrect rendering of original testcase (attachment 143012 [details]) 

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

Comment 39

13 years ago
(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

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

Comment 41

13 years ago
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

13 years ago
Created attachment 160441 [details]
IE comparison

Comment 43

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

Comment 44

9 years ago
Still not fixed in FF 3.0 (hence Gecko 1.9). 
Assignee: layout.floats → nobody
QA Contact: ian → layout.floats

Comment 45

8 years ago
Created attachment 383447 [details]
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

8 years ago
Created attachment 383449 [details]
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.
Attachment #383447 - Attachment is obsolete: true

Comment 47

8 years ago
Created attachment 383726 [details] [diff] [review]
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.
See Also: → bug 290125
You need to log in before you can comment on or make changes to this bug.