Closed Bug 97351 Opened 23 years ago Closed 23 years ago

[FIX] bullets should not inherit "size" property for backwards compat.

Categories

(Core :: Layout, defect, P2)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED
mozilla0.9.5

People

(Reporter: harishd, Assigned: attinasi)

References

Details

(Keywords: topembed, Whiteboard: checked into trunk,0.9.2 branch and 0.9.4 branch)

Attachments

(2 files)

Self explanatory testcase:

<ul>
<font size="30pt" color="red">
<li> This text should be 30pt red. But the bullet should be the default size (
per IE )
</font>
</ul>
Forgot to mention:

You need to apply the patch in bug 96031 to see this problem. Without the patch
none of the properties would get inherited by the bullet.
Blocks: 96031
Marking topembed since this blocks a topembed bug (sigh).

Status: NEW → ASSIGNED
Keywords: topembed
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
With the patch in bug 96031 the bullet, refer to example 1, appears round in
shape and red in color ( just like IE ) however, if I make the SIZE to be a non
negative value, refer to example 2, then we render differently than IE. So, I'm
not sure whether we should or shouldn't ignore the SIZE attribute.

Example 1: <FONT color=red SIZE=-1><li><b>Recoded:</b>

Example 2: <FONT color=red SIZE=+1><li><b>Recoded:</b>
Add this to quirk.css

/* QUIRK: force bullet to be the default size for IE compatability
 */
*|*:-moz-list-bullet {
  font-size: -moz-initial;
}

This rule forces the bullet to be its initial size, regardless of the influence
of the <FONT> tag (in Quirks mode only).
Keywords: patch
Summary: bullets should not inherit "size" property for backwards compat. → [FIX] bullets should not inherit "size" property for backwards compat.
Tested also with OL - the numerals are indeed resized, as they are in IE - this
only changes the bullet behavior.
OK, this patch is better for quirks.css

/* Quirk: prevent bullet from resizing with the list item
 *   see bug 97351
 */
*|li:-moz-list-bullet {
  font-size: -moz-initial;
}
It should be:
  li:-moz-list-bullet
instead of
  *|li:-moz-list-bullet
even though quirk.css is only enabled for quirky html documents

r=pierre with that change
sr=waterson if you and pierre can agree on the selector. :-)
Pierre is right - we do not need th universal namespace. Thanks.
Marc: I'm not sure if I need to open up a new bug to my last test case [
id=48192 ]. Please let me know if I have to. It looks like quirks.css needs
tweaking.
Updated status
Whiteboard: Will check fix into trunk (9/4/2001)
harish, that testcase is a different bug altogether! Please do open a new bug,
and if you have ideas about what needs to be tweaked include that too. Thanks.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
checked into trunk and 0.9.2 branch
Whiteboard: Will check fix into trunk (9/4/2001) → checked into trunk and 0.9.2 branch
Nominating for 0.9.4
Keywords: mozilla0.9.4
a=asa (on behalf of drivers) for checkin to MOZILLA_0_9_4_BRANCH
Checked into 0.9.4 branch, marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: checked into trunk and 0.9.2 branch → checked into trunk,0.9.2 branch and 0.9.4 branch
This fix seems really wrong -- see bug 110360.  Isn't the right fix to parent
the bullet's style context (in quirks mode only?) to the parent of the block
whose bullet it is rather than to the block itself?  Or something like that?
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.
Depends on: 648331
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: