Det som skjer når en slik style tag ikke er lukket er jo selvfølgelig at alt som kommer etterpå anses for å være nettopp en stil, og ikke html, men nettlesere i dag er stort sett så smarte at de skjønner at elementer slik som body og html normalt skulle vært lukket, og derfor så ordner de dette automagisk selv.
Man kan derfor ha en del feil, og dette er klassisk syntax error, men nettleseren ordner opp, i hvertfall sånn delvis ettersom den tydeligvis ikke klarer å gjette seg frem til hvor og når den style taggen skulle vært lukket, men samtidig såpass bra at alt virker omtrent slik det skal, det hadde nesten vært bedre om det bare sto "syntax error på den og den linjen", i stedet for at nettsiden kom opp, så viste man at det var noe feil, men slik er det altså ikke, og da ville vel heller ikke 80% av sidene på nettet fungert overhode så det er kanskje like greit.
Prøve å forklare så kort som mulig hvordan man kan se slike feil:
Bruker ikke noe spesielt egentlig for å sjekke slikt, men i "inspiser element" i Chrome eller med Firebug så kan man følge nettverket og se på alle script filer, samt at når man ser på elementene så er det de faktiske elementene på siden, og ikke nødvendigvis det samme som i kildekoden. Når man da ser at ga.js ikke ligger i <head> som den skal, og Analytics er egentlig veldig enkelt, alle elementer i et html dokument har diverse muligheter for "eventer", slik som klikk, mouseover, change, submit og en hel haug med andre, alle disse eventene bobbler opp (dvs. ikke alle, men de aller fleste), det vil si at dersom man har en <li> inne i en <ul> inne i en <div> og man klikker på <li> elementet så bobbler det klikket opp til neste nivå, altså <ul> elementet, deretter <div> osv. helt opp til "document" som inneholder alle de andre elementene. Setter man det som kalles en "event listener" på document elementet som fanger opp for eksempel alle klikk, eller alle musebevegelser eller hva man måtte ønske egentlig, så kan man deretter finne ut hvilket element eventen stammer fra, noe slikt:
Kode:
document.onclick = function(event) {
var stammerFra = event.target;
}
De to linjene fanger i grunn alle klikk på en side, og hvis du ser på analytics koden kan du se at det settes opp et array, "gaq = [];" hvor alt dette samles, og så sendes til Google.
Dette er veldig forenklet, det sendes en hel del annen informasjon også, men det pussige er at mesteparten av den informasjonen er åpent tilgjengelig på serveren, slik som brukernes nettlesere, lokasjon, ip og en masse annet som man ofte bruker javascript for å sende til Google er altså tilgjengelig på serveren uten at det koster en kalori.
Det er i grunn en veldig lite effektiv måte å gjøre det på å drive å sende alt til Google, og normalt så hadde det vært mye bedre å skrive sin egen analytics kode og sende det til sin egen server i stedet for å laste ned en ekstern javascript fil fra Google, og så drive å sende all den informasjonen over nettet til Google når man heller kunne sendt det til sin egen server. Bakdelen her er selvfølgelig at de færreste gidder å sitte skrive noe som ser så hyggelig ut som GA med fine grafer, kart osv. og poenget er at man kan se etter de dataene som sendes på nettverket, altså lytte etter pakker som sendes, og dersom det ikke er noen pakker som sendes til Google, så er det heller ikke noe analytics på gang.
Neste da blir normalt å bruke øynene for å sjekke koden, og i Chrome når man så på kildekoden din så forsvant all syntax highlighting som det så fint heter, som da er alle de fancy fargene, etter den FB iframe'n.
Jeg limte så en del av koden over i Komodo som jeg bruker til å skrive kode i, og der skjedde det samme, hverken kommentarene eller koden fikk rette fargen etter iframe'n, men ved å fjerne iframe'n så kom alle fargene tilbake, også i javascriptet til Analytics, og vips så har man bare noen få linjer hvor man vet at feilen ligger, og så er det bare å lese de linjene veeeldig nøye, og flere ganger helt til man ser hva som er problemet, og som sagt så er det helt innlysende når man først ser det at style="ettellerannet" må lukkes med en quote, men det er jammen ikke like lett å se med en gang bestandig, og jeg leste de linjene noen ganger før jeg la merke til at det manglet en " på slutten.
En god editor og validatoren til W3C finner i grunn mange feil, men det er mest semantiske feil, slik som elementer som ikke er lukket osv.
Slike små trykkleifer hvor man har glemt et tegn eller trykket på litt feil tast er normalt så vanskelig å ta tak i at de færreste editorer klarer å se de og si ifra at du har glemt noe, men som regel forsvinner syntax highlightingen når man gjør slike feil fordi editoren (eller Firebug e.l.) ikke skjønner hva som skjer og derfor ikke klarer å sette de rette fargene for å skille koden din, og det er ofte den enkleste måten å se om noe er feil på, se på kildekoden, helst i en skikkelig editor, men Chrome gjør også en god jobb når man ser på kildekode, og hvis alle fargene forsvinner og teksten bare blir svart, så er det normalt noe galt et sted.
