MozillaZine

Exact capitalization on link anchors is a bug

Discussion of bugs in Mozilla Firefox
dmcritchie
 
Posts: 30
Joined: September 3rd, 2004, 1:14 pm

Post Posted September 3rd, 2004, 1:34 pm

Firefox incorrectly requires matching capitalizations for local link anchors (#)

While unix servers are case sensitive for url names past the domain name
it is incorrect for for this case sensitivity to apply to local anchors.

i.e the follow should all work:
http://www.mvps.org/dmcritchie/firefox/ ... tm#fireFOX
http://www.mvps.org/dmcritchie/firefox/ ... tm#firefox

Tested on both Firefox 0.9.2 and 0.9.3,
no problem in Mozilla, Internet Explorer or any previous browser, I have
ever used.

David McRitchie, and the above is my Firefox page

Mook
 
Posts: 1752
Joined: November 7th, 2002, 9:35 pm

Post Posted September 3rd, 2004, 8:57 pm

Hmm, is that supposed to work?

The HTML 4 specs say:
http://www.w3.org/TR/html4/struct/links.html#h-12.2.1 wrote:String matching: Comparisons between fragment identifiers and anchor names must be done by exact (case-sensitive) match.


The same page also says:
http://www.w3.org/TR/html4/struct/links.html#h-12.2.1 wrote:Although the following excerpt is legal HTML, the behavior of the user agent is not defined; some user agents may (incorrectly) consider this a match and others may not.


So maybe it should be done in quirks mode - my simple test says it isn't. That might be worthy of an RFE. (Your page is in strict mode, so there really is no question - it should match the standards.)
poot.

Atropos

User avatar
 
Posts: 1116
Joined: December 4th, 2002, 6:18 pm
Location: Texas

Post Posted September 4th, 2004, 3:11 pm

Mozilla Suite 1.7.2 follows the standards as well.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

dmcritchie
 
Posts: 30
Joined: September 3rd, 2004, 1:14 pm

Post Posted September 4th, 2004, 4:19 pm

I guess I accidentally put in the "correct" anchorname when I tested with
Mozilla 1.4 or changed my HTML since failing Firefox and succeeding at Mozilla.

But this is a strange standard that after stating that uniqueness of lettering
regardless of capitalization is required, that unmatched capitalization is
specifically undefined (by definition ?), that user agents are free to do
whatever they want with regard to capitalization, and to state that unmatched
capitalization is "(incorrect)".

Atropos

User avatar
 
Posts: 1116
Joined: December 4th, 2002, 6:18 pm
Location: Texas

Post Posted September 4th, 2004, 10:27 pm

They're just saying they are not going to tell you what your web browser should do if finds two of the same id if it incorrectly ignores case. If I told you to paint <i>the car</i> red, and there was more than one, what would you do? Don't ask the W3C, they don't know.

BenBasson
Moderator

User avatar
 
Posts: 13671
Joined: February 13th, 2004, 5:49 am
Location: London, UK

Post Posted September 5th, 2004, 2:16 am

IMO, it should be case sensitive, just as filenames are. Is there a reason you particularly want them to be non-case sensitive, or was it just an observation?

dmcritchie
 
Posts: 30
Joined: September 3rd, 2004, 1:14 pm

Post Posted September 5th, 2004, 6:07 am

Filenames should never have been case sensiive, that is a unix restriction,
and was very bad software design, if that's what they want on their servers okay,
but it should never be forced on others for their servers.

I don't know what may be in the standard in that regard to filenames but that is the cause
of all of this nonsense. And probably why the standards make VERY clear that
the standard will not allow anchor names that are the same but for letter case.
But having said that it is very contrived to say that it "(should)" be sensitve to lettercase
in usage.

dmcritchie
 
Posts: 30
Joined: September 3rd, 2004, 1:14 pm

Post Posted September 5th, 2004, 7:03 am

Sorry missed the part about WHY I don't want them to be case sensitive.
1) I'd never seen them case sensitive before, anyone I told about Firefox
requiring case sensitivity told me Firefox would be in clear violation of standards

I guess they are not in violation because while the standard very clearly defines that you
can't make different anchors based on lettercase, and while it specifically says that
use of a reference to an anchor not in the same lettercase is UNDEFINED, it then
whimsically states in parenthesis the exact opposite.

2) For myself.
I want people to be be able type it in correctly and know exactly what letter is used,
and without regard to letter case and contrivances to only use lowercase. Enforcing
lettercase where the standard delibertly forbids prohibits names made distinct by
lettercase is capricious to say the least.

Fonts do not consistently distinguish what letters are which and sometimes even if you
look very carefully you can't tell because in some fonts a lowercase L is exactly the
the same as a number 1. Words usuallly aren't a problem except for first letter, which
could be a Capital I or a lowecase L, but can be a big problem when acronyms are used
or when numbers are mixed with letters or it just looks like numbers may be mixed with
letters.

Atropos

User avatar
 
Posts: 1116
Joined: December 4th, 2002, 6:18 pm
Location: Texas

Post Posted September 5th, 2004, 8:07 pm

I don't know what may be in the standard in that regard to filenames but that is the cause
of all of this nonsense.

It ridiculous to say case-sensitive filesystems caused the W3C working group to decide that fragment indentifies should be case-sensitive too unless you can back that up. All computer standards will specifically state whether or not something is case-sensitive or not. For example, in XHTML the tag and attribute names must be lowercase. Programming languagues can be case-sensitive to - in Perl $TTY is not the same variable as $tty. HTTP says the headers are case-insenstive, ie content-type is the same as Content-Type. We could go on all week here.

1) I'd never seen them case sensitive before, anyone I told about Firefox
requiring case sensitivity told me Firefox would be in clear violation of standards

That makes me laugh - how can they say it is in clear violation of the standards if the standards are requiring case-sensitivty?

I guess they are not in violation because while the standard very clearly defines that you
can't make different anchors based on lettercase, and while it specifically says that
use of a reference to an anchor not in the same lettercase is UNDEFINED, it then
whimsically states in parenthesis the exact opposite.


The standards are saying that they browser can do whatever it wants if the fragment id provided does not match any anchor names in the document, except that a browser should not consider it to match an anchor name that differs only in case. And Firefox follows this standard. I'll only agree that it doesn't make sense to make the comparison of fragment identifes and anchor names case sensitive because none of the other uses for ids (CSS, scripting, etc) require case sensitivity. <i>And this has nothing to do with the Unix filesystem.</i>

Actually, this JavaScript requires case-sensitive names:
Code: Select all
<form name="post"><input type="submit""></form>

alert(document.Post); // oops, no document.Post became identifier is actually document.post

Mook
 
Posts: 1752
Joined: November 7th, 2002, 9:35 pm

Post Posted September 5th, 2004, 10:21 pm

(This is completely irrelevant - it's just a bit of trivia, really.)

According to HTML 2.0 (RFC 1866), section 7.4:
The meaning of fragment identifiers depends on the media type of the
representation of the anchor's resource. For `text/html'
representations, it refers to the <A> element with a NAME attribute
whose value is the same as the fragment identifier. The matching is
case sensitive. The document should have exactly one such element.
The user agent should indicate the anchor element, for example by
scrolling to and/or highlighting the phrase.

(Note lack of text specifying that two fragments differing only in case is not allowed...)

Digging stuff up like this is just fun. :P

For reference - a search turned up bug 208656, bug 241063, bug 154754 (all marked resolved/invalid). None are for quirks mode though - I'm still wondering if an enhancement bug for quirks mode only would be considered valid.
poot.

dmcritchie
 
Posts: 30
Joined: September 3rd, 2004, 1:14 pm

Post Posted September 5th, 2004, 11:44 pm

Glad you find it humorous. Monk pointed out the standard, but that was after
I asked some others -- and none of us worked for Microsoft, I used to work on
mainframes, I guess that is even worse, eh? Anyway I can see that making
Firefox more friendly for some existing coding isn't likely to happen.

Return to Firefox Bugs


Who is online

Users browsing this forum: No registered users and 1 guest