[css] boxmodel verschillen Moz/IE

[crisp]

Ik ben even zo brutaal om Clay's bevindingen w/b verschillen in interpretatie van het zogenaamde boxmodel tussen IE en Mozilla uit dit topic te trekken; uiteindelijk waren we 4 onderwerpen in 1 topic aan het behandelen

Clay schreef op 13 augustus 2002 @ 21:32:
het verschil tussen IE en MOZ is idd raar. Ik wist trouwens niet van het verschil tussen borders in IE en Moz, ik wist wel dat nested layers met borders wat gevrot met positioning vereisen als je er borders indoet, maar meer niet.
Wat ik irritanter vind is dat moz anders met padding omgaat. Een div van 200px breed met een padding van 2 wordt 204 pixels breed, en 4px hoger dan de initiele height. als je een padded layer nest in een niet padded layer gaat die geneste dus "uitsteken" uit zijn parent, en dat is geen gezicht. IE laat de afmetingen wel met rust

heb hier een kleine css test, geeft het verschil aan

Ik heb dit even nagezocht in de W3C CSS2 recommendation, en vond daar het volgende:

Height: This property specifies the content height of boxes generated by block-level and replaced elements.
Iets dergelijks geldt dus ook voor de width property.

box model: The dimensions of the content area of a box -- the content width and content height -- depend on several factors: whether the element generating the box has the 'width' or 'height' property set, whether the box contains text or other boxes, whether the box is a table, etc. Box widths and heights are discussed in the chapter on visual formatting model details.

The box width is given by the sum of the left and right margins, border, and padding, and the content width. The height is given by the sum of the top and bottom margins, border, and padding, and the content height.

Kortom; in deze heeft Mozilla dus volgens mij gelijk. Je geeft een width en height property aan een blocklevel (een div). Dit bepaald dus de contentwidth en contentheight.
De hoogte van de box (de div) wordt echter bepaald door de som van de contentheight, de top en bottom margin, de border en de padding! Hetzelfde dus ook voor de breedte.

Mzzz, lijkt me weinig meer aan toe te voegen eigenlijk. Of niet?

[Hangloozz]

ja ben ik het wel mee eens: een tabel met cellpadding wordt ook breder/hoger dan de opgegeven width/height.

Of het handig is is een 2e.
Ik denk het niet want je moet nu gaan zitten rekenen wat je formaten moeten worden en anders kan je het justify-en aan de content overlaten.

[crisp]

Hangloozz schreef op 14 augustus 2002 @ 00:24:
ja ben ik het wel mee eens: een tabel met cellpadding wordt ook breder/hoger dan de opgegeven width/height.

Of het handig is is een 2e.
Ik denk het niet want je moet nu gaan zitten rekenen wat je formaten moeten worden en anders kan je het justify-en aan de content overlaten.

Of het handig is laat ik in het midden (ikzelf heb er eigenlijk weinig problemen mee). Wat zeker niet handig is, is dat IE padding en borders binnen de opgegeven dimensies laat vallen, en Mozilla erbuiten. Puur het verschil in implementatie dus die het onmogelijk maakt om met 1 stylesheet hetzelfde effect te bereiken in beide browsers

[WouZz]

IE zit inderdaad fout. Hier staat het misschien nog zelfs wat beter gevisualiseerd:

CSS1 assumes a simple box-oriented formatting model where each formatted element results in one or more rectangular boxes. (Elements that have a 'display' value of 'none' are not formatted and will therefore not result in a box.) All boxes have a core content area with optional surrounding padding, border and margin areas.

code:

 _______________________________________
|                                       |
|           margin (transparent)        |
|   _________________________________   |
|  |                                 |  |
|  |        border                   |  |
|  |   ___________________________   |  |
|  |  |                           |  |  |
|  |  |     padding               |  |  |
|  |  |   _____________________   |  |  |
|  |  |  |                     |  |  |  |
|  |  |  |  content            |  |  |  |
|  |  |  |_____________________|  |  |  |
|  |  |___________________________|  |  |
|  |_________________________________|  |
|_______________________________________|

          |    element width    |
|               box width               |

The size of the margin, border and padding are set with the margin (5.5.1-5.5.5), padding (5.5.6-5.5.10), and border (5.5.11-5.5.22) properties respectively. The padding area uses the same background as the element itself (set with the background properties (5.3.2-5.3.7)). The color and style for the border is set with the border properties. The margins are always transparent, so the parent element will shine through.

The size of the box is the sum of the element width (i.e. formatted text or image) and the padding, the border and the margin areas.

Alleen jammer van die verschillende interpretaties.. Ik merkte het toevallig laatst ook weer toen ik bezig was met een site.. Gelukkig is het een 1 pixel verschil dus ik laat het maar voor wat het is. Maar toch jammer dat het zo wel weer lastiger wordt om je pagina's een beetje identiek te krijgen in verschillende browsers..

[crisp]

Wat mij in deze stoort is dat mensen eerder geneigd zijn de IE implementatie als correct te beschouwen, ipv de Mozilla implementatie (ik trapte daar in het begin ook in, en dacht dat de fout bij Mozilla lag).
Het 'voelt' logisch dat als je een width en height aan een <div> geeft, hij ook niet groter wordt op het moment dat je borders of padding gaat toevoegen. Het simplificeerd het geheel ook als zodanig wb opmaak.
Ik kan zo 1-2-3 ook niet bedenken wat de downside is van de IE-implementatie, en wat precies de redenen zijn waarom specifiek voor dit model gekozen is als standaard...

[Bluestorm]

Downside is denk ik als je element iets is met een vaste afmeting... een plaatje bijvoorbeeld. Als je daar een border om heen maakt, wil je toch graag dat het niet je afbeelding bedekt... zelfde voor padding.

Maar het is inderdaad een vervelend probleem want als je het met één stylesheet wil oplossen zul je over het algemeen meer HTML moeten schrijven om het gewenste effect te bereiken.

[drm]

Wow, en ik tot nu toe inderdaad ook altijd maar denken dat Mozilla fout zat.

The size of the box is the sum of the element width (i.e. formatted text or image) and the padding, the border and the margin areas.

Wat border en margin betreft, vind ik dit wel terecht, maar wat padding betreft? Dat gaat echt volledig tegen mijn gevoel in.

Als je een stylesheet definieert voor bijvoorbeeld een div:

code:

div#sjaak {
   width:200px;
   height:20px;
}

En in de HTML zet je een div neer:

code:

<div id="sjaak">blaat</div>

Dan ga ik er vanuit, omdat ik de stylesheet op die div toepas dat de div dus 200px breed is, en niet de inhoud van die div.

Goed, da's natuurlijk zo vaag als wat, want wat is de div, als hij geen inhoud heeft...

Maar de afstand van de box (div) tot de text, is de padding. Heeft toch niets meer met de hoogte/breedte te maken? Imo wordt er nu een styleproperty in verband gebracht met elementen buiten de div, terwijl die er helemaal niets mee te maken hebben. Kortom, je krijgt een soort van outerMargin en innerMargin, ipv resp. margin en padding

Margin daarentegen bepaald de afstand tot andere elementen, ervoor en erna

Border legt een border om het element, kan ik me ook voorstellen

maar padding ....

[Clay]

bij MS gaan ze dit natuurlijk niet "fixen", die houden het lekker zo zoals het nu is. Moz zal wellicht ook wel een poot stijf houden, maar in Bugzilla staat oa het padding probleem er wel tussen, het wordt dus duidelijk als lastig of raar ervaren.

Even niet lettend op wat volgens de standaarden correct is; wat is handiger?
Als ik nu ergens een div nest in een andere, even breed maak en een kleur geef, maar ook een padding van bv 2 (wat heel niet ondenkbaar is) gaat de boel uitsteken. Ook tables die je met css een padding geeft worden groter, en dat kan als je ze in je ze voor design positionering gebruikt je hele slicing in de soep gooien.
De width die je dus opgeeft wordt niet de uiteindelijke width Je moet gaan rekenen om alles alsnog op zijn plek te krijgen, en dat slaat eigenlijk nergens op. Het is gewoon handiger als de width en height die je opgeeft de uiteindelijke dimensies worden, en dat vergroten alleen optreedt als de content van het element anders niet zou passen.

Maar ik snap het nou bijna helemaal niet meer, IE is echt gek

code:

table
<table border=0 cellspacing=0 cellpadding=0>
<tr><td style="width:200; background-color:blue;">test</td></tr>
</table>
<br>
<table border=0 cellspacing=0 cellpadding=0>
<tr><td style="width:200; background-color:blue; padding:2">test</td></tr>
</table>
<br>
div
<div style="width:200; background-color:blue;">test</div><br>
<div style="width:200; background-color:blue; padding:2">test</div>

Mozilla maakt als verwacht de td EN de div hoger en breder. IE maakt de td WEL breder en hoger nu, en de div alleen wat hoger (omdat het anders niet past)

[Clay]

drm schreef
maar padding ....

Inderdaad. Padding zit BINNEN het element. het voelt gewoon fout

[drm]

Wat ik vermoedde blijkt waar te zijn, XHTML en HTML doctypes maken ook nog 's verschil.

http://gerard.yoursite.nl/got/box-model/index.php

* drm is de draad kwijt...

[Clay]

de standaarden van de hele dom(me) wereld staan op instorten
het is een samenzwering! ik wist het! dat ns4 eindelijk weg was was te mooi om waar te zijn!
wazigheden schieten inene als paddestoelen uit de grond

[Verwijderd]

Ik moet zeggen dat ik er geen last van heb, je kent de verschillen en die zijn altijd hetzelfde, niet zoals bij ns4, die elke keer alles weer anders deed.

[Verwijderd]

kep nog een vraagje, weet niet zeker of ie hier thuishoort maar ut lijkt me van wel anders deed ik het niet

IE heeft het zogenaamde "parentElement" maar hoe handelt mozilla dit af ?
is er een statement wat hetzelfde doet ?
met parentElement kan je bijvoorbeeld de achtergrondkleur van de TD waar een button in staat kleur

code:

<input type="button" onclick="parentElement.style.backgroundColor='#000000'">

deze regel kleurt zoals jullie weten de achtergrond van het bovenstaande element zwart, maar heeft mozilla ook zo'n command ?

----------------------------------------------------------------------

om ook even op de discussie hier in te gaan ...
los van wat nou de standaard, vind ik het het handigste als je als width 50 opgeeft dat ie ook echt 50px breed is, en dat je margin aan de buitenkant komt, en je padding aan de binnenkant, padding de div, table whatever niet groter gaan maken
wat dat betreft doet IE het dus beter vind ik ...

[Verwijderd]

Verwijderd schreef op 14 augustus 2002 @ 11:33:
kep nog een vraagje, weet niet zeker of ie hier thuishoort maar ut lijkt me van wel anders deed ik het niet

IE heeft het zogenaamde "parentElement" maar hoe handelt mozilla dit af ?
is er een statement wat hetzelfde doet ?
met parentElement kan je bijvoorbeeld de achtergrondkleur van de TD waar een button in staat kleur

code:

<input type="button" onclick="parentElement.style.backgroundColor='#000000'">

deze regel kleurt zoals jullie weten de achtergrond van het bovenstaande element zwart, maar heeft mozilla ook zo'n command ?

code:

<input type="button" onclick="this.style.backgroundColor='#000000'">

[Verwijderd]

ghehe, je begrijpt me verkeerd, met bovenstaand element bedoel ik het element boven input ...

code:

<table>
  <tr>
    <td><input type="button" onclick="parentElement.style.backgroundColor='#000000'"></td>
  </tr>
</table>

hier bedoel ik dus de TD

[ Voor 0% gewijzigd door Verwijderd op 14-08-2002 11:48 . Reden: [code] fout ]

[Verwijderd]

Excusez:

code:

<table>
  <tr>
    <td><input type="button" onclick="parentNode.style.backgroundColor='#000000'"></td>
  </tr>
</table>

[Verwijderd]

als een tiet

die parentNode is trouwens dom1 standaard zag ik op MSDN (kwam er via google toen ik op parentNode zocht) dus die werkt ook met IE

[[eNeRGy]]

parentNode werkt bijna hetzelfde als parentElement, en in deze toepassing werkt hij hetzelfde. (zie voorbeeld Shadow3333)

[drm]

en nou weer ontopic aub

[WouZz]

drm schreef op 14 augustus 2002 @ 10:27:
Wat ik vermoedde blijkt waar te zijn, XHTML en HTML doctypes maken ook nog 's verschil.

http://gerard.yoursite.nl/got/box-model/index.php

* drm is de draad kwijt...

UH? Dit lijkt me eerder een bug in Mozilla. Want wat heeft een doctype in dit verband nou met opmaak/CSS te maken??

[[eNeRGy]]

De doctype werkt bij IE6 en Mozilla als een switch tussen de standards en quirck mode

[Verwijderd]

drm schreef op 14 augustus 2002 @ 10:27:
Wat ik vermoedde blijkt waar te zijn, XHTML en HTML doctypes maken ook nog 's verschil.

http://gerard.yoursite.nl/got/box-model/index.php

* drm is de draad kwijt...

http://tweakers.net/~crew/Cheatah/html/html.html

XHTML+XML declaration == HTML (IE)

Als je XHTML gebruikt, zet dan ook <?xml version="1.0"?> aan het begin van je document, dan zijn er geen verschillen in CSS afhandeling van IE, vergeleken met HTML. Het gekke is dat ook dit het probleem in Mozilla nog niet oplost.

Ik ben er ook nog niet helemaal achter hoe dit komt, maar ik heb in m'n template die XML declaration er ook voor staan, na al dat geknoei met DTD's.

offtopic:
Voor de geïnteresseerden is er nog een revisie van de CSS2 specificatie, hier te vinden:
http://www.w3.org/TR/CSS21/
Voorlopig zijn de aural properties weer verwijderd, aangezien dat in CSS3 een speciale module wordt

[Verwijderd]

ik was/ben ook bezig met een site met ver door gevoerde css, ik wou dus ook alleen maar divjes gebruiken etc. maar liep dus ook tegen dit probleem op,
wel even fijn om te horen dat het dus dat het niet aan mij lag,
wel irritant dat Explorer weer dwars moet liggen, alleen maar omdat hun manier eigelijk handiger is hebben ze die regel aan hun laars gelapt.

Jammer wel, maar ik ben toch maar weer overgestapt op table's en daar gewoon een style in geplakt, werkt eigenlijk net zo makkelijk, zo niet makkelijker, en is dus voor allebei de browsers geschikt.

[Verwijderd]

Me Too Eddie_n
Ben ook al de hele avond aan het klooien geweest
Dacht ook al dat het aan mij of/en aan mozilla lag.
Nu nog een oplossing bedenken

[crisp]

Verwijderd schreef op 15 augustus 2002 @ 01:04:
Me Too Eddie_n
Ben ook al de hele avond aan het klooien geweest
Dacht ook al dat het aan mij of/en aan mozilla lag.
Nu nog een oplossing bedenken

Neem het jezelf niet kwalijk; ik heb ook gevochten met deze demonen. Eerst mezelf de schuld gegeven, vervolgens Mozilla, maar dan nu uiteindelijk pas blijkt dat IE de schuldige is...
Ik vind de W3C recommendation wat dit betreft ook niet logisch gevoelswijs; echter als je het eenmaal weet kan je er rekening mee houden, maar alleen middels scripting.
Het quircks/strict verhaal maakt het zelfs nog iets gecompliceerder imho.
IE zal de boel wel niet zo gauw gaan omgooien, Mozilla aan de andere kant denk ik ook niet.
Stuck between a rock and a hard place dus...

[oh,when?]

hmm gek want dit is echt al een hele oude discussie. * oh,when? had wel verwacht dat deze bug in IE5+ allang bekend was.

* oh,when? strooit weer met linkjes ( woei ik ben de linkjesman van /13..oladiee )

* The Good, The Bad, and the Ugly
* Box Model Hack

[crisp]

oh,when? schreef op 15 augustus 2002 @ 02:11:
hmm gek want dit is echt al een hele oude discussie. * oh,when? had wel verwacht dat deze bug in IE5+ allang bekend was.

* oh,when? strooit weer met linkjes ( woei ik ben de linkjesman van /13..oladiee )

* The Good, The Bad, and the Ugly
* Box Model Hack

Blijkbaar toch niet; ik loop er tegenaan, en met mij vele anderen die geen clue hebben. Het moge duidelijk zijn dat IE hier fout zit. Het toepassen van allerlei 'hacks' zie ik echter toch niet zo zitten; straks blijkt met de komst van IE6.1 de boel 'gerepareerd' te zijn, en hebben dezelfde hacks een negatief resultaat...
Andersom geld echter hetzelfde; een webbouwer gaat nu uit van de verkeerde implementatie van IE (hoe doet hij dat? Nou, gewoon simpelweg een check op document.all!), en fixed het. Als IE besluit het te corrigeren in bijvoorbeeld IE6.1 dan hebben we weer een probleem/uitdaging on our hands...

[Verwijderd]

MAW je kan geen stylesheet maken die geldig is voor beide Browsers ?
Wat een gek*t

Wie heeft er nog een idee
Want als ik de standaard aanhou werkt het in 96% (IE) van de gevallen verkeerd dus.

[drm]

Je kan voorlopig beter IE volgen
En zooi vermijden waarbij dit echt je hele design verneukt in Mozilla

[paragon]

Wacht even ik begrijp het even niet als je IE6 nu in strict laat parsen dan is er toch geen verschil tussen de boxmodel implementatie met MOZ? En voor IE5 en 5.5 kan je dan toch gewoon wel die boxmodel hack toepassen?

[Verwijderd]

DIV is hartstikke mooi maar wat als ik mijn 'boxen' horizontaal naast elkaar wil hebben ?
En dan zonder tabellen.
Wil nl gewoon een class aan mijn <a href> hangen (width pakt ie hier al niet met Moz) en met DIV krijg ik ze dan onder elkaar.
Ik probeer nl 'buttons' te maken zonder *.gifjes
In IE lukt het me en met Moz. 'vliegen' ze alle kanten op

Kan nu heel simpel denken, "vergeet die 4% van de browsers" maar zo zit ik nu eenmaal niet in elkaar
Dus wie heeft een idee ?

[crisp]

Verwijderd schreef op 16 augustus 2002 @ 00:52:
DIV is hartstikke mooi maar wat als ik mijn 'boxen' horizontaal naast elkaar wil hebben ?
En dan zonder tabellen.
Wil nl gewoon een class aan mijn <a href> hangen (width pakt ie hier al niet met Moz) en met DIV krijg ik ze dan onder elkaar.
Ik probeer nl 'buttons' te maken zonder *.gifjes
In IE lukt het me en met Moz. 'vliegen' ze alle kanten op

Kan nu heel simpel denken, "vergeet die 4% van de browsers" maar zo zit ik nu eenmaal niet in elkaar
Dus wie heeft een idee ?

code:

<div style="display:inline">blaatieblaat</div>

[Verwijderd]

Thanks Crisp