Evertjan. said:
I do not understand much of what you are saying, but then I am not the
OP.
What fragments do you want to be identified?
Could you explain in beginners language and in simpler English ...
<snip>
Err, I don't know if I can explain it satisfactorily, but the URI
grammar rules are:-
<quote cite="RFC 2396 Section 4">
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
</quote>
<quote cite="RFC 2396 Section 3">
absoluteURI = scheme ":" ( hier_part | opaque_part )
....
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
</quote>
<quote cite="RFC 2396 Section 5">
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
</quote>
- and given that grammar, a fragment identifier is an optionl part of a
URI-reference and will appear at the end of such a reference, while the
query string is an optional part of either an absoluteURI or a
relativeURI. As an absoluteURI or a relativeURI must appear in a
URI-reference before a fragment identifier (if they appear at all) then
a query string must precede a fragment identifier if the result is going
to conform to the grammar.
PS:
Just tested the clientside location.search solution.
It had no problems with the
#blah?a=n
string under IE6
Maybe, but relying on the behaviour of the very (perhaps overly)
tolerant IE to be reproduced in all other browsers would not be a my
approach to creating a reliable cross-browser end result.
Richard.