Som Plus-medlem får du: Tillgång till våra Plus-artiklar | Egen blogg och Portfolio | Fri uppladdning av dina bilder | Rabatt på kameraförsäkring och fotoresor | 20% rabatt på Leofoto-stativ och tillbehör | Köp till Sveriges mest lästa fototidning Fotosidan Magasin till extra bra pris.

Plusmedlemskap kostar 349 kr per år

Annons

Vådan av verdana

Produkter
(logga in för att koppla)

raderad12

Aktiv medlem
Kika på bifogade lilla skärmdump, den säger egentligen allt. Tror inte att fotosidan hade tänkt det så här. Anledningen beror i grunden på två saker, dels att sajtens skapare har typsnittet Verdana installerat och dels på "tryckfelsnisse". Verdana är ett typsnitt som renderas lite större än alla andra och därmed lockar till att minska teckenstorleken. Blir lätt lite som att gå över ån efter vatten, typ. vill man att det skall se ut som 12px Arial, sätt då det och inte 10px Verdana. Jag har alltså inte Verdana och får därmed ett oläsligt litet serif typsnitt, jag skulle kunna installera Verdana men då begår jag upphovsrättsbrott enligt Microsofts nya licensavtal.

Sajtsnickaren har dock försökt göra det rätta, att ange ett generiskt alternativ efter det att denne kör över enskilda besökares egna inställningar (hos de som har Verdana installerat men kanske själva önskar något annat som std. för typsnitt utan "fötter"), men tyvärr misslyckas han (hon?) att ange något generiskt alternativ eftersom den generiska typsnittsfamiljen för typsnitt utan "fötter" heter "sans-serif" och inte "sans serif" som det nu är skrivet i fotosidans CSS. Dessutom är teckenstorleken satt i pixlar, vilket gör att texten ser mindre ut ju större skärm och upplösning man har, 11 pixlar är ju en betydligt mindre del av en skärm på 1800 pixlars bredd än på en med endast 800.

Mitt råd/förslag är alltså att ändra alla förekomster av "verdana, sans serif" till "verdana, sans-serif" (en enkel search and replace), eller ännu hellre enbart "sans-serif" för högre plattformsoberoende som webben är tänkt att fungera och att sätta teckenstorlekar i enheten "em" istället för "px", skulle tro att 0.8em skulle passa fotosidan rätt bra. 1em är detsamma som besökarens std. inställning, på windows blir 1em lika med 12 pixlar om inte besökaren själv har ställt in annorlunda för att denne önskar det. En besökare med windows som har Verdana installerat kommer inte att märka någon skillnad, medans många besökare på *nix maskiner får en bättre (närmast likadan) upplevelse av fotosidan. Vad man ser nu är ett utslag av klassisk "customer lock in" som folk ofta omedvetet hjälper till med helt i onödan.
 

Bilagor

  • fotosidan.jpg
    fotosidan.jpg
    46.6 KB · Visningar: 325
Jag som tycker att seriffer är trevliga att ha att göra med. sen vet jag inte hur trevligt det är att att jobba med 1800 pixlar på bredden.

/men css:n borde inte vara så svår att ändra.

titta förresten på MankSans, en helt underbar sans-serif, förrutom det gemena l:et som förstör hela upplevelsen.
Länk här.
 
pablito skrev:
men css:n borde inte vara så svår att ändra.

Busenkelt tom. Jag gjorde ett litet test med min bookmarklet och satte "sans-serif" för alla td element (fotosidan är ju designen hårdkodad i tabeller), viss skillnad, eller hur.

Min bookmarklet hittas här Bookmarklet, för er som kan använda sådana, högerklicka bara på länken och spara som bokmärke, använd sedan bokmärket så hoppar det upp ett litet fönster där man kan skriva in egna regler för att förändra sajten man besöker.
 

Bilagor

  • fotosidan2.jpg
    fotosidan2.jpg
    46.8 KB · Visningar: 314
MS TrueType core fonts, där Verdana ingår, får distribueras fritt om man inte ändrar på installationsfilen. MS har för 1-2 år sedan avlägsnat filerna för nedladdning från sin webbsajt, men de finns kvar på nätet, helt enligt licensen (det är alltså OK att "redistribute the fonts in unaltered form" - MS trodde nog att det faktum att fonterna låg gömda i en exe-fil skulle förhindra användare av andra OS att komma åt fonterna).

Titta här för Sourceforge-sidan: http://sourceforge.net/project/showfiles.php?group_id=34153&release_id=105355, och här för installation på ett Linux-system: http://corefonts.sourceforge.net/. Andra Unix-varianter kan jag dock inte redogöra för.
 
Asch, det där felet med det felaktiga fontfamiljnamnet ändrade jag i gamla CSS:en för ett bra tag sedan, men kom inte med i den som vi byggde nya designen med.

Men men, nu är det fixat.
 
Då får du en cachad version någonstans ifrån, den i filsystemet är fixad.

CSS:en för utskriftsversionen (style-print.css) var dock inte fixad.
 
clindh skrev:
Då får du en cachad version någonstans ifrån, den i filsystemet är fixad.

CSS:en för utskriftsversionen (style-print.css) var dock inte fixad.

Ja så kan det ha varit, Apache kan dröja lite med uppdateringar innan cachen uppdateras, i synnerhet om CMSet inte ligger på samma maskin, antagligen nåt cron-jobb som behövde väntas in. Nu får jag en mer läsbar sans-serif istället för serif, dock ganska liten, men jag tvingas inte till några större "krumbukter" för att läsa, bara zooma till 120% eftersom jag inte har Verdana.
 
Din teori/spekulation om Apache osv. stämmer nog inte.

Det är browsern (eller någon proxy) på vägen som cache:ar om något är cache:at.

Fotosidan's style sheet går inte via något CMS system, den ligger som en sten dum vanlig plain fil på filsystemet...



-Thomas
 
talthoff skrev:
Din teori/spekulation om Apache osv. stämmer nog inte.

Det är browsern (eller någon proxy) på vägen som cache:ar om något är cache:at.

Fotosidan's style sheet går inte via något CMS system, den ligger som en sten dum vanlig plain fil på filsystemet...

Näe, min Mozilla var det inte, det var det första jag kollade. Det kan ha varit någon cache efter vägen, men jag misstänker, eftersom det finns en del Ms-specifikt hos fotosidan att att fotosidan inte ligger direkt på Linux-servern med Apache som serverar fotosidan ut på webben och då cachar denna servern för effektivitetens skull. Ofta ser ju upplägget ut så, *nix ut mot Internet för säkerhetens och effektivitetens skull och wintendo mot kund eftersom de ofta inte kan något annat.

Nåja, sidan funkar betydligt bättre nu, trots en del knasigheter som webbläsarnas felhantering få jobba med t ex. de 146 html felen på förstasidan.

Nu ska jag sluta retas ;-)
 
Mozilla är inte felfri när det gäller cachen. Jag har precis lagt ner en hel del tid på felsökning av ett fel med en redirect som funkar finfint i Konqueror, Netscape, Opera och IE men i Mozilla vägrar ladda den nya sidan utan istället visar den cachade versionen...
 
jimh skrev:
Mozilla är inte felfri när det gäller cachen.
Näe, jag vet, tror inte någon webbläsare är helt felfri på den punkten, därför har jag ett script som tömmer cachen (raderar filerna) lagt som en launcher i panelen. "Kort-minnes" cachen kräver dock en omstart av webbläsaren för att vara säker.
 
Det finns inte en millimeter kodrad från MS mellan dig och våra servers eller någon "smart burk" mellan dig och oss. (Om nu din ISP eller dyl hittat på något får du ta med dom). Några "cron jobb" körs inte. Att Apache inte skulle skicka ut en korrekta/gällande filen tror jag inte ett skvatt på. Den kan möjliga filen under den "bråkdelen" av en sekund som det tar att skriva ner filen. Att placeringen av CMS systemet spelar roll är väl med troligen inget beskylla Apache för. Som sagt jag skrev inte att du hade fel eller rätt, jag skrev att jag inte tror den stämmer.

Du fick CSS:en direkt av Apache, content delen kom direkt från PHP koden som kör på samma Apache server. Christer hade inte kunnat konstaterat om det fungerade eller inte om han inte också körde "samma väg" som du. Möjligen då att ni är olika browsers ...men det var ju det jag skrev.


Dom 146 felen och den delen av ditt inlägg får någon annan kommentera. Eller sök i detta forum så får du svaret...


-Thomas

(redigerat av mig själv efter postning)
 
talthoff skrev:
Det finns inte en millimeter kodrad från MS mellan dig och våra servers eller någon "smart burk" mellan dig och oss. (Om nu din ISP eller dyl hittat på något får du ta med dom). Några "cron jobb" körs inte. Att Apache inte skulle skicka ut en korrekta/gällande filen tror jag inte ett skvatt på. Den kan möjliga filen under den "bråkdelen" av en sekund som det tar att skriva ner filen. Att placeringen av CMS systemet spelar roll är väl med troligen inget beskylla Apache för. Som sagt jag skrev inte att du hade fel eller rätt, jag skrev att jag inte tror den stämmer.

Du fick CSS:en direkt av Apache, content delen kom direkt från PHP koden som kör på samma Apache server. Christer hade inte kunnat konstaterat om det fungerade eller inte om han inte också körde "samma väg" som du. Möjligen då att ni är olika browsers ...men det var ju det jag skrev.


Dom 146 felen och den delen av ditt inlägg får någon annan kommentera. Eller sök i detta forum så får du svaret...


-Thomas

(redigerat av mig själv efter postning)

Börjar kännas lite "infekterat", det var inte min mening, jag ber om förlåtelse om jag uttryckt mig alltför provokativt/retsamt.

Vad jag menade med det Ms-specifika var delar av felen o "knasigheterna", av detta drog jag (kanske felaktigt) slutsatsen att CMS-systemet låg på annan maskin än Linux-servern, och har man det upplägget då cachar Apache, och beroende på konfigureringen så kan det ibland gå en stund, allt mellan sekunder till timmar beroende på conf. och upplägg, mellan uppdatering och att sidor som servas utåt blir detsamma. Det är ingen beskyllan, det är ju bara en "feature" i systemet som ibland är till fördel å ibland till nackdel beroende på ens upplägg och serverns konfigurering (för den som läser detta och inte "kan" Linux så kan ett "cron-jobb" på sätt o vis jämföras med schemaläggaren i windows, men det kan lösas på många andra sätt också, det är upp till root på servern vilka prioriteringar han gör).

Nåja, jag vill absolut inte bråka om detta, jag lägger ned här. Testade Christer vanliga vägen över Internet så var det ju ingen caching på er sida som orsakade förseningen, å det var ju inte heller poängen med denna tråd, "sans serif" felet är ju fixat. Tack.
 
Att vi har en massa HTML-fel på förstasidan får man gärna påpeka för oss - men påståenden om att vi skulle använda Microsoft-produkter på servern är ju betydligt känsligare... :)

Så bra att det ser bättre ut nu! En CSS som använder "em" kan vi experimentera med, det var iofs några år sedan jag testade senast men då var det så pass stora skillnader i hur browsers (fel)tolkade em-begreppet att man behövde separata stylesheets för olika browsers. Nu har vi bara ett fåtal saker i en CSS som inte laddas av NS4, och ett hack för att komma runt feltolkningen av boxstorlekar (padding/margin) i bla IE5.
 
ANNONS
Upp till 6000:- Cashback på Sony-prylar