Bøker om HTML og CSS søkes. Noen anbefalinger?

[Memetro]

Hei.

Jeg lurer på om det finnes noen gode bøker der ute som omhandler HTML og CSS? Noen erfaringer?

Det finnes jo veldig mye bra på nettet da, det gjør det. Men jeg kunne tenkt meg en bok også...

[Vindstille]

HTMLdog

Har ikke lest den selv. Men nettstedet er i hvert fall det suvurent beste på verdensveven, og det de fleste av oss, som har lang fartstid her på forumet, anbefaler.

Endret 21. mai 2008 av JonT

[FrodeNilsen]

Jeg har ikke funnet god og riktig litteratur, da det jeg har kommet over er for "dummies" aktig og enten upresist eller direkte villedende.

 

Det er mer enn nok mat i definisjonene, og det står veldig lite i bøkene som ikke står mer spissformulert i definisjonene. Bøker er typisk fulle av hacks, men jeg ikke funnet en eneste bok som lærer meg hvorfor språkene er utformet slik de er og hvordan du kan benytte språkene sånn de er tiltenkt.

 

Hvis du trenger ett tips, så må det bli å skrive ut to lister i tabellform og definisjonsfila for strict.dtd:

http://www.w3.org/TR/CSS21/propidx.html

http://www.w3.org/TR/html401/index/elements.html

http://www.w3.org/TR/html401/sgml/dtd.html

 

For å få kontroll over attributter, så er oppskriften enkel: Ikke bruk dem. Hold attributter på ett absolutt minimum. Da slipper du å måtte lære deg alt på nytt igjen om noen få år, noe mesteparten av bransjen er i ferd med å innse. Bruk rollovers og selectors. Jobb med å strukturere CSS koden din.

 

html4.01 attributter finner du her:

http://www.w3.org/TR/html401/index/attributes.html

Haken her er at det er altfor mange attributter og at for få brukere har fokus på strict.dtd. Hvis du ikke har lyst til å lære ting på nytt om flere år, så hold deg til strict.dtd. Det er praktisk talt umulig å forstå html uten å forstå html4.01 sin strict.dtd og hvorfor vi har forkastet transitional.

 

html5

http://www.w3.org/html/wg/html5/

Dette er ett dokument i utvikling, men dette er ett kompromiss dokument. Mange elementer fra transitional er tatt med for at html4.01 sider skal være leslige, men å benytte disse elementene er fremdeles ikke anbefalt. De færreste har fått med seg hva som skjer med attributtene, de slaktes bort så langt det er mulig.

 

Det ligger veldig mye "hvorfor" i html5, og det kommer til å bli sagt veldig mye rart av de som ikke har fått med seg hovedpoengene når denne deffen overtar. html5 er enklere enn html4.01, så lærer du deg html4.01 i tråd med tankene bak html5, så slipper du å gjøre alt to ganger.

 

Det er også det som er ønsket. Formatering og innhold skal skilles. Benytt så lite formaterings attributter som overhode mulig. Da er det ikke mange som trengs lenger.

 

CSS2.1 vil være standarden en stund fremover, og denne er ikke fult ut implementer av for eks. Opera 9.27 (eks :first-child/:last-child). Det har liten verdi å pugge css1.0 da dette er totalt avleggs. Behersker du css2.1 så holder det med en rask titt på css1.0 så forstår du hva som støttes og ikke.

 

Problemet med mange bøker er at de lærer deg å hacke eller fikse mot dagens nettlesere, men de forklarer ikke hva som er riktig kode og hvorfor, slik at disse hackene ikke har det dugg av verdi under neste nettleserversjon. Nesten helt borkastet tid, da mange av disse hackene unngår man ved å beherske "hvorfor" skikkelig.

 

Problemet er når du har ett hav med utviklere som har investert masse resurser i ett arbeid som forkastes. De er "eksperter" idag med høy status, men de må gjennom en ekstrem forvandling for å tilpasse det som kommer og stritter imot med alt de har. Det gir dessverre utslag i ufinheter på dette forumet også.

 

CSS3 selectors er en revolusjon for bransjen, og vil innføre ett syskarpt skille mellom innhold og formatering. Det krever informasjonsstruktur, men den kommer, og da er det ingen vei tilbake lenger.

 

Jeg la ut noen kodeforslag til ett av de mest misforståtte css problemene her:

https://www.diskusjon.no/index.php?showtopi...;#entry11104219

Ikke perfekte eksempler, men de bør gi deg ett hint om hvor vi skal hen.

 

Ved å beherske noe er det lettere å forstå hvorfor ting går galt og håndtere det fornuftig. Alternativt kan du slukke branner hele livet uten å forstå hvorfor det begynner å brenne.

 

Frode

[Memetro]

Tusen hjertelig takk for informasjonen Frode

Nyttig!! Takk!!

[Haraldson]

Problemet er når du har ett hav med utviklere som har investert masse resurser i ett arbeid som forkastes. De er "eksperter" idag med høy status, men de må gjennom en ekstrem forvandling for å tilpasse det som kommer og stritter imot med alt de har. Det gir dessverre utslag i ufinheter på dette forumet også.

 

(...)

 

Jeg la ut noen kodeforslag til ett av de mest misforståtte css problemene her:

https://www.diskusjon.no/index.php?showtopi...;#entry11104219

Ikke perfekte eksempler, men de bør gi deg ett hint om hvor vi skal hen.

Jeg vet jeg har vært ufin mot deg, det vil si - jeg sier meg uenig med det du forkynner som en selvutnevnt profet, og du anser det som ufinheter. Du snakker om ekstreme forvandlinger, men dette har vi allerede vært gjennom. Det var for eksempel det som skjedde da tabeller brukt for layout ble kasta på dør, eller når alle IR-teknikkene kom på banen. Det var da utviklerne måtte kvitte seg med de inngrodde vanene og lære seg en helt ny tankegang (som for øvrig ikke var så ny, men den måtte gjenfinnes på grunn av dårlig implementasjon av standardene i nettleserne) - nemlig å skille innhold og formatering.

 

Dette i sin tur har ingenting med å kutte ut å bruke class- eller id-attributtene. Det har ingenting med eksempelet du til enhver tid refererer til. Koden vil aldri bli så generisk som du vil ha den til å være. Ja, vi får nye tagger i HTML5, men dette begrenser seg til noen få, som <header> etc.

 

Ja, du vil nok kunne identifisere for eksempel annen hver direkte barn av .outer-diven din i eksempelet (bare diver her) en gang i fremtiden, spørsmålet er om det er så voldsomt framtidsrettet og nytenkende og fantastisk å ha masse diver i HTML-en bare for å få nok å jobbe med i CSS-DOM-en. Semantisk blir det ikke. Da bruker en heller de elementene som (i spesifikasjonen) er ment til det aktuelle formålet.

 

Eksempelet ditt har ikke så voldsomt mye med den den andre tråden hvor eksempelet befinner seg å gjøre, da elementene for så vidt var ferdig nøstet. Det at du ikke er klar over at slike problemer óg kan løses ved å flyte de ytre beholder-elementene som inneholder flytende elementer, for eksempel, men refererer til CSS som ikke støttes av dagens mest brukte nettleser, er heller ikke særlig betryggende. Framtida er én ting, nåtida er en annen. Her må vi forholde oss til allslags møkkanettlesere, og det er alltid den svakeste nettleseren i gjengen som setter begrensningene, om en vil nå ut til et så bredt publikum som mulig.

 

 

Det vil aldri bli semantisk å bruke diver uten en id- eller en class-attributt. <div>-taggen har ingen semantisk verdi i seg selv, derfor bør den brukes kun når det ikke finnes andre elementer som passer. Man kan tilføre noe av denne semantiske verdien igjen ved å beskrive funksjonen diven har, nettopp med en av de to nevnte attributtene. Det kan virke som at det er de samme attributtene du kaller 'formaterings-attributter'. Det er de ikke, de sier noe om hva et element er og hvilken funksjon det har, men blander seg aldri inn i innholdet på noen måte. Dessuten blir det mye lettere å finne igjen tilhørende CSS, eller elementer i f.eks. JS, om de har fått tildelt 'håndtak' i form av id- eller class-attributter.

 

 

 

Det kan virke som at du er så priveligert at du holder på med bittesmå sider som bare har litt innhold på hver side og lite eller ingen variasjon fra side til side, siden du mener nettopp det du mener.

 

 

 

CSS3 vil ha lite å si i forhold til å skille innhold og formatering i forhold til dagens best practices.

 

Kanskje hvis du i din framferd her på forumet kunne vise skikkelige eksempler når du kommer med dine bastante 2020-løsninger (du som jo vet akkurat 'hvor vi skal hen'), så kunne vi andre overbevises om det virkelig er noe i det du sier. Og kodeeksempler i

-tagger vil aldri være nok, smell sammen eksempelsider som du laster opp.

Endret 25. mai 2008 av Haraldson

[FrodeNilsen]

...

Jeg vet jeg har vært ufin mot deg, det vil si - jeg sier meg uenig med det du forkynner som en selvutnevnt profet, og du anser det som ufinheter. Du snakker om ekstreme forvandlinger, men dette har vi allerede vært gjennom. Det var for eksempel det som skjedde da tabeller brukt for layout ble kasta på dør, eller når alle IR-teknikkene kom på banen. Det var da utviklerne måtte kvitte seg med de inngrodde vanene og lære seg en helt ny tankegang (som for øvrig ikke var så ny, men den måtte gjenfinnes på grunn av dårlig implementasjon av standardene i nettleserne) - nemlig å skille innhold og formatering.

...

 

Jeg er ingen selvutnevnt profet. Jeg er praktisk talt alene om å stadig hendvise til spesifikkasjonene på dette forumet, men det burde i ett godt faglig miljø ikke tolkes som at jeg har utnevnt meg til en profet.

 

De som skal lære seg å programere med html i dag får beksjed om at tabeller er fy-fy til layout. De er fy-fy hvis man benytter tabeller i html til layout, da tabeller har semantisk betydning og at man skal definere layout i CSS.

 

Tabeller i CSS er noe helt annet. Da benytter man formaterings egenskapene til en tabell til layout, og det er i mange tilfeller det som er formateringsmessig korrekt. Det var jo gode grunner til at layoutformatering var så utbredt. CSS støtten kommer med IE8, noe Haraldson jo har fått poengtert før. Ikke så "eksotisk" som han fremstiller det akkurat.

 

Jeg har forsøkt å gjøre ett poeng ut av dette å spesialisere seg mot en nettleser, og dette innlegget til Haraldson illustrer nettop akkurat dette. Du kan benytte en hacket form for html og css, eller du kan lære deg den korrekte metoden til å lage colonner med lik høyde på elementene, og lage en tilpasset versjon mot IE6 og IE7. De tilpassede versjonene har ingen verdi lenger med IE8. Da er det mye greiere å gjøre ting slik de er ment å gjøres, og kunnskapen om IE6 og IE7 hacking har ingen fremtidig verdi.

 

Jeg orker ikke å forvandle også denne tråden til en tråd der Haraldson og jeg skal krangle om hvem som har rett. Det vil drepe alle diskusjoner vi er med i.

 

Hvis noen mener jeg argumenterer for noe som er strid med html eller CSS så si gjerne ifra. Da bør dere vise til en definisjon eller liknende som strider mot det jeg sier. Slike innspill vil bli tatt imot med stor takknemlighet fra min side. Hvis du synes noe høres rart ut, men ikke er noen reser på en spesifikasjon, så skal jeg forsøke å svare så fornuftig jeg kan.

 

Jeg på min side skal forsøke å fortsette å hendvise til spesifikasjonene når jeg ser at noen trenger hjelp eller tar litt feil. Jeg får jo bare håpe at de det gjelder også er takknemlige for det.

 

Frode

[Haraldson]

Jeg er ingen selvutnevnt profet. Jeg er praktisk talt alene om å stadig hendvise til spesifikkasjonene på dette forumet, men det burde i ett godt faglig miljø ikke tolkes som at jeg har utnevnt meg til en profet.

Misforstå meg rett. Spesifikasjoner er ofte fint, ikke nødvendigvis for de aller ferskeste innenfor feltet, men likefullt OK. Jeg snakker om disse fantastiske teknikkene du hele tiden snakker om.

 

De som skal lære seg å programere med html i dag får beksjed om at tabeller er fy-fy til layout. De er fy-fy hvis man benytter tabeller i html til layout, da tabeller har semantisk betydning og at man skal definere layout i CSS.

Det er ingenting som heter 'tabeller i CSS'.

 

Tabeller i CSS er noe helt annet. Da benytter man formaterings egenskapene til en tabell til layout, og det er i mange tilfeller det som er formateringsmessig korrekt. Det var jo gode grunner til at layoutformatering var så utbredt. CSS støtten kommer med IE8, noe Haraldson jo har fått poengtert før. Ikke så "eksotisk" som han fremstiller det akkurat.

Formateringsmessig korrekt? Så fordi det ligger to eller flere bokser, det være seg diver eller andre elementer, ved siden av hverandre, og dette mønsteret går igjen nedover, så er det en 'tabell'? Nuvel. Eksotisk er forresten ditt ord, og hvis jeg skal fortsette å bruke det, må det være 'eksotisk' i den form at en majoritet av verdens nettbrukere fortsatt surfer med IE8-2.

 

Jeg har forsøkt å gjøre ett poeng ut av dette å spesialisere seg mot en nettleser, og dette innlegget til Haraldson illustrer nettop akkurat dette. Du kan benytte en hacket form for html og css, eller du kan lære deg den korrekte metoden til å lage colonner med lik høyde på elementene, og lage en tilpasset versjon mot IE6 og IE7. De tilpassede versjonene har ingen verdi lenger med IE8. Da er det mye greiere å gjøre ting slik de er ment å gjøres, og kunnskapen om IE6 og IE7 hacking har ingen fremtidig verdi.

Det er din metode som er tilpasset nyere nettlesere. Det jeg foreslo er noe som fungerer nå, og som vil fungere også lenge i framtida. Det er heller ingenting som tilsier at det er en fordel at de to elementene som utseendemessig skal ha lik høyde, faktisk må være like høye. Det er ikke logisk at et element skal være 1000px høyt når innholdet i elementet bare er 600px høyt.

 

Hvis noen mener jeg argumenterer for noe som er strid med html eller CSS så si gjerne ifra. Da bør dere vise til en definisjon eller liknende som strider mot det jeg sier. Slike innspill vil bli tatt imot med stor takknemlighet fra min side. Hvis du synes noe høres rart ut, men ikke er noen reser på en spesifikasjon, så skal jeg forsøke å svare så fornuftig jeg kan.

Det du skriver strider ikke mot noen spesifikasjoner, da spesifikasjonene ikke sier noen ting om 'best practices'.

[FrodeNilsen]

Tabeller og CSS2.1:

 

http://www.w3.org/TR/CSS21/tables.html

 

Det står da utførlig her om hvordan man formaterer etter en tabell modell?

 

Best Practices

 

http://www.w3.org/html/wg/html5/#the-b

 

The b element should be used as a last resort when no other element is more appropriate. In particular, headers should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

 

Det stappa fullt av slik veiledning i praktisk talt alle w3c spesifikasjoner. Bruk heller tid på lese slik veiledning enn å lese kjedelige krangler mellom meg og Haraldson.

 

Frode

[Haraldson]

Tabeller og CSS2.1:

http://www.w3.org/TR/CSS21/tables.html

Det står da utførlig her om hvordan man formaterer etter en tabell modell?

Ja, men selfvfølgelig med tabellelementer som <table>, <thead>, <tbody>, <tfoot>, <th>, <td>, <caption> og kanskje flere. Det er aldri snakk om å simulere tabeller med CSS og divs.

 

Best Practices

http://www.w3.org/html/wg/html5/#the-b

 

The b element should be used as a last resort when no other element is more appropriate. In particular, headers should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

Jeg forstod det som at vi snakket om teknikker, ikke på elementnivå. W3 gir ofte råd om hvilke elementer som bør brukes og hvilke som ikke bør, men hele teknikker, eller flere alternative teknikker, gjengis sjelden etter hva jeg har fått med meg.

[FrodeNilsen]

Tabell formatering av ikke tabell elementer

 

User agents may ignore these 'display' property values for HTML table elements, since HTML tables may be rendered using other algorithms intended for backwards compatible rendering. However, this is not meant to discourage the use of 'display: table' on other, non-table elements in HTML.

 

http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes

 

For de som er interessert i å lese spesifikasjonen fremfor å kverrulere om den, så går det krystallklart frem at det under CSS2.1 er definert to visuelle metoder å oppnå en tabell formatering.

 

Dette er i høyeste grad ment for elementer som ikke er tabell elementer under html4.01. De som mener noe annet får dokumentere det.

 

Frode

[Haraldson]

Document languages other than HTML may not contain all the elements in the CSS 2.1 table model. In these cases, the "missing" elements must be assumed in order for the table model to work.

Hvis det er på det grunnlaget du gjør din entré i diskusjonene i dette delforumet, bør du kanskje vurdere å finne en annen kategori, eller i det minste påpeke dette?

 

For HTML bruker man de eksisterende, fungerende og lovlige tabell-elementene.

[FrodeNilsen]

Document languages other than HTML may not contain all the elements in the CSS 2.1 table model. In these cases, the "missing" elements must be assumed in order for the table model to work.

Hvis det er på det grunnlaget du gjør din entré i diskusjonene i dette delforumet, bør du kanskje vurdere å finne en annen kategori, eller i det minste påpeke dette?

 

For HTML bruker man de eksisterende, fungerende og lovlige tabell-elementene.

 

Sånn går det når man diskuterer med en brukermoderator. Triste greier.

 

Det står ikke her at dette ikke gjelder html4.01. Det er en feiltolkning. Det som står er at den visuelle formaterings modellen etterlikner html4.01, og at anonyme elementer vil bli opprettet som om de gjøres under html4.01, selv om slike elementer ikke finnes i det språket man jobber mot, eks. xml. Det står ikke at dette ikke gjelder html4.01, men er en presisering av man kan benytte dette mot xml også. Dette kan komme litt uheldig ut, da de kan feiltolkes slik Haraldson gjør. Det er jo en fordel å lese hele teksten.

 

Det står klart og tydelig at man ikke fraråder bruk av denne modellen på andre elementer enn tabell elementer, noe jeg har allerede sitert, og det står at modellen er bassert på html4.01 sin tabell formatering.

 

Du vil se at 17.4 ikke gir noe mening hvis dette ikke gjelder html4.01, samt at man i 17.5 tydelig informerer om at dette punktet ikke gjelder for html4.01. Faktisk knekker deffen hvis det ikke opprettes annonyme elementer.

 

http://www.w3.org/TR/CSS21/tables.html#table-layout

 

De som fremdeles ikke tror meg får ta en titt på kildekoden til ACID2 testen. Der må annonyme elementer opprettes for å passere testen. Under html4.01.

 

Haraldson får informere dem at de har lest CSS2.1 spekken feil.

 

Frode

Endret 25. mai 2008 av FrodeNilsen

[Haraldson]

Sånn går det når man diskuterer med en brukermoderator. Triste greier.

Sånn er det å diskutere som moderator, med én gang en bruker konfronteres er det ulv ulv.

 

----

 

Det står ikke her at dette ikke gjelder html4.01. Det er en feiltolkning. Det som står er at den visuelle formaterings modellen etterlikner html4.01, og at anonyme elementer vil bli opprettet som om de gjøres under html4.01, selv om slike elementer ikke finnes i det språket man jobber mot, eks. xml. Det står ikke at dette ikke gjelder html4.01, men er en presisering av man kan benytte dette mot xml også. Dette kan komme litt uheldig ut, da de kan feiltolkes slik Haraldson gjør. Det er jo en fordel å lese hele teksten.

Frode, det står svart på hvitt, jeg gidder ikke gjengi sitatet igjen. Jeg har ikke sett ett eneste eksempel fra deg hvor du har sagt noe om at du jobber mot XML. Dessuten ville det vel da gagne deg om du brukte XHTML som eksempel istedenfor HTML 4.01?

 

Det står klart og tydelig at man ikke fraråder bruk av denne modellen på andre elementer enn tabell elementer, noe jeg har allerede sitert, og det står at modellen er bassert på html4.01 sin tabell formatering.

Samtidig vet jeg at samme W3 anbefaler å bruke elementene i (X)HTML til det de er ment for, så fraværet av en frarådning er ikke det samme som en anbefaling.

 

Du vil se at 17.4 ikke gir noe mening hvis dette ikke gjelder html4.01, samt at man i 17.5 tydelig informerer om at dette punktet ikke gjelder for html4.01. Faktisk knekker deffen hvis det ikke opprettes annonyme elementer.

Hele spesifikasjonen du henviser til baserer seg på tabell-elementer, det er ikke snakk om andre elementer på hele siden, annet enn inni tabellceller. Det 'anonyme' elementet du henviser til, er boksen <table>-elementet i seg selv skaper, ved at den må omslutte all annen tabell-informasjon.

 

De som fremdeles ikke tror meg får ta en titt på kildekoden til ACID2 testen. Der må annonyme elementer opprettes for å passere testen. Under html4.01.

Nå består jo ACID2 av mye rar kode, noe er feil for å se hvordan nettleseren takler feil kode, noe er avansert for å se hvor mye ny teknologi en nettleser støtter, og noe er riktig for å se om nettleseren også tolker det riktig.

 

Haraldson får informere dem at de har lest CSS2.1 spekken feil.

Han ser ut til å være urokkelig i sin overbevisning.

[FrodeNilsen]

På`n igjen!

 

CSS tables — There is nothing wrong with table layouts. It is a powerful layout model which makes sense on bigger screens. However, the table markup is troublesome as it ties the content to these screens. Therefore, being able to specify table layouts in CSS is important.

 

Og en forklaring på hva de mener er riktig tolkning av css.

 

http://www.webstandards.org/action/acid2/guide/?#row-14

 

Dette er en test på bruk som de mener er ønskelig og i tråd med definisjonen, og ikke en test på avviksbehandling som Haraldson insinuerer.

 

Til alle dere andre

 

Jeg får vel også prøve å skrive litt om dette så vanlige dødlige får noe ut av all denne kranglinga.

 

Html har alltid vært sterk på innholdsformatering, men ikke på layout. Smarte hjerner fant ut at man kunne benytte en tabell til layout ved å benytte html til å tegne denne tabellen.

 

Fordelene med tabell layout er at den er særs intuitiv, svakheten er at den fort genererer komplisert kode. Problemet med at man benyttet html til å lage tabellen førte til at man knakk html strukturen for innhold, ved at benyttet en struktur som var beregnet til tabulær informasjon, som en tog tabell, til å formatere en side.

 

Kompleksiteten til koden tvang tilslutt utviklerne over til andre layout teknikker. Problemet er at de ikke forstod den semantiske årsaken til at dette skjedde opp mot den som omhandlet det å formatere som en tabell.

 

De færreste skiller mellom det å formatere som en tabell og det å lage en tabell struktur. Det ene er en visuell fremstilling, det andre er det å strukturere innholdet i en tabell. I det siste tilfellet har informasjonen typisk en bestemt relasjon, noe som ofte kalles for en relasjons tabell. Meningen er også at blinde skal kunne lese tabellen og forstå relasjonene i den.

 

Overgangen fra tabell til div bassert layout var tung og slitsom for bransjen, og er faktisk enda ikke fullført. Det virker som om tabell formatering har fått ett frynsete rykte og image, da man automatisk tenker på html tabeller.

 

CSS formatering av tabeller er enkelt, men man må forstå dette med annonyme elementer. Layout med CSS tabeller er like enkelt, om ikke enklere enn layout med floats, margin, og clear. Det er også mer elegant enn absolute positioning.

 

Sist men ikke minst, det er vesentlig mer intuitivt.

 

Det beste er å benytte denne formen for formatering på div-elementer, da de ikke har noen strukturell mening. Husk at formateringen ikke skal inneholde informasjon eller endre informasjon: Du kan godt benytte formatering som endrer utseende til elementer, så lenge det ikke endrer innholdet.

 

Haraldson har poengtert at elementer skal benyttes slik de er ment. Med det mener w3c i tråd med definisjonen, ikke at det er forbudt å formatere ut av boksen.

 

Gjør deg selv en tjeneste å skill mellom innhold og layout. Layout settes i CSS, innhold i HTML.

 

Beklager at jeg nå har gjentatt mye det samme budskapet flere ganger i denne tråden, men denne kranglen med Haraldson begrunner egentlig bare det jeg har sagt hele tiden.

 

Frode

[Sono Juventino]

Seriøst, FrodeNilsen. All logikk tilsier jo at Haraldson har rett. Hva er i det hele tatt poenget med å skulle gjøre det vanskeligere å lage nettsider? Hvis W3.org ønsker at flere skal gå for å lage nettsider på den riktige måten, så er dette neppe et skritt i riktig retning.

 

Ting må fungere i praksis også. Ingen gidder å sitte og lese på spesifikasjoner i timesvis når det finnes fine og semantiske elementer i html som kan benyttes, bortsett fra nørds som deg. Herregud.....

[Kim T]

Jeg synes en slik diskusjon er matnyttig å lese. Vil si at dette fort fører over til en diskusjon og vinneren er den som har flest supportere. I dette tilfellet vil jeg tro det er Haraldson. Men det må da ikke være tvil om at begge 2 har stor kunnskap om det de prater om. Jeg vil sammenligne denne diskusjonen med 2 professorer som diskutere samme emne. Blir omtrent samme diskusjonen. De er i bunn og grunn enige men alikevel høres det ut som de er veldig uenige.

 

Sunn og saklig diskusjon er aldri kjedelig.

 

Kim...

[FrodeNilsen]

Seriøst, FrodeNilsen. All logikk tilsier jo at Haraldson har rett. Hva er i det hele tatt poenget med å skulle gjøre det vanskeligere å lage nettsider? Hvis W3.org ønsker at flere skal gå for å lage nettsider på den riktige måten, så er dette neppe et skritt i riktig retning.

 

Ting må fungere i praksis også. Ingen gidder å sitte og lese på spesifikasjoner i timesvis når det finnes fine og semantiske elementer i html som kan benyttes, bortsett fra nørds som deg. Herregud.....

 

Jeg forventer at fagfolk kan sitt fag. Hvis du kan html så må du kjenne og forstå språket. Da må du ha lest definisjonene grundig og forstå dem.

 

Beklager, men det å angripe noe for usaklighet for å kunne html og argumentere i tråd med språket blir bare for dumt. Det sier mye mer om angriper enn den som angripes.

 

Styrken til den arbeidsformen jeg argumenterer for er at den er den mest effektive å jobbe på. Den er soleklart lettest å jobbe med, mest oversiktelig, og mest fremtidsrettet. Den krever at man kan sitt fag og ikke er en tullete synser.

 

Hvem kan argumentere for at miljøet her ikke sloss mot de endringene som må komme? Bare se på denne tråden. Det er akkurat det som skjer når man må fortelle noen at de arbeider på feil måte og at store deler av kunnskapene deres ikke har fremtidig verdi. Mange føler seg sikkert også tråkket på da de blir fortalt at de mangler grunnleggende kunnskaper, særlig de som er vandt til å holde høy status på dette feltet.

 

Da er vi jo tilbake til mitt opprinnelige innlegg i denne tråden, som forsterkes for hvert innlegg.

 

Frode

[Gjest Slettet+9018234]

Memetro: Støtter meg back HTMLdog boken. Anbefaler også CSS Mastery, denne er litt for de viderekommende dog.

 

Forøvrig kan dere ta diskusjoner på PM og ikke forurense tråden til trådstarter.

Endret 27. mai 2008 av Slettet+9018234

[Sideri]

Har fått med meg at "For dummies" serien er gankse hjelpsom. De skal være gankse enkle å følge har jeg hørt.

 

HTML for dummies

 

CSS for dummies

[Vindstille]

Har fått med meg at "For dummies" serien er gankse hjelpsom. De skal være gankse enkle å følge har jeg hørt.

 

HTML for dummies

 

CSS for dummies

Når det gjelder Webutvikling finnes det så mange dårlige bøker at å velge en bok uten å spørre en noen som har greie på det, er uaktuelt.

 

Jeg har ikke sett på bøkene. Men fra et generelt standpunkt er de antagelig dårlige.

Endret 27. mai 2008 av JonT