Mulig å bestemme linkutseende (a:link...) for div-er?

[FrodeNilsen]

...

Men Frode, benytter du deg av JavaScript for DOM-modifisering? Da er det er stort behov for ID- og class-attributter. Jeg ser heller ikke grunnen din for å ikke ha klasse-attributter og slikt og IMO er din kode gal semantisk sett. HTML/XML er ikke for å contain/inneholde content/informasjon men for å beskrive content. En navnløs <ul> når informasjonen denne inneholder har en navngibar funksjon og den er eneste av sin sort er slik jeg ser det feil. Da skal den markeres opp som f.eks id="menu" og som Haraldson har nevnt er slike selectorer mye raskere. Jeg er for å beskrive content og å bruke ID der noe er unikt og class der det er flere like elementer.

...

 

Mye gode innvendinger her. Men jeg er ikke sikker på at jeg er helt enig med deg i alt.

 

For å kunne bruke klasse og ID attributter på innhold så må man definere dette når man definerer informasjonsstrukturen. Det blir fort ett krav med ett begrenset sett med klasser, men disse må være universelle for hele designet, og kan ikke være stykkevis delt.

 

Jeg er ikke imot å bruke klasse og ID, men å bruke det i utide. Hvis du har definert en struktur på informasjonen som tillater bruk av bestemte klasser, så kan du få problemer med akkurat disse klassene hvis de er for spesifikke. Hvis du definerer noe for spesifikt blir det ufleksibelt. Du risikerer også å sette mange klasser som i fremtiden ikke vil bli benyttet, eller som i fremtiden kommer i konflikt med andre ting, da de har en for spesifikk natur. Det er b-elementet ett knakende godt eksempel på.

 

For rent innhold som artikler eller en forumpost, så er det nærmest ett krav om at strukturen er mest mulig universel.

 

Hvis du lager en navigeringsmeny og den nøster i en div med klasse "navigeringsmeny", så er det ingen problemer å flytte denne menyen rundt på siden. Hvis du skriver css som jeg har forslått tidligere i denne tråden, så vil den flytte fortsatt gjelde. Hva er problemet med det?

 

Jeg forstår heller ikke hvor jeg har hentydet at html ikke gir innholdet struktur? Det er ikke helt korrekt å si at markup er mening, men det er riktig å si at markup gir innholdet struktur, og at denne strukturen har en mening.

 

Merk også at jeg skiller mellom layout og innhold. html har ingen spesifisering av layout. Jeg viser til to forslag hvordan man kan benytte nøstede floats og tabell-celler, de er ikke innholdsorientert i det hele tatt.

 

Hvis du plasserer en div i en av boksene i forlagene mine, og kaller den for "navigeringsmeny" men den klasse, så bør du forstå hvor jeg vil hen. Da står vi plutselig ikke så langt fra hverandre lenger. Den boksen har ingen semantisk betydning i html, og har ingen betydning for innholdet ifølge html. Den er der utelukkende for å forenkle lesningen av koden og forenkle vedlikehold.

 

Jeg har sagt det før, og jeg får vist gjenta det en gang til: Hvis man endrer stilark så vil man kunne endre helt formaterings-rollen ett layout-element har. Det er derfor ikke mulig å gi fornuftige klasse eller ID navn til alle layout elementer, og html er blind for layout-elementer. Layout-elementer har ingen "semantisk betydning" under html. Hvor står det hen? I hvilken definisjon har div eller span betydning? Hva ville skje hvis vi definerte en slik betydning?

 

CSS definerer layout roller, html definerer innhold. CSS definerer formateringen av innholdet, men CSS skal ikke endre innholdet eller innholde informasjon.

 

Frode

[Haraldson]

For å kunne bruke klasse og ID attributter på innhold så må man definere dette når man definerer informasjonsstrukturen. Det blir fort ett krav med ett begrenset sett med klasser, men disse må være universelle for hele designet, og kan ikke være stykkevis delt.

Det er nettopp det de kan. En klasse innunder én klasse kan være helt forskjellig under en annen, og det er ingen krav om dette universelle som du snakker om. Dessverre trenger en ikke å begrense seg til et 'sett' med klasser, en legger til de en trenger.

 

Jeg er ikke imot å bruke klasse og ID, men å bruke det i utide. Hvis du har definert en struktur på informasjonen som tillater bruk av bestemte klasser, så kan du få problemer med akkurat disse klassene hvis de er for spesifikke.

Eksempel, takk?

 

Hvis du definerer noe for spesifikt blir det ufleksibelt.

Nei. Det blir mer omfattende, men ufleksibelt blir det ikke. En kan definere en annen nesten lik struktur som gjør mye av det samme om den første ikke passer.

 

Du risikerer også å sette mange klasser som i fremtiden ikke vil bli benyttet, eller som i fremtiden kommer i konflikt med andre ting, da de har en for spesifikk natur. Det er b-elementet ett knakende godt eksempel på.

b-elementet er vel ikke noe godt eksempel på en klasse en kanskje aldri kommer til å bruke..?

Fint om du forklarer deg her. Det er for øvrig ingen ulempe å ha en klasse ekstra som en kanskje ikke i første omgang bruker. En slik klasse kan gi fleksibilitet neste gang en skal gjøre noe med den aktuelle koden, som å utvide eller endre utseende.

 

For rent innhold som artikler eller en forumpost, så er det nærmest ett krav om at strukturen er mest mulig universel.

Universell og universell. En kan lage flere maler for alt, som kan brukes i forskjellige tilfeller. Innenfor disse malene vil innhold hentes ut i det malverket en har definert, og en kan bruke så mange klasser og id-er en bare vil.

 

Hvis du lager en navigeringsmeny og den nøster i en div med klasse "navigeringsmeny", så er det ingen problemer å flytte denne menyen rundt på siden. Hvis du skriver css som jeg har forslått tidligere i denne tråden, så vil den flytte fortsatt gjelde. Hva er problemet med det?

Hvorfor skal du ha en div rundt denne ul-en? Regner med at det var et direkte svar på det JDM sa angående manipulering av DOM-en med JS. I så tilfelle er det fortsatt enklere og mer fleksibelt med f.eks. $('spesifikt-menypunkt') enn hva det ville ha blitt med din konsekvente kode; $$('spesifikt-menypunkt').getElementsByTagName('li')[2]; (tredje li-elementet i meny-ul-en). Hvis du skulle tviholde på din konsekvens, og samtidig bestemme deg for å endre rekkefølge på menypunktene, ville det medføre at du også måtte endre på javascriptet. Lite ønskelig.

 

Jeg forstår heller ikke hvor jeg har hentydet at html ikke gir innholdet struktur? Det er ikke helt korrekt å si at markup er mening, men det er riktig å si at markup gir innholdet struktur, og at denne strukturen har en mening.

Markup gir innholdet struktur, og det aller meste av elementer i markupen har også semantisk betydning. Hadde det ikke vært for sistnevnte, hadde jo HTML vært overflødig, og en kunne bruke rene .txt-filer. Nettleserne hadde ikke visst fram og bak på et HTML-dokument om elementene ikke hadde semantisk mening, det er jo nettopp dette som er HTML.

 

Hvis du plasserer en div i en av boksene i forlagene mine, og kaller den for "navigeringsmeny" men den klasse, så bør du forstå hvor jeg vil hen. Da står vi plutselig ikke så langt fra hverandre lenger. Den boksen har ingen semantisk betydning i html, og har ingen betydning for innholdet ifølge html. Den er der utelukkende for å forenkle lesningen av koden og forenkle vedlikehold.

Feil. Den er der for de tilfellene hvor det ikke er logisk å bruke et annet element, altså når det ikke finnes et element som er mer logisk å bruke enn div-elementet som i seg selv ikke har noen semantisk betydning.

 

Jeg har sagt det før, og jeg får vist gjenta det en gang til: Hvis man endrer stilark så vil man kunne endre helt formaterings-rollen ett layout-element har. Det er derfor ikke mulig å gi fornuftige klasse eller ID navn til alle layout elementer, og html er blind for layout-elementer. Layout-elementer har ingen "semantisk betydning" under html. Hvor står det hen? I hvilken definisjon har div eller span betydning? Hva ville skje hvis vi definerte en slik betydning?

Her kommer det jo alt for en dag. Ta en titt på CSS Zen Garden. Gammelt, men beskrivende prosjekt for noe du tydeligvis ikke helt har forstått. Poenget er å markere innhold med logiske elementer med tilhørende logiske klasse- eller id-attributter, og om en ønsker å endre den visuelle utformingen en har laget på et senere tidspunkt, er de samme klassene like logiske, fordi vi ikke bruker klassenavn som '.blue-date' eller '.fancy-animated-background'. Istedenfor brukes klassenavn som beskriver nettopp hva de inneholder. '.blue-date' fra eksempelet inneholder nok en dato, og det vil den fortsette med å gjøre i HTML-en selv om vi endrer CSS. Derfor kaller vi klassen for eksempel for '.published-date'. '.fancy-animated-background' i eksempelet var kanskje et blockquote-element med et animerende sitat-tegn oppe i høyre hjørne. Hadde det ikke vært for at vi kunne identifisere blockquote-elementet med en element-selektor, hadde vi nok navngitt klassenavnet for eksempel '.quote'. Dette er generiske klasser som passer uansett om du endrer aldri så mye på utseendet. Ønsker du å modifisere siden utover dette, må du uansett inn og redigere HTML-en.

 

CSS definerer layout roller, html definerer innhold. CSS definerer formateringen av innholdet, men CSS skal ikke endre innholdet eller innholde informasjon.

Tror jeg ikke noen har påstått i noen av trådene du har involvert deg, heller. Endret 25. mai 2008 av Haraldson

[FrodeNilsen]

Dette å sitere sånn som haraldson har gjort fortløpende nedover er ett velkent virkemiddel hvis man vil starte en regelrett krangel eller vil provosere.

 

Vi beveger oss nå inn ett terreng der vi diskuterer hvordan man skal strukturere CSS, og jeg har i bunn og grunn svart på hva jeg mener. Jeg ser at Haraldson sliter litt med å forså hva jeg mener med at man ved å være for spesifikk også forhindrer fleksibilitet, så det burde jeg kanskje utdype litt.

 

Jeg har nevnt b-elementet. Dette var ett element som ble brukt til å angi fet skrift. Hva betyr egentlig det? Det gir jo ingen mening til teksten! Det fradrådes å benytte dette elementet nå.

 

Problemet er at man har tillat bruken av det tidligere, da man ikke hadde CSS. Det ble brukt i så mange settinger at vi idag i praksis ikke kan forby bruken av det. b-elementet løste ett spesifikt formaterings problem i gamle dager, som i dag er i direkte konflikt med nåværende løsninger. De mer universelle elementene som p og h1 er mye mindre problematiske.

 

Rent filosofisk betyr dette ikke annet enn at spesifikke løsninger passer til færre og spesifikke settinger, enn mer generelle løsninger. Når setting endres er det vesentlig større sjanse for at de generelle løsningene passer og vil overleve, mens de spesifikke vil skape store problemer.

 

Jeg argumenterer for å flytte de spesifikke formaterings løsningene til CSS og holde innholds markup for for eks. artikler så generell som mulig. Da er det lettere å ta med seg innholdet til nye løsninger og settinger, uten at dette vil skape konflikter.

 

En annen ting er hvordan man skal lagre informasjon. Hvis man lagrer den som markup, så oppnår man større felksibilitet ved at denne informasjonen er minst mulig låst til en bestemt setting. Da har man størst frihet i fremtidige løsninger, og større frihet til å endre på den settingen man er i nå.

 

Jo mindre formaterings-elementer og formaterings-attributter man har, des klarere blir skillet mellom formatering og innhold. Man må ofte definere noen klasser for å kunne skille mellom roller ett markup element kan ha, slik at de kan formateres deretter. Hvis du først tillater slike klasser i innholdet ditt, så risikerer du å måtte støtte disse i all overskuelig fremtid, og de kan komme i konflikt med fremtidige løsninger.

 

Akkurat som vi må leve med b-elementet i html5.

 

Frode

[Haraldson]

Jeg siterer litt og litt for å kunne svare på de spesifikke utsagnene. Det var kanskje så konfronterende og treffende at det passet seg bedre å gå i forsvarsposisjon enn å argumentere for dine synspunkter.

 

Nå er ikke elementer som <b> veldig utbredt i nyere kode lenger, selv om enkelte ikke har fått med seg elementer som <strong> og <em>. Disse elementene sier noe om hva slags betydning teksten skal ha, heller enn å angi typografiske egenskaper for teksten (selv om dette kan overstyres eller nullstilles). Én ting som er dårlig med HTML5 er vel at <b> og <i> reintroduseres. Jeg anser det ikke som veldig relevant i forhold til klasser.

 

Når mener du at klasse- eller id-attributter ikke støttes lenger (du sier at man må forvente å støtte disse i all overskuelig framtid)? Slik utviklingen ser ut i dag, er det bare mer og mer DOM-scripting (altså HTML, CSS + JS), og JS har som nevnt et par ganger godt av noen håndtak i koden. Forventer at påstandene om at støtte for disse attributtene plutselig skulle opphøre, dokumenteres når noe slikt påstås. Hvordan kommer slike attributter i konflikt med framtidige løsninger?

 

Du sier for øvrig at det beste er å lagre innhold som markup. Der må jeg si meg dypt uenig. Det aller beste er utvilsomt å lagre innhold i databaser, slik at malverket enkelt kan oppdateres om en skal oppdatere sider mtp. markup.

[FrodeNilsen]

...

Du sier for øvrig at det beste er å lagre innhold som markup. Der må jeg si meg dypt uenig. Det aller beste er utvilsomt å lagre innhold i databaser, slik at malverket enkelt kan oppdateres om en skal oppdatere sider mtp. markup.

 

Jeg har vel ikke sagt at det er det beste men gitt ett en setting der man gjør akkurat det.

 

Det er særs mange som argumenterer for å lagre i markup. De argumenterer for å lagre i XML. Ofte i databaseform.

 

Hvis ikke innhold lagres i noe XML liknende, så må man stykke opp elementer, parametere, nøsting, og tekst. Man må definere hvordan dette skal gjøres.

 

For ordens skyld så benytter jeg begge metodene, da de forskjellige løsningene har sine styrker og svakheter, og jeg vil ha det beste fra begge verdner. Jeg får vesentlig større databaser med mye redundant informasjon, men det kan jeg leve med.

 

Frode

[JohndoeMAKT]

Dette å sitere sånn som haraldson har gjort fortløpende nedover er ett velkent virkemiddel hvis man vil starte en regelrett krangel eller vil provosere.

Det er også et bra virkemiddel om du vil svare direkte på en sak og jeg vil også benytte meg av det om det er greit.

 

Jeg ser at Haraldson sliter litt med å forså hva jeg mener ..

Det gjelder meg også. Du produserer veldig mye tekst uten at jeg greier å lese ut noe som helst håndfast. Det eneste håndfaste jeg har fått ut er av å lese ditt eksempel fra tråden du linket til. Ut fra den forsto jeg at du bruker HTML-strukturen i selectorer med minst mulig attributter som dette:

 

div div div ul.menu li a span span {}

 

Slik jeg ser det er dette veldig dårlig markup og resulterer i trege og avanserte selectorer.

 

Jeg argumenterer for å flytte de spesifikke formaterings løsningene til CSS og holde innholds markup for for eks. artikler så generell som mulig. Da er det lettere å ta med seg innholdet til nye løsninger og settinger, uten at dette vil skape konflikter.

 

En annen ting er hvordan man skal lagre informasjon. Hvis man lagrer den som markup, så oppnår man større felksibilitet ved at denne informasjonen er minst mulig låst til en bestemt setting. Da har man størst frihet i fremtidige løsninger, og større frihet til å endre på den settingen man er i nå.

 

Jo mindre formaterings-elementer og formaterings-attributter man har, des klarere blir skillet mellom formatering og innhold. Man må ofte definere noen klasser for å kunne skille mellom roller ett markup element kan ha, slik at de kan formateres deretter. Hvis du først tillater slike klasser i innholdet ditt, så risikerer du å måtte støtte disse i all overskuelig fremtid, og de kan komme i konflikt med fremtidige løsninger.

 

Jeg mener man skal vokte seg mot å lage for mange unødvendige klasser, særlig klasser man blander inn på innholdsnivå.

 

I det første eksemplet vil du egentlig ikke trenge en eneste klasse i fremtiden, litt mer i tvil om det er hensiktsmessig med eksempel nummer to.

 

Ved å holde bruken av klasser på ett minimum så vil slike design kunne benyttes med moderne fremtidig CSS3, og du vil ha mange års forsprang på resten av bransjen. Dette er en drøm å jobbe med.

 

For å kunne bruke klasse og ID attributter på innhold så må man definere dette når man definerer informasjonsstrukturen. Det blir fort ett krav med ett begrenset sett med klasser, men disse må være universelle for hele designet, og kan ikke være stykkevis delt.

 

Jeg er ikke imot å bruke klasse og ID, men å bruke det i utide. Hvis du har definert en struktur på informasjonen som tillater bruk av bestemte klasser, så kan du få problemer med akkurat disse klassene hvis de er for spesifikke. Hvis du definerer noe for spesifikt blir det ufleksibelt. Du risikerer også å sette mange klasser som i fremtiden ikke vil bli benyttet, eller som i fremtiden kommer i konflikt med andre ting, da de har en for spesifikk natur. Det er b-elementet ett knakende godt eksempel på.

 

For rent innhold som artikler eller en forumpost, så er det nærmest ett krav om at strukturen er mest mulig universel.

Her er en rekke sitater og jeg må si meg totalt uenig om jeg forstår deg rett. Markup skal være så spesifik og detaljert som mulig! En struktur bestående av DOM-elementer uten beskrivende attributter er i seg selv omtrent verdiløs. Data skal ikke beskrive seg selv men markup skal beskrive data. Sagt på en annen måte, du skal kunne fjerne all data i strukturen og ut fra attributtene kan du lese hvordan hele strukturen er lagt opp.

 

Jeg forstår heller ikke hvor jeg har hentydet at html ikke gir innholdet struktur? Det er ikke helt korrekt å si at markup er mening, men det er riktig å si at markup gir innholdet struktur, og at denne strukturen har en mening.

Det jeg nok mente var at du bruker selvsagt HTML til å lage en datastruktur for å holde dine data men så lenge du ikke beskriver strukturen med HTML er strukturen dårlig. Og markup er absolutt mening, det er faktisk der meningen ligger, hvordan du har beskrevet den med attributter.

 

Hvis du plasserer en div i en av boksene i forlagene mine, og kaller den for "navigeringsmeny" men den klasse, så bør du forstå hvor jeg vil hen. Da står vi plutselig ikke så langt fra hverandre lenger. Den boksen har ingen semantisk betydning i html, og har ingen betydning for innholdet ifølge html. Den er der utelukkende for å forenkle lesningen av koden og forenkle vedlikehold.

 

Jeg har sagt det før, og jeg får vist gjenta det en gang til: Hvis man endrer stilark så vil man kunne endre helt formaterings-rollen ett layout-element har. Det er derfor ikke mulig å gi fornuftige klasse eller ID navn til alle layout elementer, og html er blind for layout-elementer. Layout-elementer har ingen "semantisk betydning" under html. Hvor står det hen? I hvilken definisjon har div eller span betydning? Hva ville skje hvis vi definerte en slik betydning?

Om noe er et layoutelement eller ikke har ingenting å si. Det er data i et markupformat og da beskrives det ved semantisk korrekt bruk av forskjellige elementer og strukturbeskrivende attributter. Den semantiske betydningen jeg nevnte gjelder ikke data men markupen.

Endret 25. mai 2008 av JohndoeMAKT

[FrodeNilsen]

...

div div div ul.menu li a span span {}

 

Slik jeg ser det er dette veldig dårlig markup og resulterer i trege og avanserte selectorer.

...

 

Det er vist ett stykke igjen før dette er allfarvei og folk forstår dette gitt.

 

Skill mellom innhold og layout.

 

Lag en layout med div-elementer. Bruk tilstrekkelig med ID og klasse attributter slik at du kan formatere alle layout elementer.

 

I det div elementet du skal ha informasjon setter du inn en ekstra div, som du kan gi klassenavn eller en ID. Klassenavn vil tillate gjenbruk av formateringen, ID vil forby dette da en ID skal være unik i markup.

 

Innholdet plasseres i denne ekstra div-en.

 

Formater layout for seg. Les layoutstrukturen ut av CSS, ikke HTML, da dette er umulig fra HTML, da rollene defineres i CSS.

 

Benytt selectors med utgangs punkt i den ekstra div-en du satt inn i layout.

 

div.artikkel p {font-size: 12px;}

div.artikkel strong {font-weight: bold;}

osv.

 

Hvis koden skal kunne leses av IE 7 må du bruke arv og ikke barn combinator. Det begynner å bli ganske mye tåpelige klager på at jeg benytter arv og resetting av dette, men dette har altså med at jeg har kodet IE7 kompatibelt, og at kritikerene ikke har forstått dette.

 

Det kritiske er ikke hva du gjør i layout, men i innhold.

 

Denne teknikken gir ikke uendelige lange selectors. De starter ikke ved body. Blir de for lange er det noe galt med informasjonsstrukturen eller man trenger å identifisere en ekstra blokk.

 

For ordens skyld så finnes det ikke effektivitetsproblemer ved dette. Gjort riktig blir ikke dette tregt.

 

Dokumentasjon

 

Det er ingenting galt med å kommentere en kode. En kode blir ikke mer lettlest av at det benyttes klassenavn og id attributter som ikke stemmer med den rollen de får tildelt i CSS. Hvis du mister oversikten på hva du holder på med, så setter du jo inn kode så du får det, for eks. en ID.

 

Hvis du dokumenterer ting skikkelig, så er en kode jennomboret av klasser vesentlig mer tunglest enn en som har ett lavt men passe nivå med klasser.

 

Eksempler

 

Jeg får komme tilbake med kodeeksempler på ett senere tidspunkt. Hvis jeg setter opp noe som egner seg for publisering her, så skal jeg si ifra. Jeg ser ikke helt for meg at det jeg gjør i nær fremtid passer seg her, da jeg egentlig ikke har problemstillinger jeg jobber med i øyeblikket som er egnet her.

 

Den klargjøringen jeg har publisert her nå får holde.

 

Frode

[JohndoeMAKT]

Den klargjøringen jeg har publisert her nå får holde.

Beklager, jeg leser så mye motstridende eller tom tale at jeg helt har mistet tråden din.

[Haraldson]

Formater layout for seg. Les layoutstrukturen ut av CSS, ikke HTML, da dette er umulig fra HTML, da rollene defineres i CSS.

Nei. 'Rollene' defineres i HTML og formateres med CSS. Det er veldig grunnleggende.

 

Hvis koden skal kunne leses av IE 7 må du bruke arv og ikke barn combinator. Det begynner å bli ganske mye tåpelige klager på at jeg benytter arv og resetting av dette, men dette har altså med at jeg har kodet IE7 kompatibelt, og at kritikerene ikke har forstått dette.

Nå trengs det sjelden noen magic 2020-tricks for å få en side kompitabel med IE7.

 

Det er ingenting galt med å kommentere en kode. En kode blir ikke mer lettlest av at det benyttes klassenavn og id attributter som ikke stemmer med den rollen de får tildelt i CSS. Hvis du mister oversikten på hva du holder på med, så setter du jo inn kode så du får det, for eks. en ID.

Jo, den blir mer lettlest. Rollen tildeles i HTML, og CSS er bare et anheng til HTML-en. Du ser ut til å snu på flisa og si at HTML kun er et anheng til CSS. CSS er null verdt om det ikke finnes et HTML-dokument CSS-en kan manipulere.

 

Hvis du dokumenterer ting skikkelig, så er en kode jennomboret av klasser vesentlig mer tunglest enn en som har ett lavt men passe nivå med klasser.

Nei. Så lenge klassene har logiske og beskrivende navn for funksjonene, er det mye lettere å lese #article p#ingress enn det er å lese .article div div p.

[Anterialis]

Siden dere er så godt i gang med fingrene, og jeg ikke har forstått alt (noe?) av det dere skriver om, burde jeg bruke #article eller .article og for å hente dette i html bruker jeg hhv div id og div class? Hva er best? =)

[Haraldson]

Dersom det er en artikkel i detaljvisning er det ingenting i veien for å wrappe alt som har med artikkelen å gjøre med en ID; #article.

 

Artikler i listevisning kan hver få sin div med klasse; .article. Så kan du lage forskjellige wrapper-diver rundt listevisningene igjen som sier noe om hvordan .article-divene inni skal se ut, slik at du kan lage forskjellig utseende på listevisningene dine.

[FrodeNilsen]

Siden dere er så godt i gang med fingrene, og jeg ikke har forstått alt (noe?) av det dere skriver om, burde jeg bruke #article eller .article og for å hente dette i html bruker jeg hhv div id og div class? Hva er best? =)

 

Hvis du benytter ID, så vær klar over at du kan benytte en ID en gang i ett dokument.

 

Du kan lage en lenke til en ID, slik at nettleseren vil hoppe til ID elementet.

 

Hvis du benytter klasser, så kan du ikke lenke til disse. Du kan benytte samme klasse flere steder i samme dokument, så her kan du benytte gjenbruk.

 

Ett tredje alternativ er å benytte begge deler samtidig.

 

Mulige designvalg

 

Hvis det skal være mulig å lenke til innholdet slik at nettleseren hopper til innholdet, då må du benytte ID.

 

Hvis du skal gjenbruke formateringen på flere elementer, så vil det være naturlig å formatere med klasser. Alternativt må du bruke flere selectorer slik jeg har gjort i mine eksempler.

 

Roller

 

Hvor har dere det fra at formaterings roller skal defineres i html? Hvorfor blander dere innhold og formatering, og hvor har dere det fra at slikt ikke skal skilles? Jeg mistet tråden litt underveis. Det er så mye motstridene i det dere sier, så jeg mister helt tråden. Markup skal vist være så detaljert som mulig, en påstand helt uten dokumentasjon. Eksempler please, med en faglig forklaring.

 

Tar hintet?

 

Frode

[Haraldson]

Roller defineres i HTML, rett og slett fordi HTML kan stå på egne bein, noe CSS ikke kan. Det er du som knytter disse rollene direkte opp mot formatering alene. CSS skal bare brukes for å formatere innholdet og layouten, mens informasjonen i HTML-dokumentet kan vises (og bør fungere) for seg selv, selv uten CSS tilknyttet.

 

Det er for øvrig naturlig at en artikkel i detaljvisning får ID og ikke klasse. Nettopp fordi denne artikkelen i detaljvisning er unik på hele siden, og det skader ikke å gjøre dette tydelig i koden, hverken i HTML eller CSS. Videre vil det ikke ha noe å si om du har laget malen med ID-er her og der, da denne malen bare skal vises én gang i hele dokumentet.

 

 

En må for øvrig ikke benytte ID-er for å internlenke i et dokument, det kan være det passer like bra å bruke anchors med name-attributter, uten at dette trenger å være den beste metoden i de fleste tilfeller.

[FrodeNilsen]

Roller defineres i HTML, rett og slett fordi HTML kan stå på egne bein, noe CSS ikke kan. Det er du som knytter disse rollene direkte opp mot formatering alene. CSS skal bare brukes for å formatere innholdet og layouten, mens informasjonen i HTML-dokumentet kan vises (og bør fungere) for seg selv, selv uten CSS tilknyttet.

 

Det er for øvrig naturlig at en artikkel i detaljvisning får ID og ikke klasse. Nettopp fordi denne artikkelen i detaljvisning er unik på hele siden, og det skader ikke å gjøre dette tydelig i koden, hverken i HTML eller CSS. Videre vil det ikke ha noe å si om du har laget malen med ID-er her og der, da denne malen bare skal vises én gang i hele dokumentet.

 

 

En må for øvrig ikke benytte ID-er for å internlenke i et dokument, det kan være det passer like bra å bruke anchors med name-attributter, uten at dette trenger å være den beste metoden i de fleste tilfeller.

 

Du tok ikke hintet.

 

Informasjonen vil være leslig uten eget stilark. Informasjon. Nå er det en illusjon å tro at det ikke benyttes ett standard nettleser stilark når ett spesifikt stilark mangler. Selv ren tekst nettlesere må formatere innholdet, og alle moderne grafiske nettlesere er uløslig knyttet til CSS. Kan du dokumentere noe annet?

 

Layout forsvinner med CSS, gjør det ikke? Jeg bare spørr. Hva skal du med alle disse attributtene uten CSS? Kan du dokumentere at de ikke er der i formateringsøyemed?

 

Det er snart på tide at du viser til dokumentasjon som argumenterer for å formatere i html. Hvor i all verden omtaler html4.01 hvordan du lager en layout slik du mener?

 

Hvem er det som er selutnevnt profet?

 

Frode

[Anterialis]

Det virker som dere er litt uenige, men for min del er det kanskje greiest, da får jeg to forskjellige svar og begrunnelser for ett problem. Da forstår jeg kanskje mer. Unntaket er jo hvis en av dere tar feil :s Men det har jeg ingen grunn til å tro. Hva er dere egentlig uenige om? Er dere enige i hva dere er uenige om?

[Lokaltog]

Haha, jeg støtter meg til w3p. Jeg klør meg litt i hodet når jeg leser noen innlegg her (f.eks. det siste innlegget fra FrodeNilsen), jeg forstår ikke hvilken sammenheng det har med diskusjonen. Hvor kom standard-stilark i grafiske nettlesere fra, og hva har det med strukturen på innholdet å gjøre?

 

Kan man ikke gjøre det så enkelt som å si at struktur defineres i HTML, og utseende defineres i CSS?

 

Når det gjelder innholdsformatering, så er jo HTML på ingen måte avhengig av CSS slik jeg ser det. Ved å angi en struktur ved å bruke elementer som h* og p forteller man enhver klient som skal tolke dokumentet hvilken betydning akkurat det elementet har (iht. W3s spesifikasjoner). Jeg kan lage en tekstbasert klient som presenterer innholdet på en hvilken som helst måte, uten å knytte meg til CSS.

[Anterialis]

Altså jeg er ikke veldig flink til slik koding, men vil lære. Hva er egentlig forskjellen på å bruker h eller p om man definerer disse helt likt i css-fila? Altså, lik farge, font ol. Hva blir forskjellen? Og hva er forskjellen på å bruke p som står alene, eller p med klasse? =)

[Lokaltog]

Altså jeg er ikke veldig flink til slik koding, men vil lære. Hva er egentlig forskjellen på å bruker h eller p om man definerer disse helt likt i css-fila? Altså, lik farge, font ol. Hva blir forskjellen? Og hva er forskjellen på å bruke p som står alene, eller p med klasse? =)

Forskjellen er rett og slett betydningen av elementene, og det er det HTML definerer. h1 definerer en stor overskrift, p definerer et avsnitt. Selv om disse elementene styles likt i CSS-fila, så har det en forskjellig semantisk betydning.

 

Det mest klassiske eksemplet på dette er table-elementet, hvis betydning er en tabell av typen togtabell. Når dette elementet brukes for å definere en layout, så brukes det feil. På samme måte blir det feil hvis du bruker p (avsnitt) for å definere en overskrift.

[Haraldson]

Et h*-element sier noe om at innholdet er en overskrift. * forteller om overskriftens nivå og implisitte viktighet. Dersom det samme utseendet oppnås med CSS og et p-element, vil ikke søkemotorer, talebaserte nettlesere etc. presentere informasjonen på nettstedet riktig. Søkemotorer er også veldig avhengig av forskjellige overskrifter for å indeksere en side eller et helt nettsted på en best mulig måte.

 

Så det som ser fint ut for oss uten funksjonshemminger, vil bli et brukervennlighetshelvete for en med.

 

 

Siden Frode trakk inn standardstiler i nettlesere, kan vi jo også ta det poenget kjapt, og koble det til en annen ting han brenner for - nemlig å simulere tabeller med andre elementer og CSS;

Er det logisk å sette opp en avansert layout i listeform, når denne rendres som nettopp en liste når CSS skrus av? Er det logisk at talebaserte nettlesere leser opp layouten som en liste, istedenfor at dette løses med elementer som ikke har semantisk verdi (slik at talebaserte nettlesere heller ikke bryr seg om de omsluttende, strukturelle elementene)?

 

Jeg vil si at den framtidsrettede og geniale kodekonvensjonen din, Frode, diskriminerer brukere med andre forutsetninger enn deg selv. Det er det som skjer når du tar utgangspunkt i formateringen og CSS-en, istedenfor HTML-dokumentet som er det som gjelder, for brukerne og for søkemotorene.

Endret 26. mai 2008 av Haraldson

[Anterialis]

Åja, dette har jeg ikke vært ordentlig klar over før :s Jeg har nesten aldri brukt h tagger, men p tagger :s Dette er good news Takk for det.