images not placed properly with css

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
8 years ago
8 years ago

People

(Reporter: olivier_levillain, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

When placing images using css + javascript, images are not well placed.
The same test works correctly in FF3.6.12 and in IE8.

Reproducible: Always

Steps to Reproduce:
1. Load the attached earth.html if FF4.0b7
2. Put your mouse over south america
Actual Results:  
Displays north america in blue over south america

Expected Results:  
Should have displayed South America in blue

Another test: place your mouse above south *africa*, it shows Russian logo instead of SA logo

All placements are made through constant x/y data in the earth.css file
Exactly the same test works correctly in FF3.6.12 and in IE8.
(Reporter)

Comment 1

8 years ago
Created attachment 494394 [details]
zip file containing the test case files (html, css and gif)
I see the same with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101130 Firefox/4.0b8pre = Google Chrome 9.0.597.0.

And MSIE 8 = Opera 11.1104 = FX 3.6.x.

not sure what is correct though.
Severity: major → normal
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk

Comment 3

8 years ago
The main problem is code like <a href=""/>

<a> is not an empty element, so the self-closing form isn't valid in html. The error handling mechanism involves duplicating the <a>, so it's in two places on the page, hence the visible result.

Testcase:
data:text/html,<ul><li><a/></li> </ul>

NOT testcase (for comparison):
data:text/html,<ul><li><a/></li></ul>

(note the missing space)

I'm willing to bet firefox's behavior is correct, but can't point to exactly where in the spec it says so.
This is XHTML being served as text/html, this is not valid because it
violates Appendix C of the XHTML specification.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Yep.  With the old parser, the </li> closed the unclosed <a>.  But now it stays open until it sees the following <a>.

Henri, is that the right behavior?  If so, given that no other browser does that, would this be worth a spec change?

Real testcase that shows that difference:

  data:text/html,<ul><li><a/></li> <li><a/></li></ul>

Robert, just because the content is invalid doesn't mean changing how we render it is necessarily ok!  Most (all, to a first approximation) content on the web is invalid.
Status: RESOLVED → REOPENED
Component: Layout → HTML: Parser
Ever confirmed: true
QA Contact: layout → parser
Resolution: INVALID → ---
(Reporter)

Comment 6

8 years ago
(In reply to comment #5)
> Robert, just because the content is invalid doesn't mean changing how we render
> it is necessarily ok!  Most (all, to a first approximation) content on the web
> is invalid.

I totally agree with this sentence! if a simple <a/> in an html page breaks this page, how many millions of pages will be broken in the world? Moreover, if it is actually working in FF3.6 and all other browsers...
(In reply to comment #5)
> Henri, is that the right behavior?

Per spec, yes.

> If so, given that no other browser does that, would this be worth a spec change?

I think this isn't worth a spec change.

Chrome 9 does exactly what Firefox 4 does. Also, pre-HTML5 WebKit (as seen in Safari and Midori) behaves similarly even if not exactly the same. IE9 PP7 Standards Mode clones pre-HTML5 WebKit here and works exactly like Safari and Midori.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → WONTFIX
> if a simple <a/> in an html page breaks this page, how many millions of pages
> will be broken in the world?

So far, only one, after many months of testing by hundreds of thousands of people.  ;)

> Moreover, if it is actually working in FF3.6 and all other browsers...

Right; that's the important part.  Except it's not true, apparently, since it doesn't work in Safari and other webkit-based browsers (e.g. in the attached testcase hovering over Egypt in Safari highlights Eastern Europe).

Given that, I agree with the wontfix.  Using valid markup would make this work, for sure.  ;)
(Reporter)

Comment 9

8 years ago
(In reply to comment #8)
Ok, I give up :)
You need to log in before you can comment on or make changes to this bug.