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

[FrodeNilsen]

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?

 

Vi er grunnleggende uenige i hvordan man skal lære seg html og css, samt at vi er grunnleggende uenige i hva som er det filosofiske grunnlaget for disse språkene.

 

Jeg er en stor tilhenger av å primært sette seg inn i selve definisjonene, og bruke andre kilder som støtte litteratur på praktiske eksempler. Du vil finne at jeg refererer til w3c eller liknende, mens Haraldson med fler typisk refererer til løsninger de finner gjennom google.

 

En annen måte å formulere mitt standpunkt på er at det å kunne selve definisjonen er fremtidens kunnskap, mens alle mulige ad hoc løsninger som "fungerer" vil bli mer og mer bortkastet.

 

Haraldson skal ha at det han argumenterer for fungerer bedre for mindre prosjekter, og at mye av det han argumenterer for virker intuitivt. Han argumenterer for å bruke klasser aktivt, slik at når du leser kildekoden så er den intuitivt lettere å lese da klassenavne forteller hvilken rolle elementen har.

 

div.artikkel a.ekstern_lenke{bla bla bla}

div.forste_kolonne div.navigerings_meny li.aktiv_linke{bla bla bla}

sier mer enn

div.navigerings_meny li.aktiv_lenke{bla bla bla}

 

CSS koden virker tilsynelatende mer lettlest, men hvis du virkelig kan CSS så er ikke det nødvendigvis tilfellet.

 

Det jeg snakker om er på ett litt annet nivå.

 

Jeg skiller sylskarpt mellom layout og innhold. Det gjør ikke Haraldson. Han skiller ikke på layout elementer i html og innholds elementer i html. Det fører til at når jeg omtaler html og layout, så blir det helt feil, for ham.

 

Det finnes ikke elementer i html for å lage en layout. Jeg har argumentert og gitt eksempler på at man ved å benytte nøstende floats gir de samme elementene en helt annen rolle i ett layout enn ved å benytte tabeller til formatering. Jeg argumenterer derfor med at man burde ta følgen av dette, og beskrive layoutrollene i CSS, og ikke i HTML. Hvis man ikke forstår at formateringsrollen kan endres helt i CSS og defineres der, så høres alt jeg skriver ut som tull, noe jeg har en følelse har skjedd her.

 

Da er vi også fremme ved om man planlegger å benytte ett utall med stilark mot den samme html koden. Jeg gjør det, og jeg simpelthen kan ikke beskrive hvilken rolle ett html element ment for layout, eks. en div, har, da det kan ha totalt forskjellig rolle i forskjellige stilark. Jeg kan ikke beskrive dette enkelt i html.

 

Tabeller

 

Da Haraldson ikke liker trynet mitt, så hopper han på alle løsninger jeg kommer med som er anderledes. Jeg har forsøkt å gi ett eksempel på det å formatere som en tabell, noe jeg aldri hadde gjort før.

 

Jeg har begge beina plantet grunnsolid på ett fjell som heter html4.01 og CSS2.1, og har drevet Haraldson fra skanse til skanse i en annen tråd. Han begynte med at det ikke var noe som het tabeller i CSS, mens det nå er ettertrykkelig tibakevist. MS, Mozilla, Opera, og Apple mener at tabeller er ett godt virkelmiddel til formatering, i CSS. Det er bred enighet om at ACID2 testen og tankene bak den er i tråd med definisjonene.

 

Jeg er smertelig klar over at IE7 ikke støtter dette, derfor har jeg jo ett eksempel på nøstende floats også. Ved å være litt fremsynt, så lager man en div struktur som støtter begge deler. Da kan man lage ett enklere layout mot IE7 og IE6, mens man har full frihet mot alt annet. I mange tilfeller er akkurat tabell-formatering det som passer best, og man kan da, idag, benytte ett mer avansert stilark med mer avansert formatering mot de moderne nettleserne.

 

IE8 vil som sagt støtte tabell formatering.

 

Skille mellom formatering og innhold

 

Jeg argumenterer for ett ekstremt skarpt skille mellom formatering og innhold. Jeg skiller også mellom markup for innhold, og markup for layout. Jeg opplever nok at mange ikke er enige i at man skal skille så skarpt, men hvilket filosofisk grunnlag de har for dette er rimelig uklart.

 

Sosiale aspekter

 

Mange vil oppleve det jeg argumenterer for som en trussel. Problemet er at det faglige nivået er for lavt slik at de ikke henger med. Jeg fortår mange godt jeg. De har kanskje tatt en flerårig utdannelse, for så å få slengt etter seg at de ikke kan faget.

 

Løsningen er ikke å fortsette å bruke underlegne metoder, men neppe heller å ignorere at dette må oppleves som problematisk for mange.

 

Informasjonsstruktur

 

Jeg argumenterer for å definere stramme og gode informasjonsstrukturer som har varig verdi. Jeg tar ikke lett på å definere nye maler i tide og utide, da gode informasjonsstrukturer ikke trengs å endres. Jeg kommer til å publisere informasjon om dette tilsvarende en tykk bok eller to. Det blir neppe her på forumet.

 

Uten stram informasjonsstruktur faller det jeg snakker om i grus. En løs struktur på hva som er tillatt i en artikkel vil gi for mange mulige kombisnasjoner av element nøsting, slik at det blir praktisk talt umulig å formatere innholdet. Ett godt stilark dekker alle muligheter og alternativer, og hvis det er for mange alternativer så blir det helt enklet for mye jobb.

 

Hvis man har for løs informasjonstruktur vil også elementer kunne spille mange forskjellige roller, slik at det å formatere ett element ikke vil ha den tiltenkte effekten hvis friheten i informasjonsstrukturen er for stor.

 

Du kan definere at tekst som skal fremheves sterkt skal benytte strong-elementet. Du kan også tillate formatering av lenker, men ikke font-weight. Hvis en lenke skal fremheves sterkt kan du definere at den skal nøste under ett strong element. Du kan også forby at ett strong element nøster under ett a-element.

 

Du har da definert (rimelig mangelfult) at en sterk fremheving alltid gjøres med ett strong element, og det å endre formateringen til strong-elementet vil da endre hvordan en sterk fremheving formateres. Stong-elementet har da en skarpt definert semantisk betydning, og denne betydningen er oversatt til en passende og generell rolle under formatering.

 

Du kan nå med stor presisjon formatere innholdet, og du kan være sikker på at ved å formatere strong-elementet så formaterer du alt som skal fremheves sterkt. Dette kan du ikke hvis du tillater alle mulig typer nøstinger.

 

Avrunding

 

Nå er det sagt nok fra meg om dette temaet, og forkjølelsen begynner og slippe taket. Endelig.

 

Hvis det kommer noen gode innspill om språkene som korrigerer meg, så skal jeg forsøke å følge de opp. Nå gidder jeg ikke svare på mer svada.

 

Frode

[Haraldson]

Haraldson skal ha at det han argumenterer for fungerer bedre for mindre prosjekter, og at mye av det han argumenterer for virker intuitivt. Han argumenterer for å bruke klasser aktivt, slik at når du leser kildekoden så er den intuitivt lettere å lese da klassenavne forteller hvilken rolle elementen har.

Jeg har fortsatt til gode å få noen eksempler på disse store prosjektene du er involvert i. Samtidig kan du jo se i kundeporteføljen til Keyteq, og legge merke til de største firmaene – dette er kun noen av kundene jeg har jobbet med. Kom ikke her og si at det jeg skriver ikke fungerer på større prosjekter.

 

Jeg legger ikke skjul på hvilken erfaring jeg sitter inne med. Du derimot, er liksom han litt anonyme som de ikke vet hvor har, men som hiver ut den ene bastante påstanden etter den andre, uten at folk vet hvilket grunnlag du har for det. Ja, det går fint an å være webutvikler og ikke bry seg om webstandarder, men jeg legger i alle fall ikke skjul på at jeg har et relevant yrke og at det derfor finnes ørsmå muligheter for at jeg faktisk vet hva jeg snakker om.

 

Jeg skiller sylskarpt mellom layout og innhold. Det gjør ikke Haraldson. Han skiller ikke på layout elementer i html og innholds elementer i html. Det fører til at når jeg omtaler html og layout, så blir det helt feil, for ham.

Hvordan vet du at jeg ikke gjør det? Alle sidene jeg lager, er svart på hvit tekst med blå lenker med underline når CSS deaktiveres. Jeg bruker innholdselementene til å hekte på layout vha. CSS, og kun unntaksvis når innholdselementene i strukturen ikke strekker til for å oppnå ønsket utseende/effekt, legger jeg til elementer for å kunne nå mitt mål, fortsatt ved hjelp av CSS.

 

Hvis man ikke forstår at formateringsrollen kan endres helt i CSS og defineres der, så høres alt jeg skriver ut som tull, noe jeg har en følelse har skjedd her.

Et <p>-element i HTML vil alltid representere et avsnitt med tekst/bilder i teorien, samme hvordan det formateres med CSS. På samme måte vil alltid et <h*>-element representere en overskrift, samme hvordan dette formateres med CSS.

 

Da er vi også fremme ved om man planlegger å benytte ett utall med stilark mot den samme html koden. Jeg gjør det, og jeg simpelthen kan ikke beskrive hvilken rolle ett html element ment for layout, eks. en div, har, da det kan ha totalt forskjellig rolle i forskjellige stilark. Jeg kan ikke beskrive dette enkelt i html.

Dette høres dumt ut. Ja, dumt. Hvis du har, si et par diver, en overskrift og en bolk med tekst i HTML-en din, vil du kunne gi disse generiske klasser som passer til ethvert tilfelle. Det virker som om du har ett blått og ett lilla stilark, og at du ikke gir klassenavn, for da måtte du ha gitt klassenavn som '.purple-heading' til overskriften etc. Dersom du gir den ytterste diven et generisk klassenavn, det være seg .text eller .article eller hva du syns blir generisk nok, vil denne generiske klassen benyttes i alle dine (u/)spesifikke stilark, og alle elementer den inneholder vil ut fra den ytre klassen kunne identifiseres enkelt i det gitte eksempelet.

 

Jeg har begge beina plantet grunnsolid på ett fjell som heter html4.01 og CSS2.1, og har drevet Haraldson fra skanse til skanse i en annen tråd. Han begynte med at det ikke var noe som het tabeller i CSS, mens det nå er ettertrykkelig tibakevist. MS, Mozilla, Opera, og Apple mener at tabeller er ett godt virkelmiddel til formatering, i CSS. Det er bred enighet om at ACID2 testen og tankene bak den er i tråd med definisjonene.

Les argumentene mine som går på nettleseres som ikke støtter ekstern CSS, som tekstbaserte lesere, eller talebaserte nettlesere for mennesker med funksjonhemminger.

 

Dersom det er slik at du baserer deg helt og holdent på stilarket ditt når du definerer den glorifiserte strukturen i dokumentet ditt, ja – da hører vi jammen to ulike skoler til. Jeg bryr meg faktisk om de besøkende, de er grunnlaget for at nettstedet eksisterer i utgangspunktet. Ellers er det verdiløst. Et nettsted som diskriminerer ulike grupper i samfunnet, når dette kunne vært unngått med enkle grep, er ikke noe nettsted jeg ønsker å assossieres med. Dessverre går det ikke alltid an å levere dette til firmakunder, særlig fordi en må samarbeide med andre utviklere som har andre syn på ting eller ikke har tatt noe standpunkt fordi vedkommende ikke har noe grunnlag for det.

 

Jeg argumenterer for ett ekstremt skarpt skille mellom formatering og innhold. Jeg skiller også mellom markup for innhold, og markup for layout. Jeg opplever nok at mange ikke er enige i at man skal skille så skarpt, men hvilket filosofisk grunnlag de har for dette er rimelig uklart.

Dette slår kun tilbake på deg selv og det du måtte produsere, ref. forrige avsnitt.

 

Sosiale aspekter

 

Mange vil oppleve det jeg argumenterer for som en trussel. Problemet er at det faglige nivået er for lavt slik at de ikke henger med. Jeg fortår mange godt jeg. De har kanskje tatt en flerårig utdannelse, for så å få slengt etter seg at de ikke kan faget.

 

Løsningen er ikke å fortsette å bruke underlegne metoder, men neppe heller å ignorere at dette må oppleves som problematisk for mange.

Forklar meg heller hvorfor nettopp du er så sosialt overlegen.

 

Jeg argumenterer for å definere stramme og gode informasjonsstrukturer som har varig verdi. Jeg tar ikke lett på å definere nye maler i tide og utide, da gode informasjonsstrukturer ikke trengs å endres. Jeg kommer til å publisere informasjon om dette tilsvarende en tykk bok eller to. Det blir neppe her på forumet.

Fint, publiser heller en bok som kan støve ned på biblioteket. De fleste større nettsteder har for øvrig store krav, og innholdet varierer gjerne fra side til side, samtidig som alt følger samme designprinsipper så det blir en enhet og helhet i det hele. Dine generiske maler ville aldri kunne konkurrere med dette. Det er en grunn til at firmaer som tilbyr stor fleksibilitet og skalerbarhet i sine løsninger har store kunder i sin portefølje, mens firmaer som tilbyr fastlåste modulbaserte systemer kun har de mindre kundene som i mye mindre grad satser på sine nettløsninger.

 

Uten stram informasjonsstruktur faller det jeg snakker om i grus. En løs struktur på hva som er tillatt i en artikkel vil gi for mange mulige kombisnasjoner av element nøsting, slik at det blir praktisk talt umulig å formatere innholdet. Ett godt stilark dekker alle muligheter og alternativer, og hvis det er for mange alternativer så blir det helt enklet for mye jobb.

Prøv å si dette til et stort firma som 'skal ha, skal ha'. Da er du nødt til å fire på kravene dine. Femti hakk.

 

Du kan definere at tekst som skal fremheves sterkt skal benytte strong-elementet. Du kan også tillate formatering av lenker, men ikke font-weight. Hvis en lenke skal fremheves sterkt kan du definere at den skal nøste under ett strong element. Du kan også forby at ett strong element nøster under ett a-element.

 

Du har da definert (rimelig mangelfult) at en sterk fremheving alltid gjøres med ett strong element, og det å endre formateringen til strong-elementet vil da endre hvordan en sterk fremheving formateres. Stong-elementet har da en skarpt definert semantisk betydning, og denne betydningen er oversatt til en passende og generell rolle under formatering.

Dette varierer vitterlig fra side til side. Det er en vurderingssak. Kommer en fram til at lenker skal være fete fordi alle lenker er viktigere enn resten av teksten, vil dette gi utslag også i tekst- og talebaserte nettlesere. En kan like gjerne komme fram til at dette er et designmessig grep hvor en kun skal bruke CSS for å oppnå ønsket effekt, i dette tilfellet fet skrift. Verden er ikke svart-hvit.

 

Det gir for øvrig ikke mening at et anchor alltid må inneholde eller omsluttes av et strong-element, særlig ikke på større sider hvor brukeren selv redigerer store deler av teksten med for eksempel TinyMCE. En kan ikke instruere kunden om å alltid huske på å gjøre lenkene fete i editoren, ergo er det alltid lettest for både utvikleren og kunden å sette formateringen rett på anchor. Dette er også mest logisk.

 

Hvis det kommer noen gode innspill om språkene som korrigerer meg, så skal jeg forsøke å følge de opp. Nå gidder jeg ikke svare på mer svada.

Jeg får altså siste ord? Av en eller annen grunn tviler jeg... Endret 26. mai 2008 av Haraldson

[JohndoeMAKT]

Frode, kan du begynne å forklare din definisjon på ordene du bruker og holde bruken konsis? Du bruker så mange ord om hverandre at jeg får ingenting ut av teksten din.

 

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.

Hva er en formateringsrolle? Hva er innhold, hva er formatering?

 

Jeg har ikke lest noe motstridene fra meg eller Haraldson ( jeg regner med at jeg er "visse andre" som blir refererte til ) men mye av det motsatte. Om du vil vite hvorfor markup skal beskrive sine data er det bare å lære deg om XML og hvorfor det er en så populær standard.

 

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?

Dette viser hvor lite fremovertenkende og begrensende din metode er og hvor lite du legger vekt på dataenes betydning over formatering. Ditt system er intetsiende uten grafisk fremstillig og er dermed utilgjengelig for andre typer datalesing. Data som kun er representert av CSS er veldig lite fremtidsrettet og innholdorientert og jeg håper at den gammeldagse tankemåten forsvinner mer og mer etterhvert som utviklere blir bedre og bedre.

 

"Hva skal du med alle disse attributtene uten CSS?" CSS er for avansert grafisk visning av innholdet, men det finnes mange andre måter å lese data. Alt fra tekstlesere til datatolkende parsere til egne overlappende stylesheet. Et system hvor data er beskrevet i CSS er helt feil og veldig begrenset.

 

Jeg er en stor tilhenger av å primært sette seg inn i selve definisjonene, og bruke andre kilder som støtte litteratur på praktiske eksempler. Du vil finne at jeg refererer til w3c eller liknende, mens Haraldson med fler typisk refererer til løsninger de finner gjennom google.

 

En annen måte å formulere mitt standpunkt på er at det å kunne selve definisjonen er fremtidens kunnskap, mens alle mulige ad hoc løsninger som "fungerer" vil bli mer og mer bortkastet.

Beklager men dette er bare tull. Hvor er kildene til dine påstander og det å påstå at kilder fra google er dårlige er en unødvendig og billig diskusjonsteknikk.

 

Jeg skiller sylskarpt mellom layout og innhold. Det gjør ikke Haraldson. Han skiller ikke på layout elementer i html og innholds elementer i html. Det fører til at når jeg omtaler html og layout, så blir det helt feil, for ham.

Det at du blander bruken av samme ord hjelper også til med å gjøre at vi ikke får noe ut av teksten din.

 

Det finnes ikke elementer i html for å lage en layout. Jeg har argumentert og gitt eksempler på at man ved å benytte nøstende floats gir de samme elementene en helt annen rolle i ett layout enn ved å benytte tabeller til formatering.

Hvor er disse eksemplene? I tråden du linker til? Med mindre du ønsker å bli missforstått ber jeg deg om å også forklare hva du virkelig mener. Med definerte og entydige forklaringer relatert direkte til kode og ikke vage utsagn om hvordan du koder relevant til ditt livssyn.

 

Da er vi også fremme ved om man planlegger å benytte ett utall med stilark mot den samme html koden. Jeg gjør det, og jeg simpelthen kan ikke beskrive hvilken rolle ett html element ment for layout, eks. en div, har, da det kan ha totalt forskjellig rolle i forskjellige stilark. Jeg kan ikke beskrive dette enkelt i html.

Hadde du beskrevet data hadde formatering, hverken med dagens teknologi eller fremdens vært et problem.

 

Jeg argumenterer for ett ekstremt skarpt skille mellom formatering og innhold. Jeg skiller også mellom markup for innhold, og markup for layout. Jeg opplever nok at mange ikke er enige i at man skal skille så skarpt, men hvilket filosofisk grunnlag de har for dette er rimelig uklart.

Jeg har enda ikke forstått hvordan du gjør dette skillet, kan du skrive litt eksempelkode og forklare med klart definerte og entydige begreper?

 

Mange vil oppleve det jeg argumenterer for som en trussel. Problemet er at det faglige nivået er for lavt slik at de ikke henger med. Jeg fortår mange godt jeg. De har kanskje tatt en flerårig utdannelse, for så å få slengt etter seg at de ikke kan faget.

I første del har du helt rett. Et WWW uten selvbeskrivende markup ser jeg på som en stor trussel. Det vil begrense muligheter og binde data til spesialløsninger og høres ikke ut som en kjekk fremtid. Som sagt håper jeg bare at kompetansenivået på utviklere vil stige slik at vi ikke opplever dette.

 

Jeg argumenterer for å definere stramme og gode informasjonsstrukturer som har varig verdi. Jeg tar ikke lett på å definere nye maler i tide og utide, da gode informasjonsstrukturer ikke trengs å endres. Jeg kommer til å publisere informasjon om dette tilsvarende en tykk bok eller to. Det blir neppe her på forumet.

 

Uten stram informasjonsstruktur faller det jeg snakker om i grus. En løs struktur på hva som er tillatt i en artikkel vil gi for mange mulige kombisnasjoner av element nøsting, slik at det blir praktisk talt umulig å formatere innholdet. Ett godt stilark dekker alle muligheter og alternativer, og hvis det er for mange alternativer så blir det helt enklet for mye jobb.

Du argumenterer tydeligvis for å lage rigide og ubeskrevede strukturer hvor den eneste som kjenner nøkkelen til strukturen er utvikleren. Dette er sikkert greit nok for deg når du koder HTML selv og bare har ditt eget stilark å måtte relatere strukturen til, men som nevnt en del ganger nå er dette hva jeg vil beskrive som en bad practice. Hva er din struktur uten stilarket? Omtrent verdiløs.

 

Hvis man har for løs informasjonstruktur vil også elementer kunne spille mange forskjellige roller, slik at det å formatere ett element ikke vil ha den tiltenkte effekten hvis friheten i informasjonsstrukturen er for stor.

Her tenker du klart i en snever og kontemporær bane. Som sagt er det å bruke CSS til å beskrive innhold noe vi absolutt bør holde oss klar for.

 

 

Til slutt, kan du kode et eksempel slik at vi kan få mer innsikt i hva du virkelig mener?