Toon posts:

IE7, doctype en CSS - layout verdwijnt

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik ben bezig met een website die ik in elkaar zet met asp.net en CSS. Ik loop tegen een probleem aan met de layout in IE7. Wanneer ik de website in IE7 start, verdwijnen vrijwel alle elementen op een foto na. Wanneer ik het window iets vergroot of verklein springt alles opeens op de juiste plek.

Na wat gepruts ben ik er achter gekomen dat dit probleem weg is wanneer ik de doctype uit het document haal. Ik gebruikt XHTML Transitional DTD, maar heb ook de strict geprobeerd en HTML transitional en strict. Maar met elk type doctype komt dit probleem terug.

Heeft iemand hier een goede suggestie voor mij. Met googlen kwam ik er niet uit.


Thanks

Verwijderd

Zou je een link kunnen posten?

  • OkkE
  • Registratie: Oktober 2000
  • Laatst online: 10-11 15:46

OkkE

CSS influencer :+

Een beetje code zou handig zijn.

Maar ik gok op een foutje (andere werking) in de CSS, die in quirksmode niet tevoorschijn komt, maar in standaard-mode wel.

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.


Verwijderd

Topicstarter
Ik heb een pagina opgelagen en geupload op een gratis webhost. Het is hier te vinden.

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 24-11 23:24

BikkelZ

CMD+Z

Bedankt voor dat plaatje :r

Sorry, ik heb hem maar weer dichtgeklikt :/

Modbreak:en wat voegt dit toe aan het topic :/

[ Voor 26% gewijzigd door BtM909 op 14-06-2007 13:17 ]

iOS developer


Verwijderd

Raar dat je dit wilt oplossen met javascript, zou je beter met css kunnen doen maar okee.

1. Code branching kun je beter op document.all doen, deze container word alleen door IE browsers ondersteunt. Zo branch je op parser en niet op een header.

2. jij wil de grootte van het html element weten niet van het browser scherm, gebruik dus de propperty scrollHeight (werkt niet goed in opera 6)

Verwijderd

dan klik ik maar niet :)

gok: je past xhtml syntax in een html document toe. Probleem is dat IE geen xhtml syntax snapt. Wat vaak gebeurt is dat mensen iets als
code:
1
<script src="..." />
in hun pagina opnemen. IE snapt geen xhtml, dus ziet die trailing slash niet. Gevolg: het script element wordt niet afgesloten en je krijgt rare dingen. Gebruik dus gewoon html syntax:
code:
1
<script src="..."></script>

  • T-MOB
  • Registratie: Maart 2001
  • Laatst online: 23:49
Verwijderd schreef op donderdag 14 juni 2007 @ 11:24:
1. Code branching kun je beter op document.all doen, deze container word alleen door IE browsers ondersteunt. Zo branch je op parser en niet op een header.
En wie garandeert jou dat de Mozilla-developers in de toekomst geen support gaan inbouwen voor document.all? In het pad "document.all -> dus IE -> dus een bepaalde feature (bug)" kan nogal wat misgaan met de aannames. Beter kun je gewoon de functies checken die je wil gebruiken, bijvoorbeeld:
JavaScript:
1
2
3
4
5
6
7
8
9
function getHeight(element) {
  ret = -1;
  if (element.clientHeight) {
    ret = element.clientHeight;
  } else if (element.offsetHeight) {
    ret = element.offsetHeight;
  }
  return ret;
}


Ontopic: ik krijg de pagina van het voorbeeld hetzelfde te zien in IE7 als Firefox. Het enige verschil dat in me opkomt wat zou kunnen uitmaken in de context van geen/wel doctype in IE is document.documentElement vs. document.body. Eea staat wel in een testcase op quirksmode.org

(plaatje viel wel mee, tis een been met psoriasis oid)

Regeren is vooruitschuiven


Verwijderd

Topicstarter
Verwijderd schreef op donderdag 14 juni 2007 @ 11:24:
Raar dat je dit wilt oplossen met javascript, zou je beter met css kunnen doen maar okee.

1. Code branching kun je beter op document.all doen, deze container word alleen door IE browsers ondersteunt. Zo branch je op parser en niet op een header.

2. jij wil de grootte van het html element weten niet van het browser scherm, gebruik dus de propperty scrollHeight (werkt niet goed in opera 6)
Thanks voor het kijken en het niet weg klikken ondanks het plaatje :). Met oplossen met javascript bedoel je het stukje javascript dat de schermhoogte bepaald neem ik aan. Die wordt inmiddels niet meer gebruikt, maar staat er nog wel in. Ik heb het er gelijk even uit geknipt, maar het probleem blijft.

Verwijderd

Topicstarter
Verwijderd schreef op donderdag 14 juni 2007 @ 11:26:
dan klik ik maar niet :)

gok: je past xhtml syntax in een html document toe. Probleem is dat IE geen xhtml syntax snapt. Wat vaak gebeurt is dat mensen iets als
code:
1
<script src="..." />
in hun pagina opnemen. IE snapt geen xhtml, dus ziet die trailing slash niet. Gevolg: het script element wordt niet afgesloten en je krijgt rare dingen. Gebruik dus gewoon html syntax:
code:
1
<script src="..."></script>
Ik heb script tags netjes afgesloten. De link tag stond wel als <link />, maar het aanpassen naar <link></link> veranderd het probleem niet.

Verwijderd

fyi: het link element mag geen closing tag hebben: http://www.w3.org/TR/html401/struct/links.html#edef-LINK

maar daar zit je probleem dus blijkbaar niet, dus dat maakt dit een beetje offtopic

Verwijderd

Topicstarter
T-MOB schreef op donderdag 14 juni 2007 @ 12:04:
[...]

Ontopic: ik krijg de pagina van het voorbeeld hetzelfde te zien in IE7 als Firefox. Het enige verschil dat in me opkomt wat zou kunnen uitmaken in de context van geen/wel doctype in IE is document.documentElement vs. document.body. Eea staat wel in een testcase op quirksmode.org

(plaatje viel wel mee, tis een been met psoriasis oid)
Vreemd dat het er bij jou in IE7 wel normaal uit ziet. Hier een screenshot van hoe het er bij mij uit ziet. Ik hen ook nog geprobeerd alles tussen <script> en </script> er uit te knippen, maar ook dit lost het probleem niet op.


(aandoening op plaatje is eczema nummulare, weet je ook weer wat die rare plekjes op je been zijn :P )

Verwijderd

En wie garandeert jou dat de Mozilla-developers in de toekomst geen support gaan inbouwen voor document.all? In het pad "document.all -> dus IE -> dus een bepaalde feature (bug)" kan nogal wat misgaan met de aannames. Beter kun je gewoon de functies checken die je wil gebruiken, bijvoorbeeld:
Omdat document.all redlijk nutteloos is en als de programeurs van mozilla dat wilden hadden ze dat al vééél eerder gedaan. Deze manier woord door veel bekenden libraries ook gebruikt.

Verder is het niet echt efficient om voor elke regel een check uit te voeren.


Ontopic: ik heb helaas geen tijd om je code helemaal te debugen, hoe worden de dimensies van je div's ingesteld? CSS only of door JS?

  • T-MOB
  • Registratie: Maart 2001
  • Laatst online: 23:49
Verwijderd schreef op donderdag 14 juni 2007 @ 12:22:
[...]Vreemd dat het er bij jou in IE7 wel normaal uit ziet.
Uhmm... Niet zo vreemd eigenlijk. Ik had javascript nog uit staan O-). Met javascript enabled krijg ik hetzelfde beeld als het screenshot...

Het gaat dus ergens mis in je script, waarbij ik nogsteeds denk dat het in het document.body <> document.documentElement verhaal ligt...

Regeren is vooruitschuiven


Verwijderd

T-MOB schreef op donderdag 14 juni 2007 @ 12:04:
[...]

(plaatje viel wel mee, tis een been met psoriasis oid)
offtopic:
Ik vond het meer op Ringworm lijken..

  • T-MOB
  • Registratie: Maart 2001
  • Laatst online: 23:49
Verwijderd schreef op donderdag 14 juni 2007 @ 12:55:
[...]Omdat document.all redlijk nutteloos is en als de programeurs van mozilla dat wilden hadden ze dat al vééél eerder gedaan. Deze manier woord door veel bekenden libraries ook gebruikt.
Het gaat er niet om of document.all nutteloos is, ook niet om wat jij denkt dat de Mozilla developers al dan niet gedaan zouden hebben. Het gaat erom dat je (eventueel op termijn) onjuiste aannames doet over de ondersteuning van bepaalde features.

En ja, er zijn libraries verkrijgbaar die dat soort technieken toepassen. Die zijn een hel om te repareren als je klant van browser(versie) wisselt en het blijkt stuk (got the t-shirt...).

Regeren is vooruitschuiven


  • Boelie-Boelie
  • Registratie: November 2004
  • Laatst online: 26-09-2020
Maar waarom niet gewoon een simpele fluid layout met een thumbnail die je vergroot op een manier zoals lightbox? Hoef je over dat resizen geen zorgen meer te maken.

Cogito ergo dubito


Verwijderd

Topicstarter
Ik heb al het javascript er uit gegooit, maar het probleem blijft. Dimensies van mijn div'jes wordt met css ingesteld.

Bovendien lijkt me de relatie javascript en doctype weer een vreemde, of zie ik dan wat over het hoofd?

Verwijderd

Topicstarter
Mooi. Ik geloof dat ik de boosdoener gevonden heb.

De parser propte er stiekem nog een stukje script onder. Als ik dit er uit haal is het probleem opgelost. Het gaat om dit stukje script:

<script type="text/javascript">
<!--
WebForm_AutoFocus('txtAnswer');// -->
</script>


Blijkbaar vindt IE7 het niet lekker om geautofocused te worden. Maar ik wil wel de focus op txtAnswer hebben. Iemand een idee hoe ik hier omheen kan?

Verwijderd

T-MOB schreef op donderdag 14 juni 2007 @ 13:02:
[...]

Het gaat er niet om of document.all nutteloos is, ook niet om wat jij denkt dat de Mozilla developers al dan niet gedaan zouden hebben. Het gaat erom dat je (eventueel op termijn) onjuiste aannames doet over de ondersteuning van bepaalde features.

En ja, er zijn libraries verkrijgbaar die dat soort technieken toepassen. Die zijn een hel om te repareren als je klant van browser(versie) wisselt en het blijkt stuk (got the t-shirt...).
Tja, ieder zijn ding dan maar. Ik kies ervoor om een makkelijk, efficient en betrouwbare methode te kiezen die "Messchien" ooit niet meer werkt (als IE zicht aan standaarden gaat houden ;).

1. Tegen die tijd is die site al aan vervanging toe.
2. Ik vervang mijn browsercheck functie met een andere > uurtje factuurtje.

Tuurlijk wil je als programeur een pakket dat "for ever" kan blijven draaien. Maar praktisch gezien is hier geen rekening mee te houden.

Jou manier is niet slecht maar wel langzamer en in grote javascript gedreven paginas zal dit zijn tol gaan eisen.

[ Voor 12% gewijzigd door Verwijderd op 14-06-2007 13:42 ]


  • T-MOB
  • Registratie: Maart 2001
  • Laatst online: 23:49
Verwijderd schreef op donderdag 14 juni 2007 @ 13:40:
Tja, ieder zijn ding dan maar. Ik kies ervoor om een makkelijk, efficient en betrouwbare methode te kiezen die "Messchien" ooit niet meer werkt (als IE zicht aan standaarden gaat houden ;).
Je doet meer aannames dan "dat IE zich niet aan de standaard houdt". Je legt een relatie tussen het ondersteunen van document.all en het ondersteunen van bepaalde functionaliteit. Dat is een aanname die gevaarlijk is omdat je geen enkele controle hebt over welke functionaliteit door welke browser wordt geimplementeerd, noch over welke browser je bezoekers gebruiken.
1. Tegen die tijd is die site al aan vervanging toe.
Wanneer is dat dan? volgende week? volgend jaar?. Zie m'n eerste punt, je weet het niet
2. Ik vervang mijn browsercheck functie met een andere > uurtje factuurtje.
Uurtje factuurtje is geen echt argument natuurlijk. Als dat zo was dan sms-te ik mijn code wel naar de server... Daarnaast is het niet per se zo simpel als het vervangen van je browsercheck. Als je pech hebt mag je een hele nieuwe branch ontwikkelen.
Jou manier is niet slecht maar wel langzamer en in grote javascript gedreven paginas zal dit zijn tol gaan eisen.
Hoeveel langzamer is dat dan? Simpele if-statements kosten haast niets in vergelijking met DOM-lookups, modulos, XMLhttp-request... Als performance een issue is dan zijn die paar extra if-statements wel het laatste waarop iets winnen valt.
Maar goed, ik lever graag een beetje performance in voor onderhoudbare code die future proof is.

Regeren is vooruitschuiven


Verwijderd

Topicstarter
ehhh....no offence, maar best wel off topic

Verwijderd

excuses, ik zal vanavond na men werk even naar je code kijken.

Verwijderd

Topicstarter
Verwijderd schreef op donderdag 14 juni 2007 @ 15:14:
excuses, ik zal vanavond na men werk even naar je code kijken.
Bedankt dat je de tijd wilde nemen er naar te kijken. Ik heb inmiddels wel uitgevonden waar het aan lag, dus mijn probleem is opgelost (zie mijn vorige bericht). Ik heb het stukje script vervangen door een onload="document.form1.ButVolgendeTest.focus()" in de body gezet. Dus ik ben weer helemaal blij.


Thanks iedereen voor de hulp _/-\o_
Pagina: 1