to div-tagger ved siden av hverandre

Frigg33 · 27. mai 2008

hvordan kan jeg få to div tager ved siden av hverandre som visst på bildet?

OlafG · 27. mai 2008

Sånn du mener, i så fall så kan du få til det med denne koden:

<div id="container">
<div id="boks_venstre">
   	<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer molestie mauris sed augue. Duis rhoncus. Proin malesuada consequat nisi. Ut mi. Etiam lacinia. Aliquam augue. Donec et neque. Integer pharetra mi ac nunc. Quisque nec pede. Sed in arcu vel dolor consectetuer vehicula. Phasellus tempor neque quis diam. Integer tellus. Nulla ligula. Nullam at pede. Sed viverra. Sed massa quam, sollicitudin rhoncus, placerat at, congue nec, risus. Ut scelerisque, ligula id tincidunt euismod, metus ante rhoncus nulla, sit amet eleifend ipsum purus non erat.</p>
   </div>

   <div id="boks_hoyre">
   	<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer molestie mauris sed augue. Duis rhoncus. Proin malesuada consequat nisi. Ut mi. Etiam lacinia. Aliquam augue. Donec et neque. Integer pharetra mi ac nunc. Quisque nec pede. Sed in arcu vel dolor consectetuer vehicula. Phasellus tempor neque quis diam. Integer tellus. Nulla ligula. Nullam at pede. Sed viverra. Sed massa quam, sollicitudin rhoncus, placerat at, congue nec, risus. Ut scelerisque, ligula id tincidunt euismod, metus ante rhoncus nulla, sit amet eleifend ipsum purus non erat.</p>
   </div>

</div>

[size=6][font="Courier New"]CSS: [/font][/size]

body {
background: #ed1b24;
font-family:Arial, Helvetica, sans-serif;
}

div#container {
width: 750px;
margin: 0 auto;
margin-top: 80px;
}

div#boks_venstre {
float: left;
width: 300px;
height: 100%;
background: #FFFFFF;
border: 2px solid #000000;
padding-left: 20px;
padding-right: 20px;
}

div#boks_hoyre {
float: right;
width: 300px;
height: 100%;
background: #FFFFFF;
border: 2px solid #000000;
padding-left: 20px;
padding-right: 20px;
}

RulleRimfrost · 27. mai 2008

Enkelt så settes div-venstre med float:left og width:50%, div-høyre float:right og width:50%.

Den nederste kan du da sette til width:100% og clear:both (det skal bety at den ikke får noen elementer på siden, og legger seg under disse)

Selv bruker jeg skjelden % på width, da det av og til bryter i noen browsere...

Frigg33 · 27. mai 2008

Tusen takk for svar.. Akkurat hva jeg trengte

FrodeNilsen · 27. mai 2008

Du kan også benytte nøstende floats. Det blir fort mye lettere å jobbe med.

Klikk for å se/fjerne spoilerteksten nedenfor

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
  <title>
	 Lag tabell med nøstede flytende elementer
  </title>
  <style type="text/css">

	/****
	Float
	* ***/

	   div.outer,
	div.outer div
	{
	float:left;
	}

	div.outer div div div
	{
	float: none;
	}

	/*****
	Margin
	******/

	*
	{
	margin:0;
	}

	div.outer div div
	{
	margin-left:5px;
	margin-right:5px;
	}		

	/******
	Padding
	*******/

	div,
	div.outer div div
	{
	padding:10px;
	}

	div.outer div
	{
	padding-left:5px;
	padding-right:5px;
	}		

	/****
	Width
	*****/

	div.outer
	{
	width:500px;
	}

	div.outer div
	{
	width:490px;
	}

	div.outer div.odd1 div,
	div.outer div.even1 div
	{
	width: 460px;
	}

	div.outer div.odd2 div,
	div.outer div.even2 div
	{
	width: 215px;
	}

	div.outer div.odd3 div,
	div.outer div.even3 div
	{
	width: 133px;
	}

	div.outer div.odd2 div div,
	div.outer div.even2 div div,
	div.outer div div div
	{
	width: auto;
	}

	/***************
	Background-color
	****************/

	div.outer
	{
	background-color:#ff0;
	}

	div.outer div.even1,
	div.outer div.even2,
	div.outer div.even3
	{
	background-color:#faf;
	}

	div.outer div.odd1,
	div.outer div.odd2,
	div.outer div.odd3
	{
	background-color:#afa;
	}

	div.outer div div
	{
	background-color:#aaf;
	}

</style>
  </head>
  <body>
<div class="outer">
	<div class="odd2">
		<div>
			Dette er en ett eksempel på hvordan man kan benytte nøstede flytende
			elementer for å lage en tabell liknende struktur.
		</div>
		<div>
			Eksemplet er testet mot opera og IE7.  Det benyttes fast bredde som er
			oppgitt i px, noe som vil fungere rimelig stabilt med de fleste 
			nettlesere.  Det går ann å lage fungerende oppsett med bredde i %,
			men det er ikke planke å få disse til å fungere med Opera, langt
			mindre med IE7.
		</div>
	</div>
	<div class="even1">
		<div>
			Det benyttes ingen form for hacks i koden.  Ingen.  Det eneste som er
			tvilsomt er om det er smart å nøste altfor dypt.  Eksemplet nøster i
			tre nivåer, og om dette er bruk i tråd med w3c og industrien er litt
			uklart.
		</div>
	</div>
	<div class="odd2">
		<div>
			Det er ikke behov for å tenke kolonner da hver rad lever sitt eget liv.
			Tenk heller stilark og klasser, se kode.	
		</div>
		<div>
			Med det oppsettet jeg har satt opp trengs det ingen vanskelige
			matte formularer, det enkleste er egentlig bare å prøve seg
			frem med i trinn på for eksempel 5 som jeg har gjort.  Husk at
			du av og til må dele på 3, og da kan det fort gå litt surr.
		</div>
	</div>
	<div class="even1">
		<div>
			Hvordan noen kan kalle denne type kode for tungvindt eller omtale den 
			som semantisk korrupt er helt utenfor min fatteevne.  Det er snart
			bare IE som trenger odd/even klassene, noe som betyr at dette kan
			kan gjøres med kun en klasse og enda enklere css for moderne nettlesere.
		</div>
	</div>
	<div class="odd3">
		<div>
			De lekreste fargene er valgt kun for deg!	
		</div>
		<div>
			Som du ser så får ikke "kolonnene" i en rad lik høyde. height:100%;
			hjelper ikke en skit.
		</div>
		<div>
			Du kan simmulere fullhøyde kolonner ved å legge ett bakgrunnsbilde 
			i rad elementet og repetere bildet nedover.  Bakgrunnsbildet kan da
			tegne opp kolonne og vil skalere i henhold til det høyeste elementet
			 I raden.
		</div>
	</div>
	<div class="even1">
		<div>
			IE7 klarer ikke å gi cellene marg i bunn, så eksemplet benytter padding
			istedenfor.  Mulig det er flere bugs mot IE6 eller IE7, noe som ikke vil slå
			ned som noen bombe.
		</div>
	</div>
</div>	
  </body>
</html>
<!--SPOILER DIV--></div><!--SPOILER DIV-->

Arve Systad · 27. mai 2008

Tør eg spørre deg kvifor du deler opp stilarket etter kva eigenskapar som er i bruk? Det medfører jo berre vanvittig mykje ekstra kode, og sidan du alltid må vete kva element det gjeld når du skal feilsøke er det jo heller ikkje lettare å navigere i under utvikling. I tillegg ser det rotete ut :S

FrodeNilsen · 28. mai 2008

Tør eg spørre deg kvifor du deler opp stilarket etter kva eigenskapar som er i bruk? Det medfører jo berre vanvittig mykje ekstra kode, og sidan du alltid må vete kva element det gjeld når du skal feilsøke er det jo heller ikkje lettare å navigere i under utvikling. I tillegg ser det rotete ut :S

Godt spørsmål

Jeg sorterer etter egenskaper da det gir meg bedre oversikt over hvordan egenskapene er implementert. Hvis du vil finne ut hvorfor ett element har fått så mye marg, så er det bare å se ett sted da all marg er samlet på ett sted.

Hvis man samler etter egenskap så må man lete gjennom alle elementer som kan påvirke det elementet du leter etter. Dette gjelder særlig da jeg benytter kompliserte selectors: Egenskapene er simpelthen ikke samlet i en selector og vil typisk sjelden være det.

I det eksempelet jeg har gitt i denne tråden så er det svært enkelt å se hvordan jeg har benyttet floats. Det er svært enkelt å lese ut hvordan jeg har benyttet bakgrunnsfarge. Hvis noen ikke forstod koden og hva den gjør, så spørr i vei.

Det er ikke like lett å lese ut alle egenskapene til ett bestemt element, dessverre. Dette er også en svakhet ved og en følge av bruk av kompliserte selectors.

CSS struktur

Sikker mange som er unige med meg her, men det vil tvinge seg frem strukturerings metoder av CSS. Avanserte selectors og bruk av disse, samt støtte for mange media, gir fort så stor kompleksitet i CSS at det må defineres noen kjøreregler eller metoder for å løse dette.

Frode

Lokaltog · 28. mai 2008

Hvorfor i alle verdens land og dager vil noen lage en tabell med div-elementer og en drøss med rotete CSS? Siden når måtte man gå vekk fra table-elementet for å lage en tabell? Det finnes en drøss av andre måter man kan lage en god CSS-basert layout på enn dette. Koden din gir ingen mening, og det blir for dumt å oppfordre uerfarne utviklere til å følge slike eksempler.

Aller mest lurer jeg på hvorfor du ønsker å simulere en tabell med divs for å lage en layout. Det er minst like ille å konstruere en layout på den måten du illustrerer her som å bruke tabeller for å bygge opp layouten på siden din. Layouten din er heller ikke særlig fleksibel, hvis du skal endre bredden på siden må man regne ut bredden på 6 elementer på nytt for at ting skal se riktig ut.

Det ser heller ikke ut til at du har særlig kontroll over elementene i layoutforslaget du postet her. Har lagt ved et screenshot fra Firebug, som illustrerer bredden på de nøstede elementene (som flyter utenfor parent-div-ene). Nice. :thumbup:

Arve Systad · 28. mai 2008

Jeg sorterer etter egenskaper da det gir meg bedre oversikt over hvordan egenskapene er implementert. Hvis du vil finne ut hvorfor ett element har fått så mye marg, så er det bare å se ett sted da all marg er samlet på ett sted.

Hvis man samler etter egenskap så må man lete gjennom alle elementer som kan påvirke det elementet du leter etter. Dette gjelder særlig da jeg benytter kompliserte selectors: Egenskapene er simpelthen ikke samlet i en selector og vil typisk sjelden være det.

Men du må uansett finne fram til det elementet som "er feil", og det må du finne ut av ved å sjå på sida. Med din struktur må du først finne eigenskap-gruppa, og deretter elementet. Ser ikkje heilt korleis det skal hjelpe på lesbarheten, though. Ting som ligg nærme kvarandre eller har mykje med kvarandre å gjere på sida ligg vanligvis ganske tett i stilarket òg, uansett.

CSS struktur

Sikker mange som er unige med meg her, men det vil tvinge seg frem strukturerings metoder av CSS. Avanserte selectors og bruk av disse, samt støtte for mange media, gir fort så stor kompleksitet i CSS at det må defineres noen kjøreregler eller metoder for å løse dette.

Enig i at der bør vere ein struktur i stilarket, men personlig klarar eg ikkje heilt sjå fordelane med din struktur. For meg så minkar den iallefall lesbarheten betraktelig.

Haraldson · 28. mai 2008

For meg også.

Det er en rekke grep en kan ta for å strukturere stilark, det var også oppe noen lenker til artikler om dette for ikke veldig lenge siden.

- Holde antall like selektorer til et minimum, bruke indenting kreativt (både for selektorer i forhold til sine egenskaper og verdier, men óg hele slike blokker seg imellom, at et hakk dypere ned i nivåene markeres med at hele blokken indenteres innunder hakket over, osv.)

- Gruppere blokker i CSS slik elementer er gruppert i HTML, og benytte kommentarer til å beskrive hva CSS under hører til

- Elementer som er dypest ned i strukturen legges også nederst i CSS, relativt til sin blokk med elementer

Også videre. Det er et vell av små ting en kan gjøre for å gjøre stilark bedre, metoden til Frode er ikke en av dem.

Endret 28. mai 2008 av Haraldson

FrodeNilsen · 28. mai 2008

Hvorfor i alle verdens land og dager vil noen lage en tabell med div-elementer og en drøss med rotete CSS? Siden når måtte man gå vekk fra table-elementet for å lage en tabell? Det finnes en drøss av andre måter man kan lage en god CSS-basert layout på enn dette. Koden din gir ingen mening, og det blir for dumt å oppfordre uerfarne utviklere til å følge slike eksempler.

Aller mest lurer jeg på hvorfor du ønsker å simulere en tabell med divs for å lage en layout. Det er minst like ille å konstruere en layout på den måten du illustrerer her som å bruke tabeller for å bygge opp layouten på siden din. Layouten din er heller ikke særlig fleksibel, hvis du skal endre bredden på siden må man regne ut bredden på 6 elementer på nytt for at ting skal se riktig ut.

Det ser heller ikke ut til at du har særlig kontroll over elementene i layoutforslaget du postet her. Har lagt ved et screenshot fra Firebug, som illustrerer bredden på de nøstede elementene (som flyter utenfor parent-div-ene). Nice.

Firebug

Jeg benytter ikke dette verktøyet til daglig, så jeg kjenner det ikke så godt. Hvis du mener noe er galt, klarer du å finne ut hva?

Den visningen du får med Firebug gir ingen mening. Det virker nesten som det er ett bugg når man benytter padding, da bredde og marg går fint, men ikke padding. FF formaterer padding som forventet, så det er bare Firebug som blir corny når det benyttes padding. Nå hører det til historien at jeg har benyttet padding, da IE7 viser marg feil.

Jeg er ukjent med at man ikke kan benytte padding på floats eller nøstende floats. Noen som vet noe om dette, eller er dette en Firebug bug? Det siste virker mest trolig, da selv det første elementet blir feil.

Siden ser ut som den skal i FF, Opera og IE7. På min maskin i alle fall. Hvis du mener jeg har gjort noe galt i koden hadde jeg satt veldig pris på en konkret tilbakemelding på hva som er feil.

Hvorfor

Hvorfor er det så stor motstand mot å formatere som en tabell?

En format struktur med rekker og kolonner blir fort en tabell. Jeg snakker her om å formatere som en tabell, ikke innhold strukturert i en tabell. Det er to vilt forskjellige ting. Dere ser skillet?

Det å formatere etter rekker og kolonner er ofte det som er mest intuitivt, og mange design er avhengige av lik høyde på alle boksene i en rad. Da er tabell formatering det korrekte designvalget.

IE6 og IE7 støtter ikke tabell formatering i CSS, så dette eksemplet er ment som en alternativ teknikk til dette. Det går også tydelig frem av teksten i eksemplet. Det å kritisere denne metoden for kompleks bredde regning er helt greit det. Hvis du har problemer så er det jo bare å benytte display:table-cell. Containing floats blir ikke det dugg enklere når det kommer til matte.

Frode

Lokaltog · 29. mai 2008

Har lagt ved et kjapt forslag til en alternativ metode for å bygge opp en slik layout, uten bruk av nøstede div-elementer og mye uoversiktlig CSS nedenfor.

css.html

Kim T · 29. mai 2008

Faen så mye peiling og kunnskaper dere har da!

FrodeNilsen · 29. mai 2008

Har lagt ved et kjapt forslag til en alternativ metode for å bygge opp en slik layout, uten bruk av nøstede div-elementer og mye uoversiktlig CSS nedenfor.

Du har ikke svart på noen av spørsmålene jeg har stilt deg. Hvorfor det?

Body er i ditt eksempel containing element, slik at du ikke trenger "wrap". "wrap" elementet ditt spiller kun rollen som vomfyll, og er ikke noe containing element. Det pakker ikke inn noe som helst, så det er helt legitimt å argumentere for at rollenavnet er feil.

Hvis du hadde formatert det til ett containing element, så ville det ikke vært legetimt å argumentere slik, for da hadde dette elementet spilt en helt annen rolle. Hvis. Hvor definerer man en slik rolle?

Du har også ett hack i koden din. Dette dreier seg om å få "wrap" elementet ditt til å skalere i henhold til sitt innhold. Det er slikt du aldri behøver med nøstende floats. Du burde ha bein i nesen til å forklare at dette er ett hack, og hvorfor det må benyttes. Hvorfor bruker du det her, når det ikke trengs? Du unngår vel hacks hvis du kan?

Hvorfor forklarer du ikke teknikken din, men bruker min tekst i ditt eksempel? Dette er tvilsom oppførsel. Hvorfor gjør du det? Hvor er din tekst hen?

Jeg skal gi Lokaltog en mulighet til å beskrive teknikken sin, og til å svare på de spørsmålene han blir stilt. Alternativet er jo at jeg forklarer det istedenfor, men nå skal Lokaltog få vise at han evner det samme. Skal vi si innen mandag?

Frode

Endret 29. mai 2008 av FrodeNilsen

Lokaltog · 29. mai 2008

Du har ikke svart på noen av spørsmålene jeg har stilt deg. Hvorfor det?

Jeg har bedre ting å fylle dagene mine med.

Body er i ditt eksempel containing element, slik at du ikke trenger "wrap". "wrap" elementet ditt spiller kun rollen som vomfyll, og er ikke noe containing element. Det pakker ikke inn noe som helst, så det er helt legitimt å argumentere for at rollenavnet er feil.

Man kan sikkert bruke body-elementet som en wrapper for alle kolonnene, men hvis man ikke ønsker 100% bredde på layouten vil jeg anta at det introduserer en del bugs hvis man f.eks. setter body{width:50%} og html{background:url(...)} i CSS-en. Du bruker selv et wrapper-element som gjør nøyaktig det samme som i mitt kodeeksempel, så jeg synes det er litt spesielt å klage på dette i mitt kodeeksempel.

Hvis du hadde formatert det til ett containing element, så ville det ikke vært legetimt å argumentere slik, for da hadde dette elementet spilt en helt annen rolle. Hvis. Hvor definerer man en slik rolle?

Jeg forstår ikke spørsmålet ditt engang. Du får sitere noen spesifikasjoner så jeg får med meg hva du mener.

Du har også ett hack i koden din. Dette dreier seg om å få "wrap" elementet ditt til å skalere i henhold til sitt innhold. Det er slikt du aldri behøver med nøstende floats. Du burde ha bein i nesen til å forklare at dette er ett hack, og hvorfor det må benyttes. Hvorfor bruker du det her, når det ikke trengs? Du unngår vel hacks hvis du kan?

La oss først definere hva et "hack" er. Jeg ser ikke på koden min som en CSS-hack, da jeg verken bruker ugyldige egenskaper eller retter koden mot spesielle nettlesere. IE viser tilfeldigvis innholdet riktig uten å cleare de siste flytende elementene (og trenger derfor ikke det ekstra elementet som legges inn vha :after), mens andre nettlesere krever denne ekstra egenskapen for å unngå å måtte bruke et tomt element for å cleare i bunnen av HTML-koden. Hvis IE hadde støttet :after, ville ikke dette på noen måte ødelagt layouten i denne nettleseren. Det er en helt gyldig måte å bruke CSS på, og det er mange andre tilfeller der man må ty til tilsvarende teknikker for å oppnå det man ønsker - nemlig at en nettside ser så lik ut som mulig i de mest populære nettleserne.

Hvorfor forklarer du ikke teknikken din, men bruker min tekst i ditt eksempel? Dette er tvilsom oppførsel. Hvorfor gjør du det? Hvor er din tekst hen?

Poenget mitt var ikke å forfatte ti nye avsnitt med meningsløs fylltekst, men å demonstrere hvordan man kan kutte ned mengden CSS og markup - i tillegg til å øke fleksibiliteten til en layout. Jeg ønsket å komme med et alternativ til ditt forslag som et innspill i denne diskusjonen, for å vise at det er flere måter å gjøre ting på.

FrodeNilsen · 29. mai 2008

Ingen eksempler med forklaring, ei heller en forklaring på hva du mener er galt med nøstende floats? Det sier jo sitt.

Du har forresten ikke kontroll på bredden på kolonnne dine. Helt utrolig, da det var akkurat dette du hånet med mitt forslag, som ikke har det problemet! Problemet har du da du ikke benytter heltall for prosent angivning, og at du ikke benytter relativ padding men fast størrelse i px. I din iver etter å vise at det går ann å benytte prosent til bredde angivelse så har du oppnådd å miste kontrollen. Hva var det du kalte det? Nice?

Det er teknikken din som er fundamentalt gal, og måten du korrigerer den på. Hvis det siste elementet ikke flyter, så slipper du dette "hacke" tullet. Du setter med andre ord ikke den siste raden til float:left men float:none.

Hvis det er noen her som ønsker en forklaring på teknikken Lokaltog forsøker å benytte, den kalles ofte for containing floats, så kan jeg gi det. Bare si ifra. Dette er en vanskelig teknikk å mestre, og du må forstå hva både containing block er, og hvordan floats fungerer. Du må også forstå problemene assosiert med å oppgi bredde i %. Du kan jo bare ta en titt på Lokaltog sitt eksempel i IE og i Opera så ser du jo hva jeg mener.

For ordens skyld så får jeg vel nevne at med nøstende floats så må du opprette en div som flyter. Ikke helt god programeringsskikk å gi "body" egengskapen "float:left". Jeg må med andre ord sett inn ett element som flyter, slik at alle andre elementer som er under dette er nøstende flytende elementer. I mitt eksempel spiller altså det ytterste div elementet derfor en container rolle. Du kan jo forsøke å regne ut høyden på body elementet i mitt eksempel. Hint: det har kun flytende innhold. Hint nr. 2: Border.

Du kan endre formateringsrollen til ett layout element helt i CSS. De forskjellige layout teknikkene gir totalt forskjellige roller til elementene, sett fra ett formaterings synspunkt. Du kan ikke lese layout formatering ut av html, den må leses ut av CSS.

Frode

Arve Systad · 30. mai 2008

Du kan ikke lese layout formatering ut av html, den må leses ut av CSS.

Pirkpirk - du kan ikkje lese layoutformatering av HTML eller CSS aleine, du må ha begge to for å kunne seie noko sikkert om layouten.

FrodeNilsen · 30. mai 2008

Du kan ikke lese layout formatering ut av html, den må leses ut av CSS.

Pirkpirk - du kan ikkje lese layoutformatering av HTML eller CSS aleine, du må ha begge to for å kunne seie noko sikkert om layouten.

Tja, dette var vel ikke altfor pirkete. CSS og HTML er i praksis uløselig knyttet sammen. Ett stilark forutsetter jo en bestemt struktur som det skal formatere, særlig når det kommer til layout.

Det er snarere slik at det ikke er så enkelt å lage generisk formatering av layout, da layout i sin natur er vanskelig å "standarisere". Det er vel heller ikke ønskelig å "standarisere" layout. Poenget er mer at man lærer seg teknikkene som er tilgjengelig for layout formatering, som contaning floats, nesting floats, table, absolute positioning, inline-block, og columns(CSS3).

Poenget mitt er mer at du kan benytte forskjellige teknikker i CSS på samme markup struktur og oppnå totalt forskjellig resultat. Det er ikke nødvendig å gi elementer klasser som "wrap", "container", "inner_wrap", "inner_inner_container", osv. Du trenger kun gi elementer klasser hvis du ikke kan identifisere elementer uten klasser. Bruk heller selectors, da dette vil gi deg mer kontroll over det du driver på med. Det er jo tross alt lov å kommentere i CSS hvis det er behov for dette.

Dette har jeg argumentert for i andre tråder, og sånn før denne tråden også eksploderer i en tullete off topic krangel, les heller hyggelige motargumenter her:

https://www.diskusjon.no/index.php?session=...&p=11241738

https://www.diskusjon.no/index.php?session=...&p=11247795

Frode

Haraldson · 30. mai 2008

Tja, dette var vel ikke altfor pirkete. CSS og HTML er i praksis uløselig knyttet sammen. Ett stilark forutsetter jo en bestemt struktur som det skal formatere, særlig når det kommer til layout.

Ergo kan vi vel konkludere med at de ikke er uløselig knyttet sammen, men at CSS baserer seg på HTML, men at HTML ikke nødvendigvis fordrer bruk av (egendefinert) CSS?

Det er snarere slik at det ikke er så enkelt å lage generisk formatering av layout, da layout i sin natur er vanskelig å "standarisere". Det er vel heller ikke ønskelig å "standarisere" layout. Poenget er mer at man lærer seg teknikkene som er tilgjengelig for layout formatering, som contaning floats, nesting floats, table, absolute positioning, inline-block, og columns(CSS3).

Problemet for meg oppstår når du (slik jeg har forstått dine eksempler og innlegg her på forumet hittil) prøver å lage én generisk layout som du kan bruke alle disse teknikkene på i forskjellige tilfeller. Det vil i de aller fleste tilfeller ikke ha en positiv effekt på markupen, og skal en gå fra layout A til B er det ofte like logisk å redefinere også HTML.

Poenget mitt er mer at du kan benytte forskjellige teknikker i CSS på samme markup struktur og oppnå totalt forskjellig resultat. Det er ikke nødvendig å gi elementer klasser som "wrap", "container", "inner_wrap", "inner_inner_container", osv. Du trenger kun gi elementer klasser hvis du ikke kan identifisere elementer uten klasser. Bruk heller selectors, da dette vil gi deg mer kontroll over det du driver på med. Det er jo tross alt lov å kommentere i CSS hvis det er behov for dette.

Her er du inkonsekvent i ordbruken. En klasse eller en ID kan også brukes i en selektor, på samme måte som mer avanserte attributt-, barneselektorer osv. som navnet tilsier også kan brukes i selektorer i CSS. En kan fint kombinere mer konvensjonelle selektorer med disse.

Som nevnt tidligere, gir 'håndtak' i markupen, som ID-er og klasser representerer, deg mange flere muligheter. Ikke nok med de nevnte, åpenbare tingene som å tilrettelegge for DOM-manipulering med JS, men også mulighetene du får til å overstyre CSS. Verdien en selektor har overstyrer til og med stilarkets interne rekkefølge, noe som i mange tilfeller er veldig nyttig. Med få eller ingen håndtak gjøres overstyring ekstremt vanskelig, og en kan risikere å gå tom for passende elementselektorer for elementer dypt nede i strukturen.

Overstyring er jo nettopp et veldig godt eksempel noe du har behov for når du gjør rammeverkene dine så generiske. Du kan lage en generell regel for hvordan et gitt element skal se ut, men overstyre dette når en klasse er tilstede.

FrodeNilsen · 30. mai 2008

Denne tråden er i ferd med å avspores. Prøv å pense tilbake til relevans for layout teknikker.

Jeg orker ikke svare på dette tullet, selv om det er faglig enkelt. Jeg har sagt det jeg mener om klasse og ID bruk. Kan vi la dette ligge nå? Eller skal jeg få ett motsvar, for n-te gang som forsøker å plukke fra hverandre alt jeg sier? Jeg lurer på når enkelte skal forstå at de ikke har faglige tunge nok argumenter og faglig god nok forståelse av hva jeg mener til å overbevise meg om at menigene mine er feil?

Noen som har innspill om layout teknikker?

Alle her forstod eksemplet med nøstende floats? Alle her forstod invendingene jeg hadde til Lokaltog sin kode? Alle her kan contaning floats? Alle her behersker tabell formatering i CSS? Alle her behersker inline-block? Hva med columns?

Jeg skal forsøke å gi vennlige svar hvis noen har noe de lurer på, så lenge motparten er vennlig. Forhåpentligvis så får vi tettet huller i vår kunnskap eller vi får en rikere horisont. Så får vi bare håpe at vi blir behandlet vennlig av resten her også, men hvor trolig er det?

Frode

to div-tagger ved siden av hverandre

Anbefalte innlegg

Lenke til kommentar

Videoannonse

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Opprett konto

Logg inn

Populær nå

Hvem er aktive 0 medlemmer