[css] Border om image link incorrect in FF2

[Roa]

Ik ben bezig met een site en alles zag er goed uit in IE7 en FF3, ik tevree (eigenlijk moet ik nog IE8 testen, maar ik moet nog even uitzoeken hoe ik IE8 naast IE7 kan draaien) tot ik op een lannetje het werk toonde aan m'n vrienden (het is een vriendensite) en één van hen FF2 gebruikte. Daar kwam een bug naar voren met betrekking tot het gebruik van een border voor een link waarin een image staat.

Wat ik dus wil is dat de border gedefineerd wordt in de link, zodat ik ook met hover kan spelen, maar mooi om de image staat. Ik heb al van alles geprobeerd met floats en display, maar het wil niet lukken! Ik snap dat een a element inline is, maar als je er een block van maakt staat de border niet mooi om de image. Een inline-block werkt dus voor IE7 en FF3, maar niet voor FF2.

Om het één en ander nog wat makkelijker te maken staat er ook nog eens een span omheen, omdat de image links, rechts of center gepositioneerd kan worden, waarbij de tekst bij links en rechts, rechts en links naast de image komt en bij center de tekst verder moet gaan onder de image.

code:

.img_standard_resized {
    padding: 0px;
    margin: 0px;
    border: none; 
    display: block;
}

#content #newspage .imgspan_center {
    display: block;
    text-align: center; 
    margin: 10px;
    margin-top: 30px;
    border: none;
}

.img_link {
    border: 2px solid #FFFFFF;
    padding: 0px;
    margin: 0px;
    display: inline-block;
}

.img_link:hover {
    border: 2px dashed #FFFFFF;
    padding: 0px;
    margin: 0px;
    display: inline-block;
}

en plaatjes ter illustratie:
Even de borders (hier staat ook een border om de image, maar dat moet dus niet) in andere kleuren in FF3, ter illustratie van hoe de opbouw is:


Hier zoals het eruit moet zien:


Hier zoals het er in FF2 uitziet:


Op het onderste plaatje zie je ook 'test33333' staan. Dit is een reactie, ik heb het idee dat de reacties hier niet goed in beeld komen omdat het a element klein is terwijl die de grootte van het plaatje zou moeten zijn en daardoor de floats van de reacties verknoeid. Ik denk dus dat het a element de sleutel is, ook voor die foute opmaak.

Google en zoeken hier levert helaas weinig op. Dat gaat vaak over achtergrond images.
Het is een stom probleem en je kan zeggen dat FF2 toch niet meer gebruikt moet worden, maarja, ik wil het gewoon goed hebben nu! Wie o wie heeft wat inzicht?

[Bosmonster]

FF2 ondersteunt geen inline-block

Je kunt eventueel experimenteren met:

-moz-inline-box
-moz-inline-block

maar beiden werken niet helemaal joepie

[ Voor 64% gewijzigd door Bosmonster op 01-06-2009 15:55 ]

[Zoefff]

Geef ook eens een HTML voorbeeld of snippet? Volgens mij denk je veel te moeilijk (inline-block niet gebruiken; ondersteuning is wazig en incompleet in browsers), en kan je in dit geval gewoon een extra element toevoegen om je problemen op te lossen.

HTML:

<p>Rapapa</p>
<p class="with-image">
    <img src="#" alt="Meisje" />
</p>
<p>Rapapa</p>

Cascading Stylesheet:

p.with-image {
    text-align: center;
}

p.with-image img {
    border: 2px solid white;
}

p.with-image:hover img {
    border-color: red;
}

Of zie ik nu dingen over het hoofd?

[Roa]

Inline block is inderdaad niet nodig. Maar op de één of andere manier werkt het nog niet! De border klopt gewoon niet... Als ik nu de link waarin het plaatje staat een border geef, maakt hij een rechthoek aan de onderkant van het plaatje van zo'n 18px hoog, ipv om het plaatje heen. Tevens wordt de achtergrond kleur veranderd bij een hover. Daarom heb ik zelf het idee dat de algemene css voor links ook op deze link werkt, maar zelfs als ik de background voor img_link op none zet, komt hij met een achtergrond kleur. Snap het even niet meer.

Ook heb ik inderdaad nu de <p> afgesloten voor het plaatje en weer geopend na het plaatje. Voorheen stond het plaatje gewoon in de <p>.

De reacties gooit hij trouwens nu veel te laag, ik snap er geen kont meer van. Maar ik denk dat dat met floats te maken heeft. Even alles nalopen op dat vlak en dan komt dat wel goed denk ik

Anyhoe, ik snap alleen niets van die links!

Cascading Stylesheet:

#content #newspage .imgspan_center {
    display: block;
    text-align: center; 
    margin: 10px;
    margin-top: 30px;
    border: none;
}

#content #newspage .img_link {
    border: none;
    background-color: none;
    padding: 0px;
    margin: 0px;
    text-decoration: none;
}

#content #newspage .img_link img {
    border: 2px solid #FFFFFF; 
    padding: 0px;
    margin: 0px;
}

#content #newspage .img_link:hover img {
    border: 2px solid #FF0000;
    padding: 0px;
    margin: 0px;
}

En de css voor de algemene links:

Cascading Stylesheet:

#content a {
    color: #666666;
    font-size: 0.8em;
    text-decoration: none;
    padding: 0px;
    margin-left: 5px;
}

#content a:hover {
    color: #dbdad6;
    background-color: #666666;
}

HTML:

<div id="newspage">
<h1>Test</h1>
<h3>Woensdag 29 april 15.34 door: Ralf</h3>
<p>lap tekst</p>
<p class="imgspan_center">
<a href="/bb/images/test.jpg" target="_new" class="img_link">
<img src="/bb/images/test.jpg" class="img_standard">
</a>
</p>
<p>
Lap Tekst
</p>
</div>

Ik zit te overwegen al m'n css weg te gooien en opnieuw te beginnen, want ik zie door de bomen m'n eigen code niet meer

[Roa]

Zo! Problemen allemaal opgelost door de algemene link-css specifieker te zetten (#content p a, ipv #content a), de image in een span te zetten en de css van het image via '#content .img_link img' te doen, waardoor je dus ook een :hover toe kunt voegen Dit werkt allemaal vlekkeloos. Tevens de span waarin de image staat een float en width meegegeven zodat m'n reacties weer gewoon staan waar ze moeten staan.

Wilde nog even de oplossingen toevoegen voor het archief Overigens dus gewoon een beetje herschikken van css was genoeg. Zoals ik al zei: ik snapte m'n eigen code niet meer

[Bosmonster]

Als ik je nog een tipje mag geven trouwens (zie dit helaas veel te vaak):

Specificeer je element-typen in je CSS. ipv #content dus div#content. Dit maakt je CSS zoveel leesbaarder en overzichtelijker, zeker als je CSS-bestanden hebt van honderden of duizenden regels.

Zeker als je losse code ziet, bijvoorbeeld als je het hier post (ik kan al niet zoveel met je CSS in de openingspost, want ik heb geen flauw idee op wat voor elementen de CSS slaat bijvoorbeeld), maar belangrijker, als een collega er mee aan de slag moet. Daarnaast kan het een hoop gezeur met naamgevings-conflicten schelen in grote/complexe websites.

Als laatste kan ik me ook nog voorstellen dat het performance-wise uit kan maken bij grotere websites.

edit: je ziet Zoeff het ook al doen in zijn voorbeeld. Het is gewoon een stukje good practice zeg maar.

edit2: daarnaast is het trouwens target="_blank" ipv target="_new".

[ Voor 38% gewijzigd door Bosmonster op 12-06-2009 01:06 ]

[Verwijderd]

Roa schreef op maandag 01 juni 2009 @ 14:30:
Ik ben bezig met een site en alles zag er goed uit in IE7 en FF3, ik tevree (eigenlijk moet ik nog IE8 testen, maar ik moet nog even uitzoeken hoe ik IE8 naast IE7 kan draaien)

De meest kritische browser blijft in mijn ogen IE6, Aan je code te zien zal hij in IE6 zeker fout weergegeven worden. Ik raad je 'IEtester' aan. Mijn ervaringen hiermee zijn goed, al is het geen perfecte garantie voor een goed resultaat.

IETester komt voor in de Meuk : http://tweakers.net/meuktracker/19976/ietester-032.html

[Roa]

Dat IE tester is inderdaad leuk
Heb iig op m'n server wel IE6 draaien, en ik begrijp dat IE8 een IE7 modus heeft. Werkt die exact hetzelfde als IE7? In dat geval kan ik IE8 eens gaan proberen

Overigens, waarom zou IE6.0 niet werken bij mij? Ik heb trouwens wel een ie6 stylesheet voor een enkele padding/margin die niet wil en voor mijn header gebruik ik een javascriptje, omdat ik daar gebruik maak van een transparante png. Het javascriptje laad een 8 bit png ipv 24 bit, waardoor transparantie in ie6 ook werkt.

Ojah, Bosmonster: ik heb nu alles aangepast in de css. Is inderdaad wel iets duidelijker!

[ Voor 8% gewijzigd door Roa op 12-06-2009 17:39 ]

[dotnetpower]

Als alternatief voor IETester (werkt namelijk niet 100%) kun je ook gebruik maken van de VPC images die door Microsoft zelf beschikbaar worden gesteld, hiermee kun je in Virtual PC of in VirtualBox gratis de volgende combo's testen:
- Windows XP SP3 met IE6
- Windows XP SP3 met IE7
- Windows XP SP3 met IE8
- Windows Vista met IE7
- Windows Vista met IE8

Helaas,werken deze images maar 120 dagen ofzo (deze tot 31 augustus) en dan moet je ze weer opnieuw downloaden (worden dan nieuwe beschikbaar gesteld), maargoed dan kun je het i.i.g. goed testen, zie http://www.microsoft.com/...d0a413c8ef&displaylang=en

VirtualBox
Wat ik zelf b.v. gedaan heb is een laptop ingericht met Ubuntu 9.06 en heb vervolgens de images omgezet voor gebruik in VirtualBox, deze images start ik dan in een zogenaamde headless mode waarmee ik dus vanaf me Mac via CoRD kan connecten (soort remote desktop) en dan kan ik al die verschillende browsers perfect testen

Hier een link naar guide om de images op VirtualBox op Ubuntu te krijgen:
http://zytzagoo.net/blog/...pid-810-using-virtualbox/

Headless mode
Als je hem in headless mode wilt draaien moet je eerst in een terminal invullen:
VBoxManage list vms

Dan krijg je een overzicht met je beschikbare Virtual Machines, b.v.
"IE6-XPSP3" {een of andere uuid}

En die kan je dan in headless mode starten met het commando:
VBoxHeadless --startvm IE6-XPSP3

Dan krijg je als goed is ook de poort te zien waarop je kan connecten met je remote desktop of iets dergelijks.

Het is wat meer werk / gepiel, maar het testen van je websites is een stuk betrouwbaarder

Daarom heb ik zelf het idee dat de algemene css voor links ook op deze link werkt, maar zelfs als ik de background voor img_link op none zet, komt hij met een achtergrond kleur. Snap het even niet meer.

Als je wilt weten wat je element allemaal beïnvloed zou ik gebruik maken van FireBug voor FireFox.
https://addons.mozilla.org/nl/firefox/addon/1843

Hierop kun je perfect zien welke styling je elementen beïnvloeden.

Tevens heb je alternatieven hiervoor voor Internet Explorer b.v.
http://www.microsoft.com/...2d-4511-bb3e-2d5e1db91038

Scheelt je i.i.g. vaak een hoop frustratie

[tonyisgaaf]

Ook al gaat dit verschrikkelijk offtopic:
MS Expression Web SuperPreview for Internet Explorer (heerlijk die verbose MS namen).
Werkt ook mooi, helaas alleen met IE6 en IE7 of IE8 (afhankelijk van lokaal geïnstalleerde browser).
Er komt een versie aan die met een willekeurige (ook van andere fabrikanten) reeks browsers werkt.

Ik zit overigens de postings van de TS al meerdere keren te lezen, inclusief de aangeboden oplossingen, maar heb toch het idee dat het allemaal nog behoorlijk ingewikkeld wordt opgelost.

Het volgende (voorbeeld online) werkt volgens mij ook crossbrowser:

edit:
My bad, het werkt niet in IE6. Zou je kunnen oplossen met een generiek :hover/.hover JavaScript (want die had je toch al nodig voor je Suckerfish menu's toch? Toch!?)

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>untitled</title>

    <style type="text/css" media="screen">
        a img {
            border: blue 5px solid;
        }

        a:hover img {
            border-color: red;
        }

        img.centered {
            display: block;
            margin: 5px auto;
        }
        
        img.left {
            float: left;
            margin: 5px 5px 5px 0;
        }
        
        img.right {
            float: right;
            margin: 5px 0 5px 5px;
        }
    </style>
</head>
<body>
    <p>
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor...
        <a href="#"><img class="centered" src="images/dummy.png" width="281" height="366" alt="Dummy"></a>
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor...
        <a href="#"><img class="left" src="images/dummy.png" width="281" height="366" alt="Dummy"></a>
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor...
        <a href="#"><img class="right" src="images/dummy.png" width="281" height="366" alt="Dummy"></a>
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor...
    </p>
</body>
</html>

[ Voor 3% gewijzigd door tonyisgaaf op 14-06-2009 16:12 ]

[Zoefff]

Bosmonster schreef op vrijdag 12 juni 2009 @ 01:01:
Als ik je nog een tipje mag geven trouwens (zie dit helaas veel te vaak):

Specificeer je element-typen in je CSS. ipv #content dus div#content. Dit maakt je CSS zoveel leesbaarder en overzichtelijker, zeker als je CSS-bestanden hebt van honderden of duizenden regels.

Zeker als je losse code ziet, bijvoorbeeld als je het hier post (ik kan al niet zoveel met je CSS in de openingspost, want ik heb geen flauw idee op wat voor elementen de CSS slaat bijvoorbeeld), maar belangrijker, als een collega er mee aan de slag moet. Daarnaast kan het een hoop gezeur met naamgevings-conflicten schelen in grote/complexe websites.

Als laatste kan ik me ook nog voorstellen dat het performance-wise uit kan maken bij grotere websites.

edit: je ziet Zoeff het ook al doen in zijn voorbeeld. Het is gewoon een stukje good practice zeg maar.

edit2: daarnaast is het trouwens target="_blank" ipv target="_new".

Je stipt daarmee overigens wel een interessant punt aan. Zoals je zegt doe ik het zelf inderdaad ook altijd als good practice, maar stiekem kost het de browser wel meer tijd om te renderen. Het dubbel specificeren (element én id) resulteert in een dubbele lookup door de browser, deze zal zowel het element als het id gaan controleren.

De performancewinst is volgens mij echter zo marginaal dat ik m'n werkwijze tot nu toe nog niet aangepast heb. Het achteraf geautomatiseerd strippen van dubbele selectors is wellicht wel interessant

[Bosmonster]

Zoefff schreef op zondag 14 juni 2009 @ 16:33:
[...]

Je stipt daarmee overigens wel een interessant punt aan. Zoals je zegt doe ik het zelf inderdaad ook altijd als good practice, maar stiekem kost het de browser wel meer tijd om te renderen. Het dubbel specificeren (element én id) resulteert in een dubbele lookup door de browser, deze zal zowel het element als het id gaan controleren.

De performancewinst is volgens mij echter zo marginaal dat ik m'n werkwijze tot nu toe nog niet aangepast heb. Het achteraf geautomatiseerd strippen van dubbele selectors is wellicht wel interessant

Ik doelde juist op een omgekeerde snelheidswinst. Met de extra selectors is het (lijkt me) sneller. Als je bij een complexe pagina div.content doet, ipv .content scheelt het de selector engine een heleboel werk. Ipv alle elementen aflopen en kijken of ze die class hebben hoeft ie alleen div elementen af te lopen voor die class.

Ik weet echter niet of dit intern ook echt uitmaakt, kan me voorstellen dat zowel de element-selector als class-selectors dermate goed geoptimaliseerd zijn dat je dit verschil niet gaat merken. Bij javascript-libraries maakt het overigens wel uit, omdat die voor oudere browsers veelal gebruik maken van getElementsByTagName.

Belangrijkste punt was voor mij de leesbaarheid en overzichtelijkheid. Voor jezelf om het later terug te lezen, maar ook voor collega's om je CSS eenvoudiger te snappen zonder continu de html ernaast te moeten houden om te kijken waar de classes op slaan.

[ Voor 8% gewijzigd door Bosmonster op 14-06-2009 16:48 ]

[Zoefff]

Mozilla geeft aan dat het tegenovergestelde waar is; als je dingen dubbel definieert levert dat een onnodige overhead op:

quote: https://developer.mozilla.org/en/Writing_Efficient_CSS

If you have a style rule that has an ID selector as its key selector, don't bother also adding the tag name to the rule. IDs are unique, so you're slowing down the matching for no real reason. (An exception to this would be when you wish to change the class of an element dynamically in order to apply different styles to the element under different situations, but where you also wish to share the same class with other elements.)

Oorzaak hiervan is dat de (en dat wist ik tot kort geleden ook niet) CSS parsers van rechts naar links lezen. Een parser zal dus eerst je class of id tegenkomen, en daarna pas de tagname.

Maar zoals ik al opmerk, ik vraag me af hoe groot (of klein) de daadwerkelijke snelheidwinst is. Met projecten van duizenden regels CSS is het echter wel steeds interessanter om hier naar te gaan kijken

[ Voor 10% gewijzigd door Zoefff op 14-06-2009 21:22 ]

[Bosmonster]

Zoefff schreef op zondag 14 juni 2009 @ 21:19:

Maar zoals ik al opmerk, ik vraag me af hoe groot (of klein) de daadwerkelijke snelheidwinst is. Met projecten van duizenden regels CSS is het echter wel steeds interessanter om hier naar te gaan kijken

Mjah, bij projecten met duizenden regels CSS wordt het ook steeds interessanter de tags wel toe te voegen voor de leesbaarheid, overzichtelijkheid en ter voorkoming van naamgevingsconflicten

[ Voor 4% gewijzigd door Bosmonster op 14-06-2009 21:54 ]

[dB90]

Naamgevingsconflicten mja misschien, maar bij projecten met duizenden regels CSS moet je imho gewoon voor performance kiezen (ook al is dat misschien minimaal) en niet voor 'overzichtelijkheid' e.d. Gewoon je CSS van duidelijk commentaar voorzien en anders pakken je collega's maar ff wél de HTML erbij

[Bosmonster]

dB90 schreef op zondag 14 juni 2009 @ 22:16:
Naamgevingsconflicten mja misschien, maar bij projecten met duizenden regels CSS moet je imho gewoon voor performance kiezen (ook al is dat misschien minimaal) en niet voor 'overzichtelijkheid' e.d. Gewoon je CSS van duidelijk commentaar voorzien en anders pakken je collega's maar ff wél de HTML erbij

Zolang er niks is 'bewezen' over performance (en heb het ook nog nooit gemerkt) blijf ik toch graag kiezen voor de andere 3 WEL merkbare voordelen

Denk dat een bak comments in je CSS overigens voor meer performance-verlies zorgt

[ Voor 15% gewijzigd door Bosmonster op 15-06-2009 08:12 ]