|
|
|
 |
|
|
Browser-beteende
Det största felet med IE är att den tolererar för mycket fel. Det FINNS en standard att följa men IE struntar i det och tillåter väldigt mycket avsteg från den standarden varpå alla andra får försöker emulera WinIEs dåliga och godtyckliga beteende bara för att folks kasst skrivna hemsidor ska funka även i andra webbläsare. WinIE lockar alltså utvecklare till att skriva kass och felaktig kod.
W3C har någonstans skrivit följande om webläsare:
Browser-beteende är ett sådant problematiskt område. Till viss det måste W3C ta på sig ett ansvar här (och de som arbetade med att standardisera HTML innan W3C existerade). Ett designbeslut som togs tidigt var att inte lägga för strikta krav på innehållsförfattare (som på den tiden alltid kodade direkt i HTML) och därmed göra det enkelt att konstruera sina sidor. Därmed gjordes HTML-standarden initialt ganska löslig -- författarna behövde inte skriva ut alla taggar och fullt ut definiera vad de ville. Browsers skulle vara klyftiga nog att kunna ta den lösligt definierade sidan och göra den entydig och sedan presentera den. T.ex. behövdes inte vissa slut-taggar, eftersom man ju av kontextet skulle kunna se var ett element slutade och nästa började. Detta resulterade i att browser-leverantörer uppfann sätt att ta lösliga och ofullständiga sidor och visa upp dem. Och då blev de t.o.m. så "Förlåtande" att de tillät fullt ut illegalt strukturerade sidor att visas i browsers. Olika browserleverantörer gjorde dock olika val av hur de hanterade inkorrekta sidor. Och detta förde med sig att även korrekt konstruerade sidor kunde uppvisa olika beteenden i olika browsers. Dessutom upfann varje browserleverantör med självaktning ett antal egna taggar som de understödde.
Detta ledde mot en kaotisk situation. Senare tiders HTML-standarder har försökt reparera situationen genom att vara mer strikta, och att mer explicit tala om vad vissa "defaultningar" skall innebära. Detta kulminerade i XHTML, där striktheten hos X(HT)ML garanterar att dokument skall ha en unik struktur. Sedan skall CSS (eller XSL) transformera på ett väldefinierat sätt till rendrerad form.
Tanken var god. men historien slog tillbaka. Det fanns redan så stora investeringar gjorda i lösliga HTMLsidor att det affärsmässigt var omöjligt att *inte* rendrera dessa. Så nyare browsers försöker vara en mädchen-fur-alles -- att kunna rendrera nya strikta (X)HTMLdokument på det välspecificerade sättet och gamla HTMLdokument på sätt som behöll deras look-and-feel. Bakåtkompatibilitetet blev omöjlig. Det hade varit bättre (i det långa loppet) att ha gjort en "clean break" med det gamla. Men så gjordes icke.
Så vad vi nu råkar ut för är s.k. "feature interaction" -- browsers har ett antal features, där varje feature är till för att åstadkomma en viss typ av funktionalitet i ett visst kontext. Men kontexten hålls ej isär i browsers och därför kommer olika features att aktiveras i en konfiguration som de inte skulle aktiveras i. Och det leder till problem. Som vi alla sett av och till.
Resultatet -- webbdesigners och innehållsförfattare måste hela tiden verifiera att det blir som de vill, och när det uppstår problem så gäller det att finna work-arounds. En helt barock situation -- javisst. Men realitet. Därför finns det en del "experter" som säger sig sälja kompetensen att gå runt problem -- och i många fall är det det de kan. Och vi tar det oftast för givet att "life is like this".
Men om man för skojs skull transponerar denna beskrivning till en annan värld. ..... Volvo levererar bilar. De beter sig underligt/undermåligt/inte alls. De kan inte svänga höger. Därmed startas det entusiastnätverk som sinsemellan utbyter tips om hur man faktiskt kan få volvo att svänga höger. Och det finns speciella yrkesmän som man kan inkalla för att i en högersväng komma och hjälpa till att få bilen runt hörnet. .... Skulle vi acceptera detta? Naturligtvis inte. Volvo har ett ansvar att bilarna inte uppvisar beteenden som är onaturliga och farliga. Och även om vi hört än det ena och än det andra om leverantörernas brist på kundstöd, så måste vi alla erkänna att bilbranchen är himmelriket jämfört med programvarubranchen.
Så var står W3C? Ja, egentligen utanför boxningsringen. I ringen finns leverantörerna — och på repen hänger kunderna/användarna. W3C kan bara säga: "Vi har ju fastlagt reglerna - och ni gick med på dem — då borde ni i anständighetens namn följa reglerna och inte slå under bältet" Men de facto är det bara det som W3C kan göra - att säga att standarden säger detta-och-detta och att detta i enlighet med förarbetet skall tolkas på detta sätt.
Så just detta fall, där Microsoft IE orsakar problem när vissa features aktiveras och inte när andra features aktiveras, här kan W3C inte agera. Hur mycket man än skulle vilja -- för att ställa upp på användarnas sida detta ganska klara fall.
Ty situationen är sådan att W3C inte är, och hitintills inte strävat efter att bli, en certfieringsorganisation. Har man en certifieringsroll är det annorlunda. Då uttalar man sig om konformitet med en standard. Och att någonting konkret uppfyller eller inte uppfyller standarden.
Men som sagt, certifiering gör inte W3C. Och därmed uttalar sig inte W3C officiellt om denna typ av frågor. Tanken var att detta skulle andra organisationer ta hand om. Vilket är något som sker i området WAI (tillgänglighet för funktionshindrade) Där skapas nu en pan-europeisk insats som skall ta fram regler för hur man certifierar m.a.p. WAI-riktlinjer, och hur organisationer kan få certifieringsrätt. I den här europeiska insatsen är bara W3C rådgivande om hur man vid certfiering bör förhålla sig till de olika WAI-riktlinjerna.
HTML skulle kunna ha hanterats på likartat sätt -- att en organisation hade skapats som skulle certifiera olika typer av webbläsare. Om en sådan organisation hade funnit hade marknaden nog varit mer sanerad nu. Men jag skulle nog också säga att starka marknadskrafter skulle kämpat emot just denna certifieringsorganisations tillblivelse (ingen nämnd, ingen glömd).
Därför -- vi står där vi började. Anarki är normen. På trettio års sikt ser det nog annorlunda ut. Men inte i det korta loppet. Och MS dominans på klientsidan har ju inte skapat en bra förutsättning för att marknadskonkurrens ska kunna sanera det vi ser. De behöver inte anstränga sig. Och det får som effekt just det man ser på webben -- att det sprids tips om hur man kan koda sig runt buggarna i IE. Och, tråkigt nog, det är bara det som är den praktiska vägen att gå.
---
Ett tankescenario: Antag att marknaden (dvs många användare) lyckades lägga upp en kampanj av klagomål som gjorde att MS tyckte att det var nog bäst att fixa den här buggen. Och anta att de kan fixa den. Och i visst avseende är nu problemet löst.
men i själva verket är problemet kvar, åtminstone på ett par års sikt. Ett fenomen man ser är att användare inte tar till sig de bugg-fixar ("patchar") som MS tillhandahåller. Dvs det finns o-uppdaterade (o-patchade) system därute. Och de kommer att finnas kvar under överskådlig tid. Så om man verkligen vill kunna stödja ett antal plattformar så måste man pervertera sig -- avvika från strikta standarder och börja hacka i mörkret i olika hörn och kanter.
Situationen kan vara annorlunda i en situation där man kan påverka kunden att ensa sina plattformar till en viss uppgraderingsnivå. Fint -- alla användare *där* *borta* ser ut att köra på plattformen som jag vill att de skall ha. Men -- om dessa kunder samtidigt har en annan leverantör som i sin tur kräver en annan uppgraderingsnivå -- hur skall användarorganisationen kunna veta vilken policy de då skall anamma. Troligen blir det i formen att "vi/kund har denna plattform, och ni måste kunna leverera på denna plattform."
Sensmoralen: bita i det sura och skrynkliga äpplet istället i det perfekt röda äpplet.
Henrik Wannheden
|
|
|
|
|
www.christina.blomqvist.us
