110360 - list numbers not using font-size from CSS

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Rodd Clarkson]

<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>
</ol>

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

[basic]

its font-size not font-family

Comment 2

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

Isn't this a duplicate of bug 5693?

Comment 3

[Jason Johnston]

This looks like a combination of bug 5693 and bug 96984.

Comment 4

[basic]

reporter was using 2001111109 Linux trunk
I'm using 2001111203 Win32 trunk and kmeleon5
sodabot from #mozillazine 2001111303 Win32 trunk

Comment 5

[basic]

the testcase mentioned by the reporter is besides the point. I'll attach a testcase

Comment 6

[basic]

Attachment: testcase (simple)

the attached testcase show that mozilla does not use the "font-size" property
in the list numbers

Comment 7

[basic]

this worked in ns4, might even be a regression

Comment 8

[Rodd Clarkson]

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

[Tuukka Tolvanen (sp3000)]

0.9.3 wfm, 0.9.4 does not

Comment 10

[basic]

maybe this blocks bug 91672 ? rule tree stuff?

Comment 11

[basic]

Pierre: could you check if this is another one of the rule tree landing
regressions (aka bug 91672)?

Comment 12

[Pierre Saslawsky]

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

[R.K.Aa.]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Benjamin Mucci]

Confirm under Mac -> Platform All

Comment 16

[rob cherny]

This is a pretty serious regression.  you can't control the size of the numbers
in an ordered list.  see test case:

http://www.cherny.com/mozilla/lists/liststest.html

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 ... 

:rob

Comment 17

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

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

[Marc Attinasi]

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

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

But is bug 97351 even fixed for the case where the UL has a non-default font size?

Comment 20

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

Attachment: 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

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

To get it to compile, I have to move these 2 lines up:

      const nsStyleList* styleList;
      GetStyleData(eStyleStruct_List, (const nsStyleStruct*&) styleList);

Comment 22

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

Attachment: testcase showing possibilities

Comment 23

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

Comment on attachment 70092 [details]
testcase showing possibilities

Oops.  Some of the OL testcases say UL.

Comment 24

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

Attachment: working patch

Comment 25

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

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

[Marc Attinasi]

Comment on attachment 70093 [details] [diff] [review]
working patch

sr=attinasi - exactly what I was thinking...

Comment 27

[karnaze (gone)]

Comment on attachment 70093 [details] [diff] [review]
working patch

r=karnaze, I guess styleList can never be null.

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz for 0.9.9

Comment 29

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

Fix checked in 2002-02-20 17:36 PST.

Comment 30

[Marc Boullet]

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

Comment 31

[Madhur Bhatia]

verified