Oprettet søn. d. 02. september 2012 kl. 23:56:04
20 point uddelt | 19 kommentarer
2 Linjer tekst ud for at input felt..?
Hej...Er der nogen der kan hjælpe mig med at gennemskue, hvorledes får 2 linjer til at stå ud for et input felt..
Ligesom han gør på denne Her
På forhånd tak for hjælpen!
Skrevet man. d. 03. september 2012 kl. 05:39:14| #1
Afvist svar
Christian_Belgien (50.883 point)
Det eksempel du viser anvender en <label> med en <span>:
<form id="form1" id="form1" action="mail.php" method="POST">
<label>Name
<span class="small">Add your name</span>
</label>
<input type="text" name="name">
<label>Email
<span class="small">Enter a Valid Email</span>
</label>
<input type="text" name="email">
o.s.v.
<form id="form1" id="form1" action="mail.php" method="POST">
<label>Name
<span class="small">Add your name</span>
</label>
<input type="text" name="name">
<label>Email
<span class="small">Enter a Valid Email</span>
</label>
<input type="text" name="email">
o.s.v.
Skrevet man. d. 03. september 2012 kl. 14:19:30| #2
olebole (216.743 point)
<ole>
Det viste eksempel er et af de utallige float-abuses. Prøv flg. kode i stedet:
- som ydermere benytter sig af LABEL elementets feature, vedr. at flytte fokus til feltet, når der klikkes på teksten
/mvh
</bole>
Det viste eksempel er et af de utallige float-abuses. Prøv flg. kode i stedet:
<style type="text/css">
body {
margin: 0;
padding: 0;
font: 13px "Segoe UI", Tahoma, sans-serif;
}
label {
position: relative;
display: block;
width: 250px;
margin: 4px 0 2px;
}
input {
position: absolute;
right: 0;
top: 0;
}
label span {
font-weight: bold;
}
label div {
margin-top: -2px;
font-size: 0.8em;
color: #999;
}
</style>
<label><span>blablabla</span><div>Og noget</div><input type="text"></label>
<label><span>blabla</span><div>Og noget andet</div><input type="text"></label>
<label><span>blablablabla</span><div>Og noget tredie</div><input type="text"></label>
<label><span>bla</span><div>Og noget fjerde</div><input type="text"></label>
<label><span>blablabla</span><div>Og noget femte</div><input type="text"></label>
body {
margin: 0;
padding: 0;
font: 13px "Segoe UI", Tahoma, sans-serif;
}
label {
position: relative;
display: block;
width: 250px;
margin: 4px 0 2px;
}
input {
position: absolute;
right: 0;
top: 0;
}
label span {
font-weight: bold;
}
label div {
margin-top: -2px;
font-size: 0.8em;
color: #999;
}
</style>
<label><span>blablabla</span><div>Og noget</div><input type="text"></label>
<label><span>blabla</span><div>Og noget andet</div><input type="text"></label>
<label><span>blablablabla</span><div>Og noget tredie</div><input type="text"></label>
<label><span>bla</span><div>Og noget fjerde</div><input type="text"></label>
<label><span>blablabla</span><div>Og noget femte</div><input type="text"></label>
- som ydermere benytter sig af LABEL elementets feature, vedr. at flytte fokus til feltet, når der klikkes på teksten
/mvh
</bole>
Skrevet man. d. 03. september 2012 kl. 21:53:39| #3
Hej..
Tak olebole... lige det jeg søgte :-)
Vil jo gerne lige være med i, hvad det er der sker...
Er det de -2px i margin-top der gør underværkerne for "og noget andet.." osv.
Tak olebole... lige det jeg søgte :-)
Vil jo gerne lige være med i, hvad det er der sker...
Er det de -2px i margin-top der gør underværkerne for "og noget andet.." osv.
Skrevet man. d. 03. september 2012 kl. 21:55:08| #4
Hej igen...
Hov.. den smuttede ;-) Du skal da selvfølgelig havde noget for hjælpen.. smid et svar olebole.
Hov.. den smuttede ;-) Du skal da selvfølgelig havde noget for hjælpen.. smid et svar olebole.
Skrevet man. d. 03. september 2012 kl. 23:02:28| #5
olebole (216.743 point)
Den lille negative margin-top flytter bare underteksten en smule op. Der er bare tale om en smule 'læbestift' =)
En lille forklaring: Et absolut positioneret element, vil med dets top, right, bottom og left værdier placere sig i forhold til første, omkransende element, som er positioneret (relative, absolute eller fixed).
Findes et sådan ikke, placerer det sig i forhold til BODY elementet.
Jeg giver LABEL elementet en fast width - gør det til et block element - og positionerer det relative.
Inden i lægger jeg et absolut positioneret INPUT, som jeg lægger helt i top og helt til højre i LABEL elementet.
Teksten i LABEL elementet efterfølges af et DIV, som vil lægge sig på en ny linje (DIV er et block element).
Absolut positionerede elementer fylder ligesom float'ede elementer ikke noget. Den fri tekst og DIV'et er det eneste, der 'spænder' LABEL elementet ud i højden. Uden disse ville LABEL elementet klaske sammen. Derfor vil margin på INPUT elementet f.eks. ikke indvirke på LABEL elementets højde.
LABEL elementerne får sig også lidt top- og bundmargin ... to separate head from butt =)
Jeg samler som bekendt ikke point - ellers tak =)
En lille forklaring: Et absolut positioneret element, vil med dets top, right, bottom og left værdier placere sig i forhold til første, omkransende element, som er positioneret (relative, absolute eller fixed).
Findes et sådan ikke, placerer det sig i forhold til BODY elementet.
Jeg giver LABEL elementet en fast width - gør det til et block element - og positionerer det relative.
Inden i lægger jeg et absolut positioneret INPUT, som jeg lægger helt i top og helt til højre i LABEL elementet.
Teksten i LABEL elementet efterfølges af et DIV, som vil lægge sig på en ny linje (DIV er et block element).
Absolut positionerede elementer fylder ligesom float'ede elementer ikke noget. Den fri tekst og DIV'et er det eneste, der 'spænder' LABEL elementet ud i højden. Uden disse ville LABEL elementet klaske sammen. Derfor vil margin på INPUT elementet f.eks. ikke indvirke på LABEL elementets højde.
LABEL elementerne får sig også lidt top- og bundmargin ... to separate head from butt =)
Jeg samler som bekendt ikke point - ellers tak =)
Skrevet man. d. 03. september 2012 kl. 23:28:01| #6
olebole (216.743 point)
Med "den fri tekst" mente jeg teksten i SPAN'et =)
Der er fordele og ulemper ved alle koder, og en ulempe ved ovenstående kunne være den manglende dynamik, hvad angår tekstlængden (p.gr.a. LABEL elementets faste bredde).
Personligt bruger jeg selv ofte en tabel som det naturlige element, når jeg skal stille en formular op. Så må Tabelpolitiet gerne jagte mig med himmelvendte øjne og kanonslag i turbanen =)
I min verden består enhver formular af synkrone søjler og rækker - og hvad handler tabuleret opstilling ellers om? *o)
Ser du en kode som den følgende ude på nettet, kunne den derfor sagtens skyldes min ugudelige og politisk ukorrekte adfærd:
Der er fordele og ulemper ved alle koder, og en ulempe ved ovenstående kunne være den manglende dynamik, hvad angår tekstlængden (p.gr.a. LABEL elementets faste bredde).
Personligt bruger jeg selv ofte en tabel som det naturlige element, når jeg skal stille en formular op. Så må Tabelpolitiet gerne jagte mig med himmelvendte øjne og kanonslag i turbanen =)
I min verden består enhver formular af synkrone søjler og rækker - og hvad handler tabuleret opstilling ellers om? *o)
Ser du en kode som den følgende ude på nettet, kunne den derfor sagtens skyldes min ugudelige og politisk ukorrekte adfærd:
<style type="text/css">
body {
margin: 0;
padding: 0;
font: 13px "Segoe UI", Tahoma, sans-serif;
}
table {
border-collapse: collapse;
}
td {
padding: 3px 10px 2px;
}
label {
display: block;
font-weight: bold;
}
label div {
margin-top: -2px;
font-size: 0.8em;
font-weight: normal;
color: #999;
}
</style>
<table>
<tbody>
<tr>
<td><label for="inp_1">blablabla<div>Og noget</div></label></td>
<td><input id="inp_1" type="text"></td>
</tr>
<tr>
<td><label for="inp_2">blabla<div>Og noget andet</div></label></td>
<td><input id="inp_2" type="text"></td>
</tr>
<tr>
<td><label for="inp_3">blablablabla<div>Og noget tredie</div></label></td>
<td><input id="inp_3" type="text"></td>
</tr>
<tr>
<td><label for="inp_4">bla<div>Og noget fjerde</div></label></td>
<td><input id="inp_4" type="text"></td>
</tr>
<tr>
<td><label for="inp_5">blablabla<div>Og noget femte</div></label></td>
<td><input id="inp_5" type="text"></td>
</tr>
</tbody>
</table>
body {
margin: 0;
padding: 0;
font: 13px "Segoe UI", Tahoma, sans-serif;
}
table {
border-collapse: collapse;
}
td {
padding: 3px 10px 2px;
}
label {
display: block;
font-weight: bold;
}
label div {
margin-top: -2px;
font-size: 0.8em;
font-weight: normal;
color: #999;
}
</style>
<table>
<tbody>
<tr>
<td><label for="inp_1">blablabla<div>Og noget</div></label></td>
<td><input id="inp_1" type="text"></td>
</tr>
<tr>
<td><label for="inp_2">blabla<div>Og noget andet</div></label></td>
<td><input id="inp_2" type="text"></td>
</tr>
<tr>
<td><label for="inp_3">blablablabla<div>Og noget tredie</div></label></td>
<td><input id="inp_3" type="text"></td>
</tr>
<tr>
<td><label for="inp_4">bla<div>Og noget fjerde</div></label></td>
<td><input id="inp_4" type="text"></td>
</tr>
<tr>
<td><label for="inp_5">blablabla<div>Og noget femte</div></label></td>
<td><input id="inp_5" type="text"></td>
</tr>
</tbody>
</table>
Skrevet man. d. 03. september 2012 kl. 23:33:58| #7
olebole (216.743 point)
Sorry, den holder ikke. Et inline element må ikke indeholde et block element.
Selvom LABEL (født som inline) elementet gøres til et block element med CSS, må det ved load ikke indeholde et DIV. Reglen skal overholdes af hensyn til HTML-parseren, og hvad den skal forvente at møde. Løsningen er at 'hækle den anden vej':
Valid HTML, og vi opnår det samme *o)
Selvom LABEL (født som inline) elementet gøres til et block element med CSS, må det ved load ikke indeholde et DIV. Reglen skal overholdes af hensyn til HTML-parseren, og hvad den skal forvente at møde. Løsningen er at 'hækle den anden vej':
<style type="text/css">
body {
margin: 0;
padding: 0;
font: 13px "Segoe UI", Tahoma, sans-serif;
}
table {
border-collapse: collapse;
}
td {
padding: 3px 10px 2px;
}
label {
display: block;
font-weight: bold;
}
label span {
display: block;
margin-top: -2px;
font-size: 0.8em;
font-weight: normal;
color: #999;
}
</style>
<table>
<tbody>
<tr>
<td><label for="inp_1">blablabla<span>Og noget</span></label></td>
<td><input id="inp_1" type="text"></td>
</tr>
<tr>
<td><label for="inp_2">blabla<span>Og noget andet</span></label></td>
<td><input id="inp_2" type="text"></td>
</tr>
<tr>
<td><label for="inp_3">blablablabla<span>Og noget tredie</span></label></td>
<td><input id="inp_3" type="text"></td>
</tr>
<tr>
<td><label for="inp_4">bla<span>Og noget fjerde</span></label></td>
<td><input id="inp_4" type="text"></td>
</tr>
<tr>
<td><label for="inp_5">blablabla<span>Og noget femte</span></label></td>
<td><input id="inp_5" type="text"></td>
</tr>
</tbody>
</table>
body {
margin: 0;
padding: 0;
font: 13px "Segoe UI", Tahoma, sans-serif;
}
table {
border-collapse: collapse;
}
td {
padding: 3px 10px 2px;
}
label {
display: block;
font-weight: bold;
}
label span {
display: block;
margin-top: -2px;
font-size: 0.8em;
font-weight: normal;
color: #999;
}
</style>
<table>
<tbody>
<tr>
<td><label for="inp_1">blablabla<span>Og noget</span></label></td>
<td><input id="inp_1" type="text"></td>
</tr>
<tr>
<td><label for="inp_2">blabla<span>Og noget andet</span></label></td>
<td><input id="inp_2" type="text"></td>
</tr>
<tr>
<td><label for="inp_3">blablablabla<span>Og noget tredie</span></label></td>
<td><input id="inp_3" type="text"></td>
</tr>
<tr>
<td><label for="inp_4">bla<span>Og noget fjerde</span></label></td>
<td><input id="inp_4" type="text"></td>
</tr>
<tr>
<td><label for="inp_5">blablabla<span>Og noget femte</span></label></td>
<td><input id="inp_5" type="text"></td>
</tr>
</tbody>
</table>
Valid HTML, og vi opnår det samme *o)
Skrevet man. d. 03. september 2012 kl. 23:39:36| #8
olebole (216.743 point)
td {
padding: 3px 10px 2px;
vertical-align: top;
}
padding: 3px 10px 2px;
vertical-align: top;
}
- hvis du har et højt element (TEXTAREA) i en højre celle. Ellers vil teksten blive vertikalt midterstillet udfor elementet
Skrevet tir. d. 04. september 2012 kl. 00:41:53| #9
Hej...
Tak.. for forklaringen. Altid rart med nogen der ved, hvad de har med at gøre :-)
Årrrh... Olebole... Jeg er ik så glad for det table værk, må squ erkende at jeg aldrig har sat mig ind i det.. Det krydsede dog min vej i forbindelse med "Det gratise" .. CMS CMSimple.. Siden har jeg squ ik brugt det.
Okay.. så snupper jeg selv pointene, da anden svare bare gav mig Vis Kilde koden. og den havde jeg jo selv set.
Tak.. for forklaringen. Altid rart med nogen der ved, hvad de har med at gøre :-)
Årrrh... Olebole... Jeg er ik så glad for det table værk, må squ erkende at jeg aldrig har sat mig ind i det.. Det krydsede dog min vej i forbindelse med "Det gratise" .. CMS CMSimple.. Siden har jeg squ ik brugt det.
Okay.. så snupper jeg selv pointene, da anden svare bare gav mig Vis Kilde koden. og den havde jeg jo selv set.
Skrevet tir. d. 04. september 2012 kl. 00:42:37| #10
Accepteret svar!20 point tildelt
Skrevet tir. d. 04. september 2012 kl. 01:56:43| #11
olebole (216.743 point)
Du vælger selv, hvad du bedst kan lide =)
Skrevet tir. d. 04. september 2012 kl. 22:04:26| #12
Hej..
Jow!!.. Men kan koden i #2 evt.. fikses, så dette famøse Label element... beholder sin inline status udadtil, men får status af et block element indadtil.. Så er div'en vel lovlig??
Eller drømmer jeg bare ??
Jow!!.. Men kan koden i #2 evt.. fikses, så dette famøse Label element... beholder sin inline status udadtil, men får status af et block element indadtil.. Så er div'en vel lovlig??
Eller drømmer jeg bare ??
Skrevet tir. d. 04. september 2012 kl. 22:15:42| #13
olebole (216.743 point)
Ja, det gør du - men jeg kan godt sætte mig ind i dit drømmeunivers =)
#7: "Selvom LABEL (født som inline) elementet gøres til et block element med CSS, må det ved load ikke indeholde et DIV. Reglen skal overholdes af hensyn til HTML-parseren, og hvad den skal forvente at møde."
Af hensyn til HTML-parseren må man ikke. Den er for så vidt ligeglad med CSS. Den parser i første omgang bare HTML'en og forventer ikke at møde et DIV i et LABEL element.
Når siden først er loaded, må du gerne indsætte et DIV i et LABEL element, som har fået display:block eller inline-block. Men det er noget andet, for her skal HTML-parseren ikke parse en HTML-kode *o)
#7: "Selvom LABEL (født som inline) elementet gøres til et block element med CSS, må det ved load ikke indeholde et DIV. Reglen skal overholdes af hensyn til HTML-parseren, og hvad den skal forvente at møde."
Af hensyn til HTML-parseren må man ikke. Den er for så vidt ligeglad med CSS. Den parser i første omgang bare HTML'en og forventer ikke at møde et DIV i et LABEL element.
Når siden først er loaded, må du gerne indsætte et DIV i et LABEL element, som har fået display:block eller inline-block. Men det er noget andet, for her skal HTML-parseren ikke parse en HTML-kode *o)
Skrevet tir. d. 04. september 2012 kl. 22:57:32| #14
Hej..
Jamen jamen... så er der måske alligevel en fortaler for den Abuse .. af float i linket i #0 ... Eller er det derfor table endnu ikke har fået det endelige dødsstød fra W3C ...
Nå men jeg hæfter mig ved denne :
"Når siden først er loaded, må du gerne indsætte et DIV i et LABEL element, som har fået display:block eller inline-block. Men det er noget andet, for her skal HTML-parseren ikke parse en HTML-kode "
Men så skal man måske over i noget javascript , hvis man skal indsætte dette div i en label og tildele den en CSS egenskab efter siden er loadet.
Jamen jamen... så er der måske alligevel en fortaler for den Abuse .. af float i linket i #0 ... Eller er det derfor table endnu ikke har fået det endelige dødsstød fra W3C ...
Nå men jeg hæfter mig ved denne :
"Når siden først er loaded, må du gerne indsætte et DIV i et LABEL element, som har fået display:block eller inline-block. Men det er noget andet, for her skal HTML-parseren ikke parse en HTML-kode "
Men så skal man måske over i noget javascript , hvis man skal indsætte dette div i en label og tildele den en CSS egenskab efter siden er loadet.
Skrevet tir. d. 04. september 2012 kl. 23:11:51| #15
olebole (216.743 point)
Der er intet, som nogensinde har peget mod, at TABLE elementet skulle glide ud af HTML. Tværtimod er det jo det langt bedste element at bruge, når noget skal stilles op i 'synkrone' søjler og rækker - og til det formål er det varmt anbefalet af W3C.
*) Tabeller er fremragende til tabulært opstillede data
*) Float er fremragende til at få tekst til at flyde omkring f.eks. et billede
*) Inline-block er fremragende til at lægge block elementer ved siden af hinanden
Det handler bare om at bruge elementer og features til det, de er gode til =)
Nej, JavaScript bør såvidt muligt forbeholdes funktionalitet - mens layout bør løses med HTML og CSS. Jeg forstår ikke, hvad du har i mod løsningen i #7. Den er lavet i helt valid og logisk HTML/CSS
*) Tabeller er fremragende til tabulært opstillede data
*) Float er fremragende til at få tekst til at flyde omkring f.eks. et billede
*) Inline-block er fremragende til at lægge block elementer ved siden af hinanden
Det handler bare om at bruge elementer og features til det, de er gode til =)
Nej, JavaScript bør såvidt muligt forbeholdes funktionalitet - mens layout bør løses med HTML og CSS. Jeg forstår ikke, hvad du har i mod løsningen i #7. Den er lavet i helt valid og logisk HTML/CSS
Skrevet tir. d. 04. september 2012 kl. 23:31:54| #16
Hej...
Nej... men havde bare en ide om at holde mig så vidt muligt fra tables.. Men som sagt rart med lidt overbevisning, det lærer man jo også af..
Jeg kigger på #7 og så tak for din hjælp Ole :-)
Nej... men havde bare en ide om at holde mig så vidt muligt fra tables.. Men som sagt rart med lidt overbevisning, det lærer man jo også af..
Jeg kigger på #7 og så tak for din hjælp Ole :-)
Skrevet ons. d. 05. september 2012 kl. 00:10:55| #17
olebole (216.743 point)
Selvtak. HTML var oprindelig tænkt som et tabel- og paragrafværk, som videnskabsfolk let kunne opstille videnskabelige måleresultater i og dele med hinanden.
Efter ret kort tid fandt kreative potheads i Californien ud af at bruge tabeller (og tabeller i tabeller i tabeller i ...) som blev spilet ud som ønsket af transparente giffer med width og height. På den måde kunne man med en 'kedelig' lige-op-og-ned teknologi pludselig lave spændende grafiske sider med elementerne spredt ud over hele siden.
Microsoft kom på banen med CSS og det ret nydannede W3C adopterede idéen. Efter Netscape droppede deres JSSS (JavaScript StyleSheets) og indså de enorme muligheder i CSS var teknologiens success sikret.
Da de gigantiske nestede tabelhelveder med hundredevis af transparente giffer af indlysende grunde ikke var hensigtsmæssige, gik W3C på et tidspunkt ud og advarede mod brug af tabeller til generelle layoutformål. I stedet anbefalede man at bruge CSS til at placere 'anonyme' container elementer som SPAN og DIV med.
Det blev til en af de sværeste misforståelser at få udryddet. At anvende en tabel til et fornuftigt formål blev efterhånden sidestillet med gruppevoldtægt af små lodne egernbørn! Der bredte sig en til tider komisk tabel'o'fobi, som blev spredt gennem 'Pixi' artikler og tutorials af folk, som komplet havde misforstået budskabet - som regel ved at læse 'Pixi' artikler af folk, som komplet havde misforstået budskabet.
Desværre læres det meste frontend kode fra den slags 'Pixi' artikler, som citerer og bekræfter hinanden i ring, hvorfor de afledte misforståelser bliver enormt svære at udrydde. Og det sker næsten hvergang en ny teknik dukker op. De fleste gider ikke bruge tiden på at sætte sig ind i tingene, men foretrækker en hurtig, misforstået og ofte fejlfyldt forklaring.
Når data skal opstilles i 'synkrone' rækker og søjler, så kan du roligt bruge en tabel og være sikker på, du bruger det bedste element til formålet *o)
Efter ret kort tid fandt kreative potheads i Californien ud af at bruge tabeller (og tabeller i tabeller i tabeller i ...) som blev spilet ud som ønsket af transparente giffer med width og height. På den måde kunne man med en 'kedelig' lige-op-og-ned teknologi pludselig lave spændende grafiske sider med elementerne spredt ud over hele siden.
Microsoft kom på banen med CSS og det ret nydannede W3C adopterede idéen. Efter Netscape droppede deres JSSS (JavaScript StyleSheets) og indså de enorme muligheder i CSS var teknologiens success sikret.
Da de gigantiske nestede tabelhelveder med hundredevis af transparente giffer af indlysende grunde ikke var hensigtsmæssige, gik W3C på et tidspunkt ud og advarede mod brug af tabeller til generelle layoutformål. I stedet anbefalede man at bruge CSS til at placere 'anonyme' container elementer som SPAN og DIV med.
Det blev til en af de sværeste misforståelser at få udryddet. At anvende en tabel til et fornuftigt formål blev efterhånden sidestillet med gruppevoldtægt af små lodne egernbørn! Der bredte sig en til tider komisk tabel'o'fobi, som blev spredt gennem 'Pixi' artikler og tutorials af folk, som komplet havde misforstået budskabet - som regel ved at læse 'Pixi' artikler af folk, som komplet havde misforstået budskabet.
Desværre læres det meste frontend kode fra den slags 'Pixi' artikler, som citerer og bekræfter hinanden i ring, hvorfor de afledte misforståelser bliver enormt svære at udrydde. Og det sker næsten hvergang en ny teknik dukker op. De fleste gider ikke bruge tiden på at sætte sig ind i tingene, men foretrækker en hurtig, misforstået og ofte fejlfyldt forklaring.
Når data skal opstilles i 'synkrone' rækker og søjler, så kan du roligt bruge en tabel og være sikker på, du bruger det bedste element til formålet *o)
Skrevet ons. d. 05. september 2012 kl. 00:23:08| #18
Hej..
Tak for lektionen... Mester olebole.. "Smiler"
Table it is :-)
Tak for lektionen... Mester olebole.. "Smiler"
Table it is :-)
Skrevet ons. d. 05. september 2012 kl. 00:40:14| #19
olebole (216.743 point)
PS: Det vigtige er synkrone rækker og søjler. De ting/data, der vises skal hænge sammen i både rækker og søjler - ligesom et Excel ark. Så er data også stillet logisk op for andre klienter, som skal tilgå koden - f.eks. en blind eller svagtseendes tekstoplæser.
Et trefløjet layout med en menu i venstre side, et indholdsfelt i midten og en høj linkkasse ude til højre er derimod ikke et eksempel på synkrone rækker og søjler. Det er en oplagt bejler til tre elementer med display:inline-block;vertical-align:top.
Både #7 og tabelversionen er mærket op, så en tekstlæser naturligt kan finde rundt. Jeg har til gengæld også set formularopmærkninger, som desparat har undgået tabeller, men som kan få enhver blind til at skvatte rundtosset ned af stolen
Et trefløjet layout med en menu i venstre side, et indholdsfelt i midten og en høj linkkasse ude til højre er derimod ikke et eksempel på synkrone rækker og søjler. Det er en oplagt bejler til tre elementer med display:inline-block;vertical-align:top.
Både #7 og tabelversionen er mærket op, så en tekstlæser naturligt kan finde rundt. Jeg har til gengæld også set formularopmærkninger, som desparat har undgået tabeller, men som kan få enhver blind til at skvatte rundtosset ned af stolen
Log ind
Seneste spørgsmål
List style ved linjeskift
Oprettet den 19. maj 2013 kl. 23.57
sarcar giver 60 point for svar | Giv et svar »
Fat footer skal fylde hele sidens bredde
Oprettet den 17. maj 2013 kl. 14.42
13thsky giver 60 point for svar | Giv et svar »
Seneste guides
Seneste nyheder
Tips & Tricks fra PC World
Fem smarte funktioner i din Mac som du sikkert ikke kender
Her har du fem muligheder for at tweake din Mac på en fed måde.
Anmeldelser fra PC World
Test: Samsung Galaxy S4 er et hit - trods gøglertricks
Kan Samsung beholde førertrøjen i det store Android-race? Galaxy S4 er smækfyldt med innovative funktioner, men også med en del gøgl. Er det for meget? Få vores dom over Samsungs nye topmodel.
Seneste blogindlæg
Tvangslukke spørgsmål: Hvad er den bedste løsning?
Hej Vi har mange åbne spørgsmål på Eksperten. Vi ville gerne tvangslukke dem - så et spørgsmål efter f.eks. 6 måneder lukkes. Men der er et par uklarheder som ville være gode at få lidt input til:...
Nyheder fra PC World
Ny opfindelse: Oplad din mobil på 20 sekunder
Måske er det snart slut med at lade mobilen op hver aften. Med ny opfindelse kan telefonen få fuld energi på sølle 20 sekunder.
Nyheder fra Computerworld
Galleri: De 10 vildeste datacentre i verden
I en gammel kirke, i et oppusteligt telt, på nedlagte militæranlæg eller midt i ørkenen. Der er ingen grænser for, hvor man kan banke et datacenter op. Her er de 10 sejeste anlæg i verden. I...
IT Kurser
Samarbejdspartnere
Udgiver · © 2013 IDG Danmark A/S · Hørkær 18 · 2730 Herlev · Tlf.: 77 300 300 · Fax: 77 300 301 · Brug af personoplysninger