- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 5 Jun 2008 09:27:47 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 5 June 2008 02:27:47 UTC