Tips til ny nettside...

[serverside]

Jeg har kjøpt domenet sqlserver.no og tenkte jeg skulle hente inn litt tips før jeg bygger selve side. Siden er ment som en side med tips og kodeeksempler på hvordan man bruker SQL database og selvsagt en del artikler om SQL Server (lage ulike funksjoner, stored procedures, spørringer, JOINS osv).

 

Det er jo ganske mange her som har sterke meninger om hvordan ting skal se ut og bygges opp etc., så jeg tenkte å være litt føre var.

 

Tar gjerne i mot tips både om design, rammeverk, oppbygning, innhold og egentlig alt :-)

 

[yinyou]

Heei

Drit bra side det.

Fant ikke noe spesielt å sette fingern på x)

 

Edit:

Bare glem det, gikk ut og inn fra sia bare

Men bra side ja

Endret 17. august 2007 av yinyou

[serverside]

Du har sikkert kikket på serverside.no. Det er en annen side jeg har. Det jeg gjerne vil er å få noen tips om hva sqlserver.no bør inneholde (den er ikke laget enda)

 

Men takk for tilbakemeldingen

[Vindstille]

Vel serverside.no er veldig rettet mot IE og Microsoft teknologi noe som ikke nødvendigvis er spesielt bra, med tanke på at ting bør være så plattform uavhengig for brukeren som mulig.

 

Det du skriver om at XHTML er bedre enn HTML, og en nyere versjon av html er også feil. (Sjekk "Les før du poster - FAQ" for mer info). XHTML-koden du har skrevet følger heller ikke W3C Spesefikasjonen.

 

Så et lite tips er å sørge for at slike feil ikke gjentar seg på sqlserver.no

 

EDIT:

Når du mener rammerverk, mener du at du skal bruke noe annet enn ASP?

Fikk intrykk av at ASP, MSSQL, osv. var det du kunne mest om.

Endret 17. august 2007 av JonT

[serverside]

Vel serverside.no er veldig rettet mot IE og Microsoft teknologi noe som ikke nødvendigvis er spesielt bra, med tanke på at ting bør være så plattform uavhengig for brukeren som mulig.

 

Det du skriver om at XHTML er bedre enn HTML, og en nyere versjon av html er også feil. (Sjekk "Les før du poster - FAQ" for mer info). XHTML-koden du har skrevet følger heller ikke W3C Spesefikasjonen.

 

Så et lite tips er å sørge for at slike feil ikke gjentar seg på sqlserver.no

 

EDIT:

Når du mener rammerverk, mener du at du skal bruke noe annet enn ASP?

Fikk intrykk av at ASP, MSSQL, osv. var det du kunne mest om.

9303400[/snapback]

 

et par ting. Ja, serverside er veldig rettet mot MS, men som det står på forsiden Vi har primært fokus på Microsoft teknologi, men vil trolig legge inn artikler og kodeeksempler både fra PHP, Java og andre platformer, dessuten: hva mener du med med tanke på at ting bør være så plattform uavhengig for brukeren som mulig.?

 

Når det gjelder den evigvarende diskusjonen om xhtml så mener jeg ikke at xhtml nødvendigvis er bedre enn html i alle tilfeller og det er ingen nyere versjon av html. Vet ikke helt hvor jeg har skrevet det... Men det er tydeligvis et hett tema her på diskusjon.no og det virker som at mange tar det personlig at enkelte velger å bruke xhtml på sine nettsider (og det er IKKE feil å gjøre det i følge w3.org, det er ikke en gang feil å sende det som text/html hvis det er xhtml 1.0 trans.) De fleste kunne fint brukt html 4.01 i stedet og det ville gjort samme nytta, men so? Skjønner ikke helt hvorfor man på død og liv skal henge alle som bruker XHTML. Se på nettsidene til de aller fleste store konsulenthusene som jobber med web i Norge. De bruker xhtml stort sett alle sammen. w3.org bruker selv XHTML på alle sine sider... (til og med diskusjon.no...)

 

Og med rammeverk me ner jeg designmessig. kolonner/oppsett etc... Jeg er definitivt ingen designer (som du sikkert kan se på serverside.no )

 

Men denne diskusjonen hører vel ikke helt hjemme i denne tråden. Jeg er interessert i tips og kanskje hjelp fra folk som vil være med å gjøre sqlserver.no til en bra portal...

[Vindstille]

dessuten: hva mener du med med tanke på at ting bør være så plattform uavhengig for brukeren som mulig.?

9303588[/snapback]

Vel ting som bokmerke-link med javascript funker ikke akkurat bra i annet enn IE.

 

Når det gjelder den evigvarende diskusjonen om xhtml så mener jeg ikke at xhtml nødvendigvis er bedre enn html i alle tilfeller og det er ingen nyere versjon av html. Vet ikke helt hvor jeg har skrevet det...

9303588[/snapback]

Bra, men det er ikke akkurat det som står her:

XHTML har kommet for å ta over etter html 4.0 og XHTML stiller noe strengere krav til koden. En del attributter er faset ut og noen nye har kommet inn. ...

 

Men det er tydeligvis et hett tema her på diskusjon.no og det virker som at mange tar det personlig at enkelte velger å bruke xhtml på sine nettsider (og det er IKKE feil å gjøre det i følge w3.org, det er ikke en gang feil å sende det som text/html hvis det er xhtml 1.0 trans.)

9303588[/snapback]

Det er ikke en gang feil å sende det som text/html når man bruker xhtml 1.0 script! Hva folk til slutt velger å bruke bryr jeg meg ikke så mye om. Derimot det at folk er feilinformert og er med på å villede folk og spre feilinformasjon ser jeg litt mer alvårlig på. Det er derfor mange av oss i Webkaféen er så opptatt av dette og ønsker å få folk på rett kurs igjen.

 

Se på nettsidene til de aller fleste store konsulenthusene som jobber med web i Norge. De bruker xhtml stort sett alle sammen. w3.org bruker selv XHTML på alle sine sider... (til og med diskusjon.no...)

9303588[/snapback]

Det at disse folkene bruker xhtml gjør ikke akkurat at folk begynner å lære, og mye av grunnen til at de faktisk gjør det er pga. mangefulle kunnskaper. De at (x)HTML-Working group i det hele tatt fant på at det skulle være mulig å sende xhtml som "text/html" er noe som aldri burde ha skjedd. Folk tror nå at xhtml-dokumentene de lager faktisk blir tolket som xhtml. (Når de i virkeligheten blir tolket som vanlig html-dokumenter. Noe som fører til at xhtml-dokumentene de skriver faktisk ikke nødvendigvis kan tolkes som xml (noe som var hele meningen med xhtml)).

 

Det at W3C bruker xhtml er forsåvidt forstålig siden man ville promotere XHTML og at man etterhvert tenkte seg at XHTML var alt man trengt. Senere tider har derimot vist at man trenger HTML (det var derfor man igjen startet (x)HTML5 i april/mai i år) og man har forstått at bakoverkompablitet og feilretting er viktige ting å ta vare på.

 

Og med rammeverk me ner jeg designmessig. kolonner/oppsett etc... Jeg er definitivt ingen designer (som du sikkert kan se på serverside.no  )

9303588[/snapback]

Rammeverk = Framework (altså ting som Django, Ruby on Rails, jQuery, Blueprint osv.)

Det du snakker om er vel mer oppsettet på siden.

 

Oppsettet på serverside.no funker vel greit? Ser ikke noen grunn til å forandre så veldig mye, selv om designet selvfølgelig kan bli litt bedre (noe du allerede har poengtert).

 

Men denne diskusjonen hører vel ikke helt hjemme i denne tråden. Jeg er interessert i tips og kanskje hjelp fra folk som vil være med å gjøre sqlserver.no til en bra portal...

9303588[/snapback]

Ja, vi bør vel la denne diskusjonen ligge nå. Send meg heller en PM, hvis det er noe du vil kommentere i det jeg har skrevet.

[serverside]

Jeg regner med at du mener XHTML strict og ikke xhtml 1.0 script. Bør lage en egen tråd på dette emnet så vi kan diskutere dette. Det er et viktig tema, men jeg mener fremdeles at slik som ting er pt så er det ikke feil å sende XHTML 1.0 Transitional som text/html. Slå opp ordet Transitional i ordboka. Det er viktig å se på de harde fakta og den beste fakta-kilden jeg har (si i fra hvis du har noen bedre) er W3.org. De sier at XHTML 1.0 som text/html er greit. Det forholder jeg meg til, men jeg er enig i at folk må vite hva xhtml egentlig er. Det er mange store nettsteder som til og med bruker XHTML 1.0 strict og XHTML 1.1 og sender som text/html.

 

Men ingen kan si at å sende XHTML 1.0 Transitional som text/html er feil!

 

EDIT: har forresten lagt til litt info på den bookmark codesnippet'en på serverside....

Endret 17. august 2007 av serverside

[serverside]

litt dobbelposting. ivrig nå....

Endret 17. august 2007 av serverside

[Vindstille]

Serverside: Vi kan like gjerne endre dette om til en "XHTML 1.0 med text/html"-tråd. Så kan du heller poste en ny tråd med det du egentlig lurte på.

 

Snart tilbake med skikkelig info....

[Ståle]

Na kommer jo HTML 5 snart, og da blir alle glad

 

Jeg bruker XHTML konsekvent, for a vaere klar a "merge" med XML nar jeg en eller annen gang finner pa a laere meg det.

[Vindstille]

All XHTML 1.0 kan sendes som text/html, og som du sier er det kun XHTML 1.1 som ikke kan sendes med text/html. (Du skrev XHTML strict, men jeg går utifra at du mente XHTML 1.1).

Hvis du trudde noe annet da du leste deg jeg skrev, beklager jeg.

 

Men siden jeg ikke ga deg noen ordentlig forklaring istad skal jeg prøve å forklare hvorfor jeg mener mange gjør ting feil og hvorfor jeg mener folk bør begynne å bruke html.

 

XHTML sendt som text/html tolkes (som jeg sa isted) som vanlig html. Mao. er ikke et xhtml-dokument sendt som text/html noe annet enn ett helt vanlig html for nettleseren. Man får ikke benyttet noen av fordelene XHTML gir, og kanskje det verste; all javascript som .innerHTML (som ikke vil funke i XHTML) vil funke helt strålende med text/html. Men hva skjer så? Jo, webmasteren finner ut at det er mer korrekt å benytte application/xhtml+xml så han endrer webtjeneren til å sende (x)html dokumenter på denne måten. Nå vil kanskje noen sider fungere helt ok, mens andre sider som tilfeldigvis bruker innerHTML, style-lementet med comments for å hindre gammle nettlesere å tolke det eller noen av de andre tingene som ikke funker i xhtml, ikke vil funke i det hele tatt.

 

Dette er selvfølgelig ikke noe problem for en som vet hva det innebærer å bruke xhtml med text/html, noe f.eks. W3C gjør. Men for en vanlig person vil det fort føre til masse problemer som ikke er så enkle å løse.

 

Når man da ikke kan benytte noen av fordelene med XHTML, og ikke i noen fremtid kan konvertere til application/xhtml+xml (altså ordentlig xhtml) pga. innerHTML ol. Hva er da vitsen med å benytte XHTML? Spesielt unødvendig er det når vi vet at mange mobiler faktisk har større problemer med å lese XHTML skrevne sider, enn HTML.

 

Nå kan du kanskje forstå hvorfor jeg anbefaler alle å bruke HTML. Det er ikke det at det er galt å benytte XHTML, det er bare det at det i de aller fleste tilfeller bare fører til problemer. XHTML bør derfor bare benyttes når man virkelig vet hva man driver med. Men så lenge IE ikke støtter XHTML sendt med application/xhtml+xml (altså å rendre xhtml som xhtml) er det nærmest igjen i hele verden som bør bruke noe annet enn HTML foreløbig.

 

 

Husk å les dette også, foresten:

Sending XHTML as text/html Considered Harmful av Ian Hickson (leder for HTML-Working Group)

En skikkelig HTML vs XHTML FAQ

 

 

EDIT:

Ståle: Jeg kan ikke skjønne at det skal være så vanskelig å putte på en /> på alle elementer som ikke består av en slutt tagg den dagen man bestemmer seg får å lære/bruke XHTML.

Endret 17. august 2007 av JonT

[serverside]

webmasteren finner ut at det er mer korrekt å benytte application/xhtml+xml så han endrer webtjeneren til å sende (x)html dokumenter på denne måten. Dette er tøys! Ingen webmaster gjør dette, dessuten er det jo snakk om filer med samme filendelse som html-dokumenter ergo vil ingen webmaster konfigurere en mime-type til å sende disse feil.

 

Men for en vanlig person vil det fort føre til masse problemer som ikke er så enkle å løse.. Jeg ser faktisk ikke et eneste potensielt problem ved dette. ref avsnittet over.

 

Når man da ikke kan benytte noen av fordelene med XHTML, og ikke i noen fremtid kan konvertere til application/xhtml+xml.. Dette er jo faktisk et argument for å bruke XHTML. Det vil trolig gå den veien (det er en egendiskusjon) og da har man ting klart.

 

Spesielt unødvendig er det når vi vet at mange mobiler faktisk har større problemer med å lese XHTML skrevne sider, enn HTML. Dette er vel ikke helt riktig. Det er vel heller omvendt nettopp fordi mange mobile enheter bl.a. krever at alle alle tager avsluttes. (ja, jeg har laget en del mobile applikasjoner)

 

Ståle er et eksempel på en som ikke har fulgt anbefalingene fra w3.org. Han bruker XHTML 1.1 og sender som text/html. Det er feil

[Vindstille]

webmasteren finner ut at det er mer korrekt å benytte application/xhtml+xml så han endrer webtjeneren til å sende (x)html dokumenter på denne måten. Dette er tøys! Ingen webmaster gjør dette, dessuten er det jo snakk om filer med samme filendelse som html-dokumenter ergo vil ingen webmaster konfigurere en mime-type til å sende disse feil.

9304700[/snapback]

Mulig det var et dårlig eksempel. Men når XHTML sendt med text/html og application/xhtml+xml ikke er kompatibelt med hverandre, og de fleste brukere ikke har noen anelse om dette, sier det seg selv at dette kan kan føre til problemer når ting blir flyttet mellom forskjellig webserver. Det er selvfølgelig ikke et mega stort problem nå, men når IE får støtte for XHTML og application/xhtml+xml blir mer vanlig kommer det til å bli et større problem.

 

Når man da ikke kan benytte noen av fordelene med XHTML, og ikke i noen fremtid kan konvertere til application/xhtml+xml.. Dette er jo faktisk et argument for å bruke XHTML. Det vil trolig gå den veien (det er en egendiskusjon) og da har man ting klart.

9304700[/snapback]

Å Forklar.

Jeg ser ingen som helst fordeler med å bruke XHTML text/html.

 

Spesielt unødvendig er det når vi vet at mange mobiler faktisk har større problemer med å lese XHTML skrevne sider, enn HTML. Dette er vel ikke helt riktig. Det er vel heller omvendt nettopp fordi mange mobile enheter bl.a. krever at alle alle tager avsluttes. (ja, jeg har laget en del mobile applikasjoner)

9304700[/snapback]

Det er litt både óg. Har aldri testet ting på en stor flåte av mobiler så skal ikke si for mye om det. Men det er også et problem at flere nettlesere kun støtter html. Spesielt av den eldre genrasjon. (Husk at jeg snakker om bruk av HTML strict, ikke vanlige HTML vs. XHTML sider. XHTML sider har en tendens til å være litt mer valid uten at det har noe som helst med de to formatene å gjøre.)

 

Uansett forandrer ikke dette at det nærmest er null fordeler med å bruke XHTML text/html fremfor HTML.

 

Ståle er et eksempel på en som ikke har fulgt anbefalingene fra w3.org. Han bruker XHTML 1.1 og sender som text/html. Det er feil

9304700[/snapback]

Hva som er valid i forhold til spesifikasjonen og hva som er brukervennlig er to helt forskjellig ting. Selv om text/html står i XHTML-spesifikasjonen betyr ikke det nødvendigvis at den er spesielt smart å bruke den i stort omfang. Dessuten var XHTML-spesifikasjoen laget lenge før man kunne se konsikvensene av hva text/html førte med seg.

 

Har du foresten lest det Ian Hickson har skrevet? Ettersom han har hovedansvaret for (X)HTML5 spesifikasjonen burde han kunne det han snakker om.

 

A number of problems resulting from the use of the text/html MIME type

in conjunction with XHTML content are discussed. It is suggested that

XHTML delivered as text/html is broken and XHTML delivered as text/xml

is risky, so authors intending their work for public consumption

should stick to HTML 4.01, and authors who wish to use XHTML should

deliver their markup as application/xhtml+xml.

[serverside]

HTML er designet til å presentere data, mens XML er designet til å beskrive data. Kombinasjonen XHTML/CSS gjør at man kan skille 100% på data og presentasjon. HTML er et markup-språk med de fordeler og ulemper det medfører. Dette tror jeg vi er enige om.

 

Jeg har i går og i dag/natt ;-) lest en rekke artikler om dette emnet og det er svært delte meninger om temaet. Det koker ned til at man ikke ser noen helt klare fordeler med XHTML, men heller ingen helt klare ulemper i praksis pr. Og siden det er gyldig å sende XHTML som text/html så må man jo gjerne bruker det.

 

Ian Hickson har egentlig bare ett argument i det han skriver og det er det argumentet du også har brukt tidligere. Hva skjer den dagen man plutselig servererer dokumentene sine som application/xhtml+xml?. Det er virkelig ikke noe problem, for det vil ikke skje. Det er først i XHTML 2.0 at man vil kreve application/xhtml+xml og da skrur man ikke bare over alle dokumentene sine fra 1.x. Det er jo like lite sannsynlig som å plutselig servere HTML 4.01 som XHTML 2.0 med application/xhtml+xml. Fordi det er common knowledge at xhtml 1.0 i de aller fleste tilfeller bruker text/html mime-type.

 

Ian Hickson understreker faktisk noen fordeler med XHTML også!

 

Men det er en ting jeg er enig med deg i og det er at man skal være bevisst på hva man gjør og hvilke valg man gjør. Dersom man ikke aner hva doctype og mime-type er så bør man nok holde seg til HTML 4.01.

[Vindstille]

Men det er en ting jeg er enig med deg i og det er at man skal være bevisst på hva man gjør og hvilke valg man gjør. Dersom man ikke aner hva doctype og mime-type er så bør man nok holde seg til HTML 4.01.

9305875[/snapback]

Vel, da er vi omtrent enige.

Folk som kan det de driver med er i hvert fall ikke noe veldig stort problem for andre så lenge de ikke feilinformerer folk. Dessvere er det bare alt for få som virkelig kan problematikken rundt html og xhtml.

 

Men det du sier om at html er laget for å presentere date, ikke beskrive date blir veldig feil. XHTML 1.0 inneholder omtrent akkurat de samme elementene som HTML 4.01 og CSS funker på akkurat samme måte. Det er fullt mulig å skrive tabellsuppe i XHTML også.

 

Det Ian Hickson skriver om fordelen med XHTML gjelder for applicaton/xhtml+xml, så det har lite relevans i denne diskusjonen. Det er tross alt igjen som har påstott at XHTML ikke har fordeler når det blir tolket som XML. Det er bare når det blir servert som text/html det ikke gir noen fordeler. Ellers har både HTML og XHTML sine gode og dårlige sider, men fordelene til XHTML kan vi dessvere først ta ibruk når IE støtter det skikkelig.

 

Ian Hickson har foresten noen andre viktig argumenter du hoppet over. Vil spesielt trekke fram en ting og det har med dokumentlagring å gjøre. (Dog kan vel ikke dette problemet fikses, nå som det allerede har oppstått så til de grader. )

 

If a user saves such an text/html document to disk and later

  reopens it locally, triggering the content type sniffing code since

  filesystems typically do not include file type information, the

  document could be reopened as XML, potentially resulting in

  validation errors, parsing differences, or styling differences.

  (The same differences as if you start sending the file with an XML

  MIME type.)