Nettaviser og kodekvalitet (valideringsfeil)

[Bolson]

For morro skyld sjekket jeg kodekvaliteten til enkelte nettaviser med w3c validator.

 

Og her er noen av resultatene.

 

Nettavis Antall feil (X)HTML Plattform

ComputerWorld 602 1.0 Trans IIS 6.0

PCWorld Norge 667 1.0 Trans IIS 6.0

Digi.no 3 4.01 Trans Apache/PHP

Hardware.no 145 1.0 Trans Apache/PHP

 

Alle resultatene finner du i denne kommentaren

 

Egentlig burde de fleste av disse ikke hatt lov å skrive noe om nett og programvare for nettet.

 

Flere kommentarer er vel neppe nødvendig. Men kom gjerne med andre sider som validerer elendig, men de bør være seriøse og av litt størrelse. Og gjerne noen som validerer også. Faktisk validere Microsoft sin norske hjemmeside.

[Steinmann]

Noe av problemet med mange av de sidene er at de har reklame som ikke validerer.

 

Men vi ser jo på hw siden, kodingen er ikke helt på topp.

[Bolson]

Noe av problemet med mange av de sidene er at de har reklame som ikke validerer.

 

Men vi ser jo på hw siden, kodingen er ikke helt på topp.

5170565[/snapback]

 

Fullt klar over at mye reklame ikke validerer grunnet elendig koda reklameapplikasjoner. Men for meg er det uansett særdeles dårlig argument. Litt bør de presses de som lager de applikasjonene også

[Moonshine]

Dårlige, dynamiske linker lager også feil.

<a href="index.php?a=b&c=d" title="a og b">...

 

Denne validerer ei.

[Nervetattoo]

Jeg kan kun svare for hw og da er det som kjent mye som skyldes reklamekode.

Her prøver vi også å presse litt på for å få bedret koden, men det er ikke bare bare så lenge vi er de eneste av kundene som bryr seg.

De sitter nok i den posisjonen at de må prioritere å enten bugfixe andre ting eller fikse validerbar kode. Da kommer kodekvalitet stort sett alltid ganske lavt.

 

Vi har også sikkert noen feil på dynamiske linker og annet smårusk, dette er ting som fort havner i samme kategori med at nedprioriteres i forhold til å lage nye funksjoner.

 

Jeg skulle veldig gjerne ønsket at vi kunne validere siden, vi er noen her på drift som faktisk virkelig bryr seg om dette, men det er det med å få prioritert pussing på html.

Annonsekodene kan vi vell håpe blir forbedret før 2010 elns, jeg har iallefall liten tro på at vi vil se noen bedring der snarlig.

 

Om noen har spesifikke ting de ser i koden som bør forbedres så kan dere sende oss en mail (alt er mye lettere å prioritere når man får klager via mail )

Men vi behøver ingen som sender oss "siden deres validerer ikke" for det er vi allerede veldig klar over.

[Bolson]

Dårlige, dynamiske linker lager også feil.

<a href="index.php?a=b&c=d" title="a og b">...

 

Denne validerer ei.

5171040[/snapback]

 

Du har helt rett. Bruken av ampersand (&) feil enkoda er vel mesteparten av feila. Men det er relativt enkelt å få publiseringsløsninger til å skrive den som "&. Som er godkjent kode, og som nettlesere forstår og oversetter internt tilbake. Selv om det beste er å bruke såkalte forståelige linker. Som sagt, begge deler er teknisk kurant. Også hashing (referansen gjøres om til en hashverdi) av linker er en mulighet i dynamiske løsninger. Jeg gjør det og får linker alla dette

<a href="singlenews+M5c2609dbad4.html" title="en nyhet">

 

digi.no endre & til &, og dermed klarer de også å få omtrent all reklamen til å få validerbar kode.

Endret 18. november 2005 av Bolson

[Cucum(r)]

Dårlige, dynamiske linker lager også feil.

<a href="index.php?a=b&c=d" title="a og b">...

 

Denne validerer ei.

5171040[/snapback]

 

Du har helt rett. Bruken av ampersand (&) feil enkoda er vel mesteparten av feila. Men det er relativt enkelt å få publiseringsløsninger til å skrive den som "&. Som er godkjent kode, og som nettlesere forstår og oversetter internt tilbake. Selv om det beste er å bruke såkalte forståelige linker. Som sagt, begge deler er teknisk kurant. Også hashing (referansen gjøres om til en hashverdi) av linker er en mulighet i dynamiske løsninger. Jeg gjør det og får linker alla dette

<a href="singlenews+M5c2609dbad4.html" title="en nyhet">

 

Det er det digi.no gjør, og dermed klarer de også å få omtrent all reklamen til å få validerbar kode.

5171102[/snapback]

Og dette slår ein skikkeleg IRI på kva måte?

[Bolson]

Jeg kan kun svare for hw og da er det som kjent mye som skyldes reklamekode.

Her prøver vi også å presse litt på for å få bedret koden, men det er ikke bare bare så lenge vi er de eneste av kundene som bryr seg.

De sitter nok i den posisjonen at de må prioritere å enten bugfixe andre ting eller fikse validerbar kode. Da kommer kodekvalitet stort sett alltid ganske lavt.

 

Vi har også sikkert noen feil på dynamiske linker og annet smårusk, dette er ting som fort havner i samme kategori med at nedprioriteres i forhold til å lage nye funksjoner.

 

Jeg skulle veldig gjerne ønsket at vi kunne validere siden, vi er noen her på drift som faktisk virkelig bryr seg om dette, men det er det med å få prioritert pussing på html.

Annonsekodene kan vi vell håpe blir forbedret før 2010 elns, jeg har iallefall liten tro på at vi vil se noen bedring der snarlig.

 

Om noen har spesifikke ting de ser i koden som bør forbedres så kan dere sende oss en mail (alt er mye lettere å prioritere når man får klager via mail )

Men vi behøver ingen som sender oss "siden deres validerer ikke" for det er vi allerede veldig klar over.

5171080[/snapback]

 

Jeg er klar over problemet, men hvordan klarer da digi.no å få dette til (3 feil). De har minst like mye reklame som hw.no. På koden deres ser jeg at dere internt bruker korte linker (til artikler med mer). Derfor kommer dere først bort i problemet når reklamen skal inn.

 

Løsningen er å parse innholdet i reklamebannerene slik at alle & blir &. Pluss enkode rett noe annet rask. Gjøres det rett, vil linkene fungere 100 %, fordi nettlesere leser & som &.

 

Nå vet jeg ikke hvordan kildekoden til digi.no er, og den er neppe tilgjengelig. Resultatet er i hvert fall at & blir & Men åpen kildekode systemet TYPO3 løser dette på måten med å endre encoding på tegn som ikke validerer.

[Nervetattoo]

Jeg er klar over problemet, men hvordan klarer da digi.no å få dette til (3 feil). De har minst like mye reklame som hw.no. På koden deres ser jeg at dere internt bruker korte linker (til artikler med mer). Derfor kommer dere først bort i problemet når reklamen skal inn.

 

Løsningen er å parse innholdet i reklamebannerene slik at alle & blir &. Pluss enkode rett noe annet rask. Gjøres det rett, vil linkene fungere 100 %, fordi nettlesere leser & som &.

 

Nå vet jeg ikke hvordan kildekoden til digi.no er, og den er neppe tilgjengelig. Resultatet er i hvert fall at & blir &  Men åpen kildekode systemet TYPO3 løser dette på måten med å endre encoding på tegn som ikke validerer.

5171134[/snapback]

 

Digi bruker da html 4.01 i.flg din "artikkel" og ikke xhtml 1.0 trans og såvidt jeg kan huske tillater html stor skrift i tagger blant annet, og language-attributten er enda støtten for script-tagen?

Det er uansett lettere å komme unna med html.

 

Men ampersand-problemene er lett å fikse på annonsekoden, andre ting kan vi også rette på i etterkant, men vi har vært forsiktige med å gjøre dette siden det alltids innebærer en liten risiko for at det ikke fungerer da.

Jeg skal se om å rette ampersand-problemet egentlig fører til andre problemer, siden det definititvt er det mest irriterende problemet.

[Bolson]

Og dette slår ein skikkeleg IRI på kva måte?

5171117[/snapback]

 

På ingen måte. Men publiseringsløsninger/reklamapplikasjoner kan ha store problemer med å lage linker ala

http://www.avisen.no/nyheter/nov/16/minnyhet.html

Særlig gjelder dette windowsbaserte systemer med IIS, fordi IIS ikke har eller har en meget dårlig mulighet til mod_rewrite som er nødvendig for å få virkelig dynamiske løsninger til å oversette fra og til en skikkelig IRI. Da er rett encoding av & den enkle løsningen, som tross alt fungerer. Microsoft bruker den på egne sider. Hashing krever mod_rewrite, men er en mye enklere løsning å sette opp for interne linker på mange systemer. Kan også brukes for eksterne, men da oversettes de internt underveis. Tross alt er det langt lettere å skrive inn en link som "singlenews+s34djjrosm.html" en en link som "zone?zid=196&cid=391&mid=973&pid=0&referrer=http%3A%2F%2F//

www.hardware.no%2F&redirect=http%3A%2F%2Fwww.komplett.no%2Fk%2Fk.asp%3F%26cks//

%3DASS%26assoc%3D767828D7-AEF1-459B-B2DA-A39CF6BF698E"

 

Og faktisk kan de to linkene bety nøyaktig det samme. Og som du ser er det IIS som er plattform på reklameapplikasjonen (jf en asp).

 

Plone, TYPO3 og Joomla er åpen kildekode CMS systemer som jeg vet bruker mod_rewrite eller lignende funksjonalitet for å få skikkelig IRI. Finnes sikkert flere.

 

Men de har også problem med linker fra reklamebanner levert av andre, og må fikse encodinga for å få det til å virke. Hadde reklameapplikasjonene kunne levert linkene som enten "hashverdi" eller reell uri ved hjelp av mod_rewrite hadde problemet vært løst.

[Cucum(r)]

Og dette slår ein skikkeleg IRI på kva måte?

5171117[/snapback]

 

På ingen måte. Men publiseringsløsninger/reklamapplikasjoner kan ha store problemer med å lage linker ala

http://www.avisen.no/nyheter/nov/16/minnyhet.html

Særlig gjelder dette windowsbaserte systemer med IIS, fordi IIS ikke har eller har en meget dårlig mulighet til mod_rewrite som er nødvendig for å få virkelig dynamiske løsninger til å oversette fra og til en skikkelig IRI. Da er rett encoding av & den enkle løsningen, som tross alt fungerer. Microsoft bruker den på egne sider. Hashing krever mod_rewrite, men er en mye enklere løsning å sette opp for interne linker på mange systemer. Kan også brukes for eksterne, men da oversettes de internt underveis. Tross alt er det langt lettere å skrive inn en link som "singlenews+s34djjrosm.html" en en link som "zone?zid=196&cid=391&mid=973&pid=0&referrer=http%3A%2F%2F//

www.hardware.no%2F&redirect=http%3A%2F%2Fwww.komplett.no%2Fk%2Fk.asp%3F%26cks//

%3DASS%26assoc%3D767828D7-AEF1-459B-B2DA-A39CF6BF698E"

 

Og faktisk kan de to linkene bety nøyaktig det samme. Og som du ser er det IIS som er plattform på reklameapplikasjonen (jf en asp).

 

Plone, TYPO3 og Joomla er åpen kildekode CMS systemer som jeg vet bruker mod_rewrite eller lignende funksjonalitet for å få skikkelig IRI. Finnes sikkert flere.

 

Men de har også problem med linker fra reklamebanner levert av andre, og må fikse encodinga for å få det til å virke. Hadde reklameapplikasjonene kunne levert linkene som enten "hashverdi" eller reell uri ved hjelp av mod_rewrite hadde problemet vært løst.

5171204[/snapback]

IIS skal eg ikkje uttale meg om, sidan eg ikkje har nokre kunnskaper om dette, men ein har alternativ til mod_rewrite, òg. For eksempel kan ein splitte PATH_INFO, og hente ut dei forskjellige delane på den måten.

[Bolson]

Det er uansett lettere å komme unna med html.

 

Helt enig, men ampersand-problemet er der uansett XHTML/HTML.

 

Men ampersand-problemene er lett å fikse på annonsekoden, andre ting kan vi også rette på i etterkant, men vi har vært forsiktige med å gjøre dette siden det alltids innebærer en liten risiko for at det ikke fungerer da.

Jeg skal se om å rette ampersand-problemet egentlig fører til andre problemer, siden det definititvt er det mest irriterende problemet.

5171175[/snapback]

 

Dette kaller jeg konstruktiv problemløsning. Min erfaring/kunnskap med ampersand-problemet er at det særdeles sjelden skaper problemer. Vi har hatt lange diskusjoner om problemet på news-lista for content-rendering hos TYPO3, og konklusjonen er relativt klar.

 

Ellers var ikke min hensikt å henge ut hardware.no (som jeg oppfatter har folk som tar dette alvorlig), men vise hvor dårlig det tildels står til med kodekvalitet hos enkelte. Også hos leverandører. NB! Teksten hos de er som oftest relativt kort, ingen eksterne linker (reklame), så å ha mer en 2 - 6 valideringsfeil er etter min mening håpløst.

[Nervetattoo]

Ellers var ikke min hensikt å henge ut hardware.no (som jeg oppfatter har folk som tar dette alvorlig), men vise hvor dårlig det tildels står til med kodekvalitet hos enkelte. Også hos leverandører. NB! Teksten hos de er som oftest relativt kort, ingen eksterne linker (reklame), så å ha mer en 2 - 6 valideringsfeil er etter min mening håpløst.

5171262[/snapback]

 

Tar det ikke som uthenging, men det er et problem, helt klart, og vi er jo klar over det selv.

Jeg skulle helst sett hw som ledende innen å følge webstandarer på nett

[Bolson]

IIS skal eg ikkje uttale meg om, sidan eg ikkje har nokre kunnskaper om dette, men ein har alternativ til mod_rewrite, òg. For eksempel kan ein splitte PATH_INFO, og hente ut dei forskjellige delane på den måten.

5171254[/snapback]

 

Går visst ikke i alle system, etter det jeg har fått forklart. Er forskjell på hvordan de "virtuelle linkene" relatert til nettstedets rot lagres i databasen. TYPO3 lagrer disse som virtuell katalogstruktur, men må allikevel bruke mod_rewrite for å få det til å fungere. Andre bruker helt andre prinsipper.

 

Men det viktigste er å ha bedre løsninger en 100 tegns lange linker med & % = ? og annet rart

[Steinmann]

Digi bruker da html 4.01 i.flg din "artikkel" og ikke xhtml 1.0 trans og såvidt jeg kan huske tillater html stor skrift i tagger blant annet, og language-attributten er enda støtten for script-tagen?

Det er uansett lettere å komme unna med html.

5171175[/snapback]

Og det er en utrolig god grund til å gå over til html

Bedre med riktig html enn nesten riktig xhtml(dere får den ikke riktig så det er bare å gi opp)

Forstår at cms systemet mest sannsynlig er laget for xhtml og det er der problemet ligger da.

 

Men får dere ikke lov til å endre på reklame "koden" firmaene sender dere?

[Bolson]

Digi bruker da html 4.01 i.flg din "artikkel" og ikke xhtml 1.0 trans og såvidt jeg kan huske tillater html stor skrift i tagger blant annet, og language-attributten er enda støtten for script-tagen?

Det er uansett lettere å komme unna med html.

5171175[/snapback]

Og det er en utrolig god grund til å gå over til html

Bedre med riktig html enn nesten riktig xhtml(dere får den ikke riktig så det er bare å gi opp)

Forstår at cms systemet mest sannsynlig er laget for xhtml og det er der problemet ligger da.

 

Men får dere ikke lov til å endre på reklame "koden" firmaene sender dere?

5171459[/snapback]

 

Problemet endrer seg ikke om man koder etter HTML 4.01, & (ampersand) er like ulovlig uansett. Grunnen er at dette er startkarakteren i kodesett for å forstå tegn som ikke er vanlige. F.eks heter ø - &oslash: å - å osv. Skulle man mot formodning lage en link som var som følger www.side.no/index.php?siteønoe=rart, ja da hadde det gått galt. Nettleseren hadde lest dette som www.side.no/index.php?siteønoe=rart.

 

Ellers er HTML 4.01 en gammel standard, som ikke bør brukes på nye nettsider. I dag skal/bør XHTML brukes. Problemet til hardware.no har i liten grad med HTML 4.01 Transitional kontra XHTML 1.0 Transitional å gjøre. (selv om det finnes noe feil som er ikke er knyttet til reklame)

 

CMS systemer bør ikke lages for bestemte HTML standarder. De bør/skal lage validerbar kode slik at den følger den standarden man ønsker. Derfor skal aldri HTML kode hardkodes i PHP, .net, java eller lignende.

 

Hardware.no kan kun endre hvordan linkene til reklame ser ut på siden dersom de lager en funksjon for rekoding/oversetting. Hvor komplisert dette er vil jeg ikke uttale meg om, til det kan jeg for lite om PHP.

[Steinmann]

Jasså ja

 

amp blir fortsatt et problem, og det er jeg veldig klar over,

hadde vært pent med mod_rewrite da

Endret 20. november 2005 av orsus

[Bolson]

Jasså ja

 

amp blir fortsatt et problem, og det er jeg veldig klar over,

hadde vært pent med mod_rewrite da 

5171596[/snapback]

 

Jeg er fullt klar over denne debatten, og at det uten tvil er to klare leire i den. DEt blir litt som AMD kontra Intel, *nix kontra Windows. Selv tilhører jeg klart XHTML leiren og ser klart flere argumenter for å gå den veien enn å holde meg til HTML. At IE ikke løser mime-type rett er et dårlig argument, så lenge det foreløpig kan løses. Mime-type XHTML+XML vil slå gjennom etterhvert, rett og slett fordi vi i større og større grad bruker XML som standard. Det blir dokumentformatet, overføringsformatet, og ser ut til å bli viktig format i kommunikasjon med databaser. DB2 legger inn dette i sin nye versjon, med protokollen Xquery.

 

Finnes også langt flere argumenter.

 

Men la oss ikke lage dette til den vesentlige parten. Uansett er målet å få ryddet bort feil, ikke bruke gamle tagger og attributter, og ikke tabeller til sidedesign. Og da er jeg enig i at det er bedre med en godt koda HTML 4.01 side en elendig XHTML 1.0. Og at flertallet av de som lager personlige blogger med mer fint klarer seg med å bruke HTML 4.01 Strict. Derfor liker jeg TYPO3 som lar meg bestemme hvilken standard jeg ønsker å følge, og som i versjon 4 vil følge XHTML 1.0 Strict, men la deg like gjerne bruke HTML 4.01 Strict om du ønsker dette, med rett kode som resultat.

 

mod_rewrite er en lekker liten funksjon i Apache. Må si jeg liker den. Men jaggu skal man holde tunga beint i munnen når CMS'en konfigureres.

[Steinmann]

regulær utrykk er noe man fort begynner å grine litt av indeed.

[Nervetattoo]

Og det er en utrolig god grund til å gå over til html

Bedre med riktig html enn nesten riktig xhtml(dere får den ikke riktig så det er bare å gi opp)

Forstår at cms systemet mest sannsynlig er laget for xhtml og det er der problemet ligger da.

 

Men får dere ikke lov til å endre på reklame "koden" firmaene sender dere?

5171459[/snapback]

 

Så du mener det er en god grunn å gå over til HTML slik at vi ikke har et pressmiddel for å drive teknologien videre?

XHTML får ikke grobunn før folk faktisk bruker det, og en side med valideringsfeil som har doctype xhtml trans/strict er da et pressmiddel for oss selv til å videreutvikle oss. Vi vet at vi kunne valgt en utdatert standard og antageligvis sluppet unna med en del mindre feil og mindre kommentarer fra f.eks forumbrukere, vi kunne også fortsatt å bruke tables til design og andre semantiske feilskjær. Men vi gjør jo ikke det, vi vil jo holde et høyt nivå.

Jeg vil også si vi er i en overgangsfase, alt var ikke rett når vi lanserte, men fram til nå har flere feil blitt luket bort, og bedre vil det bli. Jeg kan love at antall valideringsfeil på siden vil bli mindre veldig snart, det krever bare litt prioritet, og nå har jeg prioritert å bruke litt tid på å se på hvordan vi kan pynte litt på annonsekodene.

 

Vårt cms-system er orginalt sett laget for html da det begynner å bli en del år gammelt (det er 100% selvskrevet på huset), men det blir konstant videreutviklet og det meste er nå "beregnet" for xhtml.

Vi får ingen koder fra firmaer. Vi kjører en annonseserver med advertpro som generer annonsekoden. Denne programvaren er som dere ser tredjeparts. Men vi pusher selvsagt på advertpro for å få de til å bedre advertpro slik at den blant annet kan lage xhtml-validerenede kode.

 

La nå ikke dette bli til en diskusjon om html kontra xhtml