[CSS] Rare margin in IE7

[Verwijderd]

Ben bezig met het opzetten van een simpel treemenutje. Nu is het zo dat de layout van de tree goed werkt op zowel IE6 als firefox maar in IE7 zit er een margin die er niet thuishoort en ik kan niet achterhalen waar deze vandaan komt en hoe ik hem weg kan werken.

Heb al van alles geprobeerd met margins en paddings, ook overflow kon ik niks mee, negative margin werkt ook niet (wel gedeeltelijk).

Voorbeeld van de tree is hier te vinden: http://adsoft.nl/misc/tree/tree.html

Het lijkt misschien niet helemaal op een tree maar dat komt omdat de paddings van de node divs in de li elementen via javascript geset worden.

[Tehkram]

Als je slim bent kijk je ook nog even hoe je menu in elkaar zit met absolute/relatieve positioning + margins & paddings. Er is zoveel dat hier mis kan gaan en zonder een daadwerkelijk stukje code is dit moeilijk te vinden vind ik.

[--MeAngry--]

Puur beoordelend op de broncode van je URL, gewoon even de padding en margin van de UL en LI op 0 zetten, en display: block toevoegen aan de UL.

UL en LI elementen hebben een basis margin en padding hoger dan 0 in diverse browsers, vandaar. Daarnaast zou ik de structuur van je menu nog eens bekijken, want echt duidelijk vind ik hem niet, en daarnaast zou ik geen DIV's binnen je LI's gebruiken, maar SPAN's met display: block omdat je dan ook netjes aan de W3C validatie voldoet.

[Verwijderd]

Bedankt voor jullie reacties!

De padding en de margin zou niet uit moeten maken aangezien ik bovenaan in de css alle margins en paddings op 0 zet.

Cascading Stylesheet:

        *
        {
            margin: 0;
            padding: 0;
        }

Voor de zekerheid heb ik het er bij de ul en die li tag nog een keer bijgezet en de display van ul op blok gezet maar het maakt nog geen verschil.

Een div mag toch binnen een li? heb hem net even door de w3c validator gehaald maar hij gaf er geen melding van.

[RobIII]

Ik heb niet naar het voorbeeld gekeken (druk druk druk ) en heb geen IE bij de hand hier, maar is het geen haslayout probleem van een UL?

Concreet: probeer even een ul { zoom: 1; }. Als dat je probleem oplost is het idd een haslayout bug.

[ Voor 46% gewijzigd door RobIII op 27-01-2009 15:59 ]

[Verwijderd]

Bedankt voor je reactie, de gegeven oplossing werkt niet helemaal maar wel deels

Zoom haalde niks uit op de ul maar zoom instellen op de li heeft het probleem deels opgelost.

[Verwijderd]

Ik heb het probleem nu deels opgelost door:

zoom: 1; op de li's te zetten
margin-bottom: -4px: op de li's te zetten
padding-bottom: 4px; op de ul's te zetten

Er blijft alleen wel een spacing bestaan in de laatste ul van de tree.

Er moet haast wel een betere oplossing bestaan, die spacing moet ergens vandaan komen.

De structuur van de tree heb ik ook iets aangepast, heb een nieuwe versie geupload naar: http://adsoft.nl/misc/tree/tree.html

[BalusC]

Je kan al veel oplossen (en voorkomen) door (X)HTML strict te gebruiken ipv (X)HTML transitional.
Lees dit: http://hsivonen.iki.fi/doctype/

[Verwijderd]

Was er niet van bewust dat dit voorbeeldje nog op xhtml transitional stond, heb het nu op strict gezet.

Volgens de w3c validatie tool voldoet alles zich aan de standaard (dat is waarschijnlijk dan ook meteen het probleem aangezien het om ie7 gaat )

Ik ben nu weer terug bij af want zoom:1; liet de tree op een bizarre manier verspringen wanneer hij groter werd en er een hover css toegevoegd wordt aan de content div.

Hover effect toevoegen gaat op deze manier (denk niet dat daar iets fout gaat):

JavaScript:

        $(nodeContainer).find("> li > div.content").hover(
            function(e)
            {
                $(this).addClass("hover");
            },
            function(e)
            {
                $(this).removeClass("hover");
            }
        );

nodeContainer is het ul element.

[ Voor 32% gewijzigd door Verwijderd op 29-01-2009 10:09 ]

[RobIII]

Verwijderd schreef op donderdag 29 januari 2009 @ 10:07:
Volgens de w3c validatie tool voldoet alles zich aan de standaard (dat is waarschijnlijk dan ook meteen het probleem aangezien het om ie7 gaat )

Dat iets valideert heeft geen ene moer te maken met de manier waarop iets door een (al dan niet brakke) browser gerenderd wordt.

[Verwijderd]

Ben er nog steeds niet uit, weet iemand nog waar het probleem mogelijk in kan zitten? ik ga nog even verder proberen morgen als het nog niet lukt dan haal ik denk ik heel de ul/li structuur eruit en vervang deze met divs.

RobIII schreef op donderdag 29 januari 2009 @ 10:19:
[...]

Dat iets valideert heeft geen ene moer te maken met de manier waarop iets door een (al dan niet brakke) browser gerenderd wordt.

Valideren heeft niks meer weergave te maken maar de standaard is een beschrijving van hoe dingen er uit zouden moeten zien als de browser bepaalde opdrachten geeft en aangezien IE zich daar niet aan houd zal een website die zich aan de standaard houd hoogst waarschijnlijk niet goed weergegeven worden in IE. Maar dat is een hele andere discussie en een klein beetje off topic.

[curry684]

Verwijderd schreef op zondag 01 februari 2009 @ 17:45:
de standaard is een beschrijving van hoe dingen er uit zouden moeten zien als de browser bepaalde opdrachten geeft en aangezien IE zich daar niet aan houd zal een website die zich aan de standaard houd hoogst waarschijnlijk niet goed weergegeven worden in IE.

Hoewel het offtopic is is dit wel een erg negatieve variant op de werkelijkheid. IE7 mag dan geen ster zijn in het strak naleven van regels, hij gaat er wel dermate ver in dat een renderfout als deze gewoon een bug is die gepatcht kan worden aan jouw kant. Merendeel van de goed opgezette standards-compliant sites rendert net zo perfect in FF, Opera en Safari als in IE7: tis met name IE6 die zich grondig verslikt in veel W3C-standards (denk max-height en min-height).

[Boelie-Boelie]

BalusC schreef op woensdag 28 januari 2009 @ 17:09:
Je kan al veel oplossen (en voorkomen) door (X)HTML strict te gebruiken ipv (X)HTML transitional.
Lees dit: http://hsivonen.iki.fi/doctype/

Het is een uitstekend artikel waar je naar verwijst, maar daar staat geen bewijs voor wat jij beweert. Sterker nog, een strict doctype voorkomt niet meer problemen dan een transitional doctype; een valide doctype (strict of transitional) voorkomt wel meer problemen dan een ontbrekend of onvolledig doctype.

[Verwijderd]

Ben er net weer even naar aan het kijken geweest en heb het probleem nu volgens mij volledig opgelost.

Na elk li element per niveau een andere background color te geven werd het een stuk duidelijker waar de margins vandaan kwamen.

De margins die ontstonden waren als volgt:

3px bottom margin op elk li element

3px top margin op het eerste li element in het 2e niveau of hoger

Wat ik heb gedaan om deze margins ongedaan te maken is dit:

Cascading Stylesheet:

        .tree ul li
        {
            margin-bottom: -3px !ie; /* IE 7 fix */
        }
        .tree ul li ul li:first-child
        {
            margin-top: -3px !ie; /* IE 7 fix */
        }

Het !ie is om ervoor te zorgen dat alleen ie het inleest, dit is volgens mij geen erkende css hack, gebruik het ook alleen even in dit voorbeeld, voor de volledige versie gebruik ik een 2e css die alleen bij IE7 ingeladen wordt.

[Verwijderd]

Met de laatste oplossing versprong de tree op dezelfde manier als met zoom:1; heb dat nu opgelost door een niet bestaande css class te verwijderen uit de div waar de tree inzit wanneer de hover css wordt toegepast. Het hover effect is er wel een beetje laggy van geworden.

$("#tree").removeClass("dummy");

De browser zal het hele ding dan wel opnieuw tekenen ofzo waardoor het goed gaat, soort gelijk probleem ooit is in ie6 gehad.