293070 - [FIX]Ordered lists (<ol> tags) inside <font> display all 0s

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Thomas K. (:tom)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050504
Firefox/1.0+

Ordered lists typically go like this:

1. Item!
2. Item!
3. Item!

They are currently going like this:

0. Item!
0. Item!
0. Item!

Apparently Gecko forgot how to count.

Comment 1

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050505
Firefox/1.0+

He is indeed correct, they are broken on that page.  Unfortunately, I am unable
to see them broken on other pages using ordered lists.  For example, the 403
page on my site uses an ordered list, and appears correctly in latest-trunk. 
http://knightsoftriumph.com/403.shtml

<Tom> Tristor: probably quirks mode ols, google cant code

Perhaps he has something there, perhaps not.  

Removing regression from the keywords since the bug that caused this to regress
is not identified.  Added regression? to the status whiteboard, and the qawanted
keyword for help in finding what caused this issue, I am going to go ahead and
confirm this, since I think maybe Tom has the right idea there with the Quirks
Mode ols being rendered differently than those on valid pages (like mine).

Comment 2

[Tim De Pauw]

Happened on at least Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050419 Firefox/1.0+ already. Also, Google has a <font> tag inside the
<ol> but outside the <li>s.

Comment 3

[Tristor]

(In reply to comment #2)
> Happened on at least Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
> Gecko/20050419 Firefox/1.0+ already. Also, Google has a <font> tag inside the
> <ol> but outside the <li>s.

Oooh, naughty.  I thought Google hired the best and the brightest, they must be
slacking off.  Didn't their momma ever teach them that using markup for styling
was bad?

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

See bug 4522.

The parser can work around this by not allowing <font> to contain <li>, but then
the list items won't get the correct font. I'm not sure what exactly we want to do.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

By the "list items" I mean the "list numbers".

Comment 6

[Tristor]

(In reply to comment #4)
> See bug 4522.
> 
> The parser can work around this by not allowing <font> to contain <li>, but then
> the list items won't get the correct font. I'm not sure what exactly we want
to do.

I am kind of curious why it breaks, because technically (assuming you are being
daft and using presentational markup instead of stylesheets) as long as the
<font> tag is outside the <ol> tag it should be able to affect all the <li>
without any problems.  I believe their tag resides within the <ol> however,
which makes it invalid.  Speaking of invalid, Google can't write markup.
http://validator.w3.org/check?uri=http%3A%2F%2Fwebaccelerator.google.com%2Fsupport.html&charset=%28detect+automatically%29&doctype=%28detect+automatically%29&ss=1&sp=1&No200=1&verbose=1

Comment 7

[Gabe Jones]

I'm seeing this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050505 Firefox/1.0+ on the following sites:

http://desktop.google.com/gettingstarted.html?hl=en
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-javacard.html

The Google site starts at 1, but then gives up and goes back to 0.  The Sun site
is 0 from the start.

Comment 8

[Ronald Tilby]

Attachment: Testcase1

Comment 9

[Justin Wood (:Callek)]

Blake, I would say that if the parser is strict about this, at least the numbers
would be correct.

IMHO, having correct semantic numbering is more important than FONT sizing/face.

That said, you may want to consult other layout peers about this, as you know as
well as I do, that I am far from the guy to make the call.

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: parser workaround

This patch makes <font> not contain <li>. This allows the list numbering to be
correct, however, we don't style the numbers as "expected". This is as close to
a fix as the parser can come to (without fixing things on the layout end).

dbaron, what do you think?

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

This is a regression somewhere in layout. The parser builds the same content
model for the testcase in both Firefox 1.0 and in current trunk builds. This
needs a narrower regression window.

Comment 12

[Ronald Tilby]

Regression Window (Mozilla Suite Nightly Builds on Windows XP):
2005-04-01-05 Pass
2005-04-02-05 Fail

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-01+05&maxdate=2005-04-02-05&cvsroot=%2Fcvsroot

I suspect the checkin for Mozilla Bug 3247

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 182922 [details] [diff] [review]
parser workaround

This isn't the right thing to do.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

We're looking at the wrong content node when we hit the <font>'s blockframe as
we're recursively renumbering...

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed.