Gå til innhold

Nettaviser og kodekvalitet (valideringsfeil)


Anbefalte innlegg

Bolson: På kva måte slår XHTML HTML? Korleis er XHTML strengare enn HTML, og kva meiner du med at MIME-type-problemet kan løysast midlertidig?

Sender du eit GIF-bilete som image/png? Nei.

 

Vi har mange formater for å publisere informasjon på internett. Mange fleire enn dei fleste er klar over (ESF, OPML, CDF osv.). Men kvifor er XHTML veien å gå?

Er informasjonen på ei side med ein XHTML-DTD (som faktisk ikkje har noko å seie) enklare tilgjengeleg enn på ei side koda i "original" HTML? Ikkje enda.

 

Dei fleste som har informasjon som er interessant for ei brukergruppe som har interesse for dette feltet, og som har kunnskapar om dei forskjellige oppmarkeringsspråka, har i tillegg til den visuelt tilgjengelege versjonen vanligvis eit XML-dokument (Atom, RSS, RDF osv.) der innholdet enkelt kan takast ut av samanhengen.

 

Verda er langt i fra klar for XHTML. Eg trur aldri at eit oppmarkeringsspråk som er avhengig av at alt er velforma for å renderast vil lukkast som det einaste brukbare markeringsspråket. Det vil alltid vere ein majoritet av utgivarar her på nettet som ikkje har gode nok kunnskapar om (X)HTML til å alltid kunne levere eit velforma dokument.

 

Eg ser absolutt ikkje korleis XHTML2 kjem til å slå HTML5, for eksempel.

 

 

-------------- <- Dette er ein strek.

Endret av Henrik Lied
Lenke til kommentar
Videoannonse
Annonse
Bolson: På kva måte slår XHTML HTML? Korleis er XHTML strengare enn HTML, og kva meiner du med at MIME-type-problemet kan løysast midlertidig?

Sender du eit GIF-bilete som image/png? Nei.

 

The Future: HTML or XHTML. Jeg synes konklusjonen her sier det meste. Eller for å gjenta, HTML har ingen reelle utviklingsmuligheter, mens XHTML har nesten uendelige. Blant annet fordi det er laget for å kunne håndtere namespace. og sitt langt strenger syntakskrav. Og er det noen som programmer, som ikke avslutter kodesekvenser. Det er jo faktisk det HTML gjør. Og egentlig er det nettleserens innebygde triks som redder oss. Mime-type løses jo på noe vi kan kalle en midlertidig måte i dag, tror neppe XHTML 2.0 vil gi mulighet for text/html (faktisk gjør ikke XHTML 1.1 det heller), og bakoverkompablitet løses.

 

Vi har mange formater for å publisere informasjon på internett. Mange fleire enn dei fleste er klar over (ESF, OPML, CDF osv.). Men kvifor er XHTML veien å gå?

Er informasjonen på ei side med ein XHTML-DTD (som faktisk ikkje har noko å seie) enklare tilgjengeleg enn på ei side koda i "original" HTML? Ikkje enda.

 

Nei, ikke i dag. Men er det argument for ikke å pushe for en standard som faktisk ikke vil krever at tagger, attributter og andre element må være hardkodet i nettleseren. Tanken har aldri vært slik. Med XHTML og namespace kan man faktisk lage nettlesere som vil kunne håndtere enhver ny tag, og nye kombinasjoner av tagger. Bare den nødvendige CSS og definisjon er mer vil det se meget bra ut. Flere enn artikkelforfatteren ovenfor mener at HAppy 1.0 (det du senere kaller HTML 5.0) bare vil virkelig fungere med XHTML 2.0. Og ellers er jo både OPLM og CDF spesialversjoner av XML for spesifikke formål, noe faktisk SOAP også er. Så faktisk snakker vi ikke om flere formater, vi snakker i stor grad om et XML, der XHTML er versjonen for å vise nettsider.

 

Dei fleste som har informasjon som er interessant for ei brukergruppe som har interesse for dette feltet, og som har kunnskapar om dei forskjellige oppmarkeringsspråka, har i tillegg til den visuelt tilgjengelege versjonen vanligvis eit XML-dokument (Atom, RSS, RDF osv.) der innholdet enkelt kan takast ut av samanhengen.

Gjør dette XHTML mindre interessant.

 

Verda er langt i fra klar for XHTML. Eg trur aldri at eit oppmarkeringsspråk som er avhengig av at alt er velforma for å renderast vil lukkast som det einaste brukbare markeringsspråket. Det vil alltid vere ein majoritet av utgivarar her på nettet som ikkje har gode nok kunnskapar om (X)HTML til å alltid kunne levere eit velforma dokument.

Skal faktisk være enig med deg at det er mange som ikke har den kompetansen, i dag. Også blant leverandører av nettbaserte løsninger. Men bruker ikke flertallet av de som produserer for nettet enten kommersielle, egenutviklede eller åpen kildekode publiseringsløsninger. Og bør man ikke kunne stille krav til at disse har kompetansen.

 

Eller for å sitere David Siegel fritt oversatt til norsk. "Hadde jeg visst hva resultatet av å anbefale tabeller til design hadde blitt, hadde jeg aldri gjort det".

 

HTML har aldri vært ment for det det til slutt er brukt til, til det har det altfor mange logiske mangler og svakheter, og ble aldri implementert korrekt. Også den sentrale grunnen til at W3C gikk det skritt å lage

 

Eg ser absolutt ikkje korleis XHTML2 kjem til å slå HTML5, for eksempel.

 

-------------- <- Dette er ein strek.

5172138[/snapback]

 

Rett og slett fordi et HTML 5 må slite med alle hardkodede tagger i nettlesere så lenge det skal lages på basis av HTML 4.01 og bare være en utvidelse til en del nye element og strengere syntaks. XHTML kan velge å gjøre det gjennom text/html, men har muligheten for å gå nye veier. Og kanskje det mest interessante, de nye elementene i HTML 5, dvs Web Application vil trolig bli tillegg til både HTML 4.01, XHTML 1.1 og XHTML 2. Og i og med at XHTML 2 og Web Applications kan leve side ved side grunnet ulike namespace, vil de ikke konkurrere, men være komplementære.

 

Men du mener kanskje noe annet med HTML 5

 

Og et jeg ser faktisk et poeng i å følge anbefalinger fra W3C. De fleste der er faktisk relativt skarpe øverst, og har en klar ide med hva de vil oppnå.

 

Og faktisk gir XHTML meg en fordel. Den lærte med relativt fort av med slappy HTML koding, noe jeg var plaget av etter å ha kodet HTML siden versjon 1.0.

Lenke til kommentar

Hvilken fordel gir XHTML servert som text/html deg?

XHTML servert som tekst/html er dårlig HTML.

 

Du kan lage så gennialt markeringsspråk du bare vil, har ikke noe å si uten støtte for det.

 

Du har absolutt endel gode argumenter, men de ligger fremtiden til.

Idag finnes det bare et utbredt markeringsspråk som kan brukes riktig.

 

Får vi en dag utbredt støtte for namespaces er det jo ingenting som kan stoppe oss. Da kan vi lage egene markeringsspråk som det passer oss.

(Satt litt på spissen)

Lenke til kommentar
Hvilken fordel gir XHTML servert som text/html deg?

XHTML servert som tekst/html er dårlig HTML.

 

Du kan lage så gennialt markeringsspråk du bare vil, har ikke noe å si uten støtte for det.

Gir det meg noen ulemper? Hvorfor er det dårlige HTML når semantikk og kodekvalitet er den samme, ja i mange tilfeller bedre? Og hvorfor er XHTML servert som text/html dårlig HTML? Når faktisk forskjellen er bare at jeg bruker små bokstaver, lukker alle tags, og lar være å bruke noen attributer. Noe som etter min mening er gode regler.

Du har absolutt endel gode argumenter, men de ligger fremtiden til.

Idag finnes det bare et utbredt markeringsspråk som kan brukes riktig.

Er det uriktig å bruke XHTML med text/html så lenge det er en anbefalt måte for å sikre at det leses korrekt i nettlesere?

 

Selv om noen ser det som skadelig. Og poenget deres er bra, med text/html oppfører jo XHTML seg som HTML, og nettlesere oppfatter det som tagsuppe. Men blir det bedre av å bruke HTML 4.01. Den oppfattes jo som tagsuppe den også, fordi ingen nettlesere parser verken SGML eller XML. Men rett gjort er det faktisk verktøy som oppfatter XHTML som XHTML. Men jeg ser ikke som noe argument at andre kanskje vil kopiere fra min kode, å ikke bruke XHTML. Og får vi noen av nettleserene til å utvikle seg til å bli det de skulle ha vært uten å ta i bruk nye standarder.

 

Og fremtiden den er i dag den. Uten vilje til å hele tiden ta i bruk det nyeste, vil vi heller ikke fremme utvikling. Da ville vi fremdeles laget sider med tabeller og HTML 2.0 eller kanskje 3.2. Og tros alt, XHTML er en mange år gammel standard.

 

HTML versus XHTML. Denne artikkelen gir de fleste argumenter for å benytte XHTML, men sier også klart at i daglig bruk er det ingen reelle forskjeller. Hovedargumentet er at XHTML er XSL klart, de bruker XML-syntaks (så lærer man det også), mange mener det er enklere å lære pga helt konsistente regler, og det er enklere å flytte dokumenter til nye standarder.

 

Så for meg var det ingen argumenter for å fortsatt bruke HTML 4.01. Greit, det ga ingen direkte fordeler, men jeg kunne like gjerne lære det først som sist. Og i ettertid har det gitt meg fordeler, blant annet fordi jeg skriver mye i xml og det var greit å ha lært kodereglene.

 

Men mitt poeng med denne tråden var ikke å lage debatt om HTML eller XHTML. HTML (slik den er definert som applikasjon i SGML) er "dead end", om ikke i dag så i løpet av 2 - 5 år. Akkurat like mye som SGML er "dead end". Poenget var å sette søkelys på elendig kodekvalitet uansett HTML eller XHTML. Rett og slett fordi det er "skadelig" (harmful) at seriøse aktører lager så dårlig kvalitet.

Endret av Bolson
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...