See http://www.w3.org/TR/xhtml1/#h-4.10 This probably isn't supposed to work the way you expected.
I looked into this some more. Firefox's behavior was changed with bug 183683. Duping to a related bug. *** This bug has been marked as a duplicate of 314922 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Thanks a lot for providing the resolution! :-) For my web-site it is an easy fix now but - as a more general thought - was it necessary to introduce such an incompability for Firefox? After reading the rationale in https://bugzilla.mozilla.org/show_bug.cgi?id=183683 I felt it was quite radical to drop the frame/name attribute since it still has a deprecated status just like framesets altogether. The original bug only pointed out that frame/id support was ailing.
The developers may have a better answer, but my take on the situation: While the 'name' attribute has deprecated status, the use of 'id' is mandated in the spec. So as a practical matter I'm not sure what use leaving the 'name' attributes in serves, other than allowing pages to be written that are compatible with HTML without causing validation errors. In any case, the Firefox 1.0 behavior was incorrect. Regarding compatability, Firefox has a 'quirks' rendering mode to match old Netscape and IE behavior (see http://developer.mozilla.org/en/docs/Mozilla's_Quirks_Mode). XML/XHTML on the other hand does not have the same amount of [incorrect] legacy content, so there's less of a reason to support documents that don't meet the requirements set forth in the spec (and such documents are always processed in 'strict' mode). You may also want to read http://www.hixie.ch/advocacy/xhtml for a discussion on HTML vs XHTML.
I am seeing the points you make and do agree. Still, from a support viewpoint I have to consider it somewhat unnecessary to ruin end-user experience of Firefox just because a deprecated feature is dropped as soon as possible.
You need to log in before you can comment on or make changes to this bug.