Vreemd. Ik begrijp wat je bedoelt (had dit probleem gezien en gefixt tijdens de sprint), maar zie het hier niet op Firefox 3.0.10 op Windows Vista. Anderen die het zien?
ik probeer het nu eens met een andere firefox (3.0.7) via portable apps op zelfde pc en zie dezelfde 1-pixelrand. het kan dus niet liggen aan een oude stylesheet in de cache van de browser
Ik heb even gekeken met firebug:
ul.primary-links li a.active span.tab-right,
ul.primary-links li.active-trail a span.tab-right,
ul.primary-links li a:hover span.tab-right {
background:#0273BA url(/sites/all/themes/lagelanden/images/tab-top-bg.png) no-repeat scroll 100% -60px;
padding-top: 4px;
}
Als je de padding-top van span.tab-right aanpast van 4px naar 5px was het bij mij in firefox ok. Kan niet zo snel zien of het dan voor andere browsers goed blijft. Denk het wel.
Voor secondary menu iets soortgelijks:
ul.secondary-links li a span.tab-right {
padding: 5px 12px 2px 0;
}
De hoekjes worden bij verschillende browser/platform combinaties verschillend weergegeven. Dus bijv. firefox op XP, Vista, Linux, OSX zouden zich allemaal verschillend kunnen gedragen. Het eenvoudig aanpassen van een padding lost het probleem niet in alle situaties op, helaas.
Ik denkt aan twee mogelijke oorzaken van de verschillen: verschillende defaults van a, li, span, enz. tussen browsers of afrondingsverschillen tussen de redering engines. Ik heb naar het eerste gezocht en vind dat alleen de span (span.tab-inner) geen margin heeft gekregen (0px). De tweede is moeilijker te beoordelen en kan misschien opgelost worden door de hoekjes niet aan [a] en [span] te koppelen maar aan [li] en [a] zodat de [span] van de benodigde padding kan worden voorzien i.p.v. de [a].
-- Erik
Door hansrossel op 11 juni, 2009 - 11:16
Die padding pixels had ik tijdens de laatste sprint al die pixel verhoogd verlaagd, maar dit gaf dan bij Internet Explorer een pixel te veel. Ik heb zelf die menutabs niet oorspronkelijk opgesteld dus ken de code ook niet in detail. Maar ik denk dat Sutha gelijk heeft dat het wellicht meer structureer in de html bouw van het menu zelf moet opgelost worden, die pixel bij padding verschuift enkel het probleem naar een andere browser.
Vreemd. Ik begrijp wat je bedoelt (had dit probleem gezien en gefixt tijdens de sprint), maar zie het hier niet op Firefox 3.0.10 op Windows Vista. Anderen die het zien?
Hans
KOBA
ik probeer het nu eens met een andere firefox (3.0.7) via portable apps op zelfde pc en zie dezelfde 1-pixelrand. het kan dus niet liggen aan een oude stylesheet in de cache van de browser
overigens gebeurt hetzelfde bij het secundaire menu:
http://boris.doesb.org/sites/boris.doesb.org/files/screenshot.23.jpeg
eens zien of er anderen zijn die het zien
boris
===
druppelend sinds 2005
Yep, ik zie de lijn ook op firefox 3.0.10 winxp
Ik heb even gekeken met firebug:
ul.primary-links li a.active span.tab-right,
ul.primary-links li.active-trail a span.tab-right,
ul.primary-links li a:hover span.tab-right {
background:#0273BA url(/sites/all/themes/lagelanden/images/tab-top-bg.png) no-repeat scroll 100% -60px;
padding-top: 4px;
}
Als je de padding-top van span.tab-right aanpast van 4px naar 5px was het bij mij in firefox ok. Kan niet zo snel zien of het dan voor andere browsers goed blijft. Denk het wel.
Voor secondary menu iets soortgelijks:
ul.secondary-links li a span.tab-right {
padding: 5px 12px 2px 0;
}
Hier de 5px veranderen in 6px.
http://blog.merge.nl
De hoekjes worden bij verschillende browser/platform combinaties verschillend weergegeven. Dus bijv. firefox op XP, Vista, Linux, OSX zouden zich allemaal verschillend kunnen gedragen. Het eenvoudig aanpassen van een padding lost het probleem niet in alle situaties op, helaas.
Ik denkt aan twee mogelijke oorzaken van de verschillen: verschillende defaults van a, li, span, enz. tussen browsers of afrondingsverschillen tussen de redering engines. Ik heb naar het eerste gezocht en vind dat alleen de span (span.tab-inner) geen margin heeft gekregen (0px). De tweede is moeilijker te beoordelen en kan misschien opgelost worden door de hoekjes niet aan [a] en [span] te koppelen maar aan [li] en [a] zodat de [span] van de benodigde padding kan worden voorzien i.p.v. de [a].
-- Erik
Die padding pixels had ik tijdens de laatste sprint al die pixel verhoogd verlaagd, maar dit gaf dan bij Internet Explorer een pixel te veel. Ik heb zelf die menutabs niet oorspronkelijk opgesteld dus ken de code ook niet in detail. Maar ik denk dat Sutha gelijk heeft dat het wellicht meer structureer in de html bouw van het menu zelf moet opgelost worden, die pixel bij padding verschuift enkel het probleem naar een andere browser.
De defaults voor css kunnen normaal gezien opgelost worden door een reset css toe te voegen, bijvoorbeeld http://meyerweb.com/eric/tools/css/reset/
Hans
KOBA
helaas moet ik nog een verloren pixel melden:
de witte tab "vertaalgids" op http://drupal.be/node/1827 schiet een beetje door
zie: http://www.flickr.com/photos/batigolix/3632555700/
gespot in ff 3.0.10 op ubuntu
boris
===
druppelend sinds 2005