Last Comment Bug 110360 - list numbers not using font-size from CSS
: list numbers not using font-size from CSS
: regression, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: x86 All
-- normal (vote)
: mozilla0.9.9
Assigned To: David Baron :dbaron: ⌚️UTC-8
: Hixie (not reading bugmail)
: Jet Villegas (:jet)
: 112878 113598 127849 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2001-11-15 15:08 PST by Rodd Clarkson
Modified: 2014-04-26 03:32 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (simple) (634 bytes, text/html)
2001-11-15 15:53 PST, basic
no flags Details
possible fix (not yet tested) (3.40 KB, patch)
2002-02-18 08:33 PST, David Baron :dbaron: ⌚️UTC-8
no flags Details | Diff | Splinter Review
testcase showing possibilities (773 bytes, text/html)
2002-02-18 10:11 PST, David Baron :dbaron: ⌚️UTC-8
no flags Details
working patch (3.88 KB, patch)
2002-02-18 10:13 PST, David Baron :dbaron: ⌚️UTC-8
karnaze: review+
attinasi: superreview+
Details | Diff | Splinter Review

Description User image Rodd Clarkson 2001-11-15 15:08:16 PST
<ol> tag not using font-family in CSS.  This may also affect <ul> but I wouldn't
know how to tell.  Also, the font-size element might also be ignored.

Sample html:

<ol class="helpOn">
<li class="helpOn">a list item</li>
<li class="helpOn">another item in list</li>

Sample CSS:

.helpOn:hover {
        font-family: Arial, Helvetica, Lucida, sans-serif; color: #000000;
        font-size: 13px; font-weight: normal; text-decoration: none;

I would expect the ordered numbers to have the same font and size as the text as
the text in the list items.  They don't.
Comment 1 User image basic 2001-11-15 15:40:28 PST
its font-size not font-family
Comment 2 User image David Baron :dbaron: ⌚️UTC-8 2001-11-15 15:45:12 PST
Isn't this a duplicate of bug 5693?
Comment 3 User image Jason Johnston 2001-11-15 15:45:36 PST
This looks like a combination of bug 5693 and bug 96984.
Comment 4 User image basic 2001-11-15 15:48:09 PST
reporter was using 2001111109 Linux trunk
I'm using 2001111203 Win32 trunk and kmeleon5
sodabot from #mozillazine 2001111303 Win32 trunk
Comment 5 User image basic 2001-11-15 15:49:22 PST
the testcase mentioned by the reporter is besides the point. I'll attach a testcase
Comment 6 User image basic 2001-11-15 15:53:15 PST
Created attachment 58026 [details]
testcase (simple)

the attached testcase show that mozilla does not use the "font-size" property
in the list numbers
Comment 7 User image basic 2001-11-15 16:00:02 PST
this worked in ns4, might even be a regression
Comment 8 User image Rodd Clarkson 2001-11-15 16:08:13 PST
Ooops.  I posted up the the wrong line out of my css file when posting the
original example, and it might have confused a few people into thinking this had
something to do with the :hover part.

The CSS should have been:

.helpOn {
        font-family: Arial, Helvetica, Lucida, sans-serif; color: #000000;
        font-size: 13px; font-weight: normal; text-decoration: none;

Basic's example above is a good example of what is going wrong.
Comment 9 User image Tuukka Tolvanen (sp3000) 2001-11-15 16:10:35 PST
0.9.3 wfm, 0.9.4 does not
Comment 10 User image basic 2001-11-19 06:29:19 PST
maybe this blocks bug 91672 ? rule tree stuff?
Comment 11 User image basic 2001-11-19 06:49:50 PST
Pierre: could you check if this is another one of the rule tree landing
regressions (aka bug 91672)?
Comment 12 User image Pierre Saslawsky 2001-11-19 16:11:36 PST
It is a regression that happened sometime between 08/30 and 09/24: nothing to do 
with the rule tree.  It is probably related to bug 96031 / bug 22899.
Comment 13 User image R.K.Aa. 2001-11-30 11:29:46 PST
*** Bug 112878 has been marked as a duplicate of this bug. ***
Comment 14 User image Boris Zbarsky [:bz] (still a bit busy) 2001-12-05 08:01:23 PST
*** Bug 113598 has been marked as a duplicate of this bug. ***
Comment 15 User image Benjamin Mucci 2001-12-11 18:10:16 PST
Confirm under Mac -> Platform All
Comment 16 User image rob cherny 2002-02-04 05:13:59 PST
This is a pretty serious regression.  you can't control the size of the numbers
in an ordered list.  see test case:

I think this is pretty bad. i'd like to think this could get fixed ASAP.  These
regressions are bad news.  This worked fine in earlier mozillas and went bad
somewhere around the milestones used for NS 6.2 ... works fine in NS6.0, 6.1 ... 

Comment 17 User image David Baron :dbaron: ⌚️UTC-8 2002-02-04 07:13:02 PST
It turns out this was done intentionally, to "fix" bug 97351.  To really fix
that bug requires parenting the list bullet's style context to the parent of the
block it's related to rather than to the block itself.
Comment 18 User image Marc Attinasi 2002-02-12 10:36:09 PST
Yes, this was done to fix another bug (IE compat).  However, I thought I tested
the OL case - apparently I did not do it right.

Having style context parentage differ from frame parentage is freightening to
me.  I think there are assumptions that the trees match, and only tables break
that AFAIK.

I can think of two other approaches: 

1) change the selector to
  ul > li:-moz-list-bullet {
    font-size: -moz-initial;

2) change the pseudo used for numerals to -moz-list-numeral so we can
differentiate between the two cases.

In an email I received from Luke Stone, he suggested we hack the bullet sizing
code to implement the quirk.  Something like checking for quirks mode and then
using the default font size for the bullets rather than the size in the style
struct.  I personally prefer the child-selector approach, but only because it is
easier and it will allow me to go back to fixing the crashers I have on my plate.
Comment 19 User image David Baron :dbaron: ⌚️UTC-8 2002-02-12 10:52:27 PST
But is bug 97351 even fixed for the case where the UL has a non-default font size?
Comment 20 User image David Baron :dbaron: ⌚️UTC-8 2002-02-18 08:33:02 PST
Created attachment 70074 [details] [diff] [review]
possible fix (not yet tested)

This is a possible fix.  I haven't yet tested it, or even compiled it.	I also
haven't yet had a chance to test the IE behavior that we're trying to imitate.
Comment 21 User image David Baron :dbaron: ⌚️UTC-8 2002-02-18 08:35:02 PST
To get it to compile, I have to move these 2 lines up:

      const nsStyleList* styleList;
      GetStyleData(eStyleStruct_List, (const nsStyleStruct*&) styleList);
Comment 22 User image David Baron :dbaron: ⌚️UTC-8 2002-02-18 10:11:27 PST
Created attachment 70092 [details]
testcase showing possibilities
Comment 23 User image David Baron :dbaron: ⌚️UTC-8 2002-02-18 10:12:34 PST
Comment on attachment 70092 [details]
testcase showing possibilities

Oops.  Some of the OL testcases say UL.
Comment 24 User image David Baron :dbaron: ⌚️UTC-8 2002-02-18 10:13:48 PST
Created attachment 70093 [details] [diff] [review]
working patch
Comment 25 User image David Baron :dbaron: ⌚️UTC-8 2002-02-19 11:21:12 PST
Comment on attachment 70092 [details]
testcase showing possibilities

WinIE 5.5 displays this testcase with all bullets the same size but the number
always the same size as the LI text.  That's what my patch makes Mozilla do.
Comment 26 User image Marc Attinasi 2002-02-19 13:49:25 PST
Comment on attachment 70093 [details] [diff] [review]
working patch

sr=attinasi - exactly what I was thinking...
Comment 27 User image karnaze (gone) 2002-02-20 14:23:41 PST
Comment on attachment 70093 [details] [diff] [review]
working patch

r=karnaze, I guess styleList can never be null.
Comment 28 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2002-02-20 14:39:16 PST
a=roc+moz for 0.9.9
Comment 29 User image David Baron :dbaron: ⌚️UTC-8 2002-02-20 17:42:39 PST
Fix checked in 2002-02-20 17:36 PST.
Comment 30 User image Marc Boullet 2002-02-26 08:25:09 PST
*** Bug 127849 has been marked as a duplicate of this bug. ***
Comment 31 User image Madhur Bhatia 2002-10-18 11:25:11 PDT

Note You need to log in before you can comment on or make changes to this bug.