alpha(opacity) gør knuder

Er du i gang med et projekt, der kun skal virke på een browser ?-)

-- og så kan det da generelt frarådes at skifte className on-the-fly, da det performer helt elendigt ...

-- og grunden til den elendige performance er, at browseren på forhånd opgiver at vide, om et klasse-skifte evt. kan have indflydelse andre steder, og derfor beregner den hele sidens visning helt forfra, i komplicerede sider kan det betyde, at der går flere sekunder før siden igen kan ses ...

det er helt bevidst at det ikke er 'ren' html ja, og jeg har ikke mærket noget 'performance' problem ved metoden i de to eksempler .. det er jo bare den 'normale' måde at få msie il at have :hover funktionalitet på elementer den ellers ikke understøtter det på.
forstået at jeg aldrig har oplevet 'flere sekunder' eller tilsvarende.

Men jeg tror det er en fejl i den måde explorer håndterer styles på (intet nyt under solen) for jeg har lavet et andet eksempel der ikke på nogen måde benytter dynamisk skift af hverken klasse eller id, udelukkende 'visibility' eller 'display'.
begge metoder (udkommenteret i koden) viser samtlige lister i strukturen indtil man begynder at bevæge musen over liste punkter og begge virker a-ok ... indtil opacity filteret bliver sat til i style-elementet. Så bliver underlister slugt, allerede fra starten .. inden der er gjort noget som helst dynamisk ved hhv. 'visibility' eller 'display'.
http://svendsenontheinter.net/showbox/opacity_forsog.htm

-- et eksempel på, hvor elendigt, det performer, kan du finde på tv2-sportens resultat og/eller Live-sider, hvis man bevæger musen op over en hel stribe elementer i en tabel, vil skiftet komme klart forsinket ...

-- opacity-tingen har jeg desværre ikke oplevet på den måde, så jeg kan ikke give dig en forklaring ...

-- men ville det ikke være hensigtsmæssigt, at du brugte det, så også andre end IE-brugere fik noget ud af det ?-)

nu er der ikke 'andre ie-brugere' på det her 'projekt' .. det er ganske simpelt en side jeg skal bruge som desktop :)
men den foregående metode jeg frembragte burde vel ikke være lige så tung at behanlde som 'den almindelige' måde med klasser? Jeg har slet ikke nok menupunkter til at lave en uddybende vurdering, men den virker en tand mere glidende. Måske bare mig.

en side med intet andet end en liste, med evt. underlister, sort baground, og hvid baggrund på top-listen + opacity fungerer fint, så jeg tror måske det har noget at gøre med den måde filteret bliver påført da man jo også kan anføre dækningsområde for opacity. hvad der falder uden for det område bliver så -måske- åbenbart slet ikke vist, fremfor vist med den styling der eksisterer inden opacity.
det der undrer mig big-time med det foregående eksempel er at hvis man udvider top-listen til dobbelt bredde, så begynder princippet pludselig, delvist, at fungere.
så det må næsten være fordi msie ikke kan håndtere den type dynamisk ændring af det område der er fundet på basis-elementet, hér top-listen. samme fejl gør sig gældende hvis man ikke angiver en bredde på <ul>-elementet, som dermed er en dynamisk størrelse som udgangspunkt.
indtil videre er det korte af det lange, at opacity kan rende mig .. det bliver bare en fuldfarve menu.

'andre end ie-brugere'

Jeg har uden problemer lavet dynamiske ting med f.eks. opacity (f.eks. glidende overgange: http://roenving.users.whitehat.dk/WD5Opacity.html !-)

dét eksempel der er jo så heller ikke samme princip som på menuen. Billedet er statisk og det der ændres er opacity'en. Det jeg ser som den mulige MSIE fejl er netop håndteringen af et dynamisk indhold, med opacity.
Som understreget med eksemplet med en liste på en sort html side, hvid liste-baggrund + opacity. Der netop viser hele listen inkl. underlister med gennemsigtighed.
Så snart der styles med lister/underlisters indbyrdes relation så er det det f***er up.
En dynamisk opacity som den du viser dér har jeg også lavet før og har liggende et sted i skufferne.