[HTML] Navigatie alleen via links (not?)-done?

[mbravenboer]

Ik heb een vraag, maar ook een beetje een discussie-punt . Het gaat allemaal over navigatie op een website.

Allereerst even wat info

1. Ik ben absoluut niet geinteresseerd in een doelgroep die percee toegang moet hebben tot de site. Als iemand geen recente browser heeft: IE6 of Mozilla/Netscape 6 heeft hij pech en mag hij upgraden.

2. Ik wil mijn site puristisch opzetten

Dan nu de vraag

Ik denk erover om navigatie alleen maar via de link elementen in de head tag te doen. Ik heb wat gezocht in W&G maar kon hier geen enkele discussie over vinden. Wat vinden jullie van deze link elementen?

Mijn motivatie

Het web bestaat uit documenten met inhoud. Inhoud moet los staan van de context waarin het document zich bevindt en daarom wil ik liever geen navigatie in de body van mijn pagina hebben.

Tables zijn vanuit dat standpunt dus extreem 'evil'. Op dit moment schrijf ik mijn XHTML documenten zonder navigatie. De navigatie voeg ik later toe via een XSLT transformatie op die XHTML documenten. Ik wil ze echter ook graag zonder navigatie op het web hebben staan.

Je kunt uiteraard frames gebruiken, maar daar valt ook een hoop op aan te merken. Er is echter nog een optie: volledig menu-georienteerd werken. Je kunt je dit simpelweg voorstellen als een menu bovenaan de pagina. Navigatie toestanden vind je alleen terug bovenaan het document. De 'Site Navigation Bar' in Mozilla is hier uiteraard perfect voor. Je krijgt zo schone, opgeruimde pagina's en duidelijke navigatie zonder frutsels.

Dus: ik wil al mijn navigatie uit de content en volledig overstappen op navigatie via de link elementen. Uiteraard kan ik dat zelfs nog genereren met XSLT uit een site-index.

Commentaar?

(luiheid vanwege Linux gebruik: hoe zit het trouwens met de ondersteuning van deze link-types in IE6?)

[Blue-eagle]

Ik denk dat veel designers heel veel gaan missen in hun werk als ze geen kickass menu`s meer mogen maken voor een site. Het kan inderdaad wel handig zijn, voor een standaar voor handleidingen ofzo, maar ik zie er verder niet veel nuttigs in.. eerlijk gezegd

[SchizoDuckie]

Les 1 uit de cursus: Hoe maak ik me hetzelf onnodig moeilijk voor beginners

[RM-rf]

in theorie is dit redelijk interessant,
als je doelgroep specifiek te pinpointen valt kan het probleem van inzichtelijkheid van de navigatiemethode best te overkomen zijn;
al zou ik zoiets altijd specifiek extra vermelden (vreemd genoeg, als ik in Mozilla: 'show/hide site navigation bar: only as needed' doe , verschijnt hij helemaal niet als ik pagina's bezoek die van link-elements gebruik maken)

Opera 5.0b (OSX) gebruikt het ook, en eigenlijk een stukje netter dan Mozilla (auw, kennelijk vergeten alle theme-bouwers dit hoekje, en zijn de buttons nog gemaakt door exact degene die het geheel geprogrammeerd heeft , zo'n style van een programmeur die tijdelijk wat grafische buttons in elkaar klust, dat herken ik van 3 kilometer afstand)

persoonlijk vind ik de navigatie-methode eigenlijk erg schoon en praktisch, zeker voor technische uitgebreidde document-structuren erg praktisch, al is het even wennen met zowel een prev-back button als up-home knoppen te werken
(wat dat betreft blijft een betere visuele weergave wenselijk, hierin is Opera eigenlijk erg interessant, tov van een statische menu-popup-structuur in mozilla hebben zij een visuele weergave van de index in de pagina)

..veel designers heel veel gaan missen in hun werk als ze geen kickass menu`s..

dan moeten die 'designers' alvast gaan oefenen in het dynamisch nummertjes trekken bij de sociale dienst...
als vormgeving enkel gebaseerd is op 'hippe' dingen en er geen interesse is voor praktische gebruiksvriendelijkheid ben je kortzichtig bezig.

zo'n link-navigatie is ook erg praktisch als alternatief voor vaak 'buggy' en gebruiks-onvriendelijke opties

[Pelle]

Op maandag 21 januari 2002 13:19 schreef mbravenboer het volgende:
1. Ik ben absoluut niet geinteresseerd in een doelgroep die percee toegang moet hebben tot de site. Als iemand geen recente browser heeft: IE6 of Mozilla/Netscape 6 heeft hij pech en mag hij upgraden.

That's the spirit!

Ik denk erover om navigatie alleen maar via de link elementen in de head tag te doen. Ik heb wat gezocht in W&G maar kon hier geen enkele discussie over vinden. Wat vinden jullie van deze link elementen?

Hmja, ik heb ze nooit gebruikt.
Ten eerste vanwege de gebrekkige browsercompatibility die je net al aanstipte. Als ik een site bouw voor een grote (inter)nationale klant, dan kan ik het niet maken dat de mensen met Netscape 4 of Opera 5 een 'upgraden eikel'-message voor hun neus krijgen.

Ten tweede vanwege het feit dat het omslachtig is om voor elke link zowel een <a> en een <link> op te nemen. Jaja, ook webdesigners zijn liever lui dan moe

Het idee achter content en navigatie scheiden gaat er bij mij op zich wel in, maar aangezien je toch ergens aan moet geven dat iets een link is en waar het naar toe linkt, vind ik het niet nodig om dat apart in een <link>-tag op te gaan nemen.

Als straks 98% van de mensen een browser hebben die deze ongein ondersteunt, dan ga ik er nog eens een keer over nadenken
Er zit zeker wat in; vooral voor grote db-driven sites, maar nu vind ik het vooral omslachtig en te puristisch (hoewel dat wel is wat je voor ogen had).

[cutter]

Voor de duidelijkheid:
http://matthias.gutfeldt.ch/translation/LINK/ENaddendum.html
Je bedoelt dit soort navigatie.

http://www.euronet.nl/~tekelenb/WWW/LINK/
Hier meer uitleg

Probleem:
Hoe wil je dat in IE uit gaan voeren, want Explorer ondersteunt niet standaard dit soort dingen.
http://www.subotnik.net/html/link
Moet je de activeX plugin hier downen
http://www.meadroid.com/scriptx/secmgr.htm
(let op hij downed automatisch)

En dan hier naar toe
http://ppewww.ph.gla.ac.uk/~flavell/charset/

[edit]
En eerst was er boven een navigatiebalkje in die site en nu dus niet meer op mijn browser dan. Ergo: ik zou dat hele navigeren op die manier lekker vergeten......

[Blue-eagle]

Misschien is het handig als ik probeer een paar potentieële nadelen neer te zetten:

• in het begin is er onduidelijkheid over de navigatie bij mensen die nu gewend zijn op knoppen te klikken
• geen fancy menu`s meer op sites. Menu`s die mooi zijn, kunnen ook handig zijn. Als ze slecht zijn, tja. Jammer dan.
• .. ehm.. ..

Wat is het e-mail adres van het W3C?

[drm]

mbravenboer:
1. Ik ben absoluut niet geinteresseerd in een doelgroep die percee toegang moet hebben tot de site. Als iemand geen recente browser heeft: IE6 of Mozilla/Netscape 6 heeft hij pech en mag hij upgraden.

en terecht

2. Ik wil mijn site puristisch opzetten

dapper

Ik denk erover om navigatie alleen maar via de link elementen in de head tag te doen. Ik heb wat gezocht in W&G maar kon hier geen enkele discussie over vinden. Wat vinden jullie van deze link elementen?

Mijn motivatie

Het web bestaat uit documenten met inhoud. Inhoud moet los staan van de context waarin het document zich bevindt en daarom wil ik liever geen navigatie in de body van mijn pagina hebben.

Dit punt begrijp ik niet helemaal. In feite ben je zelf in staat aan te geven wat body is en wat navigatie. Of je die scheiding nou legt in de grens head-body of je legt de grens in <div id="nav">-<div id="content">, dat maakt imo geen bal uit.

En zodra je dus voor de "div"-oplossing gaat, heeft het ook geen zin meer om link-elementen op te nemen. Het argument dat het "puristisch" zou moeten zijn begrijp ik dus ook niet echt. Als je zelf die scheidslijn aan zou kunnen geven, waarom dan niet

Tables zijn vanuit dat standpunt dus extreem 'evil'. Op dit moment schrijf ik mijn XHTML documenten zonder navigatie. De navigatie voeg ik later toe via een XSLT transformatie op die XHTML documenten. Ik wil ze echter ook graag zonder navigatie op het web hebben staan.

begrijpelijk. En juist omdat je het over een transformatie hebt, is het dus ook niet belangrijk dat het eindresultaat wel degelijk een HTML-document met combinatie van content en navigatie bevat, toch?

Je kunt uiteraard frames gebruiken, maar daar valt ook een hoop op aan te merken. Er is echter nog een optie: volledig menu-georienteerd werken. Je kunt je dit simpelweg voorstellen als een menu bovenaan de pagina. Navigatie toestanden vind je alleen terug bovenaan het document.

En wat is er dan op tegen om dat op basis van DHTML te doen?

De 'Site Navigation Bar' in Mozilla is hier uiteraard perfect voor. Je krijgt zo schone, opgeruimde pagina's en duidelijke navigatie zonder frutsels.

...en die frutsels verzin je zelf, of laat je dan zelf achterwege

Dus: ik wil al mijn navigatie uit de content en volledig overstappen op navigatie via de link elementen. Uiteraard kan ik dat zelfs nog genereren met XSLT uit een site-index.

Kijk, samenvattend is mijn punt: Dat je content en navigatie gescheiden wilt houden is niet gedaan door <link> elementen in de head te zetten. Want wat zou het verschil zijn tussen:

code:

<html>
<head>
   <link .../>
</head>
<body>
content
</body>
</html>

en

code:

<html>
<head>

</head>

<body>

<div id="nav"><a ...>...</a></div>
<did id="content">content</div>

</body>
</html>

Het blijft imo een verweven boeltje. Of, snap ik je nou gewoon helemaal verkeerd

[RM-rf]

Blue-eagle:
1) in het begin is er onduidelijkheid over de navigatie bij mensen die nu gewend zijn op knoppen te klikken
2) geen fancy menu`s meer op sites. Menu`s die mooi zijn, kunnen ook handig zijn. Als ze slecht zijn, tja. Jammer dan.

1) tja, dan kun je iedere innovatie wel de prullemand ingooien, windows3x was ook een ramp voor gebruikers die aan A:> gewend waren (en betwijfel nog steeds een beetje of het drag-and-drop-principe door meer dan 10% van de windows gebruikers begrepen wordt) is dat een reden het niet te doen?

2) wie zegt dat dit verplicht is, dit is een optie die toevoegd aan je site, verder mag je je site volstoppen met draaiende flash-filmpjes in flikkerend contrasterende kleuren dat het een lust is, maar door een aantal van dit soort elementen in je HEAD te plaatsen voeg je extra navigeerbaarheid toe:

tevens is het mogelijk om dit al in HTTP-headers te doen, dus eventueel zou je gebruik kunnen maken van een webserver die default al bepaalde link-informatie meestuurd (wat is de home, copyright-page)
(alhoewel ik niet weet of www-link nu al een goedgekeurde http-header is en of browsers hem meenemen)

indexering van LINK-elementen is voor spiders ook een extra voordeel, n zekere zin geeft de mogelijkheid een standaard index over een site te maken directe voordelen bij indexering, wat dat betreft zou ik me kunnen voorstellen dat spiders dit ook beter gaan meenemen

[cutter]

Microsoft heeft wel de fantastische image toolbar geintroduceerd in IE6.

In plaats hiervan hadden ze ook een toolbar kunnen maken die overweg zou kunnen met de linktags. Wat je nu bijvoorbeeld kunt doen is een standaard javascriptje op iedere pagina dat de <head> tag uitleest en de <links> vertaalt in <a href> tags.

Voor wap/pda functionaliteit is de <link> tag een geweldige uitkomst.

[drm]

Op maandag 21 januari 2002 14:23 schreef RM-rf e.e.a.:

Voor toegevoegde waarde moet je het niet achterwege laten, maar is dat dan ook reden genoeg om <a ...>...</a> tags een eigen plekje in /dev/null te geven

_edit:

cutter:
Wat je nu bijvoorbeeld kunt doen is een standaard javascriptje op iedere pagina dat de <head> tag uitleest en de <links> vertaalt in <a href> tags.

Voor wap/pda functionaliteit is de <link> tag een geweldige uitkomst.

Dat is in dit geval niet echt belangrijk c.q. handig, gezien we het over een XML/XSLT => XHTML toepassing hebben.

Als je dan ook nog eens een javascriptje toe gaat voegen wat je links vertaalt, dan ben je niet echt juust bezig

[mbravenboer]

Ik zie interessante meningen . Kan nu niet zo lang overal op ingaan, maar zal dat vanavond zeker alsnog doen.

Discussieer vooral door .

[cutter]

Ik vraag me alleen af hoe je de <link> tags praktisch uit wil werken op IE...

[Verwijderd]

[quote]Op maandag 21 januari 2002 13:54 schreef Pelle het volgende:

[..]

That's the spirit!
[..]

zorg je er dan wel voor dat het menuutje op je site het onder netscape 6.2 doet? en alt teksten?

[drm]

ll0ll:
zorg je er dan wel voor dat het menuutje op je site het onder netscape 6.2 doet? en alt teksten?

<sub>*proest*

webdesigners zoals ik en Pelle hebben domweg geen tijd om hun eigen site te onderhouden. Die van mij staat al een jaar zoals nu, en gaat helemaal nergens over.</sub>


</offtopic>

[Verwijderd]

Op maandag 21 januari 2002 16:10 schreef drm het volgende:

[..]


<sub>*proest*

webdesigners zoals ik en Pelle hebben domweg geen tijd om hun eigen site te onderhouden. Die van mij staat al een jaar zoals nu, en gaat helemaal nergens over.</sub>


</offtopic>

^{druk met got?}

[Verwijderd]

hmm.. werken misschien

Doordeweeks kijk je 40 uur (excl. rookpauze en charly pauze) naar een bende van sourcecode van je collega's. Thuisgekomen denk je... ja laten we ff de website gaan updaten ... NOT

[Pelle]

Op maandag 21 januari 2002 15:48 schreef ll0ll het volgende:
zorg je er dan wel voor dat het menuutje op je site het onder netscape 6.2 doet? en alt teksten?

He, daar hebben we mister hahahaaahaa ook weer. Ik weet niet hoe je er bij komt om hier offtopic te gaan blaten, maar zolang jouw site ook niet werkt onder Mozilla stel ik voor dat je je er even buiten houdt. Hoe bevalt het trouwens op m'n ignore-list?

/no offence

[Verwijderd]

BTW zorg eerst maar voor dat je margins etc. van je body via CSS regelt ipv in je body tag, dan praten we verder met jou

[Verwijderd]

Op maandag 21 januari 2002 16:31 schreef Pelle het volgende:

[..]

He, daar hebben we mister hahahaaahaa ook weer. Ik weet niet hoe je er bij komt om hier offtopic te gaan blaten, maar zolang jouw site ook niet werkt onder Mozilla stel ik voor dat je je er even buiten houdt. Hoe bevalt het trouwens op m'n ignore-list?

/no offence

ik noem mezelf niet webgoeroe
^{btw, heb je al bij stoute usertjes gepost dat ik aan het flamen ben? daar post jij toch het meest?}

[Verwijderd]

Op maandag 21 januari 2002 16:36 schreef ll0ll het volgende:

[..]

ik noem mezelf niet webgoeroe
^{btw, heb je al bij stoute usertjes gepost dat ik aan het flamen ben? daar post jij toch het meest?}

Ja vooral bij persoontjes die Peter heten en in Zwolle werken .. nietwaar

[Verwijderd]

Op maandag 21 januari 2002 16:37 schreef Gordijnstok het volgende:

[..]

Ja vooral bij persoontjes die Peter heten en in Zwolle werken .. nietwaar

Micha, hoe is ie bij devote?

[Tom]

Goh, ik denk dat iemand z'n account niet zo heel erg bruikbaar meer is

[Yellow|A]

* Yellow|A denkt dat sommige stervelingen hier naar bezig tegen elkaar zijn

Ik denk dat het wel erg mooi is, maar het internet is tegenwoordig meer een entertainment medium aan het worden. Natuurlijk gaat het nog 90% om informatie, maar entertainment speelt wel steeds een belangrijkere rol en door je navigatie puur op dat <link> principe te baseren is handig voor sommige websites, maar voor een boel ook niet.

[Verwijderd]

Op maandag 21 januari 2002 16:31 schreef Pelle het volgende:

[..]

He, daar hebben we mister hahahaaahaa ook weer. Ik weet niet hoe je er bij komt om hier offtopic te gaan blaten, maar zolang jouw site ook niet werkt onder Mozilla stel ik voor dat je je er even buiten houdt. Hoe bevalt het trouwens op m'n ignore-list?

/no offence

over ignorelists gesproken, pelle....
//ot

/me is zich nog ff aant verdiepen in dat link gedoe... is errug nieuw voor mij

trouwens, ik zie mijzelf als designer, niet als developer. I don't really care about the usability of my website, die ik trouwens opnieuw aant opbouwen ben, met n redelijk "vreemde" navigatie.

[Oefening]

En het was nog wel zo'n mooie discussie

Op maandag 21 januari 2002 17:14 schreef denki_akira het volgende:

[..]

trouwens, ik zie mijzelf als designer, niet als developer. I don't really care about the usability of my website

Gewaagde uitspraak moet ik zeggen. Zeker als je bedenkt dat een site vaak staat of valt bij haar navigatie. Daarnaast heb je vaak rekening te houden met andere webdesigners/developers (binnen een team).

Maargoed, de navigatie alleen via 'kale' links op een vaste plaats te laten verlopen is wel weer het andere uiterste. Internet is voor een groot deel amusement. Ik moet er niet aan denken om zo te surfen, als ik snel kale info wil vinden dan surf ik wel met lynx.

[cutter]

Ja, sommige OT's zijn idd iets minder, en ik weet nog steeds niet hoe je dat hele <link> gebeuren in xhtml/sgml/whtml of wat voor markup language dan ook werkend in IE kunt implementeren.....

[Verwijderd]

Op maandag 21 januari 2002 17:34 schreef nelis het volgende:
En het was nog wel zo'n mooie discussie
[..]

Gewaagde uitspraak moet ik zeggen. Zeker als je bedenkt dat een site vaak staat of valt bij haar navigatie. Daarnaast heb je vaak rekening te houden met andere webdesigners/developers (binnen een team).

dan zal ik t even toelichten
ik ben scholier
ik ben vooral bezig met het maken van grafische composities, en mijn site moet bijzonder zijn, niet te bijzonder, maar wel anders dan anders.
bij mij is het vooral hoe je het concept om zet in iets waar misschien de usability hoog is en niet andersom.
Ik maak sites voor mezelf, niet voor anderen.

[Verwijderd]

Waarom zet je ze dan op internet en bekijk je ze niet vanaf je harde schijf

[Yellow|A]

* Yellow|A denkt dat sommige mensen eerst even moeten nadenken over wie wat doet in een traject

"Usability. De mate waarin een product kan worden gebruikt door een gespecificeerde gebruikers om gespecificeerde doel te bereiken met effectiviteit, efficiëntie en tevredenheid."

Goh!

Op maandag 21 januari 2002 17:14 schreef denki_akira het volgende:
trouwens, ik zie mijzelf als designer, niet als developer. I don't really care about the usability of my website

De usability van producten kan worden verbeterd door in te spelen op wensen en eisen van eindgebruikers. Je moet uitgaan van potentiële eindgebruikers en wat hun doen met het systeem.

Je moet je site usable maken voor je doelgroep. Stel jij wil leuk gaan freaken en mooie plaatjes online zetten, maak dan een thumbnail pagina. Ik neem aan dat je door je "dingetjes" online te zetten graag af en toe wilt horen van je vak genoten, zo denki, dat hebbie toch wel hip gedaan. Dat kan .. dan bestaat je doelgroep dus uit vormgevers en dat soort tuig

Nou je hebt geluk, want jou doelgroep vindt een ontdekkingstocht op een site wel leuk, veel leuke spelletjes waar je op kan klikken waarvan je niet echt weet wat het perse doet. Maakt niet uit het gaat om de ontdekking. Zodra je niets leuks meer kan ontdekken, zat andere websites.

In andere woorden, je doelgroep zit niet te wachten op een serie hyperlinks die allemaal netjes links staan uitgelijnd, maar zit te wachten op iets hips.

Door te zeggen dat je een designer bent en usability je geen ene zak uitmaakt ben je een beetje muf bezig, no offence denki...

* Yellow|A denkt dat ie' maar ergens gauloises gaat zoeken voordat ie' echt gaat flippen

[Clay]

Op maandag 21 januari 2002 20:55 schreef Gordijnstok het volgende:
Waarom zet je ze dan op internet en bekijk je ze niet vanaf je harde schijf

lol

Maareh, die <link> tag, waar werkt dat dan wel in? want ik heb hier blijkbaar niets liggen waar dat het in doet handig.

Verder vind ik dat het web idd best een beetje spannend mag zijn. Als alle sites alleen maar superuserfriendly zijn is er toch ook niets meer aan. Da's net als dat alle auto's er hetzelfde uit zouden zien. Neem nou die retro-chrysler dat is OMG en zo moeten er ook sites zien die dat effect op je hebben.
Design hoort daarbij, en nou kan je misschien vast wel een nuttige site waar het meer om de content gaat met <link>s bouwen, maar echt warm word ik daar niet van. Ook ben ik er van overtuigd dat duidelijke nav en oogstrelende graphics prima samen kunnen gaan

Daarnaast kan je ook met dhmlt een menutje bouwen op basis van een lijstje links met labels, zonder iets in je body te hebben. Naja ik heb iig reden genoeg om voorlopig nix met die <link> te doen.

Als XML tot gevolg heeft dat we wat site-design betreft 4 jaar terug de tijd in gaan hoeft het van mij niet

[RM-rf]

Op maandag 21 januari 2002 17:47 schreef cutter het volgende:
Ja, sommige OT's zijn idd iets minder, en ik weet nog steeds niet hoe je dat hele <link> gebeuren in xhtml/sgml/whtml of wat voor markup language dan ook werkend in IE kunt implementeren.....

dan moet je je eigen linked pages eens doorlezen
http://www.subotnik.net/html/link#dom

ActiveX http://jibbering.com/toolbar/
MS' IE5 Tools http://ppewww.ph.gla.ac.uk/~flavell/www/ie5wa.html
Frameset + DOMscripting http://www.siteexperts.com/dhtml/ch9/chapter/part3.asp

drm: Dat is in dit geval niet echt belangrijk c.q. handig, gezien we het over een XML/XSLT => XHTML toepassing hebben.
Als je dan ook nog eens een javascriptje toe gaat voegen wat je links vertaalt, dan ben je niet echt juust bezig

tssk, dat verpest een beetje de rest van je goede remarks, als er iets toegevoegde waarde heeft binnen een xml-omgeving is het juist gebruik van DOM-scripting.

verder snap ik de reservaties van veel mensen niet, alsof usability en scripting elkaar steken, juist binnen een heftige scripted omgeving kan zoiets ietwat helderheid brengen;
ipv te werken met javascript variabelen en arrays om menustructuren weer te geven, wat vaak weinig inzichtelijk en gepaard gaat met veel escapes en encoding (oMenu.addItem("blaat", "http://www.blaat.com", parentId, "none", "foo\'bar\'"))
verdient weergave van een structuur via een markUp-alternatief al snel mijn voorkeur, ben ook wel dol op xml-data-islands, enkel jammer dat weer niet direct aan javascript te koppelen zijn (en had ook wel mooie ideeen voor gebruik van watch(), een ns4x methode)

ben eigenlijk wel benieuwd of aan LINK ook weer javascript:-url's te koppelen zijn, misschien valt zoiets weer buiten de beoogde reach ervan, maar zoiets zou weer nieuwe opties brengen

[mbravenboer]

Sorry dat ik een beetje lang niet reageerde, was een tijdje weg . Grappig om te zien dat een topic zelfs in een flame kan ontaarden als ik niet post .

RM-rf: in theorie is dit redelijk interessant

Inderdaad, theoretisch is het op dit moment interessant. Het is voor een serieuze website die percee een algemene doelgroep moet bedienen absoluut geen optie: In Mozilla staat hij zelfs standaard uit en IE6 begin je er standaard helemaal niets mee. De compactheid en standaardisatie van deze vorm van navigatie vind ik wel interessant. Helaas vind ik de uitvoering weer wat minder: er zou best een aparte specificatie vorm mogen zijn voor dergelijke menu's. De link elementen komen op mij over als onnodig hangend naar het verleden... Het had nog fraaier kunnen zijn.

RM-rf: hierin is Opera eigenlijk erg interessant, tov van een statische menu-popup-structuur in mozilla hebben zij een visuele weergave van de index in de pagina

Hum, dat klinkt interessant. Ik heb deze feature nog niet bewonderd in Opera, maar dat ga ik zeker even doen.

Pelle: Het idee achter content en navigatie scheiden gaat er bij mij op zich wel in, maar aangezien je toch ergens aan moet geven dat iets een link is en waar het naar toe linkt, vind ik het niet nodig om dat apart in een <link>-tag op te gaan nemen.

Het is inderdaad ook wel een beetje zeikerig, maar er is toch wel een verschil: als je het in het document zelf opneemt (in de body dus) maakt het echt onderdeel uit van het document. In feite hoeft dit echter helemaal niet als je gewoon basic navigatie wilt bieden zonder frutsels. Als je het in de head sectie zet is het als het ware een soort meta-data over de pagina die geen onderdeel uit maakt van de pagina zelf. Het is dus ook aan de browser om te bepalen hoe dit zichtbaar wordt, en dat vind ik een mooi aspect .

zo meer, anders wordt dit erg lang .

[mbravenboer]

cutter (en vele anderen): Hoe wil je dat in IE uit gaan voeren, want Explorer ondersteunt niet standaard dit soort dingen.

Dat is inderdaad een vervelende situatie. Dat IE6 standaard helemaal geen link elementen voor navigatie ondersteunt is vrij vervelend. Dat gaat zelfs mij toch eigenlijk te ver . Gelukkig is mijn content echter XHTML. Ik wilde de links sowieso al via XSLT gaan invoegen uit een site-map. Het is niet erg veel werk om een alternatieve, table gebaseerde versie te maken voor oude browsers en IE totdat ook IE dit ondersteunt. Dat is precies een groot voordeel van een XHTML oplossing: je kunt de documenten zeer gemakkelijk manipuleren en omzetten naar andere vormen.

drm: Dit punt begrijp ik niet helemaal. In feite ben je zelf in staat aan te geven wat body is en wat navigatie. Of je die scheiding nou legt in de grens head-body of je legt de grens in <div id="nav">-<div id="content">, dat maakt imo geen bal uit.

Ik denk dat er toch wel een belangrijk verschil is. Content in de body tag maakt namelijk allemaal onderdeel uit van de pagina. Deze onderdelen moeten allemaal zichtbaar worden in wat voor vorm dan ook. Mijn site bestaat ook uit pagina's. Deze pagina's verschaffen de informatie die ik kwijt wil. De navigatie maakt geen onderdeel uit van deze informatie. Dit is slechts een relatie tussen de pagina's van mijn website. Als ik de navigatie beschrijf in de 'head' is dit dus geen onderdeel van de informatie die ik aanbied: het is een stukje meta-informatie over de pagina waarin ik geeneens specificeer hoe deze informatie zichtbaar moet worden. De browser mag zelf beslissen hoe hij deze meta-informatie weergeeft. Als veel sites dit toe gaan passen krijg je een voor een gebruiker een standaard manier van navigeren voor alle sites die hij bezoekt. Lijkt mij ook voordeel .

[mbravenboer]

drm: Begrijpelijk. En juist omdat je het over een transformatie hebt, is het dus ook niet belangrijk dat het eindresultaat wel degelijk een HTML-document met combinatie van content en navigatie bevat, toch?

Voor mij is het inderdaad niet zo belangrijk omdat ik voor mezelf al een goede scheiding heb aangebracht. Ik kan dezelfde content in allerlei vormen gebruiken. Ik wil echter ook de bezoeker die scheiding graag bieden . Ik zal niet ontkennen dat ik overdrijf, maar ja: zonder principes valt er ook niet te discussieren .

Yellow: Ik denk dat het wel erg mooi is, maar het internet is tegenwoordig meer een entertainment medium aan het worden. Natuurlijk gaat het nog 90% om informatie, maar entertainment speelt wel steeds een belangrijkere rol en door je navigatie puur op dat <link> principe te baseren is handig voor sommige websites, maar voor een boel ook niet.

Inderdaad, daar heb je volkomen gelijk in: voor sites die een reklame folder willen aanbieden is het wellicht niet de beste weg (alhoewel het ook erg opgeruimd kan staan). Voor sites die no-nonsense informatie willen aanbieden met een zo duidelijk mogelijke structuur, is het wel een interessante optie . Het is sowieso erg handig als de content gescheiden is van de navigatie, maar zols ik al omschreef kan je dat ook met een simpele XSLT oplossing realiseren. Je kunt je 'atomaire' XHTML pagina's gewoon opleuken met layout door ze in tables of wat dan ook te plaatsen.

denki_akira: trouwens, ik zie mijzelf als designer, niet als developer.

* mbravenboer precies andersom .

[mbravenboer]

Clay: Als XML tot gevolg heeft dat we wat site-design betreft 4 jaar terug de tijd in gaan hoeft het van mij niet

Dat hoeft helemaal niet IMHO . XML verandert voor websites maar 1 ding: een duidelijke, consequente syntax. Dit is geen weg terug, dit is een weg veruit! Door deze consequente aanpak kunnen vele andere tools gerealiseerd worden. XSLT stelt je bijvoorbeeld in staat data te scheiden van presentatie. Alle standaarden rond XML hebben niet als doel om websites 'basic' te maken. Het enige doel is consequentie en een standaard syntax die vanuit vele tools goed gebruikt kan worden. Al deze standaarden doen geen enkele afbreuk aan presentatie mogelijkheden. Sterker nog: omdat implementaties zich kunnen concenteren op het implementeren van standaarden kan er vooruit gedacht worden ipv aan alle mogelijke varianten en afwijkingen van een syntax.

XML zorgt er juist voor dat web-ontwikkeling weer leuk kan zijn!

[mbravenboer]

RM-rf: [over drm zijn opmerking over XML/XSLT] tssk, dat verpest een beetje de rest van je goede remarks, als er iets toegevoegde waarde heeft binnen een xml-omgeving is het juist gebruik van DOM-scripting.

Ik vermoed dat drm probeerde duidelijk te maken dat met dom-scripting links omzetten naar a-hrefs hier niet de mooiste/makkelijkste oplossing is. Met behulp van XSL Transformaties kan de ene navigatie vorm veel makkelijker, duidelijker en krachtiger omzetten in de andere . DOM-scripting is uiteraard interessant, maar om hiermee (in feite static) content te gaan transformeren is onnodig lastig...

[Orphix]

Vooraf ik weet niet echt hoe links in je header werken. Kom het hier pas voor het eerst tegen

Maar kan je met links ook sub-structuren genereren. Vaak staan links op een bepaalde plek omdat ze juist daar horen, ze moeten opvallen of juist niet.
Stel je een webshop voor. De eigenaar heeft veel liever dat ze op de nieuwste aanbieding klikken dan op het copyright linkje. Is hier onderscheid tussen te krijgen.

Ik vind het idee wel goed. Maar dan zie ik de toepassing meer in documentatie. Maar zelfs dan klik ik liever snel door de pagina's heen dan dat ik aldoor in het menu moet gaan zoeken. Je leest de pagina dan is het logisch dat je pas gaat klikken wanneer je een link leest. Als de bedoeling is dat alle links overzichtelijk onder elkaar staan .. dan gebeurd dat ook wel (zie bijvoorbeelde de man pages op internet).

ennuh ohja ik wil niet terug naar het lynx tijdperk het oog wil ook wat!

[cutter]

RM-rf: Zo zie je maar dat je iets vindt wil nog niet zeggen dat je het ook echt leest. Maar mij ging het eigenlijk om een bebruiksvriendelijke ondersteuning zoals in alle andere browsers. Dit is wel de eerste echte feature die ik mis in IE.

Het is daarom jammer om te zien dat de meest exotische browsers ondersteuning bieden voor de linksstructuur in een html document, maar IE daar een steekje laat vallen. Op msdn is er helemaal niets te vinden over de LINK structuur.

Natuurlijk kun je met lappen java code de link stuctuur uitlezen, maar dan doe je afbreuk aan de handigheid die er in zit. Ik kan me voorstellen dat je in word je hele document met TOC structuur makkelijk kunt exporteren naar HTML met LINK structuur. Een LINK toolbar in IE maakt het dan voor de eindgebruiker makkelijk om in het document te navigeren.

[drm]

RM-rf >

RM-rf:
[drm: XSL transformatie sluit Javascript "transformatie" bij een goede opzet uit]
tssk, dat verpest een beetje de rest van je goede remarks, als er iets toegevoegde waarde heeft binnen een xml-omgeving is het juist gebruik van DOM-scripting.

• [sub][b]quote van mbravenboer[/b]:[/sub] [sup]_________________________________________[/sup] [sub][i]Ik vermoed dat drm probeerde duidelijk te maken dat met dom-scripting links omzetten naar a-hrefs hier niet de mooiste/makkelijkste oplossing is. Met behulp van XSL Transformaties kan de ene navigatie vorm veel makkelijker, duidelijker en krachtiger omzetten in de andere :) . DOM-scripting is uiteraard interessant, maar om hiermee (in feite static) content te gaan transformeren is onnodig lastig...[/i][/sub] [sup]_________________________________________[/sup]

Zoals mbravenboer al zei: mijn punt is als antwoord op cutter, die zegt dat je met Javascript je links wel weer kan vertalen naar <a href> tags. Maar dat lijkt mij opzich niets te maken te hebben met DOM scripting, maar is in feite ook een vorm van transformatie, die je dus imo al een stap eerder kan, of misschien zelfs moet doen.

Je zal mij echt nooit horen ontkennen dat DOM, wanneer functioneel gebruikt, ook absoluut een goede toevoeging, of meerwaarde kan geven aan een site/paginastructuur.

Daarnaast gaat het er mbravenboer om dat er een XHTML output komt, en niet dat er javascript toegepast gaat worden op de XML zelf, als ik het goed begrijp.
^{is dat uberhaupt toepasbaar, JS + XML ...?}

RM-rf: verder snap ik de reservaties van veel mensen niet, alsof usability en scripting elkaar steken, juist binnen een heftige scripted omgeving kan zoiets ietwat helderheid brengen;

Ben ik het mee eens.

RM-rf: ipv te werken met javascript variabelen en arrays om menustructuren weer te geven, wat vaak weinig inzichtelijk en gepaard gaat met veel escapes en encoding (oMenu.addItem("blaat", "http://www.blaat.com", parentId, "none", "foo\'bar\'"))
verdient weergave van een structuur via een markUp-alternatief al snel mijn voorkeur, ben ook wel dol op xml-data-islands, enkel jammer dat weer niet direct aan javascript te koppelen zijn (en had ook wel mooie ideeen voor gebruik van watch(), een ns4x methode)

Schrijf een javascript XML parser

mbravenboer >
Ik begrijp je punt, en ik vind inderdaad dat je overdrijft.

Als je dan inderdaad die mogelijkheid wilt bieden, om de browser uit te laten maken wat hij/zij^(?) met link-tags doet, kan dat natuurlijk geen kwaad.

Wat echter wel kwaad kan, is dat mensen dat niet gewend zijn. Ik in ieder geval niet. Ik ben een tree-menuutje of een indexbestand o.i.d. gewend, vooral bij informatieve sites. Dus: ik zou zeggen leg: leg die keuze bij de gebruiker neer.
Geef de gebruiker de mogelijkheid van link-tags gebruik te maken, en de mogelijkheid om toch ook een navigatieschermpje te gebruiken.

Want puur uit puristisch oogpunt denk ik toch dat je niet echt gelijk hebt. In die zin is HTML nou eenmaal geen puristische taal, als je begrijpt wat ik bedoel.

[cutter]

Op dinsdag 22 januari 2002 09:39 schreef drm het volgende:
Wat echter wel kwaad kan, is dat mensen dat niet gewend zijn. Ik in ieder geval niet. Ik ben een tree-menuutje of een indexbestand o.i.d. gewend, vooral bij informatieve sites. Dus: ik zou zeggen leg: leg die keuze bij de gebruiker neer.
Geef de gebruiker de mogelijkheid van link-tags gebruik te maken, en de mogelijkheid om toch ook een navigatieschermpje te gebruiken.

Dit soort <link> structuren hebben alleen zin bij grote documenten. Je praat over een feature die handig is bij het publiceren van handleidingen, open source documenten, boeken, wetenschappelijke publicaties etc etc Bezoekers van de documentenpagina's zullen niet vallen in de catagorie matig geinteresseerde gelegenheidsbezoekers, maar juist bereid zijn en de interesse hebben om een weinig tijd te investeren in het doorgronden van een goede tijdsbesparende navigatie structuur.

[drm]

cutter:
Dit soort <link> structuren hebben alleen zin bij grote documenten. Je praat over een feature die handig is bij het publiceren van handleidingen, open source documenten, boeken, wetenschappelijke publicaties etc etc Bezoekers van de documentenpagina's zullen niet vallen in de catagorie matig geinteresseerde gelegenheidsbezoekers, maar juist bereid zijn en de interesse hebben om een weinig tijd te investeren in het doorgronden van een goede tijdsbesparende navigatie structuur.

Daarom zeg ik: leg de keuze bij de gebruiker neer

[cutter]

Op dinsdag 22 januari 2002 10:28 schreef drm het volgende:

[..]

Daarom zeg ik: leg de keuze bij de gebruiker neer

Hoho, die bezoeker komt op mijn pagina, dan past ie zich maar aan aan mijn navigatiestructuur.

[mbravenboer]

drm: Daarom zeg ik: leg de keuze bij de gebruiker neer

Zit wat in .

Ik denk dat ik twee varianten ga maken: 1 voor mensen die verstandig zijn en willen navigeren via een menu bovenaan de pagina. De documenten zelf zijn dan opgeruimd zonder lastig gevallen te worden door navigatie onderdelen . De andere variant is gewoon traditioneel met een navigatie onderdeel in een table.

Als ik tevreden ben over het resultaat zal ik deze wel even een schop geven .

[drm]

mbravenboer:
Als ik tevreden ben over het resultaat zal ik deze wel even een schop geven .

Ben heel erg benieuwd