Closed Bug 11431 Opened 26 years ago Closed 25 years ago

content inside of <MAP> is not displayed

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mshenha, Assigned: ian)

References

(
URL
)

Details

(5 keywords, Whiteboard: fixed by setting MAP {display: block}in HTML.CSS)

Attachments

(5 files)

reduced test case
146 bytes, text/html
Details
Extended test case
515 bytes, text/html
Details
Test case - normal behaviour
706 bytes, text/html
Details
Test case - map as inline element
738 bytes, text/html
Details
Test case - map as block element
737 bytes, text/html
Details
I use a win98 (build 4.10.1998 hebrew enabled) and using the milestone 8 Mozilla. The main page at www.aopen.com.tw has a big picture (composed out of several smaller pictures). On any other browser the picture would be intact. On the minestone 8, the smaller pictures do not allign correctly. They form some sort of one long thin picture. I use a 1024x768 screen area
Assignee: karnaze → pollmann
Reassigning to Eric.
Assignee: pollmann → troy
Component: HTMLFrames → Layout
OS: Windows 98 → All
Hardware: PC → All
Summary: <MAP> as a block element: backwards compatability?
I'm *really* confused as to why I got this bug. There are no framesets or form elements. Upon examination, the page is one large table with layout problems. I was going to reassign it back to Chris, but he seemed happy with his newly lowered bug count so I actually took 20 minutes to reduce it down. The problem is this: <html> <body> <img src="http://bugzilla.mozilla.org/ant.jpg"> <MAP></MAP> <img src="http://bugzilla.mozilla.org/ant.jpg"> </body> </html> The <MAP> is forcing a line break, even when the window is wide enough to display both images side by side. This is because the map is a block element. I changed the definition in ua.css to display: none and this "bug" went away. I'm not making that change because according to the spec, if there is content other than <AREA> tags inside the <MAP> it should be treated as a block container. Kipp or Troy, do you know how this should be handled (or if we are already doing the right thing here?)
Attached file reduced test case —
Assignee: troy → kipp
Kipp probably knows
Status: NEW → ASSIGNED
Summary: <MAP> as a block element: backwards compatability? → {compat} <MAP> as a block element: backwards compatability?
Target Milestone: M10
See bug 7660 -- we are basically doing the right thing. <map> elements should act like <p> elements. What we really need is a CSS3 extension such as the one I proposed on www-style, that can check on the contents of the element. Then we could do: MAP:matches(*) { display: block; } MAP, MAP:matches(AREA) { display: none; } ...or something like that. Since this is a {compat} bug I am leaving it, but really I suggest that this should be marked REMIND or INVALID.
Target Milestone: M10 → M12
Target Milestone: M12 → M15
Actually, per HTML 4.01 the <MAP> element can take anything, even mixed <AREA> and <A> elements and everything. So we would have to do something excruciatingly silly like this: MAP { display: block; } MAP:empty, MAP:matches(AREA:first-node):matches(AREA:last-node):not-matches(!AREA) { display: none; } ...which basically should (given almost all of my new selector suggestions...) make MAP elements that are either empty or _only_ contain AREA elements have a display of 'none'. I very seriously think we should mark this INVALID; pages with empty <MAP> elements between inline images are really *asking* for trouble...
QA Contact: beppe → petersen
Updating to default Layout Assignee...kipp no longer with us :-(
Why are you re-reassing layout bugs? Do NOT touch layout bugs. The bugs are assigned to Kipp so they can stay neatly organized until we have a new owner for the block/inline code.
Severity: normal → minor
Priority: P3 → P4
Summary: {compat} <MAP> as a block element: backwards compatability? → {compat} [BLOCK] <MAP> as a block element: backwards compatability?
mine! mine mine mine! all mine! whoo-hoo!
Assignee: kipp → buster
(Hmm... Actually that stylesheet snippet I quote above is not quite enough, since it would still hide a MAP element that started with an AREA element, ended with an AREA element, but had some PCDATA in between... Hmm... What we need is: MAP { display: block; } MAP:empty, MAP:matches(>AREA:only-type-of-node) { display: none } ...but now I really am getting silly...) I still think we should mark this INVALID. Or at least WONTFIX.
Keywords: compat
Summary: {compat} [BLOCK] <MAP> as a block element: backwards compatability? → <MAP> as a block element: backwards compatability? [BLOCK]
*** Bug 34586 has been marked as a duplicate of this bug. ***
Note: We are currently VERY wrong, in that our html.css apparently says MAP { display: none; } This should NOT be the case. We should at least say MAP { display: block; } /* Before changing this see bug 11431 */ Setting MAPs to be invisible (display:none) is contrary to the HTML spec and will beak bug 34586.
Whiteboard: MAP is currently set to "display:none" which is wrong.
Leaving map set to display:none breaks the fewest number of pages. It'll probably have to do for the first release. The way to fix this is to leave display:none in the style sheet. Then, during frame construction, after we've processed all the children of the map, we scan then for something other than area. If we find something other than area, we re-run the frame construction manually changing that instance of MAP's style struct display to block. It's probably a day's worth of work. I'm very tempted to just "FUTURE" this one, but leaving on the list in case someone finds the time to fix it. Very soon, it will be too late for the first release. cc'ing Eric, since this is a compat and standards issue. Eric, how widespread is the idiom of MAP containing block elements? Any idea? also cc'ing Rick: don't you have a tool that can scan the web for content patterns?
Status: NEW → ASSIGNED
Keywords: helpwanted
Buster: Yes, I have a tool that can scour the web for usage patterns. And there are other tools already in the public domain that do it as well. Also: I can easily tell the contentsink whether the map contains nothing/area only/or other. (Probably an hour of work) -- if that helps. I would also agree to simply marking this "future".
Even if the parser told us the MAP's content in time for us to make a good decision about it, what would we do in the case of the DOM adding/removing MAP children? We'd still need logic in the frame constructor code to get this right 100% of the time. Rick: could you set your tool loose on the web and see how many MAPs contain elements other than AREA? If the % of MAPs that contain non-AREA elements is small, let's just FUTURE this.
If we say MAP { display: block; } ...then we are correct per HTML4 but we break lots (?) of pages. If we say MAP { display: none; } ...then we are wrong and we break lots (?) of other pages. If we say MAP { display: inline; } ...then we are wrong again, and break a third set of pages. We break pages either way, but the first is correct per the HTML spec. I would personally change the following line in html.css: MAP { display: none; } ...to: MAP { display: block; } /* Before changing this see bug 11431 */ ...(including the comment). If we do the "display:none" then we are going to HIDE valid content; if we do "display:block" then we are only going to be causing layout errors (adding 1em whitespace here and there, probably). However, I would be interested in seeing the results of a trawl of the web to find out what patterns there are, regarding the content of AREA elements. If we need logic in the frame code then I would recommend not doing it until bug 8131 is fixed (currently marked Future), since that will need it too. Note: If you _do_ do that code, then please make the logic of "does this element contain only elements of this type" be a -moz-css pseudo class rather than some hardcoded system...
Blocks: html4.01
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: M17 → Future
Nominating for nsbeta3. This is an important HTML4 compliance issue. MAP should work correctly. We are losing content here because MAP is set to display:none. This is just a one line fix in html.css, and will swap behaviour which causes problems but is non-standard, for behaviour which causes problems and which is correct per the HTML4 spec. If we are going to cause problems, we might as well do it right.
Keywords: nsbeta3
Whiteboard: MAP is currently set to "display:none" which is wrong. → [fix in hand] MAP is currently set to "display:none" which is wrong.
I don't think that I can approve this at this time. When Stever comes back from Africa I'll talk to him about his concerns vis a vis the pages that will break. I agree with Ian that it is better to display the content and risk bad layout (rather than simply hiding content) however there may be more to the issue, like a crash? Leaving on the nsbeta3 radar for now...
Keywords: correctness, dataloss
Summary: <MAP> as a block element: backwards compatability? [BLOCK] → <MAP> as a block element: backwards compatability? [BLOCK]
Severity: minor → normal
Raising priority to normal - this is not a "minor loss of function", IMHO. Should this be marked a dup of bug 2970 (or the other way around)?
A quick look confirms that Nav 4.x, IE 5.5 and Opera 4.02 (Win32 versions) all show MAP element's contents, so I'm adding '4xp' keyword.
Keywords: 4xp
*** Bug 2970 has been marked as a duplicate of this bug. ***
*** Bug 48778 has been marked as a duplicate of this bug. ***
Taking this since it is an html.css fix. I am leaning towards making MAP be display:block. If anyone has strong views about this, please speak now.
Assignee: buster → py8ieh=bugzilla
URL: http://www.ebay.com/
Status: ASSIGNED → NEW
Keywords: testcase, top100
I'm concerned about the variant nature of <MAP>. It's been a while, but what I remember is that <MAP> should act like display:none if it has no children or if it has 1 or more children that are all of type <AREA>. Otherwise, it should act as display:block. So, to fix it right we need logic to detect what type of children the MAP has, and if it's only children are all <AREA> we need to make it have 0 impact on layout. Could we do this by setting something other than display:none on MAP in the style sheet? In any event, setting it to display:block is the lesser of 2 evils, but only just barely. The extra white space introduced by <MAP> elements that are not meant to display anything can really screw up table-based layout. Rick, maybe this is something you could work with Ian on? Maybe we could have go with the default display:block, and in frame construction or content sink code we could detect the close of the </MAP> and scan it's children. If we find only <AREA>, we could set that instance of MAP's display:none and let incremental style change magic do it's thing.
the relevant part of the HTML 4 spec is: http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.6.1
Buster, Rick: see my comments dated 2000-04-14 07:31 and 2000-06-05 12:22. Buster: There are no crash issues that you are aware of, right? (re: Marc's last comments on this bug.) Rick: Do you have a tool that could tell us how many pages of the top100 and related sites have <MAP> elements than contain elements other than <AREA>, only <AREA>, and a mixture?
no known issues wrt crashes in this bug.
Status: NEW → ASSIGNED
Priority: P4 → P1
Target Milestone: Future → M18
Ian, not specifically: but I can easily wire up a testbed. I'll look into it this weekend.
Attached file Extended test case —
Good gracious, this a a true tarbaby bug. Every punch just makes it worse. Looking at the spec posted by buster 2000.08.22 MAP is an inline element. <!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO"> <!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;"> But the writeup for MAP that he points to states that it can contain both %block; and AREA elements. <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map --> Then this pops up in the description of MAP behavior: Note that the user agent should render block-level content of a MAP element. GAH! They've created a THIRD kind of element here. It's "transparent"! An inline element that can contain %block; elements. Bleagh no wonder this is evil! $100,000 question, given all that can it be fixed like this? (from my user.css MAP { display: inline !important; } MAP P,DL,DIV,NOSCRIPT,BLOCKQUOTE,FORM,HR,TABLE,FIELDSET,ADDRESS,H1,H2,H3,H4,H5,H6,UL ,OL,PRE { display: block !important; } In the extended test case I added the above in user.css got IE5,NS4 and Moz2000080820 all doing exactly the same thing. Sure is an ugly style hack and will have to be updated unless there is a handy --moz-block-elem trick for spec'ing all the block elements but it might help?
CCing myself, Bugzilla needs a way to suppress cc's for things like this. =(
Thanks for the testcase. This is an annoying bug, but I am leaning towards making MAP a 'block' element for everthing. The idea of a complex set of rules slows down the whole of Mozilla, and is not fool proof anyway (since you can make P inline, for instance). Rick? Any luck with finding out what MAP's typical contents are? And what MAP's typical parents are, too, if possible? Thanks...
Whiteboard: [fix in hand] MAP is currently set to "display:none" which is wrong. → [nsbeta3+] [fix in hand] MAP is currently set to "display:none" which is wrong.
Ian: the proposed solution won't work compatibly with IE/Nav. It seems that any <map> with leaf content (text/img/etc) renders as block, which <map>'s with inline or block children (but no leaf data) is display:none. After discussion with buster/attinasi (given the dataloss), we propose a new selector: _moz-has-leaf-content, which will have a default css property for. If the <map> contains a leaf, we'll add this hidden property and the css rule will get invoked. I'll take the bug for now (to do my part), then hand it to buster/attinasi to deal with the style rule.
Assignee: py8ieh=bugzilla → rickg
Status: ASSIGNED → NEW
Your assertion regarding legacy behaviour is wrong. The set of testcases I am about to attach show: 1. We do not allow <div> inside <map>, which we should. Rick, this sounds like an easy content sink / DTD fix. 2. IE treats <map> as an inline element. 3. If we treat <map> as an inline element, we will generated an extra space whenever a <map> element appears between block level elements. (IE doesn't because it is quirky.) 4. If we treat <map> as a block element, we will generate a line break whenever a <map> element appears in inline level content. (In my experience this is quite rare.) IE does NOT have special logic relating to leaf elements. I am not sure how this came into the discussion. I recommend we just say display:block and be done with it. This is not that important a problem. There are easy workarounds for authors. Let's concentrate on the real bugs! If you agree, then reassign it to me and I'll do it.
Ian: not so fast, buckaroo. Here's feedback: 1. We DO allow div in <map> (at least I see it on my machine) in the debugger. 2. I suppose 3/4: agreed. I did a slew of tests, and the trick about whether to treat it as block v. inline comes down to whether there is leaf content (hence my comment). If we always treat it as block, then areas are wrong (and folks get mad). If we always treat it as inline, then it can't contain block elements and we'll get the structure wrong. Buster/attinasi and I all feel that filtering on content will produce the best result (modulo post-load scripts).
IIRC, shouldn't that be -moz-has-leaf-content not _moz-has-leaf-content? I seem to recall that proprietary CSS extensions are supposed to be prefixed with a hyphen, not an underscore, and dbaron is currently working on a bug to make that the case for Moz.
Buster/Ian: I will write a test to see how prevalent map in block is, vs map in inline. Thanks.
Ok, per Rick, Buter, Ian: For FCS we can just treat MAP as display:block. This is the lowest risk at this stage. If we wanted to do it in a fully backwards compatible way then we believe that we would have to follow these rules: If the previous sibling is inline level, then treat the MAP as display:inline Otherwise if there are no previous siblings then if the parent is inline level then treat the MAP as display:inline Otherwise, treat MAP as display:block This seems to be a high risk change in a fragile area and it would be hard to get it to dynamically work with the CSS DOM. (Also, we are not 100% sure that this is the correct answer.) I am therefore taking this bug back, and will fix it during the ua.css changes. ekrock: For some reason, we have been using underscores as a prefix for extensions in attributes (as this would have been) and hyphens in prefixes for CSS properties, values and pseudo elements. RELEASE NOTE ITEM: Mozilla is rendering MAP elements as "block level". However, this can cause line breaks when MAP elements are inserted directly into inline content, as is allowed by the HTML4 specification. Authors may work around this by setting their MAP elements to inline level or by hiding them completely in their stylesheets, for example with the following line: MAP { display: inline; } Note, however, that due to the details of the inline box model of CSS, setting MAP to inline level may cause extra whitespace to appear when MAP elements are *not* within other inline content. This is our reasoning behind setting MAP to block level by default.
Assignee: rickg → py8ieh=bugzilla
Keywords: helpwanted → relnote
Depends on: 3935
per PDT team: PDT concerned about the comments from Ian on 9/6 about "this seems to be a high risk change in a fragile area..." and having such changes at such a date late into the Netscape PR3 and release cycle. Changing the priority to P4. If you feel the priority needs to be higher, please let PDT know and include a reason on the P1 priority based on PDT's P1 criteria and include a user impact/point of view reasoning. Thanks.
Priority: P1 → P4
Whiteboard: [nsbeta3+] [fix in hand] MAP is currently set to "display:none" which is wrong. → [nsbeta3+][PDTP4][fix in hand] MAP is currently set to "display:none" which is wrong.
PDT: You've misunderstood Ian's comment. He was indicating that the full, proper, 100% backwards compatible solution "to do it in a fully backwards compatible way" would be high risk, and therefore we are choosing *not* to attempt that at this time. However, the fix that Ian wants to check in, with mine and Rick's blessings, is very low risk, and gets us most the way to backwards compatibility. I've removed [PDTP4] from the whiteboard because I think it was based on a misinterpretation of Ian's comment. Please approve this.
Whiteboard: [nsbeta3+][PDTP4][fix in hand] MAP is currently set to "display:none" which is wrong. → [nsbeta3+][fix in hand] MAP is currently set to "display:none" which is wrong.
Ok, I'll forward to PDT for reconsideration.
No longer depends on: 3935
Blocks: 6625
Thanks for the explanation. PDT reassessment is a P2.
Priority: P4 → P2
Whiteboard: [nsbeta3+][fix in hand] MAP is currently set to "display:none" which is wrong. → [nsbeta3+][PDTP2][fix in hand] MAP is currently set to "display:none" which is wrong.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Ian, this was fixed with your *.css checkin a couple days ago, right? Please reopen if I'm mistaken, thanks.
blake: You are mistaken. This was fixed by Pierre's checkin of my changes to html.css one day ago. FIXED. Thanks for checking the files in Pierre!
Marking verified in the Sept 29th build.
Status: RESOLVED → VERIFIED
Blocks: 56492
changing summary and status whiteboard to reflect what really is wrong, and what happened to partially fix the problem (good enough for RTM.)
No longer blocks: 56492
Summary: <MAP> as a block element: backwards compatability? [BLOCK] → content inside of <MAP> is not displayed
Whiteboard: [nsbeta3+][PDTP2][fix in hand] MAP is currently set to "display:none" which is wrong. → [nsbeta3+][PDTP2][fix in hand] fixed by setting MAP {display: block}in HTML.CSS
Blocks: 57054
Whiteboard: [nsbeta3+][PDTP2][fix in hand] fixed by setting MAP {display: block}in HTML.CSS → fixed by setting MAP {display: block}in HTML.CSS
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: