2 Linjer tekst ud for at input felt..?

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.

<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>

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.

Hej igen...

Hov.. den smuttede ;-) Du skal da selvfølgelig havde noget for hjælpen.. smid et svar olebole.

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  =)

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:

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)

- hvis du har et højt element (TEXTAREA) i en højre celle. Ellers vil teksten blive vertikalt midterstillet udfor elementet

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.

.

Du vælger selv, hvad du bedst kan lide  =)

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 ??

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)

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.

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

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 :-)

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)

Hej..

Tak for lektionen...  Mester olebole.. "Smiler"

Table it is :-)

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