[whatwg] usemap="" and related issues

[Ian Hickson]

On Wed, 15 Nov 2006, Shadow2531 wrote:
> 
> begin<map></map>end
> 
> In Opera and IE, you'll see beginend. In Firefox quirks mode, you'll see 
> the same. In Firefox standards mode, you'll see:
>
> begin
> end
> 
> The default style applied to the map element varies between browser and 
> rendering mode.
> 
> Someone once pointed out to me that even if the map element has a 
> content model of block, that doesn't mean it should have a default style 
> of block applied to it. That is a css issue though.
> 
> Anyway, yeh, if you put stuff inside map, it takes up space except for 
> <area> and <param> etc.

I'm not sure what to do about this. I guess maybe we should just make 
<map> 'display:inline' in the default CSS?


On Tue, 28 Nov 2006, Simon Pieters wrote:
> 
> Currently <map> only allows block-level elements, and <area> is 
> considered a strictly inline-level content (but only allowed as a 
> descendant of <map>).
> 
> HTML4 allowed either block-level elements or <area>s as children of 
> <map>, where the idea with block-level elements was to use a paragraph 
> or a list with <a> elements that acted as areas.
> 
> When authors switch from HTML4 to HTML5 they will find that the 
> conformance checker complains about lack of block-level elements in 
> <map> and then they will just insert a <div> or a <p> around all areas 
> and complain about the change.
> 
> Now <a> can't act as areas anymore in HTML5. But why are block-level 
> elements required? Is the intent that authors should place their <area>s 
> in paragraphs or lists? Why? Isn't it better to only allow <area>s as 
> children of <map>s, and then let UAs treat the <area>s as being a list 
> of links when used as fallback (as described in [1])?
>
> [1] http://www.hixie.ch/specs/html/usemap-alt

This is moot now right?


On Wed, 8 Aug 2007, Anne van Kesteren wrote:
> On Wed, 08 Aug 2007 07:54:33 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > Should we drop it? My research indicates there's an insignificant 
> > number of pages with usemap="" attributes on <input type=image> 
> > elements (on the order of 0.008%).
> 
> The only usecase, while using <input> as control, seems to be to make 
> certain parts of the image not "clickable". Given that, it makes sense 
> to me to reduce the number of attributes browsers have to implement for 
> <input>...

Ok it's only on <img> and <object>.


On Wed, 8 Aug 2007, Michael A. Puls II wrote:
> 
> Just wan to be sure:
> 
> Even though id is required, name is allowed on <map>. Correct? (It 
> currently needs to be for Safari and Firefox in text/html or image maps 
> won't work (even on trunk versions)

I've changed the spec to require name="" instead of requiring id="", based 
on the collective feedback on this issue.


> So, it seems it might have to be case-sensitive for xhtml5 (since other 
> things are case-sensitive in xml)  and case-insensitive for html5. 
> (Unless there's no need to be case-sensitive for XHTML5. If so, then 
> Opera's way would be cool.)

I'm trying to minimise the differences, so I've left it as insensitive.


On Fri, 10 Aug 2007, Benjamin Hawkes-Lewis wrote:
> 
> Since HTML5 handles standard HTML, tag soup, and faux-XHTML (i.e. almost 
> all public web content), what is the benefit of introducing a backwards 
> incompatibility with the XHTML 1.x specifications for the 
> application/xhtml+xml serialization, in which any content (the "esoteric 
> cases" Hixie mentioned) correctly relying on case sensitivity would 
> break?

The only time this would break anything is if a page is using XML _and_ 
relying on two names different only in case to match differently. That's a 
pretty specific case and unless someone knows of a case that does this, 
I'm willing to risk breaking it to get the simplicity of fewer 
differences between the modes.


On Sat, 18 Aug 2007, Jonas Sicking wrote:
> 
> Since ID is case sensitive everywhere else, I don't see a reason to make 
> an exception from that rule here. That seems to unnecessarily complicate 
> implementation as well as introduce weird inconsistencies for authors.

It already is inconsistent for usemap="". At least for legacy Web content 
I don't think we can do much about it. At that point, I'd rather just 
extend that to XHTML than to keep another difference.


On Mon, 20 Aug 2007, Jonas Sicking wrote:
> 
> Why can't you keep ids case sensitive always for all those? Seems weird 
> from a user perspective that ids are case sensitive in all cases except 
> this one.

Well, they should be using name="" anyway, so it's not like they'll run 
into this much.


> In gecko we keep a hash for id->element which is case sensitive. This 
> hash is used for the implementation of getElementById, anchor scrolling, 
> and anything else that uses ids.
> 
> We also have a hash for name->element which is case insensitive, this 
> hash is used for things like form.elements.foo and document.foo and 
> anything else that uses names.
> 
> What you suggest is to add a third hash for id->element which would be 
> case insensitive and only used for <map>s.

I think a hash would be overkill for this, except for the rare case 
where there are a lot of <map>s.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'