[whatwg] usemap="" and related issues
Ian Hickson
ian at hixie.ch
Thu Jun 5 02:27:47 PDT 2008
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list