Vreemd teken vooraan bij breadcrumb

[Hero of Time]

Het viel mij net op dat er een klein vierkantje voor de breadcrump staat. Ga ik kijken, dan zie ik waar 't vandaan komt: frameword.css, regel 418 volgens m'n Opera Dragonfly. Dit is de code:

code:

.bulletSeparatedList > li:first-child::before { 
content: "​" !important;
margin: 0px !important;
}

Waarom dat er staat, geen idee.

Het teken wordt door het forum vertaald naar een HTML code. Het lijkt iig op [] en is blijkbaar zero width space.

Owja, Opera 12.16 op Debian Sid x64.

[ Voor 24% gewijzigd door Hero of Time op 21-11-2013 17:36 ]

[crisp]

Installeer een unicode versie van het Arial font

[Hero of Time]

Kan niet, heeft een non-free licentie en is daarom niet beschikbaar op Linux. Alternatieven wel, ik zal eens kijken welke ik dan nodig heb, anders dan de Dejavu die ik al heb (en wordt gezegd dat 't een alternatief is).

Maar waarom is het verandert? Waarom niet de » die bij de rest staat? Of • die een regel ervoor wordt gedefinieerd? En al helemaal de lelijke !important gebruik

Het is de eerste keer dat ik ergens kom waarbij de gehele site normaal leesbaar is, op een klein puntje na dat weer vreemde tekens moet geven.

[crisp]

Liberation Sans en DejaVu Sans Condensed zijn de fallback fonts die we hebben gespecificeerd.

Maar waarom is het verandert?

Omdat we het leuk vinden om af en toe zomaar dingen te wijzigen

Waarom niet de » die bij de rest staat? Of • die een regel ervoor wordt gedefinieerd?

Omdat voor de eerste list-item juist weer geen seperator hoort te staan.

En al helemaal de lelijke !important gebruik

Dat heeft ook een goede reden. Ja, het kan anders opgelost worden maar net als met alles kost dat weer extra tijd en soms hebben we dat niet.

De reden dat we hier een ZWSP karakter gebruiken is overigens een workaround voor een specifieke bug in Chrome waarbij dit de meest snelle en praktische oplossing leek. 99% van de systemen beschikken gewoon over unicode fonts.

[Hero of Time]

crisp schreef op vrijdag 22 november 2013 @ 08:52:
Liberation Sans en DejaVu Sans Condensed zijn de fallback fonts die we hebben gespecificeerd.

Liberation Sans heb ik geïnstalleerd staan. De DejaVu Sans Condensed gister nog bij gezet (fonts-dejavu-extra), maar Opera doet blijkbaar niet on-the-fly checken voor nieuwe fonts, zal later eens kijken of het dan weg is. Ik ga 'm nu iig nog even niet herstarten.

[...]

Omdat we het leuk vinden om af en toe zomaar dingen te wijzigen

Nou, lekker dan. Moet dan maar zo denken, wij Tweakers wijzigen nog wel eens wat en ach, als er dan iets stuk gaat, zien we 't wel.

[...]

Dat heeft ook een goede reden. Ja, het kan anders opgelost worden maar net als met alles kost dat weer extra tijd en soms hebben we dat niet.

Dat begrijp ik. Jammer dat het dev team zo is geslonken.

De reden dat we hier een ZWSP karakter gebruiken is overigens een workaround voor een specifieke bug in Chrome waarbij dit de meest snelle en praktische oplossing leek. 99% van de systemen beschikken gewoon over unicode fonts.

Ja, wie gebruikt er dan ook Chrome? Die browser is al zo gaar dat 't bij een vreemd plaatje al paranoïde wordt.


Hmm, doet mij nu eventjes denken. Ik heb al best veel via custom CSS aangepast. Er staat mij niets in de weg om dit ook met CSS te fixen totdat ik herstart. Het is tenslotte via de CSS van jullie dat ik 't zie, kan die van jullie ook zo overrulen.

[Kees]

Hero of Time schreef op vrijdag 22 november 2013 @ 10:48:
Ja, wie gebruikt er dan ook Chrome? Die browser is al zo gaar dat 't bij een vreemd plaatje al paranoïde wordt.

Bijna de helft van onze bezoekers:

[Hero of Time]

Kees schreef op vrijdag 22 november 2013 @ 12:08:
[...]

Bijna de helft van onze bezoekers:
[afbeelding]

Het was dan ook een retorische vraag. Ik weet hoe gewild de browser is onder de tweakers. Daarom begrijp ik de 'hack' ook.

[Hero of Time]

Ik heb 't nu voor mijzelf opgelost. Zag overigens ook tijdens 't aanpassen van m'n eigen CSS voor GoT dat de Tracker 't ook heeft, voor Instellingen. Maar dat was vast bekend.

[crisp]

Ik heb het inmiddels vervangen door een lege string; blijkbaar was het toch niet nodig voor de Chrome bug waar we tegenaan waren gelopen

Online metde volgende iteratie dus