When the element input uses usemap=IDREF to point to a client-side image map in the same document, WebKit should make use of that image map in several ways. 1) it should map the area elements within the map element to the appropriate coordinates and shapes onto the image for the input element; 2) it should provide tooltips from the area element's title attribute upon mouse-over on those mapped areas; 3) it should treat those areas generally as frames (though not necessarily rectangular frames) with all of the behaviors and methods of those frames, including: a) receive events b) focus outline indicateion c) apply CSS bos model (though not necessarily rectangular) properties including margin, padding, border and outline. d) apply CSS :hover and other pseudo selectors to the frames corresponding to the area elements e) apply other CSS where appropriate Currently WebKit submits a form onclick, but does not provide any of the benefits of the usemap attribute.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" > <title>Untitled</title> <style type='text/css'> input {height: 100px; width: 200px;} #leftarea {border-style: solid; border-color: red; border-size: 1px; } #rightarea {border-style: solid; border-color: blue; border-size: 1px; } img:hover {cursor: crosshair;} input:hover {cursor: wait;} area:hover {cursor: wait;} </style> </head> <body> <p> <map name=m> <area id=leftarea title='left-side' alt='left-side' shape=rect coords='0,0,100,100' > <area id=rightarea title='right-side' alt='right-side' shape=rect coords='100,0,200,100' > </map> <img src='image'> </p> <form onsubmit='alert("submit")' action=.><input type=image src=image usemap='#m'></form> </body> </html>
This feature is underspecified in HTML4, and not implemented by IE. It is also likely to be dropped in HTML5 and may be removed from Mozilla and Opera as a result.
Clearly, breaking compatibility with IE just because of HTML4 spec is not an option for us. This issue is being extensively discussed by the HTML WG right now, so I do not see any reason to rehash the discussion here. Please re-open this bug if HTML5 draft changes to accommodate this feature.
(In reply to comment #3) > Clearly, breaking compatibility with IE just because of HTML4 spec is not an > option for us. This issue is being extensively discussed by the HTML WG right > now, so I do not see any reason to rehash the discussion here. > > Please re-open this bug if HTML5 draft changes to accommodate this feature. This would not break compatibility with IE. The point is to provide greater visual feedback to the user. The form should still be submitted as WebKit already does. The title attribute tooltip is based on the existing recommendations. and brings parity with Firefox and Opera. The other enhancements would not break compatibility with anything else, but would set WebKit above the competing implementations. As for HTML5, by the editors own admission, this is a recommendation that is years away from reaching candidate recommendation status. We cannot wait until then to fix bugs in WebKit or make enhancements. Once it becomes a candidate recommendation, we can consider what changes should happn to WebKit to bring it in line with the new recommendation.
Created attachment 16048 [details] This demonstrates the different behavior between the client-side image maps when referenced from a INPUT and from and IMG
With this latest attachment,I think the bug is clearly demonstrated. The image maps should behave the same with respect to the @title attribute tooltips. The other features mentioned in the bug are properly feature enhancement requests and filed elsewhere. However, the bug as written in the summary should properly be fixed.
I have a new attachment to replace the previous attachment. I think this better illustrates the problem and that it also applies to OBJECT (also the last example had some non-relevant validation errors). Perhaps a succinct way to put this is: Image maps do not enable feedback such as mouseover tooltips and The relevant discussion in the HTML 4.01 recommendation is here: http://www.w3.org/TR/html4/struct/objects.html#include-maps and here: http://www.w3.org/TR/html4/interact/forms.html#h-17.4.1
Created attachment 16050 [details] This attachment replaces the previous one Shows how image map behavior is inconsistent across the three elements that support client-side image maps
Hello all, First, an importantissimo and excellent testcase meeting well this bug's summary: http://haignet.co.uk/object-image-map.htm Opera 9.26, Opera 9.50, Firefox 3 RC1, Seamonkey 2.0a1 all pass all 4 example-tests in that webpage. Explorer 8 beta 1 passes example-test 1.2. Safari 3.1.1 build 525.17.0 fails all 4 example-tests. Other related/mentioned issues: HTML 4 and HTML 5 both have usemap as an attribute: http://www.whatwg.org/specs/web-apps/current-work/#the-object http://www.whatwg.org/specs/web-apps/current-work/#usemap1 The only changes worth mentioning (so far, at this moment) regarding HTML 4 versus HTML 5 differences is that map and object HTML elements will no longer require (or no longer will use) name attribute and that id attribute should be preferred/used instead. And that W3C draft document was last updated just a few days ago (17 May 2008). <input type="image" usemap="..."> has not been specified so far in HTML 5: http://www.whatwg.org/specs/web-apps/current-work/#the-input Cheers and regards, Gérard (I have just voted for this bug!)
Robert, 1- Could it be possible to split this bug into 2 separate, distinct bugs? ... where bug 15032 new summary would read: "OBJECT element with attribute usemap do not provide client-side image map functionality" 2- How to view webarchive file type? I have 7-zip latest version and can not successfully open attachment 16050 [details] (ImageMap.webarchive). 3-URL http://software.hixie.ch/utilities/js/live-dom-viewer/?... seems not interoperable for Windows users...
I believe example-test 2.2 at http://haignet.co.uk/object-image-map.htm fails just because of bug 5566
(In reply to comment #10) > Robert, > 1- > Could it be possible to split this bug into 2 separate, distinct bugs? ... > where bug 15032 new summary would read: > "OBJECT element with attribute usemap do not provide client-side image map > functionality" Fine with me to split it up. I just want to see WebKit excel in image map UI. > 2- > How to view webarchive file type? I have 7-zip latest version and can not > successfully open attachment 16050 [details] [edit] (ImageMap.webarchive). I'm sorry. I guess I had not considered other browsers when I used that format. You can use Safari on Mac (and probably Windows) to open the file after download. Then it can be saved to as source for use in other browsers. > > 3-URL http://software.hixie.ch/utilities/js/live-dom-viewer/?... seems not > interoperable for Windows users... > Sorry, I think the utility gets updated from time to time and something might have been broken then.
> Fine with me to split it up. Someone besides me will have to do this as I do not have sufficient edit privileges to edit bug report summaries. ---------- > You can use Safari on Mac (and probably Windows) to open the file after > download. Then it can be saved to as source for use in other browsers. Safari 3.1.1 on Windows XP Pro SP3 can not open filetype webarchive. "Safari can't open the file 'ImageMap.webarchive' because no available application can open it" It would have been different with a more widely supported compression format that a wide majority of compression softwares can uncompress. Can you upload a reduced testcase in this bug? ---------- Also, I earlier said "HTML 4 and HTML 5 both have usemap as an attribute" but meant to explicitly say HTML 4 and HTML 5 both have usemap as an attribute for <object>s ---------- > The title attribute tooltip is based on the existing > recommendations. and brings parity with Firefox and Opera. (...) > The image maps should behave the same with respect to the @title > attribute tooltips.(...) > Image maps do not enable feedback such as mouseover tooltips Regarding attribute title tooltip for <area>s, this is implemented in Safari 3.1.1 build 525.17.0: hover the mouse cursor over the upper-left blue rectangle and over the middle-centered blue rectangle in this webpage http://www.mozilla.org/access/qa/tiny/map_area.html and the correspondent title attribute will be displayed in a tooltip in Safari 3.1.1 for Windows ... just like it is in Firefox 2.0.0.14 and Opera 9.50 Cheers, Gérard
" You tried to change the Summary field from (...) to (...) but only the assignee or reporter of the bug, or a sufficiently empowered user may change that field."
Bug 19365 is: <object> element with attribute usemap do not provide client-side image map functionality
References update: ----------------- HTML 4 and HTML 5 both have usemap as an attribute for the HTML object element: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#the-object-element http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#attr-hyperlink-usemap <input type="image" usemap="..."> still has not been specified so far in HTML 5 and I don't think it will be. usemap attribute for <object> is different though. regards, Gérard
See also: bug 14638.
*** Bug 19365 has been marked as a duplicate of this bug. ***
Created attachment 93594 [details] Proposed patch
*** Bug 56654 has been marked as a duplicate of this bug. ***
Comment on attachment 93594 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=93594&action=review > Source/WebCore/html/HTMLObjectElement.cpp:133 > + } else if (attr->name() == usemapAttr && isImageType()) > + setIsLink(!attr->isNull()); This is incomplete. If an object element has a usemap attribute and anything changes that can change the result of isImageType, we will need to call setIsLink at that time too, since it can become false if isImageType becomes false, or become true if isImageType becomes true. Unless there is some reason that it’s OK to have isLink set incorrectly at that time. I’d like to see test cases covering this. That’s the main thing that’s tricky about correctly implementing object elements as opposed to single-purpose elements like the image element -- dynamically changing between different types of embedded content.
Comment on attachment 93594 [details] Proposed patch Clearing r? until I've fixed the issue Darin pointed out.
Another test link: http://haignet.co.uk/object-image-map.htm.
Based on test case from link in Comment 09 and 23, here are updated test results: *** Example 1.1 *** << Safari 15.6 >> Faces are not clickable << Chrome Canary 106 >> Faces are not clickable << Firefox Nightly 105 >> Faces are not clickable -- Summary: All browsers match in the following example although not showing expected results (i.e. clickable) *** Example 1.2 *** << Safari 15.6 >> Does not show bullet / list items (even in Safari Technical Preview 150, which has fix for <object> fallback) << Chrome Canary 106 >> List items show and they are clickable and open links << Firefox Nightly 105 >> List items show and they are clickable and open links -- Summary: Safari / Webkit need to fix this test case. *** Example 2.1 *** << Safari 15.6 >> Faces are not clickable but bullet / item list shows up as well. << Chrome Canary 106 >> Faces are not clickable but bullet / item list shows up as well. << Firefox Nightly 105 >> Faces are not clickable but bullet / item list shows up as well. -- Summary: All browsers match in the following example although not showing expected results (i.e. clickable) *** Example 2.2 *** << Safari 15.6 >> Shows blank space to indicate the image area and bullet / item list shows-up << Chrome Canary 106 >> Does not show blank space area to indicate non-existent image but show bullet / item list. << Firefox Nightly 105 >> Does not show blank space area to indicate non-existent image but show bullet / item list. -- Summary: Safari 15.6 is different here from other browsers. ___________ Appreciate if someone can conclude on from web-spec perspective which behavior needed to be followed in case of deviation from other browsers (Example 1.2 and 2.2). Thanks!