[CSS]Linken menu aan target dezelfde pagina

[Verwijderd]

Beste Tweakers,

TT Dreamweaver Essentials CS4, TT Dreamweaver Advanced CS4 en veel zoeken heeft mij nog niets opgeleverd.
Mijn vraag is vrij simpel: Vroeger maakte ik sites met frames. Ik kon dan heel simpel een link uit het menu linken aan een target en zo de gewenste pagina laten openenen in het frame op dezelfde pagina (header, footer en menubar refreshen dan niet)
Nu ik een site in CSS moet maken lukt het me niet de menu items te laten openen in hetzelfde scherm. Moet ik als target de DIV maincontent benoemen, en zoja, hoe doe ik dat.

Ik kom er niet uit, ben nu zelfs bezig met Lynda.com videos, maar ook daar gaan ze niet verder dan het laten zien van hoe je links maakt (en de links openen steeds een volledig nieuwe pagina. Hoe je ze zover krijgt dat ze openenen in je maincontent is mij nog steeds onduidelijk, ben een beetje ten einde raad.
Ik gebruik een liquid 3 colum template van dreamweaver.
ALvast bedankt voor het meedenken.
Greetz Victorretje

[kaesve]

dit gaat niet met alleen css en zonder frames. je kan dit wel berijken door met ajax de andere pagina's te laden. hiermee kun je ook delen van pagina's ophalen en weergeven.

[Verwijderd]

Betekent dit dat ik dus, als ik geen ajax wil gebruiken, elke keer de volledige pagina herlaad wordt, inclusief flashheader, footer en menubar? Ik kom toch regelmatig sites tegen waarbij enkel de maincontent verandert wanneer je op links in het menu klikt? Zijn die dus allemaal met ajax gemaakt.
Probleem voor mij is dat de website gehost en meestal bezocht wordt in Zuid-Afrika (slomme verbindingen) en ik een flash header hebt die het liefst niet elke keer herlaadt als een bezoeker een andere pagina bekijkt?

[Avalaxy]

Verwijderd schreef op zondag 23 mei 2010 @ 11:40:
Betekent dit dat ik dus, als ik geen ajax wil gebruiken, elke keer de volledige pagina herlaad wordt, inclusief flashheader, footer en menubar? Ik kom toch regelmatig sites tegen waarbij enkel de maincontent verandert wanneer je op links in het menu klikt? Zijn die dus allemaal met ajax gemaakt.

Wat dacht je van zoiets?

[code=php]
/* menu block */
<a href='index.php?page=1'>Click</a>
<a href='index.php?page=1'>Click</a>

<?php
$page = mysql_real_escape_string($_GET['page']);

switch($page) {
case 1:
// do this
break;
case 2:
// do this
break;
default:
// do this by default
break;
}
[/code]

edit:
oh wait, je wilt niet dat de rest refresht... Dan zul je toch wel met Ajax aan de slag moeten.

[ Voor 6% gewijzigd door Avalaxy op 23-05-2010 11:45 ]

[macciez]

Waarom zet je er überhaupt een flash header in als de verbindingen zo slecht zijn?
Verder sluit ik me bij de rest aan, je moet dan ff een scriptje schrijven die dat voor je doet.

[Civil]

Ik weet niet hoe jij Tweakers zelf ervaart. Maar daar wordt bij elke klik ook gewoon alles ververst. Vind jij dat storend? Ik kan me niet voorstellen dat het storend is namelijk. Ik zou dus gewoon lekker de header, footer en het menu in elke pagina opnemen. Zoals hierboven aangegeven kan dat heel eenvoudig met php includes.

[kaesve]

Civil schreef op zondag 23 mei 2010 @ 11:54:
Ik weet niet hoe jij Tweakers zelf ervaart. Maar daar wordt bij elke klik ook gewoon alles ververst. Vind jij dat storend? Ik kan me niet voorstellen dat het storend is namelijk. Ik zou dus gewoon lekker de header, footer en het menu in elke pagina opnemen. Zoals hierboven aangegeven kan dat heel eenvoudig met php includes.

maar tweakers is heel performant. de software steekt goed in elkaar en de servers waarop ze draait zijn ook niet de minste. de TS heeft al aangegeven dat de site die hij bouwt op een trage servert gehost zal worden en dat zijn doelgroep mensen zijn met een trage internetverbinding. nu snap ik dan zelf niet helemaal de keuze voor grote flashbanners, maar als dat moet dan is het toch echt wel vrij storend als er bij elke nieuwe pagina eerst gewacht moet worden totdat die flashheader iets begint te doen.. in zo'n geval kan ajax veel ergernis voorkomen. :]

[crisp]

Verwijderd schreef op zondag 23 mei 2010 @ 11:40:
[...]
Probleem voor mij is dat de website gehost en meestal bezocht wordt in Zuid-Afrika (slomme verbindingen) en ik een flash header hebt die het liefst niet elke keer herlaadt als een bezoeker een andere pagina bekijkt?

Je zou dan iig ervoor moeten zorgen dat dat soort bestanden clientside gecached kunnen worden (als ze dat nog niet waren). Verder pas je natuurlijk ook HTTP compressie toe en zorg je dat je zo min mogelijk requests hoeft te maken. Als clientside performance belangrijk is download dan bijvoorbeeld eens Yslow of Page Speed om te kijken waar je nog verbetering aan kan brengen.

Verder zou ik ook eens kijken of je ueberhaupt wel flash nodig hebt.

[ Voor 3% gewijzigd door crisp op 23-05-2010 12:11 ]

[Juup]

Er zijn alternatieven:

1. iframe voor je main content
2. :target gebruiken om display op block te zetten voor een div met dezelfde id als in je url hash (zie bv :target gebruik (Fx/Webkit only)
3. Ajax

[crisp]

kaesve schreef op zondag 23 mei 2010 @ 12:08:
[...]

maar tweakers is heel performant. de software steekt goed in elkaar en de servers waarop ze draait zijn ook niet de minste. de TS heeft al aangegeven dat de site die hij bouwt op een trage servert gehost zal worden en dat zijn doelgroep mensen zijn met een trage internetverbinding.

Een trage server is meestal niet de grootste bottleneck. Zelfs optimalisaties aan de serverside software, tenzij je echt pagina's hebt die seconden duren om te genereren, dragen niet erg veel bij aan de snelheidsbeleving voor de bezoeker. Daarvoor moet je echt specifiek kijken naar zaken die de clientside performance wel in grote mate beinvloeden, bijvoorbeeld met de tools die ik in mijn vorige post al noemde

[Tarabass]

Weten dat er gebruik gemaakt gaat worden van trage verbindingen, flash header implementeren om vervolgens over een refresh te gaan bakkeleien. In mijn ogen de omgekeerde wereld. Daarnaast zijn de browsers van nu zo slim dat ze niet alle content opnieuw gaan laden. Divs die niet renewed worden worden niet in zijn geheel opgehaald maar gecashed door de browsers. Om je website performance omhoog te gooien is het eerste wat je doet je header vervangen door een gif, mocht dat mogelijk zijn. Vervolgens zou je er voor kunnen kiezen om met jquery -> tabcontrol de content kunnen switchen per pagina. Dan wordt de gehele pagina in één keer opgehaald en veranderd enkel de content van de div waar nodig.

[RobIII]

Tarabass schreef op zondag 23 mei 2010 @ 12:37:
Divs die niet renewed worden worden niet in zijn geheel opgehaald maar gecashed door de browsers.

Oh? Since when? Bron?
En hoe gaat de browser op voorhand weten of "een div" niet gerenewed hoeft te worden zonder een request te doen? Enkel héle pagina's en andere (héle) objecten (CSS/JS/Images etc.) kunnen gecached worden en dat gebeurt ook alleen maar als je de juiste headers meestuurt. Een deel van een pagina ("een div") is dus niet als zodanig cacheable (noch bestaat er infrastructuur voor om die al dan niet op te halen etc.)

[ Voor 27% gewijzigd door RobIII op 23-05-2010 12:51 ]

[apokalypse]

RobIII schreef op zondag 23 mei 2010 @ 12:50:
[...]

Oh? Since when? Bron?
En hoe gaat de browser op voorhand weten of "een div" niet gerenewed hoeft te worden zonder een request te doen? Enkel héle pagina's en andere (héle) objecten (CSS/JS/Images etc.) kunnen gecached worden en dat gebeurt ook alleen maar als je de juiste headers meestuurt. Een deel van een pagina ("een div") is dus niet als zodanig cacheable (noch bestaat er infrastructuur voor om die al dan niet op te halen etc.)

Ik denk dat de browser zeker wel wat cached, en die overeenkomst kan hij vinden bij het opbouwen van de abstract syntax tree (AST). Qua parsen wordt er niks gecached, maar wel hoe-te-renderen. Ik heb alleen ook geen links, maar ben er wel benieuwd naar

[crisp]

apokalypse schreef op zondag 23 mei 2010 @ 13:47:
[...]

Ik denk dat de browser zeker wel wat cached, en die overeenkomst kan hij vinden bij het opbouwen van de abstract syntax tree (AST). Qua parsen wordt er niks gecached, maar wel hoe-te-renderen. Ik heb alleen ook geen links, maar ben er wel benieuwd naar

Ik weet wel zeker dat dat niet het geval is; op een dergelijk niveau cacheing toepassen is van een dermate complexiteit dat die de normale cacheing-algoritmes voor volledige bestanden ver zou overschaduwen en daarmee dus juist weer bijzonder ineffectief zou blijken. Zelfs de huidige cacheing-algoritmes van browsers blijken hedentendage met het grote aantal benodigde (en grotere) resources van huidige websites al nauwelijks effectief meer.

Het enige waar browsers de laatste tijd verbeteringen in aangebracht hebben is de history-cache - als je terugkomt op een pagina die je eerder in een browsersessie al bezocht hebt dan wordt die veelal al compleet uit memory geladen en hoeft 'ie niet meer compleet gerendered te worden. Maar ook dat is afhankelijk van headers die je stuurt; voorheen stuurden we hier op GoT bijvoorbeeld een 'no-store'-directive die deze behaviour in Firefox kortsloot.

Dus nogmaals: kennis van HTTP is enorm belangrijk als het gaat om clientside performance; legio sites maken hier gewoon fouten (of kijken hier simpelweg niet naar) en performen daardoor sub-optimaal. Tools als Yslow en Page Speed kunnen helpen om de grootste bottlenecks te identificeren. Als je daarnaast tools en logging gebruikt om ook je serverside performance in kaart te brengen en waar nodig te verbeteren (gewoon 80/20 rule toepassen) dan kan zo'n beetje elke gemiddelde site (zelfs veel grote sites trouwens) met erg weinig ingrepen zeker 2x zo snel gemaakt worden

[Verwijderd]

Hey Tweakers,

Bedankt voor alle kundige replies, sommigen gaan mijn boven de pet.
Voor mij is het duidelijk dat ik de swf header (144kb) liefst vervang door een gif, en dan gewoon elke pagina opnieuw laden. I frame en php toevoegen lijkt me niet de beste optie, daarom moet het maar zo.
Kan ik dat het beste doen door vanuit Dreamweaver een template te maken van de hoofdlayout en vervolgens een aantal pages from template?

[ Voor 10% gewijzigd door Verwijderd op 25-05-2010 09:27 ]

[Verwijderd]

Probeer inderdaad je code te optimaliseren. Zowel de server side scripting als de omvang van de code (HTML, Flash, CSS en afbeeldingen) die door de bezoeker gedownload moeten worden. Op het web is heel veel te vinden over de optimalisatie van websites.

En als een trage host de bottleneck is, waarom dan niet een paar eurootjes per maand meer betalen voor een fatsoenlijke provider? Ik ken er zat waar je niet teveel betaalt en toch gewoon een snelle service krijgt.

Ik ben niet bekend genoeg (meer) met de werking van Dreamweaver, maar het is vast mogelijk om daarmee de pagina's van je website te laten opbouwen a.d.h.v. templates. En anders is het includen van vaste onderdelen van je pagina met PHP echt niet lastig, ook daarvan kun je zo voorbeelden van het net plukken.