IE object verschuift niet mee met parent box.

[killercow]

Ik hen een serie divjes,
Deze divjes staan onder elkaar, met een 10px marge er tussen.
Elke div heeft 1 h1 tag bovenin.
Elke h1 tag is relative gepositioneerd, 60 pixels naar links.

Als ik de bovenste div vergroot (text toevoegen), verschuiven alle dvijes netjes naar beneden, maar de h1 van de volgende box blijft hangen.

Hoe kan ik hier een redraw op triggeren?

HTML:

<div>
    <h1>tekst</h1>
    <table>
    <tbody>
    </tbody>
    </table>

    Voeg aan de tbody tr's toe onclick.<button onclick="addtr();" />
</div>
<div>
    <h1>deze blijft hangen.</h1>
    Deze tekst verschuift netjes mee naar beneden.
</div>
<div>
    <h1>Deze is weer ok</h1>
    Dit ook
</div>

Welke bug is dit?
Aleen IE heeft dit probleem.

edit:
plaatjes:

Goed (voor het toevoegen van rows):

Fout (na het toevoegen van rows):

[ Voor 15% gewijzigd door killercow op 12-09-2006 09:49 ]

[Rowanov]

Ik heb wel eens last van zulk soort fratsen met headers en vaak helpt het om handmatig de marges en paddings opnieuw in te stellen. Misschien heb je even een online voorbeeldje zodat we ook je css kunnen zien?

[killercow]

Hmm, okok zou het dus specifiek een probleem van de h* tags kunnen zijn?

voorbeeldje is:
http://ilse.greentides.net/new.php

Waar zoals je ziet tussen enkele div's ook nog een enter staat omdat IE de marges anders collapsed. maar dat is een ander probleem.

Om de bug te triggeren moet je in het keywords gebiedt nieuwe keywords invoeren.

[ Voor 13% gewijzigd door killercow op 12-09-2006 16:44 ]

[Rowanov]

Hij gaat per keyword selectie een x-aantal pixels omhoog en dit is 100% zeker een geheel ander probleem dan waar ik op doelde in mijn post.

Dit lijkt me wel een hele vreemde browserbug, aangezien hij alleen een kennelijk willekeurige h2 pakt. Het enige verschil wat die h2 heeft met andere dingen, is dat de div die de stap aangeeft een lege voorloop-regel heeft, maar het moet wel heel gek lopen wil het daar aan liggen

Edit: Weet je zeker dat er niet iets is in je javascript wat de top van bepaalde elementen modificeert en door een ietwat losse selectie perongeluk de verkeerde pakt? Sterker nog, ik denk dat je het probleem kan beperken tot de javascript actie die keywords toevoegt aan de textarea. In feite schuift er namelijk niets in de layout

[ Voor 28% gewijzigd door Rowanov op 12-09-2006 18:47 . Reden: kleine formuleringsfouten ]

[killercow]

De toevoeg functie binnen de textarea leest de inhoud van de textarea en voegt regels toe aan de table met keywords een stukje lager in de pagina.

De div waarin die table staat wordt dus groter.

De div die daarop volgt bevat de problematische h1 tag, maar de div zelf schuift wel netjes naar beneden.

De javascript doet niets met afmetingen en dergelijke.
De div die op de problematische div volgt met zijn h1 zakken wel zoals het hoord.

Crisp, André, gordijkstok! (anyone! )

Is dit een nieuwe bug? ik kan A list apart, en ppk's site enzo iig niks vinden over dit soortproblemen.

[Rowanov]

Ah wacht, ik vat hem nu pas

Renderbugje?

[crisp]

Dit is inderdaad gewoon weer een hasLayout gerelateerde bug en dus zeer eenvoudig op te lossen door layout te forceren:

Cascading Stylesheet:

.step {
  height: 1%;
}

(alleen voor IE dus)

let je ook nog even op de validatie-errors? (en fix je je DTD ook nog? )

overigens is de margin-collapsing natuurlijk per specificatie, de <br> vind ik eerlijk gezegd maar een lelijke oplossing, vergroot dan gewoon je marge...

[ Voor 38% gewijzigd door crisp op 12-09-2006 21:40 ]

[killercow]

Crisp, mooi dat je er bent

Ok, height:1% voor ie moet ik wel kunnen fixen

Validatie-error? welke
Die lege ul? die heb ik later nodig om hem vanuit de javascript de populaten.
De iframe -> object tags vervangen hem toch nog niet goed genoeg.
De Input die leeg is zal ik idd even wat een waarde voorzien. Of vervangen door een grouper.
selected=selected, ga ik ook fixen, vreemd dat tidy selected=true ook accepteerd.

De tfoot blijft exact waar hij zit, bovenin ziet er ackward uit in 99% van de browsers anno 2006, dus dat gaat niet door
De marges zijn goed, in firefox in ieder geval, 10 pixels boven, 10 pixels onder. Collapsed tot 10 in totaal.

IE tekent echter geen marges als de bovenste div 2 floats bevat gevolgt door een <br style="clear:both"/>
Any tips? (check me nu maar in IE, de br's die zo vies zijn (en daar niet mogen volgens de validator zijn nu weg, en IE verkloot het nu)

WAt is er mis met m'n dtd trouwens?

[ Voor 7% gewijzigd door killercow op 12-09-2006 22:23 ]

[crisp]

killercow schreef op dinsdag 12 september 2006 @ 22:19:
Crisp, mooi dat je er bent

Ok, height:1% voor ie moet ik wel kunnen fixen

Validatie-error? welke
Die lege ul? die heb ik later nodig om hem vanuit de javascript de populaten.

Maak die ul dan ook mooi met javascript aan?

De iframe -> object tags vervangen hem toch nog niet goed genoeg.

toch maar Transitional gebruiken dan?

[...]
De marges zijn goed, in firefox in ieder geval, 10 pixels boven, 10 pixels onder. Collapsed tot 10 in totaal.

IE tekent echter geen marges als de bovenste div 2 floats bevat gevolgt door een <br style="clear:both"/>
Any tips? (check me nu maar in IE, de br's die zo vies zijn (en daar niet mogen volgens de validator zijn nu weg, en IE verkloot het nu)

Zal eens kijken, maar margin-collapsing is inderdaad buggy in IE
Edit: die height op je .step lost dat ook grotendeels op, enkel heb je tussen je 1e en 2e div wel 20px marge doordat daar nog een form-tag tussenstaat.

WAt is er mis met m'n dtd trouwens?

Nou, er staat XHTML in je DTD maar mijn browser zegt dat je pagina gewoon als HTML verstuurd wordt

[ Voor 6% gewijzigd door crisp op 12-09-2006 22:39 ]

[killercow]

crisp schreef op dinsdag 12 september 2006 @ 22:32:
[...]

Maak die ul dan ook mooi met javascript aan?
[...]
toch maar Transitional gebruiken dan?
[...]
Zal eens kijken, maar margin-collapsing is inderdaad buggy in IE
[...]
Nou, er staat XHTML in je DTD maar mijn browser zegt dat je pagina gewoon als HTML verstuurd wordt

Die UL aanmaken, tjah, maar dan moet ik daar wel weer een mooie (niet childnode[n]) manier voor vinden om de plek voor dat ding in de DOM te vinden. Ik vind een lege UL behoorlijk mierenneuken. Dat de validator hem niet nuttig vind, klopt mee eens, maar de validator heeft niet het volledige overzicht, dat heb je met websites die dynamisch gevuld gaan worden. sommige elements lijken overbodig, maar zijn dat niet.

De margin's heb ik nu tijdelijk opgelost met br's maar die geven dan weer een extra space in alle wel compliant browsers, erg naar dus.

Hmfz, dat xhtml/html gebeuren zijn een heleboel devvers nog niet erg blij mee ey?
Ik vindt zelf Xhtml veel netter, En inderdaad ik zou het als xhtml moeten serveren, maar nu was er iets met IE, wat dat weer lastig maakte begreep ik.

ps, heb je er bezwaar tegen als ik jouw mooie ajax handler gebruik om de huidige te vervangen zodat het wat meer browsers netjes ondersteund? (de gene die ik voor freevolution gebruikte)

[killercow]

Even een nieuwe post, anders wordt het zo'n rommeltje.

Ik heb een ie6/7 hack toegevoegd aan de stylesheet, en inderdaad nu de parent div haslayout heeft is het opgelost. (cheers)

Ik heb ook even snel getest met echte xml headers (voor browsers die dat wel aan kunnen).
Zowiezo krijg ik meteen al errors (die de validator niet zag), en dus blokeert de hele view. (wat vreselijk non productief is.)

Serveren als XML is dus niet te doen voor dynamische content, ik kan op dit moment niet geranderen dat IEDEREEN (met een correcte browser) ook echt correcte xml krijgt, en dus nog aan de slag kan.

Een stapje lager zou strict html zijn i asume?

HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Nu nog de verdwijnende marges in IE na een div gevuld met floats.
Hmm, Als ik een   toevoeg na de <br style="clear:both" /> snapt IE t wel

[ Voor 5% gewijzigd door killercow op 13-09-2006 09:33 ]

[crisp]

killercow schreef op woensdag 13 september 2006 @ 09:25:
Ik heb ook even snel getest met echte xml headers (voor browsers die dat wel aan kunnen).
Zowiezo krijg ik meteen al errors (die de validator niet zag), en dus blokeert de hele view. (wat vreselijk non productief is.)

Serveren als XML is dus niet te doen voor dynamische content, ik kan op dit moment niet geranderen dat IEDEREEN (met een correcte browser) ook echt correcte xml krijgt, en dus nog aan de slag kan.

Leuk hè, die draconian error-handling

Een stapje lager zou strict html zijn i asume?

Dat is geen stapje lager maar gewoon het equivalent zonder de nadelen van een XML-applicatie

[killercow]

crisp schreef op woensdag 13 september 2006 @ 11:41:
[...]
Leuk hè, die draconian error-handling
[...]

Dat is geen stapje lager maar gewoon het equivalent zonder de nadelen van een XML-applicatie

okok, strict html it is
IE lijkt nu goed te werken, nu -> topic is klaar
Opera is ook functioneel volgen mij, en dan alleen Konqueror nog. bhew.