[html] anchors en query strings

[BetuweKees]

hoi,

op een site, opgemaakt met stylesheets, geef ik onderaan mijn complete (onbewerkte) menu weer bij wijze van site map. deze sitemap is ook bereikbaar via een interne link, en staat aangegeven in de header, zodat deze voor de ivm accesibilty eenvoudig te bereiken is.

punt is dat op een behoorlijk pagina's ook extra parameters middels een query string staan. daarnaast gebruik ik een <base> tag die naar de directory verwijst waarin het bestand zich bevindt.
om de interne link in dit geval correct te laten verlopen dienen mi de querystring en interne link dus gecombineerd te worden. na wat spelen met firefox kwam ik tot de conclusie dat het formaat pagina.php#link?querystring de juist zou moeten zijn.
nu blijken echter zowel lynx als opera dit niet te slikken. toch niet helemaal correct dus..

zou iemand me kunnen vertellen hoe ik dergelijke link wel aan zou moeten geven?

[Skaah]

Ik doe meestal

code:

pagina.php?optie1=dittu&optie2=dattuh&#link

Let op de extra ampersand.

[ Voor 20% gewijzigd door Skaah op 17-04-2004 11:41 ]

[crisp]

code:

pagina.php#link?querystring

Dit is toch volgens de RFC de enige juiste methode. Ik heb zelf ook inderdaad wel eens ruzie hiermee gehad met Opera en kon toen niet anders concluderen dan dat het een bug in Opera was.

Maak trouwens niet deze fout:

HTML:

<a name="#link">

in het name attribuut mag geen # zitten

[ Voor 20% gewijzigd door crisp op 17-04-2004 11:46 ]

[Verwijderd]

crisp schreef op 17 april 2004 @ 11:45:

Maak trouwens niet deze fout:

HTML:

<a name="#link">

in het name attribuut mag geen # zitten

En het name attribuut is prima te vervangen door een id attribuut, en je kunt dan beter een al bestaand element een id attribuut geven en daarnaar verwijzen, dan een element te gaan toevoegen speciaal voor dat doel.
Fatsoenlijke browsers ondersteunen dat gewoon, en al een hele tijd ook.

[ Voor 21% gewijzigd door Verwijderd op 17-04-2004 12:24 ]

[Verwijderd]

crisp schreef op 17 april 2004 @ 11:45:

code:

pagina.php#link?querystring

Dit is toch volgens de RFC de enige juiste methode.

Weet je dat zeker? (Vooral omdat Mozilla een relatieve, '#idnaam' link achter de '?bar=foo' stopt.)

[Verwijderd]

Verwijderd schreef op 17 april 2004 @ 12:28:
[...]
Weet je dat zeker? (Vooral omdat Mozilla een relatieve, '#idnaam' link achter de '?bar=foo' stopt.)

Ik maak uit RFC 2396 eigenlijk ook op dat fragment identifiers aan het eind van een URI horen.

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]

Lijkt me dus duidelijk.

[ Voor 26% gewijzigd door Verwijderd op 17-04-2004 12:33 ]

[BetuweKees]

edit:
ff verkeerd gelezen

ok op de hierboven geadviseerde manier (bestand?query#anchor) snapt lynx em wel. opera doet beetje moeilijk, maar heb meer het idee dat dat aan de linktoolbar ligt, aangezien ie het bij handmatige invoer wel snapt..

opgelost dus, mijn dank

[ Voor 159% gewijzigd door BetuweKees op 17-04-2004 13:04 ]

[crisp]

mmmz, ik beroepte me eigenlijk op een oude JS reference mbt het location object; ik nam aan dat dat wel RFC-conform zou zijn: http://devedge.netscape.c...3/reference/location.html

In general, a URL has this form:

protocol//host:port/pathname#hash?search

come to think of it; de problemen die ik hier ooit mee heb gehad betroffen IE5 op de MAC bij een submit van een GET form met een fragment identifier in de action...
Het probleem met Opera is dat je via scripting niet de hash property van het location object kan lezen of zetten, maar hopelijk is dat in latere versies alweer verholpen.

En inderdaad, id werkt prima ipv een name in de laatste versie browsers.

[ Voor 23% gewijzigd door crisp op 17-04-2004 13:54 ]