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.