[IE] Tabellen trekken zich niks aan van opgegeven grootte

[Arjan]

Alwéér een vraag van mijn kant ivm websites maken.
Ditmaal lijkt het een IE only probleem te zijn waar ik mee zit.
Ik heb voor een kennis een site gemaakt, die maar heel simpel hoeft te zijn, maar natuurlijk wel correct moet functioneren.
Nu heb ik de site gemaakt dmv kladblok en FireFox. Dus toen ik em klaar vond ging ik hem testen in andere browsers en toen bleek dat ie het deed in Opera, Mozilla en Firefox. Internet Explorer trekt zich itt de anderen helemaal niks aan van het feit dat ik de "MENU" class een width meegeef van 140px.

IE vind dat beide cellen 50% breed moeten zijn. Voor de rest gaat alles zoals het bedoeld is, behalve dan de Firefox een renderbug lijkt te hebben. Hij renderd het menu namelijk met een dubbele rechterborder, maar dat vind ik verder niet zo'n probleem.

Logische vraag, waarom doet IE wat ie doet en hoe kan ik dit oplossen?

Wat ik geprobeerd heb:
De width aan te geven in de HTML file, dmv een inline style de width opgeven en zelfs de andere tabel een width van 100% geven. Zonder resultaat natuurlijk.

Hier is de url: http://members.home.nl/drkatz/coen/
Let niet op de inhoud, daar gaat het niet om.

Alvast hartelijk bedankt!

[André]

Voor die border: zet hem op 1px ipv 1pt borders altijd in pixels definieren.

[mmedia]

offtopic:
Below are the results of attempting to parse this document with an SGML parser.

1.
Line 24, column 83: there is no attribute "WCLASSTH"

...nhoud.html" FRAMEBORDER="0" WCLASSTH="10"></IFRAME>

You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.

bron

[André]

En voor de linker TD, zet hem op procenten ipv pixels, dan heb je bijna je gewenste resultaat. Beter nog is om deze simpele layout met layers te maken.

www.glish.com/css

[Arjan]

André schreef op 20 september 2004 @ 22:29:
Voor die border: zet hem op 1px ipv 1pt borders altijd in pixels definieren.

Damn, nog 1 vergeten, dacht ze allemaal te hebben (had in het begin zonder op te letten alles op pt getypt)

mmedia schreef op 20 september 2004 @ 22:30:

offtopic:
Below are the results of attempting to parse this document with an SGML parser.

1.
Line 24, column 83: there is no attribute "WCLASSTH"

...nhoud.html" FRAMEBORDER="0" WCLASSTH="10"></IFRAME>

You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.

bron

das ook al een typo, ben erg slordig vandaag
Helaas hebben beide typo's niks te maken met de menu width (wel met de dubbele border)

André schreef op 20 september 2004 @ 22:34:
En voor de linker TD, zet hem op procenten ipv pixels, dan heb je bijna je gewenste resultaat. Beter nog is om deze simpele layout met layers te maken.

www.glish.com/css

Ik had eerst layers, maar die gaven nog meer problemen dan de tabellen. Heb uiteindelijk toch maar besloten voor ye good old tabellen. Zie hier voor m'n probeersel met layers: http://members.home.nl/drkatz/debug/

[ Voor 21% gewijzigd door Arjan op 20-09-2004 22:40 ]

[marko77]

Ik ben dit wel eens eerder tegengekomen,

een tabel waar je de cellen een bepaalde breedte geeft en dat het toch niet werkt.

uit mijn tests is gebeleken dat de colspan van de bovenste rij de boel in de soep doet lopen.

Als je die gewoon als 2 kolommen definieert is er geen probleem, hetzelfde geldt als je de twee rijen als aparte tabellen neerzet, maar dat is bij jou niet handig.

Waar dit probleem door komt, daar ben ik echter nog niet achter

[Verwijderd]

mmedia schreef op 20 september 2004 @ 22:30:

offtopic:
Below are the results of attempting to parse this document with an SGML parser.

1.
Line 24, column 83: there is no attribute "WCLASSTH"

...nhoud.html" FRAMEBORDER="0" WCLASSTH="10"></IFRAME>

You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.

bron

Ik vraag me serieus af waar toch altijd elk design door de w3 validator gehaald moet worden?

[Arjan]

marko77 schreef op 20 september 2004 @ 22:39:
Ik ben dit wel eens eerder tegengekomen,

een tabel waar je de cellen een bepaalde breedte geeft en dat het toch niet werkt.

uit mijn tests is gebeleken dat de colspan van de bovenste rij de boel in de soep doet lopen.

Als je die gewoon als 2 kolommen definieert is er geen probleem, hetzelfde geldt als je de twee rijen als aparte tabellen neerzet, maar dat is bij jou niet handig.

Waar dit probleem door komt, daar ben ik echter nog niet achter

Tja, lijkt een bug te zijn in IE, want de andere browsers doen het netjes.

Wel vervelend dat ik voor IE door de knieen moet en dus percentages moet gebruiken

Iig, Thanks André het is een beetje een twijfelachtige oplossing, maar werkt er niet minder op. Het menu is nu 23% procent breed, tot tevredenheid van IE.

Verwijderd schreef op 20 september 2004 @ 22:44:
[...]


Ik vraag me serieus af waar toch altijd elk design door de w3 validator gehaald moet worden?

Omdat je dan goede hoop mag hebben dat hij cross-browser is. Zoals je ziet is het geen harde regel omdat IE het weer vernachelt. Ook met de pixels validate hij, maar IE slikte het niet.

[ Voor 20% gewijzigd door Arjan op 20-09-2004 22:47 ]

[Verwijderd]

Check je doctype... op een of andere manier wil IE nog wel eens vanaf versie 6 ineens dingen anders interperteren als je doctype niet (goed) specificeerd.... zoook dat ineens een horizontale scrollbar uit het niets erbij komt ofzo.

[Verwijderd]

zet in je tabel eigeschappen eens: nowrap en definieer idd in px en niet in procenten

Succes!

[crisp]

Ik mag hopen dat de topicstarter er na een maand ook wel uitgekomen is...