IE6 - manglende repaint af iframe ved scroll

<ole>

Du mangler en del, før du kan kalde koden HTML  :)
1. Du mangler en DOC-TYPE (DTD), og du mangler tegnsæt.
2. Det er dårlig kodeskik at udelade at lukke sine tags. Luk dine options med </option>
3. Undlad såvidt det overhovedet er muligt at bruge expressions i CSS. Det er ualmindelig dårligt performende - og frarådes i øvrigt af MS.

/mvh
</bole>

Du mangler en del før du kan kalde din kommentar et svar, 1) du mangler at læse spørgsmålet. 2) Det er dårlig chatskik helt overse spørgsmålet 3) ....
Nå! spøg til side. Som du sikkert også selv ved, er det vedlagte "HTML" et nedbarberet eksempel udelukkende for at vise problemet, og dine kommentarer er helt uden betydning for problemets eksistens. Problemet opstår kun i IE. Jeg bruger expression i CSS  for i det hele taget at få IE til at lave noget der ligner "position: fixed". Har du et bedre forslag?

1. Hvad skal man med chatskik udenfor en chat?
2. Hvis du vil have svar på det spørgsmål, du stillede - og som jeg havde mulighed for at læse inden min kommentar - må det jo være: "Ja"  :)

Uden den rigtige kode er det ganske vanskeligt at give et fyldestgørende svar - et faktum mange spørgere ikke er opmærksom på. Da de jo i sagens natur ikke ved, hvad der er problemet, kan de heller ikke afgøre, hvad der er relevant kode for et relevant svar  ;o)
Jeg kan f.eks. ikke se, om man kan anvende IE's funktion til lige netop at 're-tegne' en del af dokumentet, da du ikke viser, om formen ligger i tabel:
    TABLE.refresh();
Desuden er der jo mange, der udelader DTD'en, hvilket gøre, at IE ikke overholder CSS-standarderne - og kan give andre problemer. Jeg kan ikke se på dit nick, om du er en af dem ... jeg har kun den kode, du skriver at forholde mig til  :)

Ellers kan du jo altid anvende et JS-script à la dem, man bruger så mange steder til at få et banner til at flyde med siden, når der scrolles.
/mvh

PS: TABLE.refresh() er selvfølgelig ikke en funktion - men en metode  :)

Olebole, du behøves da ikke kommentere mit spørgsmål hvis det irritere dig og gør dig i dårligt humor. Jeg takker dog alligevel for din interesse. Problemstillinger gør sig ofte bedst vist alt unødvendigt kode er fjernet. Derfor har jeg også reduceret CSS'en til STYLE="". Mit spørgsmål havde til hensigt
1) at opklare om problemet skyldes en IE - bug
2) om man kan løse/omgå problemet på en eller anden måde.
Til orientering skal jeg nævne, at hverken den eller anden doc-type, eller lukke-tags a'la XML har nogen indflydelse. I Mozilla og Opera browserne findes problemet slet ikke da man her kan erstatte
<div style="position: absolute; top: expression(body.scrollTop+220+'px');">
    Fixed text
</div>
med
<div style="position: fixed; top: 220px">
    Fixed text
</div>

PS Om jeg er en af dem, vil jeg ind til videre lade dig gætte på, vi kan eventuelt mødes over en øl for at få det afklaret.

Steen >> Dit spørgsmål irriterer mig ikke det mindste, men det er - af hensyn til at få et relevant svar - ikke videre hensigtsmæssigt udformet.
Det er i øvrigt et tilbagevendende 'problem', hvorfor en anden E-bruger har skrevet en E-artikel om, hvordan man (for sin egen skyld) skriver spørgsmål på den bedst mulige måde  :)

Det er ikke til at fastslå, hvad årsagen er, uden at se hele koden. Fejlen kan ligge en masse steder - det er ikke en generel IE-bug.
Om man kan løse problemet på anden måde, kan jeg derfor heller ikke udtale mig om ... udover, hvad jeg skrev om at bruge 'rigtig' JS i stedet. Brugen af IE's blanding af JS/CSS i dynamiske CSS-expressions er som sagt yderst sjældent en god løsning.

Jeg er helt klar over, problemet i sagens natur er IE-orienteret  :)
/mvh

Eksempelkoden er tilstrækkelig til at vise problemstillingen. Problemet opstår kun når select-listen er i en iframe. Jeg har brug for at have en select-liste i en iframe, samtidig med at jeg har en div-container på hovedsiden, der er fast placeret uanset scroll.

Steen >> Det må være svært at være så pokkers klog  :)
Prøv at kikke på dette eksempel:
  http://www.tjenester.dk/x-codes.dk/eksperten/kloge_aage/
læs resten af dette indlæg - og overvej så, om du nu kan se det formålstjenlige i at beskrive sit problem lidt bedre.

Det eneste, jeg har gjort er at rette de ting, jeg nævnte i (29/03-2004 01:01:25).
Nu tegnes dit select-element fint ved scrolling, men din expression virker til gengæld ikke.

Den DTD, jeg har brugt, er den korrekte til IE, hvis man vil bruge CSS (IE kan ikke tolke CSS korrekt, hvis man ikke bruger URL'en i DTD'en - browseren går i quirks-mode) - men den udelukker samtidig brugen af expressions.
Noget kunne tyde på, du enten ikke har brugt den korrekte DTD - eller helt har udeladt den. Det kan jeg dog ikke vide, da du hårdnakket insiterer på ikke at fortælle mig det.

Som du kan se, er det nødvendigt at vide hvilken DTD, der er anvendt for at afgøre, hvad problemet er - og hvordan det skal løses. Det er i det hele taget nødvendigt at vide, hvordan koden ser ud, da årsagen til et problem kan ligge et utal af steder.

Spørger man folk, der lever af at lave websider, er det en meget god taktik at lytte til, hvad de siger - og ikke fortælle dem, hvor problemet ikke ligger. Ved man ikke, hvor problemet ligger, ved man yderst sjældent, hvor det ikke ligger  ;o)

Jeg vil stadig anbefale en ren JS-løsning.
/mvh

OleBole>> Jeg fornægter slet ikke brugen af doc-type. Det er klart at select-elementet tegnes rigtigt når du bruger doc-typen. Det skyldes at expression i style'n nu er inaktiv. Jeg kan få samme effect ved at fjerne expression fra style'n. Men så ide'en med det hele lige som forsvundet. Er der mon ikke en løsning i IE, hvor man både kan have select-elementet i iframe'n og et faststillet element på hovedsiden?

Nej, det er ikke spor klart - ikka af den grund. Det skyldes, at når du bruger den DTD, hvor IE går i standard-compliant mode (den DTD, hvor IE er istand til at læse og forstå CSS korrekt), kan du ikke aftaste body'ens scrollTop, men skal bruge 'documenElement.style.scrollTop' i stedet.

Det ændrer dog ikke på den dårlige tegning af select-box'en. Årsagen til den dårlige tegning er formodentlig, at IE under scrolling konstant spytter et nyt DOM-træ ud, som hele tiden skal evalueres.
Da select-elementer er lidt anderledes end de fleste andre HTML-elmenter (og mere komplekse), går der 'kamel i tangoen' ... IE taber simpelthen pusten  :)

En bedre løsning er nok dette eksempel. Det virker tilmed både i IE, Opera og Moz ... så kan du vente, til MS endelig engang begynder at understøtte CSS på en brugbar måde, med at bruge 'fixed':

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<html>
  <head>
  <title>test.html</title>
<style type="text/css">
html, body {
    height: 100%;
    margin: 0px;
}
</style>
<script type="text/JavaScript">
var myDiv;
window.onload = function() {
    myDiv = document.getElementById("ib");
    window.onscroll = function() {
        myDiv.style.top = document.documentElement.scrollTop + 220 + "px";
    }
}
</script>
  </head>
<body>

  <div id="ib" style="position:absolute;top:220px;z-index:2">Fixed text</div>
 
  <div style="position:relative;overflow:visible;height:800px;z-index:1">
    <iframe name="ib" src="frame.html" frameborder="1" style="height:200px;"></iframe>
  </div>

</body>
</html>

Dit tekst-div skal af uopdagede grunde ligge før dit iframe-div. Du skal også være opmærksom på, det aldrig vil kunne gå ind over dit select-element, da dette (sammen med object- og applet-elementer) befinder sig på et andet z-plan end andre HTML-elementer - men det er jo et gammelt, kendt problem.

Læg også mærke til, at jeg definerer 'myDiv' én gang for alle på onload-event'en. Det gøres af hensyn til bedre performance. Skulle den defineres på onscroll-event'en, ville det betyde, at det ville ske konstant, mens der scrolles - hvilket er helt unødvendigt.

"Årsagen til den dårlige tegning er formodentlig, at IE under scrolling konstant spytter et nyt DOM-træ ud, som hele tiden skal evalueres." ... underforstået: Når man bruger expressions på style-objektet  ;o)

Phuck ... mere vrøvl:
"... men skal bruge 'documenElement.style.scrollTop' i stedet."
skulle naturligvis være:
"... men skal bruge 'documenElement.scrollTop' i stedet."

>>Olebole, tak for indsatsen og tålmodigheden. Den sidste detalje er fin og funktionalitet er acceptabel (den fås nok ikke bedre for IE). Jeg antager, at IE i bund og grund benytter de samme objekter og metodekald uanset javascript, style og doc-type. Den egentlige årsag til problemet kan, man som du selv antyder, jo indtil videre kun gætte på. Men mon ikke det er en bug. Det er jo kun hvis selectelementet placeres i en iframe problemet opstår. Send et svar og du får flux point.

Jeg tror ikke, det er en bug. Det er en kendt sag, at man skal undlade at skifte klasse - men i stedet skifte de enkelte properties på et elements style-objekt - da man ellers beder browseren om løbende at spytte et nyt DOM-træ ud og reevaluere dette.
Jeg forestiller mig noget lignende sker ved brug af expressions. Er det tilfældet, vil det naturligvis være en voldsom belastning ved onScroll, da der så formodentlig bliver spyttet flere hundrede træer ud inden for en ganske kort scrolling.
Da den underliggende struktur for et select-element er betydelig mere kompleks - og temmelig meget anderledes - end for andre HTML-elementer, er det formodentlig det, der er skyld i balladen. Du skal tænke på, at det iforvejen er et helt window-objekt, der skal flyttes (også en tung satan at danse med), så 'stakkels, lille' IE må med andre ord _virkelig_ slide i det under en sådan process. Jeg har set noget lidt lignende før, hvor jeg også overbelastede IE med yderst komplekse beregninger og rotation af et element (jooo, det _kan_ skam godt lade sig gøre, men det er forløbig min forretningshemmelighed ... hehe). Her kom jeg ud af det ved en lille +/- 1 pixels resize.

Som sagt, advarer MS selv mod at bruge expressions:
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebgen/html/dhtmlperf.asp
Det er en god side at lære af - og du skal i denne forbindelse specielt kikke under "Don't Be Too Dynamic with Your Properties". Tænk så på, du skal flytte et komplekst element, indlejret i et komplekst element hundredevis af gange i sekundet. Mon ikke, det er forklaringen? Jeg finder det i det mindste mere end sandsynligt  :)

Anyways ... godt vi fandt en løsning. Ikke et skønmaleri ... men dog en løsning - og som du selv skriver: Den fås nok ikke bedre til IE  ;o)
/mvh

Tak for alle dine gode bemærkninger, jeg har fået lidt ekstra viden og visdom, og det er jo altid rart. Med den fart tingene ændre sig med kan det være svært at have fingeren på pulsen inden for alle områderne. Her er dine points.

Selvtak ... meningen med sitet er jo, vi alle skal blive lidt klogere, så det er altid rart, når det sker. Og tak for points  :)
/mvh