Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

[HTML/CSS] Renderverschil tussen Webkit en Gecko + Trident

Pagina: 1
Acties:

  • Booster
  • Registratie: februari 2000
  • Laatst online: 24-02 13:12
Ik ben er al een tijd mee bezig, maar ik krijg het volgende renderverschil tussen Webkit (boven) en Gecko en Trident (onder) niet verklaard. Wat doe ik verkeerd?

Het verschil geillustreerd:


De code:
HTML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

[...]

<div id="top">
    <div id="logo">
        <a href=""><strong><span style="color: #005288;">pre</span><span style="color: #00aeef;">view</span></strong> <span style="color: #fcaf17;">website</span></a>
    </div>
    
    <div id="topmenu">
        <ul>
            <li><a href=""><span>over</span> ons</a></li>
            <li><a href=""><span>onze</span> partners</a></li>
            <li><a href="">contact</a></li>
            <li><a href="">helpdesk</a></li>
        </ul>
    </div>
    
    <div style="clear: both;"></div>
</div>

Om de invloed van eventuele omliggende elementen te beperken heb ik bovenstaande stukje ook op zichzelf getest in een los HTML-bestand, en daar treed hetzelfde probleem op.
Cascading Stylesheet:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
#container, #top, #contentcontainer {
    padding: 12px;
}

#logo {
    float: left;
    
    margin: 0;

    font-size: 2em;
    letter-spacing: -2px;
}

#topmenu ul, #mainsubmenu ul {
    margin: 0;
    padding: 0;
    
    list-style-type: none;
}

#topmenu li, #mainsubmenu li {
    display: inline;
}

#topmenu li {
    margin-left: 20px;
}

#topmenu li:first-child {
    margin-left: 0;
}

#topmenu a {
    color: #005288;
}

#topmenu a:hover {
    color: #00aeef;
}

#topmenu a span {
    color: #005288;
}

Het lijkt wel of het element zelf zijn breedte mag bepalen, maar zichzelf toch te klein maakt. Er is immers alle ruimte om de div rechts nog naar links te verbreden. Ze meten wel hetzelfde: in Chrome's Firebug lite is het element 390 pixels breed, en in Firefox DOM-inspector ook.

Het uitzetten van de font-weight: bold; helpt overigens niet (voor de zekerheid ff een poging gedaan).

Vreemd is, dat als ik onderstaande code weghaal, dit in Webkit geen invloed heeft op de plaatsing van "over ons", maar, dan wordt het item "helpdesk" naar voren verplaatst, uitgelijnt met "over ons" een regel erboven. Dit terwijl er in Gecko en Trident dan helemaal geen verschil te zien is, heeft de div zich dan gewoon wat naar links uitgebreid.
Cascading Stylesheet:
1
2
3
#topmenu li:first-child {
    margin-left: 0;
}

Ik wil vooral graag weten waarom dit gebeurt en heb niet echt behoefte aan "een hele andere manier waarmee het er wel hetzelfde uitziet" ;)

The cake is a lie | The Borealis awaits...


  • Willem
  • Registratie: februari 2001
  • Laatst online: 16:56

Willem

#bearacer

#topmenu een vaste breedte geven?

Inherit #topmenu niet de padding van #container?
Dus of vaste breedte @topmenu of daar een padding (right) van 0 definieren?

The client may be king, but he's not the art director


  • Booster
  • Registratie: februari 2000
  • Laatst online: 24-02 13:12
#topmenu inherit geen onderdelen van #container, maar ze hebben wel met opzet allemaal dezelfde padding :) Er is geen sprake van dubbele padding dus, bv.

Een individuele padding-right: 0; op #topmenu doet niets. In principe staat de padding daarvoor ook al op 0.

Een vaste breedte voor #topmenu zorgt er uiteindelijk wel voor dat alles op een regel staat. Dat is bij 390 (huidige breedte) + 20 pixels voor een totaal van 410px. (Bij 409 wrapped die laatste LI dus nog)

Toevallig precies de 20 pixels die ik voor margin-left heb ingegeven op het LI-element in de UL van dat menu, en die ik er bij de first-child weer vanaf haal. Zou dit een ordinaire renderbug zijn door een combinatie van float: right, en margin/padding op first-child? :?

Booster wijzigde deze reactie 30-03-2011 12:01 (3%)

The cake is a lie | The Borealis awaits...


  • RobIII
  • Registratie: december 2001
  • Laatst online: 19:21

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

Even op 't oog en zonder pixels gerekend te hebben of je code nader beschouwd: is het niet gewoon een verschil in font-rendering waardoor engine A breedte X rendert en engine B breedte Y? Als je afhankelijk bent van de breedte van de tekst zou ik sowieso niet de container op 1 pixel precies maken maar wat speling toelaten.

RobIII wijzigde deze reactie 30-03-2011 12:02 (26%)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Booster
  • Registratie: februari 2000
  • Laatst online: 24-02 13:12
Aja, vergeten dat te vermelden:

Ik heb alle elementen nagemeten met DOM-inspector en Firebug voor Chrome. De breedte van #topmenu (936px), #logo in binnenliggende A (217px), #topmenu (390px) en binnenliggende LI's/A's (69, 113, 60 en 73 px) zijn binnen beide browsers hetzelfde.

Dat is denk ik de enige manier om te meten of het een verschil in font-rendering zou zijn. Maar: zolang #topmenu geen vaste breedte heeft, zou een verschil in font-rendering denk ik een ander effect moeten hebben dan nu: bij een breder woord zou de div dan gewoon wat uit kunnen breiden naar links, daar is nog genoeg ruimte :)

Ik heb de div expres geen vaste of krappe breedte gegeven, omdat je dan bij het veranderen meteen aan de CSS moet gaan sleutelen.

Booster wijzigde deze reactie 30-03-2011 12:12 (9%)

The cake is a lie | The Borealis awaits...


  • MueR
  • Registratie: januari 2004
  • Laatst online: 19:25

MueR

Moderator Devschuur®

is niet lief

Welke browsers hebben we het eigenlijk over? Trident is bijvoorbeeld tussen IE8 en IE9 nogal verschillend. Zo ook met de andere engines. Laat maar, browser versie staat er bij. Hardware font rendering comes to mind.

Voor de enigsinds ranzige fix zou je met overflow kunnen werken. Dan ga je rechts een paar pixels witruimte verliezen, maar soit.

MueR wijzigde deze reactie 30-03-2011 12:15 (7%)

Anyone who gets in between me and my morning coffee should be insecure.


  • Booster
  • Registratie: februari 2000
  • Laatst online: 24-02 13:12
IE8 voor Trident (had ik vermeld in het plaatje)

Maar zoals gezegd: ik wil met name weten of het een bug is, of dat ik echt zelf iets fout doe. Een prima fix verzinnen lukt me denk ik wel.

The cake is a lie | The Borealis awaits...


  • Booster
  • Registratie: februari 2000
  • Laatst online: 24-02 13:12
Ik heb hem even bij de Webkit Bugzilla naar binnen geschoten, hoop hij daar op de goede plek staat.

A combination of float/margin/first-child causes strange behaviour

The cake is a lie | The Borealis awaits...

Pagina: 1


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True