{ib}style not inherited inside floated span

RESOLVED WORKSFORME

Status

()

Core
CSS Parsing and Computation
P3
normal
RESOLVED WORKSFORME
19 years ago
16 years ago

People

(Reporter: Ian Graham, Assigned: Marc Attinasi)

Tracking

({css1, testcase})

Trunk
Future
x86
Windows 98
css1, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P3], URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
Given
<a href="...."><span>some text</span>more text</a>

Then the cursor property should be inherited inside the span --
or at least that's what I would expect to happen. This does not
always take place, as illustrated in the URL-referenced document.

An example illustrating the bug is shown in (B). Here,
the span is floated to the left: the resulting
span content is active (it works as a link), but does not inherit
the cursor property corresponding to a link.

As (C) shows, an explicit cursor:inherit declaration fixes this --
but since cursor is by default inherited (see Section 18.1), this
should not be needed ....

Also, as shown in (D), if the text content of the span is replaced
by an img, then the span content _does_ inherit the 'pointer'
cursor from the anchor element.

Tested on Nov 20 nightly build...., Windows 98.

Comment 1

18 years ago
Testing the URL, in none of the 4 testcases provided did the cursor over an
anchor become the proper "hand pointing" cursor whether over the span or not.
The reason for this is probably the same reason that none of the Anchor links
work, which is probably bug 21186 "[DOGFOOD] Can't click on links in CNET story"
(also has <span> inside <a>, see comments ). As it is and at present the
testcases are untestable.

Tested with: 1999-12-14-08-M12 nightly binary on Windows NT 4.0sp3

Suggest making this bug dependent on bug 21186.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 2

18 years ago
Agreed: marked as dependent of bug 21186.
Thanks, Ian, for the excellent testcase.

Comment 3

18 years ago
Pushing my M15 bugs to M16

Updated

18 years ago
Target Milestone: M16 → M18

Comment 4

18 years ago
Created attachment 9976 [details]
testcase from the reporter

Comment 5

18 years ago
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another known 
resource will be working on this bug, or if it blocks your work in some way -- 
please attach your concern to the bug for reconsideration. 
Target Milestone: M18 → Future
Keywords: correctness, css1, testcase
(Assignee)

Comment 6

18 years ago
This is a dup of 51113, which is a more general statement of the problem with a
patch.


*** This bug has been marked as a duplicate of 51113 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 7

18 years ago
Verified dupe.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

17 years ago
This bug is not fixed in Mozilla 0.7 (WIndows 98R2) as indicated 
by viewing the test case
http://smaug.java.utoronto.ca/NS5-bugs/cursor-inherit-test.html
(note that the 'attached' test case is missing an image file).

First look to Example (b). The underline initially should, and does, span 
the entire anchor. But if the mouse moves over the link, the underline 
vanishes from the text inside the <span>, and does not return when the 
mouse moves off the link. 

I believe this is a rendering bug. This is not an inheritance bug, as 
the underline should be a property of the <a> element, and should be 
drawn under the <span> content, and have the same f.g. color as the 
<a> (which it does, at least until it disappears ;-) ) 

There is also an inheritance bug, however, as the cursor type inside the 
<span> should (by default) inherit from the parent <a>, and does not.


Example (C) is similar, except in this case mousing over and off the 
anchor causes both the background color and underline for the <span> 
to vanish. 

Ian (the other one) will be able to verify whether or not these are 
all CSS bugs, or perhaps my misinterpretation of hte CSS1/2 specs.
But, regardless of interpretation, the browser shouldn't render the
content differently before and after the mouse rolls of the link.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
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
(Reporter)

Comment 10

17 years ago
For additional (I hope) clarity, I've prepared a second test case,
http://smaug.java.utoronto.ca/NS5-bugs/cursor-inherit-test2.html,
that has text nodes before and after the floated <span>. This
demonstrates the same bugs, but at least puts the floated 
span on a new line.
Whiteboard: [Hixie-P3]

Comment 11

17 years ago
The remainer part of this bug is not a problem with the cursor but a rendering 
problem with floating elements.  The floating spans don't inherit the style 
correctly.  It is related to the fact that floating inline elements should be 
displayed as blocks (see EnsureBlockDisplay()) but then we end up with a block 
element which should be considered style-wise as a child of the inline anchor 
element.

Ian: am I correct?
Marc: do we want to fix this?  At the best, I would leave it Future but I won't 
mind if you mark it WontFix.
Assignee: pierre → attinasi
Status: REOPENED → NEW

Updated

17 years ago
Summary: cursor: inheritance bug: not inherited inside floated span → style not inherited inside floated span
(Assignee)

Comment 12

17 years ago
Accepting, leaving as future for now...
Status: NEW → ASSIGNED
Summary: style not inherited inside floated span → {ib}style not inherited inside floated span

Comment 13

16 years ago
WorksForMe using FizzillaCFM/2002070913. In all four tests, the cursor changes
to pointer over both the anchor and the SPAN.
Works here in 2002070708 Win32 Nightly (WinXP). Resolving WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.