[javascript] Menu wijzigen met innerHTML of style.display? - Softwareontwikkeling

zondag 28 december 2003 15:58

Acties:

Aus der Reihe...

Topicstarter

Ik heb een menu dat op basis van twee tabs bovenaan verschillende content moet tonen. Deze ASCII-art verduidelijkt de situatie hopelijk:

code:

 _____________________
| een      | twee     |
|__________|__________|
|                     |
| hier de content     |
|                     |
|                     |
|_____________________|

Hierin representeren een en twee de tabs en op basis van de actieve tab wordt hier de content gevuld. Dit switchen gebeurt client-side d.m.v. geschikte javascript. Ik heb dit tot nu toe op twee manieren geïmplementeerd:

hier de content is één DIV waarvan de juiste inhoud m.b.v. innerHTML wordt geschreven;
hier de content bestaat uit twee DIV's onder elkaar, waarvan de juiste m.b.v. de style.display property wordt weergegeven. (de niet active DIV krijgt dan de waarde 'none')

Beide code werkt even goed in alle browsers die ik wil ondersteunen.

De reden dat ik dit post is dat ik mij pas net aan het verdiepen ben in client-side programmeren met javascript (m.a.w. ik ben een ongelofelijke beginner). Ik zie zelf niet in waarom ik een van de twee methoden zou kiezen boven de andere. Graag wil ik van iemand met meer ervaring weten welke van deze methode te verkiezen is. Of is er wellicht een derde manier hoe ik dit probleem moet oplossen? M.a.w. hoe lost de professional dit op?

[ Voor 2% gewijzigd door Ralluph op 28-12-2003 17:03 . Reden: typo nu pas opgemerkt :| ]

zondag 28 december 2003 16:06

Acties:

creative8500

freedom.

Met style.display, omdat het een officiële propery betreft, innerHTML is door Microsoft bedacht. Maar omdat we natuurlijk met XML willen werken en niet met HTML zal ik de eerste methode altijd verkiezen, en de tweede altijd mijden.

_{extra bron: http://www.quirksmode.org/dom/w3c_html.html}

zondag 28 december 2003 16:27

Acties:

Sendy

creative8500 >
Helaas gebruik je een null-argument. Er is een DOM methode 'nodeValue' die je zo'n beetje hetzelfde gebruikt als innerHTML.

Ik zou style.display gebruiken als de tekst in je container vooral niet dynamisch is en node.nodeValue als de tekst juist wel (in meer of mindere mate) dynamisch is.

zondag 28 december 2003 16:39

Acties:

Ralluph

Aus der Reihe...

Topicstarter

creative8500 schreef op 28 december 2003 @ 16:06:
_{extra bron: http://www.quirksmode.org/dom/w3c_html.html}

Bedankt! De site van Peter-Paul Koch had ik al ontdekt, deze pagina had ik echter tot nu toe nog niet aandachtig bekeken.
Het kan dus ook nog door met W3C DOM-manipulatie de inhoud van hier de content te wijzigen. Gebruiken jullie die manier al?

zondag 28 december 2003 16:48

Acties:

creative8500

freedom.

Sendy schreef op 28 december 2003 @ 16:27:
Helaas gebruik je een null-argument. Er is een DOM methode 'nodeValue' die je zo'n beetje hetzelfde gebruikt als innerHTML.

Bepaald niet hoor!

code:

<html>
    <body>
        <h1 id="test">
            <a href="http://gathering.tweakers.net/forum/list_messages/853536//www.tweakers.net">
                [javascript] Menu wijzigen met innerHTML of style.display?
            </a>
        </h1>
        <p onclick="alert (document.getElementById('test').nodeValue);">nodeValue</p>
        <p onclick="alert (document.getElementById('test').innerHTML);">innerHTML</p>
    </body>
</html>

offtopic:
Ben jij de Sendy uit Spongebob?
Mag ik dan je handtekening?

Afbeeldingslocatie: http://www.nickelodeon.com.au/toonroom/sponge/images1/images/sandycol.gif

Afbeeldingslocatie: http://www.nickelodeon.com.au/toonroom/sponge/images1/images/sandycol.gif

offtopic:
Hey, Clay heef net de site van Anne van Kesteren bezocht.

Hij gebruikte het als springplank om via de externals naar andere weblogs te komen

[ Voor 57% gewijzigd door creative8500 op 28-12-2003 16:57 ]

zondag 28 december 2003 16:50

Acties:

Ralluph

Aus der Reihe...

Topicstarter

Sendy schreef op 28 december 2003 @ 16:27:
Ik zou style.display gebruiken als de tekst in je container vooral niet dynamisch is en node.nodeValue als de tekst juist wel (in meer of mindere mate) dynamisch is.

In het content-blok komen per tab ongeveer 30 links, die door de backend worden gegenereerd en dus dynamisch zijn (de query van de URL's verschilt). Ik wil echter dat het wisselen van tab snel gebeurt, een refresh en dus een nieuwe request duurt te lang voor de gebruikservaring.

Er is een DOM methode 'nodeValue' die je zo'n beetje hetzelfde gebruikt als innerHTML.

Als ik mij niet vergis kun je met nodeValue alleen maar text schrijven. Met innerHTML kun je ook gemengde content (tags + text) schrijven.
_{* Ralluph heeft zijn laatste opmerking nog niet gevalideerd, dus zou nu best wel eens iets kunnen typen dat helemaal niet/niet helemaal waar is.}

edit:
creative8500's laatste post doet vermoeden dat ik gelijk heb.

[ Voor 6% gewijzigd door Ralluph op 28-12-2003 16:55 ]

zondag 28 december 2003 17:06

Acties:

Sendy

creative8500 >
Yahoo! Iemand heeft een tekenfilm character naar mij vernoemt! (Eigenlijk ken ik Spongebob niet, maar ik hoor die naam zo vaak dat ik misschien maar eens moet gaan kijken). Btw hier is de handtekening:
Afbeeldingslocatie: http://rotzorg.org/~sgr/GoT/spongebob-sendy-sig.png

Afbeeldingslocatie: http://rotzorg.org/~sgr/GoT/spongebob-sendy-sig.png

<edit>
En nu zie ik dat de Spongebob sendy 'Sandy' heet...

</edit>

Ralluph & creative8500 >
Het lijkt er inderdaad op dat nodeValue alleen tekst kan teruggeven en wijzigen. Je kan wel de addChild etc. methodes gebruiken dan. Het snelst lijkt me display = 'visible', want dan zijn de pagina's al helemaal voor gerenderd. Ook is er dan al plaats gemaakt voor je container, dus schuift er waarschijnlijk niets naar beneden als de hoogte van de content verschillend is.

[ Voor 16% gewijzigd door Sendy op 28-12-2003 17:23 ]

zondag 28 december 2003 17:22

Acties:

Ralluph

Aus der Reihe...

Topicstarter

Sendy schreef op 28 december 2003 @ 17:06:
Het lijkt er inderdaad op dat nodeValue alleen tekst kan teruggeven en wijzigen. Je kan wel de addChild etc. methodes gebruiken dan.

Inderdaad. Om client-side nu ook de hele structuur in het content-blok te laten renderen m.b.v. DOM-manipulaties lijkt mij overdreven; dit kan IMHO veel sneller server-side gebeuren. Recapitulerend: blijven dus nog steeds de twee aanvankelijk door mij genoemde opties over (innerHTML en twee DIV's). De tweede manier vinden jullie blijkbaar netter, omdat innerHTML een Microsoft-toevoeging is en geen 'officiële' standaard.

Ook is er dan al plaats gemaakt voor je container, dus schuift er waarschijnlijk niets naar beneden als de hoogte van de content verschillend is.

Dit ontgaat mij even. Je zet bij deze implementatie de ene layer (DIV) op display: block en de andere op display: hide. Dit kun je naar believen switchen. Hoe kan er dan al plaats gemaakt zijn voor de container?

zondag 28 december 2003 17:26

Acties:

creative8500

freedom.

Ralluph: De tweede manier vinden jullie blijkbaar netter.

Ik denk dat je voor tabs eigenlijk van z-index gebruik moet maken.

zondag 28 december 2003 17:31

Acties:

Sendy

Ralluph >
Als je met addChild() of innerHTML elementen aan de pagina toevoegt dan weet de browser de lengte nog niet, dus kan je pagina worden uitgerekt. Als je z-index (goed idee, creative8500) of display: visible/hidden gebruikt is de pagina al gerenderd, alleen zie je de content niet. De pagina blijft dan dus zo groot als hij is.

Maar Ralluph, wat is het verschil tussen de pagina in de browser samenstellen (met addChild() etc.) of een grote blob html code met innerHTML te zetten?

zondag 28 december 2003 17:54

Acties:

crisp

Devver

Pixelated

innerHTML wordt door zo'n beetje alle moderne browsers ondersteund ook al is het oorspronkelijk een IE-toevoeging aan de DOM. Dit in tegenstelling tot innerText, maar via childNodes.item(0).nodeValue kan je hetzelfde bereiken (initieel moet de node dan wel een textNode bevatten, anders moet je die met createTextNode nog apenden.
Ik gebruik innerHTML alleen als ik echt hele HTML-structuren wil toevoegen, niet als het om 1 of 2 elementen gaat, dan gebruik ik de gewone DOM methoden.
Volgens mij kan je met cloneNode trouwens ook een node inclusief alle childNodes dupliceren en in 1 keer toevoegen; handig voor herhalingen.

Als het gaat om het dynamisch zichtbaar/onzichtbaar maken van elementen, die je van te voren al onzichtbaar kan laten genereren, dan verdient dat toch de voorkeur in verband met snelheid (de content is immers al gerenderd).

Kortom: het ligt er een beetje aan wat het doel is, en je kan zelfs opteren om een mix van dit alles te gebruiken

Intentionally left blank

zondag 28 december 2003 18:02

Acties:

Ralluph

Aus der Reihe...

Topicstarter

Sendy schreef op 28 december 2003 @ 17:31:
Maar Ralluph, wat is het verschil tussen de pagina in de browser samenstellen (met addChild() etc.) of een grote blob html code met innerHTML te zetten?

Het verschil is meer dan een factor 10 aan snelheid in het renderen (afhankelijk van de gebruikte browser). Dit las ik net op deze pagina van de site van Peter-Paul Koch. Je kan het daar ook zelf testen.

Nu ik jullie gedachten heb aangehoord denk ik dat het voor mijn situatie het beste is om een tweetal layers voor hier de content te maken en op basis van de actieve tab de display-property te schakelen.
Bedankt voor jullie reacties, het is mij weer wat duidelijker geworden.

creative8500 schreef op 28 december 2003 @ 17:26:
[...]

Ik denk dat je voor tabs eigenlijk van z-index gebruik moet maken.

Dat zou inderdaad het mooiste zijn, ware het niet dat in mijn geval de inhoud van beide content-layers niet even groot zal zijn. Ze zullen elkaar niet geheel bedekken. Daarom is het schakelen van display in mijn geval het meest geschikt.

[ Voor 44% gewijzigd door Ralluph op 28-12-2003 18:09 ]

zondag 28 december 2003 18:06

Acties:

creative8500

freedom.

Ralluph schreef op 28 december 2003 @ 18:02:
[...]

Meer dan een factor 10 aan snelheid in het renderen. Dit las ik net op deze pagina van de site van Peter-Paul Koch. Je kan het daar ook zelf testen.

Als je het maar één of twee keer gebruikt, merk je dat verschil niet natuurlijk - het is dus zeker niet een argument om dat altijd opgaat. _{Ik weet dat je dit niet zei, maar ik wil dit toch even toevoegen.}