Closed Bug 276651 Opened 20 years ago Closed 20 years ago

MAP ID attribute isn't accepted

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED DUPLICATE of bug 109445

People

(Reporter: web, Unassigned)

Details

Hi there.  Long-time Mozilla user/fan, first-time caller.

I recently noticed that Mozilla-based browsers expect a MAP element to be
identified by the NAME attribute (see bug #269939), as declared in the HTML-4
spec.  However, as I was attempting to code a MAP element in a XHTML 1.0 page, I
learned that the NAME attribute is going away in favor of the ID attribute (see
http://www.w3.org/TR/xhtml1/#h-4.10).

I suppose this could affect other elements that previously accepted either ID or
NAME as listed in the w3 spec referenced above, but I have not tried any of them
to observe Mozilla's behavior.
can you give a URL showing the problem?
I believe this is invalid. We only support the ID attribute for the MAP element
in 'application/xhtml+xml' documents. (It is required for XHTML 1.1 validation.)

Although it might be nice to support it for text/html as well for IE compatibility.
See also bug 109445.
Yep.  This is one of the major areas of incompatibility between XHTML and HTML.
 Since the page is being served as HTML, we should have the HTML behavior, as we do.

*** This bug has been marked as a duplicate of 109445 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
How difficult is it exactly to let ID and NAME behave the same for MAP elements
in text/html documents? Or this is more an advocacy thing? If it is the latter,
I wonder why it is important.

Opera and Internet Explorer already support it.
It's easy to do.  The question is whether it's worth it to violate the HTML
standard that way.

IE treats id and name as equivalent altogether; getElementById will find an
element with a name attr and no id attr.  So what IE does with id/name is just
not a good guideline...
Status: RESOLVED → VERIFIED
Aha.  The difference between using the XHTML DTD while still having a content
type of HTML is truly where the unfortunate behavior I encountered came into
play.  That is a good enough answer for me, which I had overlooked while looking
at this.  Thank you!
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.