- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Sun, 22 Jun 2008 09:42:18 -0400
- To: public-html@w3.org
Consider the following: <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> <style> div { position: absolute; top: 1500px; } </style> </head> <body> <div id="√ 45">Destination</div> <p><a href="#√ 45">Test 1</a></p> <p><a href="#%E2%88%9A%2045">Test 2</a></p> <p><a href="#%E2%88%9A 45">Test 3</a></p> <p><a href="#√ 45">Test 4</a></p> </body> </html> In Firefox and Safari, the fragids for Test 1, Test 2, Test 3 and Test 4 all match the id for the Destination div. In Opera and IE, they do not. In short, Firefox and Safari support percent-encoded fragment identifiers and decode them before trying to find a match (even for manual input in the address field). Further, Firefox and Safari make the navigation to the destination div work when there's a match even if the id value contains spaces or non-ascii charactesr like √. How Firefox and Safari *handle* these situations makes sense to me. Whether you're technically supposed to encode the fragid data in the URI or not, I expect it to be encoded. This also fits well with how browsers return a resolved and normalized value for .href. And, even though the id value might not validate, Firefox and Safari have no problem making the navigation work if the fragid data and the id value match. Do you feel that behavior is ideal for this situation? Or, do you feel that navigation should be broken in Safari and Firefox in these situations? Does anything explain what should happen in these situations? I have the same type of concern for usemap="#percent-encoded_value" matching. -- Michael
Received on Sunday, 22 June 2008 13:42:54 UTC